Oracle still ignores community’s will

The Java community for some time complained that Oracle isn’t a good Java EE steward, as neither JCP-decided schedules had been fulfilled, nor external parties where effectively allowed to chime into the stalled JSRs. Voices claimed it might be time to shift over control of this standard to another stakeholder or organization, effectively fork it, or rendering it irrelevant by producing own standards for the same area of technology. To quieten the masses, Oracle asked developers to stay tunded to JavaOne — which did not really change anything. While Oracle actually said they still have strong interest in Java EE, JavaOne did not result in a reactivation of the stalled JSRs. Moreover, at that conference Oracle pulled out a bunch of their sole interest as a new schedule for Java EE, while in fact not being the party to have the ultimate say in that matter — which is the JCP’s EC. Doing so once more Oracle slapped into the face of community clearly showing that they not care about the democratic structures they officially committed to (and one should think, also legally are bound to). To convince the people that this would be effectively what the people wants (assuming the people did not know what it wants so far), Oracle asked to fill out a survey. Not that Oracle ever had claimed any interest in the outcome, some parts of the community still did not see that this (again) is just a marketing trick.

Now the survey is over, and it took a while until Oracle published the result (here). Guess what, the survey clearly says that Oracle was absolutely right! Yay! And in addition, it even allows Oracle to work less than pretended at JavaOne! And that is the people’s will! Wait… Is it?

It is not. Folks, just read that PDF a second time and the check the facts:

  • The majority of the participants had 8 and more years of experience with Java EE, so Oracle should take it serious. But Oracle ignores the actual outcome, as the below explains.
  • The survey was never claimed to end up in some kind of “JSRs top-ten”. Nobody said that the idea is to rule out JSRs. But Oracle says MVC, JMS and other lost “the ranking”. This is not true (see below, MVC had 30+% “Very Important” votes), and it was never said there will be a ranking or some other kind of knock-out. If Oracle would have asked for “either X or Y” upfront then people possibly would have changed their vote.
  • There sheer deviation of the new Java EE plan from the survey result shows that Oracle does not care about democracy. Apparently the target was not to ask people what they want, but just to see how much trouble will arise if Oracle goes on with their weird plan of effectively investing nothing but just publish the already “finished” features.
  • Nobody noticed, BTW, that Oracle never talked about features. They only talk about JSRs. The content of the JSRs is ignored anyways, so “who cares?” about the outcome of the survey? Oracle still can do whatever Oracle wants but taking an empty JSR and declaring it as “finished” — what Oracle actually does, see below.
  • The report explicitly (for what purpose?) explains graphically that most participation came from Germany. And due to that reason… nothing. Oracle just does not care. A correct reaction would be to ask iJUG for immediate consultations.
  • The report says (quote): “Note that no technology averaged an unfavorable importance rating of below 3 in this survey.”. The rating was 1 to 5. There had been no 1. There had been no 2. There even had been nothing smaller than 3.18. A correct graphical representation would reflect that. But Oracle simply cut-off levels 1 and 2, so the graphics looks like “Nobody has any interest in MVC, so we can drop it (as planned already)”. The truth is, even MVC, apparently the “looser” in the ranking, gained 3.18 points in average, and more than 30% voted for “VERY important to Java EE 8”.
  • The “conclusions” are just ridiculously far-fetched. Please understand that “conclusion” typically means a logical consequence of a survey. There is just no logical connection between the survey result in the particular consequence on a JSRs, for example wrt to OAUTH.
  • But let’s start at the top. “REST (JAX-RS 2.1) and HTTP/2 (Servlet 4.0) have been voted as the two most important technologies surveyed, and together with JSON-B represent three of the top six technologies. Much of the new API work in these technologies for Java EE 8 is already complete.”. That is simply cherry-picking. Picking three of six. Okay, and the rest? Next time a president for the USA is getting elected, let’s also just pick three of six and ignore the rest. I doubt the result would be anything less than civial war. BTW, I am a member of the JAX-RS 2.1 EG and so can tell you that it is simply not true that much of the new API work would be done. The discussion on many topics still had been paused. It is true that Jersey (an Oracle product, not necessarily meaning that it is a blueprint for upcoming APIs) has most of the features already. But that does not imply that the EG agreed that this API looks good. In particular, there is a lot of open work in the JIRA tracker as everybody can see, and there are no plans when to go on. For many months the EG’s mailing list is dead, and the spec leads have not yet said when work will go on. Red Hat even left the EG meanwhile, so I doubt that the result will be worth the term “industrial standard”.
  • “There is significant value in delivering Java EE 8 with these technologies, and the related JSON-P updates, as soon as possible.”. Interesting to see that JSON-P updates are mentioned to bring significant value, because the survey shows that interest in JSON-P is NOT a top priority for most professionals — while JSON-B actually is instead.
  • “CDI 2.0, Bean Validation 2.0 and JSF 2.3 were not directly surveyed, but significant progress has been made on these technologies and they will be included in Java EE 8.”. I doubt that JSF 2.3 really has significant progress. According to what I heared from that expert group, JSF is more or less “final” and only minor optimizations had been done. Oracle does not invest anything in JSF, and spec leadership is Ed’s private hobby in his spare time. At least this is what it feels like, looking at big stakeholders like PrimeTek: Most of their blog entries talk about migrating to Angular 2, not about great new stuff in JSF.
  • “We considered accelerating Java EE standards for OAuth and OpenID Connect based on survey feedback. This could not be accomplished in the Java EE 8 timeframe, but we’ll continue to pursue Security 1.0 for Java EE 8”. Both most-influencing groups of the survey, the Java EE experts and the Microservices experts, see OAuth as one of the top-three (see, I also can do cherry-picking), and I can tell you that there are open source OAuth implementations ontop of JAX-RS ready-to-use, and what does Oracle? Dropping it. That is absurd. Java EE 8 is claimed to be cloud-ready, and the cloud speaks OAuth. So let’s drop it?! It cannot be finished it the time frame? Maybe Oracle should have worked on Jersey in the past year (statistics), then it would be done already!
  • “At JavaOne, we had proposed to add Configuration and Health Checking to Java EE 8, and these technologies rank reasonably high in survey results. However, after additional review we believe the scope of this work would delay overall Java EE 8 delivery. We have concluded it is best to defer inclusion of these technologies in Java EE in order to complete Java EE 8 as soon as possible.”. Sounds like somebody big-talking and then not willing to deliver anyhing that needs efforts. I doubt that it would be “best” to defer features that are “ranked reasonably high”, actually.
  • “Management, JMS, and MVC ranked low in survey results, and this ranking supports our proposal to withdraw new APIs in these areas from Java EE 8. We have withdrawn the JSRs for Management 2.0 (JSR 373), and JMS 2.1 (JSR 368), and are investigating a possible transfer of MVC to another community member or organization in order to complete JSR 371 as a stand-alone component.”. How nice that the survey exactly supports what Oracle did already! Isn’t that cute! Unforutantely this claim is simply a lie. As Oracle says in its own report, nothing ranked low. Actually they just cut the scale to make it look like. The interest in MVC is high, as the pure numbers say (30% voted “very important”). Anyways, it is good to see that Oracle allows someone else to continue. I just wonder what organization they are searching for: Just let Ivar and Christian continue their good work in that open source project. No organization needed at all, just make the TCK public and that’s it. Or give the IP to the JCP, it is the official developer of MVC anyways. Or finally let us start a Java Foundation, which is really democratic, and give MVC to them.

