6 ms·

Nope, this is Oracle stop caring about Java EE. They are not doing this for Java SE as long as they are caring about Java SE. I also doubt IBM still cares abou

Nope, this is Oracle stop caring about Java EE. They are not doing this for Java SE as long as they are caring about Java SE. I also doubt IBM still cares about Java EE. Their last JSR (Batch/JSR-352) was particularly disgusting and seems to be abandoned already.

topspin 9y ago
"JSR (Batch/JSR-352) was particularly disgusting" Good grief. Another mountain of XML programming. It's like the last 10+ years of software engineering never happened. I wonder how many half completed JSR-352 implementations will emerge.
- skocznymroczny 9y ago
  Just replacing XML with JSON doesn't make anything modern.
  - mseebach 9y ago
    No, but replacing "programming-in-configuration-files" (whether those configuration files are XML or JSON or something else) with programming in an actual programming language (see eg Maven -> Gradle) is, IMO.
    - pjmlp 9y ago
      > Maven -> Gradle Given that my Maven builds run circles around the Android Gradle ones, and that it is still a session subject at Google IO, I hardly see that as progress.
    - _pmf_ 9y ago
      I've always thought of Gradle as a slow Maven with a slightly disgusting syntax[0]. [0] No offense to Groovy; I'm only hating on Gradle's usage here
      - Communitivity 9y ago
        We at Communitivity see build ecosystems as being in one of four phases of evolution: * Instructive - Actual low level commands are basically entered in the build file, with some flow control logic. An example is Make. Ant is another, though Ant straddles the line between Instructive and Imperative. In military terms, you dictate individual unit actions. * Imperative - Build commands are entered into the build file, with each command having parameters used to control how it executes. Each build command represents two or more low level commands. There can be some declarative configuration, but the main part of the build is still a program of commands. Examples are Gradle and Rake. In military terms, you dictate individual unit tactics. * Declarative - The build file is now no longer about entering low or high level commands, it is about declaring your intent, i.e. what you want the build to do. Examples are Lein and Maven. In military terms, this is providing units with Commander's Intent and letting the units do what they do best. * Predictive - The build file is declarative, but the build ecosystem tracks developer activities and incorporates AI technologies to predict what the user's intent will be, and to inform the user so they are better able to determine their needs. In military terms this is strategy augmented with a Centaur System (a system with both a human and one or more AI components that work together as one entity). Communitivity, Inc is building Chiron, an Open Source predictive build ecosystem that will be released in 2018. Follow @Communitivity on Twitter for more information in the coming months.
        lovich 9y ago
        Is this from a poorly trained bot?
        Communitivity 9y ago
        Ouch. Well, live and learn. It would be nice though if one or two of those who down-voted me explained why my comment was objectionable, so at least I can avoid a repeat of whatever mistake I made.
        mseebach 9y ago
  - znpy 9y ago
    Someone is finally saying this. Plus, there is a ton of things that json can't do or isn't supposed to do (things like defining a grammar, xpath, xquery, xslt and a lot more)
    - jgalt212 9y ago
      I'd rather write brainfuck for a living than the abomination xslt is.
  - alangibson 9y ago
    Where XML really shines is as an interchange format between the type of mission critical upgraded-once-a-decade systems that are the bread and butter of Big Business IT. I think XML got it's bad rep from people applying it where it's bulk and complexity is just not needed. For instance, storing configuration for an application that you completely control or shuffling around data inside of an application domain that you can change at will.
    - vbezhenar 9y ago
      XML is not a good interchange format, because it doesn't map well to a standard programming structures. There's no array or map in XML. Developers must use OXM libraries (object to xml mapper). JSON is much more direct and simple format. XML is good for anything that looks like document markup.
      - andrewflnr 9y ago
        Sometimes your actual data doesn't map well to "standard programming structures". If that's the case, you really want your interchange format to express reality as far as possible, not how it will be processed in any particular program. I don't have enough experience to be authoritative here, but this seems like a bad argument.
      - mring33621 9y ago
        I will agree that JSON is 'simple' but it is only 'direct' in the context of javascript. For other languages, it is similar to XML in handling overhead. JSON's significant technical problem is a lack of a formal schema definition and enforcement mechanism. You may feel that this is actually an advantage, but I assure you, as someone who has written systems of record for billion dollar businesses, it is not.
