The baby and the bathwater

[Jochen Theodorou]

On 27.03.2018 15:56, Gregg Wonderly wrote:
> I think that Stephen is largely announcing that JigSaw presents more problems than it solves for the community.  My list of issues, which I have shared before, goes basically like this.
> 
> 1. Modules should have versions which new tooling on community toolsets could use for managing details like maven is doing now, but without explicit version details available at runtime.  There should be runtime version details available.  Java’s dynamic binding mechanisms would allow a lot more flexibility in how software was assembled at runtime, and that would be a good thing.

the module system is all about not dynamically assembling applications 
at runtime. JLink is the high point of that so far

> 2. The complete set of changes around JigSaw are primarily about isolating the community from the innards of the JDK implementation, which they developed reliance on due to the JCM not functioning and not caring enough about actual software development, but money making instead.  Now, they have to completely rearchitect large amounts of software that is mostly 100% reliable, to use these JDK “improvements”.  What’s the chance of that happening for anything that is not going to be actively developed because it completely works as needed?

I still find comments like "not caring enough about actual software 
development, but money making instead" a bit unfair. Sure, those cases 
exist. But in other cases there used to be no other way, or there have 
been other needs that required doing a solution in a very stupid way.

For example, for me to be able to call constructors of a super class I 
have to have an invokespecial. Since I have to decide what constructor 
to call at runtime I have basically something like a switch with 
multiple invokespecial and the switch-case deciding which one to take. 
This is a major hack, no Java compiler would ever emit code like that. 
But the Java compiler decides this at compile time, not my requirement 
at all. And of course when in Java8 the verifier got rewritten, this was 
no longer working for a while. But do you think there will be ever a 
better solution to this with these requirements? I doubt it. 
invokeSpecial has very specific semantics in this case, that are not 
going to change in my favor, just because I need that feature. The 
alternative is to introduce strange unrelated constructors, no longer 
enabling extending classes, wrapping everything, making constraints 
about the constructors... Alternatives are there... all horrible.

I can give quite a list of things that are why they are because the 
software is almost 15 years old now. And I am pretty sure it would have 
never existed in a world of Java 9+... And actually the last point is 
what saddens me the most here.

Anyway. You did go a way did does not fit jigsaw anymore, now you have 
to change the architecture - big times. So big, that there is no chance 
of hiding the changes from my users. And suddenly I will have a MOP that 
will have to expose do-what-you-want-with-me Lookup objects, just to get 
things somehow still working.

And for those not actively developed it is easy. They will die at one 
point. Not that this is good, just the effect.

> 3. It seems from the outside, that there was little attention payed to the 80% of Java users who don’t write code or use enterprise services, but instead have Java applets, WebStart clients and clickable jars, until late in the game.  This caused a derail of the projects desire to lock-it-down in JDK-9.  Now that the realities of all of this are becoming much more obvious, it’s actually much clearer, that a lot of java code runs without deployment plans or explicit lifecycle management of neither the Java software nor the JDK version used to run it.  The result is that more and more people are going to give up on using Java because they will try to use an application which has always worked for them, and it will either silently fail (clickable jar with a security violation), or scream about some kind of security violation (applet or webstart app) which will alarm them into deleting it or moving on.

enterprise services... considering how long jigsaw chose to ignore 
things like dependency injection and continues comments about how jigsaw 
is not for the enterprise, there is also a large portion of the 
enterprise services that got no attention.

> 4. When I was a member of the Sun Developer Advisory Council in the early 2000’s, I learned a lot about how Sun was focused on just the enterprise opportunity to sell hardware and support contracts.  How did that work out?  Oracle who is also a “server” company, demonstrated again, with JigSaw, that only the enterprise platform environment with planned software schedules and controlled releases was interesting.  In SDAC parties with James Gosling, we heard stories about his frustration with the desktop environment being ignored by Sun Management.  There were a lot of “I’m sorry” and “I’m trying to work on those things” comments.  Where’s Gosling now in Java involvement?
> 5. The AWT and Swing parts of Java as well as DOM integration with Applets hasn’t been touched or worked on in decades.  The demise of the Netbeans team and other changes around various platforms and people who were serving communities outside of the enterprise platform, demonstrates that the platform is no longer viable for anything except enterprise class projects, and I’d suggest that even there, it’s questionable because of how these JDK changes are changing things that Oracle needs, but not “providing” things that the community benefits from, except for Oracle’s argument that now the JDK can actually be improved.

You forgot JavaFX. Since it will be no longer part of the JDK I did hear 
very worried words from some people and others giving up JavaFX 
completely. And no, they do not go to Swing and AWT. They move to 
javascript UIs. That means Java on the server if at all. Nashorn isn't 
even considered as an alternative to the likes of node and electron.
Desktop Java as application, Applet or Webstart will have a very very 
bad standing in the future. The only reason to keep Java on the server 
and not use for example Go instead is... the supporting libraries... 
many of them having to do a lot of changes because of jigsaw.

I have not worked on any application in the last 4 years that will work 
in that version on Java9 as module, nor will it do now.

> I know this sound extremely whiny and fussy.  I understand how it can easily be ignored.  The detail for me, is simply that after 20 years of Java, with the first 5-10 years being very exciting because of the opportunity for unifying platforms, we are now not doing that at all.  Apple has moved on with Swift, so that platform is not interested in Java by and large.  Windows has .Net, like it or not, and people use that platform because of the rich end to end integration it has with all aspects of the platform, unlike Java which is not completely focused on ignoring anything about the UX for desktop environments.  Thus, we are left with “Linux/BSD/Solaris” as the only place that Java is being used, to some degree.  Python has a lot of traction because it is lighter weight and has better platform integration.
> 
> It’s sad to say these things, because Java could of been so much more.  But, instead, it’s getting to be less and less to fewer and fewer people, largely because the only focus is on the 10,000 customers who do enterprise computing, instead of the 10,000,000 developers who could really benefit from using Java.  That was on a slide at the first SDAC meeting.
> 
> Java was going to be for everyone!

But somebody has to pay the development. It is not like the JVM is a 
cash cow. But let me as a different question: Why should I use Java in 
the cloud? Oracle fails to answer this in my opinion. And in my opinion 
Oracle is on a good way to loose Java on the desktop as well as the 
server. I may overestimate trends I imagine to see of course. But 
frankly, the superior JVM technology and not having to compile for each 
platform (I ignore jlink here) are the things keeping me around for now. 
Java as platform would have to set a new positive trend to get out of 
this... difficult to do.

bye Jochen