java 9 - modules - red hat/ibm

[Jeanne Boyarsky]

I'm surprised we don't have a thread on Red Hat and IBMs plan to vote no on Jigsawyet. First of all, it is 80 days to release. You'd think major features would be voted on before now. But that would be just silly. And yes, I understand it is a complex issue. This interviewexplains it well.

So now we are in a situation where two large application server providers are voting against the largest feature in Java 9. It seems like there are a few outcomes here:

the vote doesn't pass

java 9 gets delayed again

the vote does pass

The third possibility is interesting. Because I imagine IBM and Red Hat wouldn't be so quick to adopt support for these features.

Thoughts?

[Claude Moore]

Thanks Jeanne for raising this question. I think  this choice - if really IBM and RedHat eventually won't vote for jigsaw - may be a serious problem for the future of Java. Is just a technical divergence? For the few news I've read on the web, the whole matter smells more of politics than technology...

[Jeanne Boyarsky]

Even if IBM and Red Hat don't vote yes, that doesn't mean they won't support the technology though.

[Jeanne Boyarsky]

The vote was 10 yes votes and 13 no votes. A few of the parties said they voted no to invoke the 30 day period to deal with the remaining issues and they think they will vote yes in 30 days.

I particularly liked what SAP wrote in their comment with the vote:

SAP wrote:Finally, we adjure all members and the spec lead to come back to the table and communicate directly to each other instead of blaming each other through blogs and open letters!”

[Claude Moore]

Jeanne Boyarsky wrote:Even if IBM and Red Hat don't vote yes, that doesn't mean they won't support the technology though.

That's right. Both of them have endorsed heavily Java on their middleware and appserver products  so I'm not afraid they are going to dump Java support, or make Java less strategic.

[Tim Moores]

These issues have been hashed around for a long time - it's unlikely much can be resolved in 30 days, IMO.

Personally, I would like to see better interoperability with OSGi, and am dismayed that they didn't just co-opt OSGi entirely. Seems like a case of not-invented-here syndrome, akin to how java.util.logging was developed when log4j already existed and was widely used.

Reinhold responded to the criticism with what I thought was a rather misguided statement: "A vote against this JSR due to lack of consensus in the EG is a vote against the Java Community Process itself." So apparently folks should vote for it, even if they're against it, because votes against are apparently aimed at the JCP itself rather than the technical issues involved. If that's how the battle lines are drawn, I doubt there can be a meeting of minds any time soon.

[Jeanne Boyarsky]

I don't think IBM or RedHat will be happy in 30 days. But there is a chance they'll still vote no and then be forced to implemented it anyway to continue being app servers. I think another delay of Java 9 is far more likely.

Link to who voted how

[Tim Moores]

I wouldn't think they'd have to implement anything. This is a JRE feature, not a JEE feature, after all. Unless some future version of JEE requires the ability to deploy modules that are compatible with it. But JEE 8 isn't even released, so I think this would be a few years off.

[Claude Moore]

Tim Moores wrote:I wouldn't think they'd have to implement anything. This is a JRE feature, not a JEE feature, after all. Unless some future version of JEE requires the ability to deploy modules that are compatible with it. But JEE 8 isn't even released, so I think this would be a few years off.

I'm afraid that finding a common way to develop Java EE 8 will not be so easy. Last summer, I've read with a certain interest about Java EE Guardians initiative, as well as about   Microprofile initiative.
The first is about "encouraging" Oracle to put new, important efforts in enhanching Java EE and design a shared roadmap towards new releases. The latter is about defining a common subset of Java EE features that a programmer can pick up to "compose" a bunch of libraries to run an app packaged as uberjar.
Interestingly, both IBM and RedHat endorsed Microprofile (with WebSphere Liberty and WildFly Swarm), while Oracle - as far as I know - did not.

[Jeanne Boyarsky]

Tim: IBM has their own JDK so they'd care for that alone. I would think Java 9 with Java EE 7 is affected by modules, no? Because you care about classloading and dependencies.

Claude: That is interesting!

[Tim Moores]

Jeanne Boyarsky wrote:I would think Java 9 with Java EE 7 is affected by modules, no? Because you care about classloading and dependencies.

How do you figure? JEE 7 knows nothing about Java 9 modules, so I don't see how it could be affected. And while JEE 8 isn't released, it's pretty far along, and will be based on Java 8 - so it won't rely on modules, either.

Claude Moore wrote:I'm afraid that finding a common way to develop Java EE 8 will not be so easy. Last summer, I've read with a certain interest about Java EE Guardians initiative, as well as about   Microprofile initiative.

While the microprofile initiative was interesting when it came out -mainly due to JEE 8 being stalled at the time- JEE 8 is now in Public Review. I don't expect holdups like with the module system, so it's likely to be final by June. I can't imagine the major app server vendors not supporting it in due course after that.

[Jeanne Boyarsky]

Tim,
Hmm. I was thinking the jars would relate to each other with modules. But you're right. They have to relate via the manifest and Java EE modules first.

[Claude Moore]

Tim Moores wrote:
While the microprofile initiative was interesting when it came out -mainly due to JEE 8 being stalled at the time- JEE 8 is now in Public Review. I don't expect holdups like with the module system, so it's likely to be final by June. I can't imagine the major app server vendors not supporting it in due course after that.

IMHO Microprofile initiative is still interesting, and supporting it doesn't imply that a vendor isn't going to support Java EE 8 full stack as well. In a nutshell, a microprofile is "a composite of Java EE parts" you need for a project to be packaged as a self contained (uber)jar; so a microprofile cannot exists outside Java EE umbrella. Moreover, microprofiles is focused on microservices, Java EE AFAIK is not: they are complementary.