Item — HN Reader

This is IBM finally beating Sun over control of enterprise Java - something they've been fighting for for well over a decade (and much closer to two). IBM has been trying to get the Java process away from Sun - and they even backed an IDE to compete with NetBeans.

Eclipse... of the Sun (Microsystems).

Apparently, Oracle has finally gotten tired of IBM (through Eclipse) saying "we can do it better" and trying to manage it and said "ok - you can do it."

5 comments

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.

"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.

Just replacing XML with JSON doesn't make anything modern.

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.

> 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.

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

> No offense to Groovy

Groovy (on the JVM) joined the Apache Software Foundation 2 years ago after being ditched by VMware/Pivotal. Like the EF, the ASF is another place where software goes to die -- Apache Groovy and Eclipse Ceylon. There's nothing wrong with the original premise of Groovy being a lightweight dynamically-typed scripting language for the JVM, by adding closures to Beanshell. But along the way it got plagued by feature-creep and leadership problems, and started trying to compete with statically-typed languages like Java and Scala. It's only real widespread use nowadays is for writing 20-liner build scripts for Gradle in Android Studio. As for Grails, no-one's upgrading their old version 2 projects to version 3, or starting new projects in it.

I thought Gradle is faster than Maven these days.

Only with the help of a background daemon to catch its data model, a few GB of memory and SSD, to achieve what Maven has doing without daemon help on plain HDDs.

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.

Is this from a poorly trained bot?

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.

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.

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.

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.

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)

I'd rather write brainfuck for a living than the abomination xslt is.

Not even that; this is 1970s batch processing rising again.

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.

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.

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...

> 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.

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.

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.

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.

> 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.

> Their last JSR (Batch/JSR-352) was particularly disgusting

So a good fit to Websfear then?

This is the time when Oracle and IBM both know Java EE is past sell by date. IBM is betting Swift and Go now.

Nothing makes me doubt the future of Swift like this sentence.

For IBM one of the pillars of cloud computing is Swift.

https://www.ibm.com/cloud-computing/bluemix/swift

They used to be one of the main contributors of Swift on Linux.

Now IBM just needs to obtain cloud customers to support said pillars...

Poor ole big blue has seen better days...

Watten Buffet even wrote it off.

eh, Swift Runtime is a IBM product and not community. Go is community btw, and they do have a couple of other IBM and community runtimes avail[0].

[0]: https://console.bluemix.net/catalog/?cm_mc_uid=5252549325751...

I don't understand. What companies that are targetted by Java EE supposed to use in the future?

Wow, after 15 years or whatever it is, I never made the connection between Eclipse and Sun!

> "According to Lee Nackman, Chief Technology Officer of IBM's Rational division (originating in 2003) at that time, the name 'Eclipse' (dating from at least 2001) was not a wordplay on Sun Microsystems, as the product's primary competition at the time of naming was Microsoft Visual Studio, which Eclipse was to eclipse." [1]

[1] https://en.wikipedia.org/wiki/Eclipse_(software)#Name

Haha yes, don't bite the hand that feeds you.

Even more curiosly, Sun never saw a full solar eclipse in the US

Doesn't Red Hat have a lot of involvement with Eclipse Foundation stuff as well? Or am I remembering that incorrectly?

Oh yes. Just last month Redhat's Ceylon language became Eclipse Ceylon

I would argue that Pivotal has beaten both of them with Spring.

Few years back I wouldn't have doubted but today I am not so sure that adding layers of Java framework for all base technologies is sure shot way to win.

I'd like to note here that Spring being popular doesn't mean it's good. Also see: nodejs