- pjc50 9y ago
  Not even that; this is 1970s batch processing rising again.
  - skissane 9y ago
    I believe they are positioning it as a replacement for mainframe batch workloads written in JCL, along with rewriting the associated COBOL code in Java. Run WebSphere for z/OS on the same machine as your existing JCL/COBOL batch workload and then slowly rewrite the COBOL into Java and the JCL into JSR-352 JSL, and IBM has Java APIs for VSAM/IMS/etc so you can still access your existing mainframe data from the new Java code. Even if XML is no longer the hotness it was in the early 2000s it is still an improvement on JCL, and it is easier to rewrite batch-oriented COBOL into batch-oriented Java than to change its batch-oriented nature into something more real time.
  - wiz21c 9y ago
    Not sure of what you mean, but batch processing is still pretty useful. I happen to work on a project which has batch running 10 hours a day, processing complex business cases, calling dozens of web services, etc. This could absolutely not be made in real time. Or maybe you said that 1970's batch were inferior to today's batch. In which case I'd be happy to read what non-superficial differences exist...
  - StevePerkins 9y ago
    I have not reviewed that JSR, so I have no comment on the merits of its implementation. However, it's worth pointing out that MOST tech concepts people regard as "modern" today are actually re-treads of 1970's ideas.
_pmf_ 9y ago
> Nope, this is Oracle stop caring about Java EE. They are not doing this for Java SE as long as they are caring about Java SE. That's strange. How do they make money off SE but not EE? EE has been the cash cow that kept Java alive after applets fell out of favor.
- Delmania 9y ago
  If I remember correctly, Oracle has a licensing scheme if you want to build and release your own JVM. Java SE always has significant more usage in production thanks to Android, Kotlin, Clojure, and Scala. While Java EE does get used a lot in more conservative large enterprises, the alternatives developed to overcome the inherent complexity of EE (Spring, Hibernate) get a LOT more. Java EE is big, but Java SE is even bigger.
  - thedudemabry 9y ago
    Thanks for the explanation. As someone who in a past life developed Java systems (post-2006) for a variety of targets, I was never super clear on what Java EE's value proposition was or how it differed from frameworks that didn't require a separate install. I now gather that it is a collection of helpful packages constituting a framework, but distributed separately from mainline Java core packages.
    - pjmlp 9y ago
      Java EE was also the cloud, before the term was coined. When targeting EE application servers, you don't need to worry at all where it is being executed. As an application, container, bare metal, whatever. Of course this only works ad long as no native methods or APIs for file or process management are used.
- needusername 9y ago
  > EE has been the cash cow that kept Java alive after applets fell out of favor. I have no insight into Oracles reasoning or finances, I can just see their actions. While I assume they make money off WebLogic licenses I can't image that revenue is growing in the double digit range per year. I assume that Oracle as a publicly traded company is forced to produce growth numbers. These days that's could. They probably some imagine to provide some sort of Java could, that would explain why they pushed so hard for Jigsaw. This doesn't really have make sense to you and me, just to Oracle execs.
tannhaeuser 9y ago
> Their last JSR (Batch/JSR-352) was particularly disgusting So a good fit to Websfear then?

topspin 9y ago

"JSR (Batch/JSR-352) was particularly disgusting" Good grief. Another mountain of XML programming. It's like the last 10+ years of software engineering never happened. I wonder how many half completed JSR-352 implementations will emerge.

skocznymroczny 9y ago
Just replacing XML with JSON doesn't make anything modern.
- mseebach 9y ago
  No, but replacing "programming-in-configuration-files" (whether those configuration files are XML or JSON or something else) with programming in an actual programming language (see eg Maven -> Gradle) is, IMO.
  - pjmlp 9y ago
    > Maven -> Gradle Given that my Maven builds run circles around the Android Gradle ones, and that it is still a session subject at Google IO, I hardly see that as progress.
  - _pmf_ 9y ago
    I've always thought of Gradle as a slow Maven with a slightly disgusting syntax[0]. [0] No offense to Groovy; I'm only hating on Gradle's usage here
    - Communitivity 9y ago
      We at Communitivity see build ecosystems as being in one of four phases of evolution: * Instructive - Actual low level commands are basically entered in the build file, with some flow control logic. An example is Make. Ant is another, though Ant straddles the line between Instructive and Imperative. In military terms, you dictate individual unit actions. * Imperative - Build commands are entered into the build file, with each command having parameters used to control how it executes. Each build command represents two or more low level commands. There can be some declarative configuration, but the main part of the build is still a program of commands. Examples are Gradle and Rake. In military terms, you dictate individual unit tactics. * Declarative - The build file is now no longer about entering low or high level commands, it is about declaring your intent, i.e. what you want the build to do. Examples are Lein and Maven. In military terms, this is providing units with Commander's Intent and letting the units do what they do best. * Predictive - The build file is declarative, but the build ecosystem tracks developer activities and incorporates AI technologies to predict what the user's intent will be, and to inform the user so they are better able to determine their needs. In military terms this is strategy augmented with a Centaur System (a system with both a human and one or more AI components that work together as one entity). Communitivity, Inc is building Chiron, an Open Source predictive build ecosystem that will be released in 2018. Follow @Communitivity on Twitter for more information in the coming months.
      - lovich 9y ago
        Is this from a poorly trained bot?
        Communitivity 9y ago
        Ouch. Well, live and learn. It would be nice though if one or two of those who down-voted me explained why my comment was objectionable, so at least I can avoid a repeat of whatever mistake I made.
        mseebach 9y ago