To sum up, Oracle just twisted the survey result to support their sole will. The will of the developers, the users or other vendors, is completely ignored. They have a plan what is good for them, and this is we done. Whether the JCP EC likes that or not, does not care. It is a shame that the JCP EC accepts that. For me, it clearly shows that Oracle is a dictator that uses the JCP and the community in general as a fig leave, covering their private interests and activities.

One could say, Oracle can do what they want. Java EE is theirs. Guys, that is simply wrong. Java EE is open source, it belongs to the JCP, and the JCP is a democratic organization. Oracle is just one of many contributors, but the one owning the Java EE trademark and the IP of many TCKs. Not more, not less. So what we talk about is commons (like water and air), not products. We should all have a say in the future of commons, and nobody should be allowed to ignore the people’s will. Also, there is freedom of speech and freedom of opinion. This is mine. Feel free to exress yours in the comments section — but please take the time to back it with real facts!

Posted in Java, Oracle, Politics, Standards | Tagged , , ,

Oracle still has no clue how to go on with Java EE 8

So here it is, the long awaited JavaOne announcement on the future of Java EE 8, and what it tells us can be summed up quite simply: Oracle still has no clue how to go on with Java EE 8, so they let us wait even more years, and again ask us dumb questions on whether MVC and JMS should be cancelled or whether multi-tenancy would be necessary. One could hardly see any difference to the original Java EE 8 plan in fact. An at-most content-free and meaningless roadmap: “We do V8 then V9. For V8 we do another survey hoping that you agree when we kill MVC and JMS. For V9 we have drawn a chaotic chart. And we ask eight companies what they want. Ain’t that cool, folks?”. Good grief! And that’s everything they come up with after all that long time of silence and absence and protests by the community? No updated content and time frame for the existing JSRs? No real plan how to get the community in the boat, for really-open open source? Nothing? Not even an apology to the JCP for breaking their rules over and over again? You dare to come here barehanded? Really? Just once more the same Oracle-self-adulation that nobody wants to hear anymore — I’m really sick of that!

