The baby and the bathwater

Tue Mar 27 13:56:23 UTC 2018

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

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!

Gregg

> On Mar 26, 2018, at 1:08 PM, mark.reinhold at oracle.com wrote:
> 
> Stephen Colebourne's recent blog entry [1] contains many true statements,
> along with some reasonable advice for library maintainers.  To summarize:
> 
>  - As of Java 9, with Jigsaw, there are two ways in which a library can
>    be used: Either on the traditional class path, or on the newfangled
>    module path.  If you maintain a library but don't modularize it then
>    it can still -- unbeknownst to you -- be used on the module path as
>    an automatic module.
> 
>  - When code runs on the module path there are some differences in the
>    behavior of some pre-9 APIs, in particular those related to resource
>    lookup.
> 
>  - As a consequence, if you maintain a library that's intended to work
>    on Java 9 or later then you should test it on both the class path
>    and the module path, even if you do nothing to convert your library
>    to a module.  If your library doesn't work on the module path then
>    you should either fix it or document that limitation.
> 
>  - If you don't modularize your library, or at least claim an automatic
>    module name for it via the `Automatic-Module-Name` manifest entry,
>    then you potentially block the maintainers of libraries that depend
>    upon yours from modularizing their own libraries.
> 
>  - The tools that we use, and in particular Maven, could be improved.
>    It's difficult to compile the classes for a modular JAR file that's
>    intended to work on the class path of pre-9 releases, it's difficult
>    to test a library on both the class path and the module path, and
>    various Maven plugins still need to be upgraded to handle (or else
>    ignore) `module-info.java` files.  (Stephen has helpfully filed
>    issues in the appropriate bug trackers for some of these problems.)
> 
>  - Some old tools, bytecode libraries, and other systems fail when they
>    encounter `module-info.class` files or multi-release JAR files.
> 
> From these points Stephen concludes that the module system, "as currently
> designed, has 'negative benefits' for open source libraries," saying that
> this is primarily because "the split (bifurcation) of the module-path
> from the class-path is an absolute nightmare."
> 
> Hyperbole aside, Stephen's main complaint here is only about the need
> to test a library on both the class path and the module path if it's
> intended to work on Java 9 or later.  With automated testing this
> shouldn't, in principle, be a huge burden, but still it's worth asking
> the question: Could we have avoided the need for such dual testing if
> we hadn't introduced the module path as separate from the class path?
> 
> Consider, as a thought experiment, an alternative Jigsaw design that
> didn't have a separate module path, and instead treated modular JARs
> on the class path as modules rather than traditional JAR files.  You
> wouldn't have to dual-test if your baseline is Java 9 or later, but
> if you want to support earlier releases with the same artifact then
> you'd still have to test on the class path.
> 
> With the actual Jigsaw design you do need to dual-test your library
> when your baseline is Java 9 or later.  There is, however, a benefit
> to this: If someone uses your library in an application that works on
> the Java 8 class path today then they can migrate it to the Java 9 (or
> later) class path and then, when they're ready, move your library (and
> perhaps some others) over to the module path.  (There were many other
> reasons to define the module path as separate from the class path, but
> those aren't directly relevant here.)
> 
> The tradeoff, then, is a little bit more dual testing on the part of
> library maintainers in exchange for greater flexibility for those who
> will migrate existing applications to Java 9 or later releases.  Many
> library maintainers will be reluctant to baseline to Java 9 (or later)
> for a while yet, so they'll be dual-testing anyway, so I think this
> was the right tradeoff.
> 
> Stephen closes with a specific suggestion:
> 
>  "There needs to be a way for a library author to insist that the
>   modular jar file they are producing can only be run on the module-path
>   (with any attempt to use it on the class-path preventing application
>   startup).  This would eliminate the need for testing both class-path
>   and module-path."
> 
> Yes, this would eliminate the need for dual testing, but only if you're
> willing to baseline to Java 11.  As with a unified class/module path,
> however, if you want your library to work on earlier releases then you'd
> also, still, have to test on the class path, and you'd make it harder for
> application maintainers to migrate old class-path applications.  I don't
> think this idea is worth pursuing.
> 
> What ideas are worth pursuing?  We should, by all means, continue to
> improve our tools, Jigsaw itself, and the rest of the JDK.  Several of
> us here collaborated on the initial support for modular development in
> Maven, but clearly there's more to do.  If nothing else, the Surefire
> plugin should be able to test a library on both the class path and the
> module path.  There's also at least one improvement in the JDK worth
> considering, which a few of us have already discussed, namely a small
> enhancement to javac that would allow a single invocation to compile a
> module, in module mode [2], but target class files other than
> `module-info.class` to an earlier release [3].
> 
> To sum up: We have more work to do, based on practical experience.  This
> shouldn't be a surprise, with a change to the platform of this scope.
> Let's keep doing that work, let's not unduly alarm ourselves or anyone
> else, and please let's not throw out the baby with the bathwater.
> 
> - Mark
> 
> 
> [1] http://blog.joda.org/2018/03/jpms-negative-benefits.html
> [2] http://openjdk.java.net/jeps/261#Compile-time
> [3] https://bugs.openjdk.java.net/browse/JDK-8200254