- znpy 9y ago
  Someone is finally saying this. Plus, there is a ton of things that json can't do or isn't supposed to do (things like defining a grammar, xpath, xquery, xslt and a lot more)
  - jgalt212 9y ago
    I'd rather write brainfuck for a living than the abomination xslt is.
- alangibson 9y ago
  Where XML really shines is as an interchange format between the type of mission critical upgraded-once-a-decade systems that are the bread and butter of Big Business IT. I think XML got it's bad rep from people applying it where it's bulk and complexity is just not needed. For instance, storing configuration for an application that you completely control or shuffling around data inside of an application domain that you can change at will.
  - vbezhenar 9y ago
    XML is not a good interchange format, because it doesn't map well to a standard programming structures. There's no array or map in XML. Developers must use OXM libraries (object to xml mapper). JSON is much more direct and simple format. XML is good for anything that looks like document markup.
    - andrewflnr 9y ago
      Sometimes your actual data doesn't map well to "standard programming structures". If that's the case, you really want your interchange format to express reality as far as possible, not how it will be processed in any particular program. I don't have enough experience to be authoritative here, but this seems like a bad argument.
    - mring33621 9y ago
      I will agree that JSON is 'simple' but it is only 'direct' in the context of javascript. For other languages, it is similar to XML in handling overhead. JSON's significant technical problem is a lack of a formal schema definition and enforcement mechanism. You may feel that this is actually an advantage, but I assure you, as someone who has written systems of record for billion dollar businesses, it is not.
pjc50 9y ago
Not even that; this is 1970s batch processing rising again.
- skissane 9y ago
  I believe they are positioning it as a replacement for mainframe batch workloads written in JCL, along with rewriting the associated COBOL code in Java. Run WebSphere for z/OS on the same machine as your existing JCL/COBOL batch workload and then slowly rewrite the COBOL into Java and the JCL into JSR-352 JSL, and IBM has Java APIs for VSAM/IMS/etc so you can still access your existing mainframe data from the new Java code. Even if XML is no longer the hotness it was in the early 2000s it is still an improvement on JCL, and it is easier to rewrite batch-oriented COBOL into batch-oriented Java than to change its batch-oriented nature into something more real time.
- wiz21c 9y ago
  Not sure of what you mean, but batch processing is still pretty useful. I happen to work on a project which has batch running 10 hours a day, processing complex business cases, calling dozens of web services, etc. This could absolutely not be made in real time. Or maybe you said that 1970's batch were inferior to today's batch. In which case I'd be happy to read what non-superficial differences exist...
- StevePerkins 9y ago
  I have not reviewed that JSR, so I have no comment on the merits of its implementation. However, it's worth pointing out that MOST tech concepts people regard as "modern" today are actually re-treads of 1970's ideas.

_pmf_ 9y ago

> Nope, this is Oracle stop caring about Java EE. They are not doing this for Java SE as long as they are caring about Java SE. That's strange. How do they make money off SE but not EE? EE has been the cash cow that kept Java alive after applets fell out of favor.

Delmania 9y ago
If I remember correctly, Oracle has a licensing scheme if you want to build and release your own JVM. Java SE always has significant more usage in production thanks to Android, Kotlin, Clojure, and Scala. While Java EE does get used a lot in more conservative large enterprises, the alternatives developed to overcome the inherent complexity of EE (Spring, Hibernate) get a LOT more. Java EE is big, but Java SE is even bigger.
- thedudemabry 9y ago
  Thanks for the explanation. As someone who in a past life developed Java systems (post-2006) for a variety of targets, I was never super clear on what Java EE's value proposition was or how it differed from frameworks that didn't require a separate install. I now gather that it is a collection of helpful packages constituting a framework, but distributed separately from mainline Java core packages.
  - pjmlp 9y ago
    Java EE was also the cloud, before the term was coined. When targeting EE application servers, you don't need to worry at all where it is being executed. As an application, container, bare metal, whatever. Of course this only works ad long as no native methods or APIs for file or process management are used.
needusername 9y ago
> EE has been the cash cow that kept Java alive after applets fell out of favor. I have no insight into Oracles reasoning or finances, I can just see their actions. While I assume they make money off WebLogic licenses I can't image that revenue is growing in the double digit range per year. I assume that Oracle as a publicly traded company is forced to produce growth numbers. These days that's could. They probably some imagine to provide some sort of Java could, that would explain why they pushed so hard for Jigsaw. This doesn't really have make sense to you and me, just to Oracle execs.

tannhaeuser 9y ago

> Their last JSR (Batch/JSR-352) was particularly disgusting So a good fit to Websfear then?