Oracle, once more, hand out the TCKs and let the community take over. We know what we want, we can deliver it in time, so let us just do our work now as we asked for months ago!

Posted in Allgemein, Java, Open Source, Oracle, Politics, Standards | Tagged

Java EE Guardians Achieve Partial Success

Today The Register reports that Oracle committed itself to sustained maintenance of Java EE. This is clearly (but possibly not uniquely) a partial success to the Java EE Guardians initiative. Hooray! 🙂 Nevertheless, as Oracle employees told me in private, this does not necessarily means to really develop Java EE any further, or in any particular direction… So the Guardians will keep up their Monitoring of Oracle’s actual next steps. Anyways I wonder how Oracle will be able to finish Java EE in time. They say they can deliver Java EE 8 early in 2017, but according to the rules of the JCP (number of steps and time Frames) and looking at the current state of some JSRs (like 370 / JAX-RS 2.1) I doubt that this will be possible in time without violating the rules of the JCP. My fear is that either Oracle will simply declare the current state (hence: rather zero) as “Java EE 8” or simply ignore other Stakeholders and declare their own products as “Java EE 8”. I shouldn’t wonder about the latter, as Oracle recently (possibly frequently) ignored JCP rules, e. g. by simply being unresponsive to EG members, dictating results without asking EG members about their opinion, or just ignoring the JCP timeframes without any shame.

Aside | Posted on by

JavaForum Stuttgart 2016 Slides Are Online

The slides of my talk “JavaFX in professionellen Anwendungen” (JavaForum Stuttgart 2016) can be found on Speaker Deck.

Aside | Posted on by | Tagged

Toolchains + Exec Maven Plugin = Swiss Army Knife

I am pretty excited about Karl Heinz Marbaise this week kindly releasing version 1.5.0 of Exec Maven Plugin, because it contains three additions which are really awesome (not only because I authored them, but because of their combined effect): Support for custom tool chains, an integrated and fully configurable toolchain, and finally a documentation how to use both together.

What makes this combination so great is that you now have a Swiss Army Knife which makes integration of native tools much easier. In my case, I had to provide POMs for projects written in ancient languages like Install Script (Install Shield), Power Script (Power Builder), MS Visual C++ 6, Borland C++ Builder 7, and other deprecated technology. It was hard to tell our Jenkins build nodes where all those tools are located on disk without cluttering the OS search PATH. Certainly the clean solution would have been writing a Maven plugin for each of those tools, and let that plugin find it on disk somehow magically (i. e. running a Windows registry query or checking product-specific environment variables). But the exec plugin was much cheaper to employ. The only pain point was that I had to put all the tools statically in the OS search PATH.

My contribution allows to get rid of that PATH: Just define the path to each tool using the new and now embedded Paths Maven Toolchain by locating a toolchains.xml file in the .m2 configuration file and we’re done. This keeps the PATH pristine, and is a 100% clean Maven solution. Not as sophisticated as custom plugins certainly, but getting the project days earlier finished!

Now, if you don’t know how to use this new cool stuff, just copy-and-paste the example I added to the docs: http://www.mojohaus.org/exec-maven-plugin/examples/example-exec-using-toolchains.html.

Posted in Allgemein, Java, Open Source, Programming, Projects | Tagged ,

How Immutables Speed Up Even Non-Parallel Software

Just learned one interesting aspect of immutables: Besides the fact that they help you to provide a lot of ugly threading problems, they potentially speed your your code by itself. The trick is that once you prevent the creation of two identical object instances (e. g. by using builders and caches) you can be sure that two references always point to distinct objects. As the objects are immutable, this is an invariant. Hence, you can reduce the equals() and hashCode() methods to fixed implementations: There is no more need to actually compare any state, but it is enough to compare the reference itself. This certainly speeds up the code, even in non-parallel situations. Also, you spare memory, as you will never have any copies, but only singletons. As a side effect, less GC pressure exists, which also will result in faster Overall execution.

Cool, this really is the tip of my day. Good that I had time to attend “parallel//2016” conference. 🙂

Aside | Posted on by | Tagged ,

Maven Coordinates for Java EE’s Individual APIs

There are things on earth you search for again and again and again. One of these is the page where the Maven Coordinates (GAV) for all the individual APIs of Java EE (like JPA, JAX-RS, etc.) is found. Here it is: https://glassfish.java.net/wiki-archive/Java%20EE%207%20Maven%20Coordinates.html.

Aside | Posted on by | Tagged ,