
Concerns with JPMS spec and Jigsaw implementation - chris_overseas
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000684.html
======
nullnilvoid
Despite all the flaws of Java such as verbosity and heavy JVM, Java has been
rock-solid and working very well. Reaching consensus might be slow, but it
also ensures the stability and reliability of Java. I have used so much buggy
software that is pushed out before it is ready. Java is not one of them.

~~~
bluejekyll
Sure. But the longer jigsaw is delayed, the longer we have to wait for a
viable native option. osgi is the only alternative when this is required, but
the tooling and JDK integration aren't great.

There are many large applications that can benefit from jigsaw; this is sad.

~~~
mindcrime
_There are many large applications that can benefit from jigsaw_

What is it you need from Jigsaw that OSGI doesn't already provide?

Personally I'm ambivalent about Jigsaw. My main hope is that they don't f%!#
up and create something that breaks existing OSGI implementations. As long as
I can just ignore the new stuff and keep using my existing OSGI bundles -
until such a time as I'm ready to embrace the Jigsaw stuff - then I'm not
going to worry about this too much. But if they break OSGI with Java 9, I'm
going to be incredibly pissed.

~~~
pjmlp
> What is it you need from Jigsaw that OSGI doesn't already provide?

Simplicity, native language integration and a sane path for a Java linker.

------
ognyankulev
The link in the mail
[https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri...](https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-
deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns)
contains much more detailed discussion on Jigsaw concerns by "members of the
Red Hat middleware team, Apache Maven chair, Paremus, Sonatype, as well as
other Java Executive Committee(EC) members"

~~~
chris_overseas
Here is a response with a somewhat opposing view: [https://blog.plan99.net/is-
jigsaw-good-or-is-it-wack-ec634d3...](https://blog.plan99.net/is-jigsaw-good-
or-is-it-wack-ec634d36dd6f)

~~~
DamonHD
Good find, good read.

While I've dealt with hugely complicated systems from bare electronics up to
(eg) full banking systems, I have to say that I found my encounter with OSGi
over a year or so to be quite unhappy.

So the argument "it should be like OSGi" wouldn't work for me!

------
tannhaeuser
It should be noted that IBM is heavily invested in OSGI and thus its not
surprising they're objecting everything that intersects with OSGI's terrain
which is pretty wide.

Personally, I've never seen the need for something like OSGI at all. I could
grok service component jars (as in SCA) with service description artifacts and
manifests, but OSGI, making its way from a modular Java spec for mobile apps
(J2ME anyone?) to a general-purpose server module thingy and service container
was too much a projection surface for everything and anything for me. Last
time I had to deal with it was years ago with Apache Camel/Service Mix and I
didn't like it. If I remember correctly, it had a System V-init like directory
in a .jar file which indicated run levels of an app. Obviously, replacing
POSIX by a partial "100% Java" implementation can't be the use case for OSGI.
I believe it's also heavily used in Eclipse, but then this isn't good
advertising for OSGI either, as getting into Eclipse internals is such a PITA
that its almost easier to code an app from scratch.

As I understand, Oracle wants to unbundle some Java dependencies (such as
Swing/awt) from the JRE, but using OSGI for that doesn't seem to work since
you must explicitly call loadBundle() or something on each and everything.

So please convince me of a use case for OSGI.

~~~
needusername
> So please convince me of a use case for OSGI.

Imagine you're build a "platform" into which other people can load their own
code. Examples include IDEs but also ci servers, static analysis platforms,
CMSes, repository managers, build systems, …. The code people can load takes
the form of "plugins". These plugins are written by third parties that you do
not control.

That plugin code should be able to use APIs that you offer but you want
prevent the plugin code from accessing your internals because you want to be
free to change your internals without breaking the plugins. In addition you
would like to isolate these plugins as much as possible. One plugin should be
able to use one version of a library with a different plugin being able to use
a different version of the same library without conflict.

While I do agree that OSGi is a bad fit for the JDK I also believe Jigsaw is a
bad fit for applications because Jigsaw is constrained by the requirement that
it has to work for the JDK.

> It should be noted that IBM is heavily invested in OSGI and thus its not
> surprising they're objecting everything that intersects with OSGI's terrain
> which is pretty wide.

While true I believe IBMs objections are much more nuanced and center around
the unfortunately still ongoing immaturity of Jigsaw. With new features being
introduced or dropped on an almost weekly basis after we're officially feature
complete since 11 months I believe they have a point.

> I believe it's also heavily used in Eclipse, but then this isn't good
> advertising for OSGI either, as getting into Eclipse internals is such a
> PITA that its almost easier to code an app from scratch.

I have trouble following this argument.

------
sorokod
Redhat also voted No.

[http://mail.openjdk.java.net/pipermail/jpms-spec-
comments/20...](http://mail.openjdk.java.net/pipermail/jpms-spec-
comments/2017-April/000087.html)

------
spullara
As part of the original JSR-277 expert group I am hugely disappointed they
didn't actually solve the problems that I'd like to see solved. Distribution,
versioning, repository and runtime loading. Instead they solved the non-
problem of access control. Really frustrating and totally useless. Read the
early draft of JSR-277 to see what it should have looked like:

[https://jcp.org/aboutJava/communityprocess/edr/jsr277/index....](https://jcp.org/aboutJava/communityprocess/edr/jsr277/index.html)

------
geodel
It would seem no surprise anyone who invested heavily in osgi or other
competing technology to Jigsaw will be unsympathetic to Jigsaw irrespective of
technical merit. The sustained campaign against Jigsaw is going on for more
than 10 years.

------
jjm
The spirit of the desire for a robust yet useable module system i believe is
at odds between Oracle and the community. A middle approach while seemingly
sensible is less attractive to the community. What works for core modules may
not work for the (regardless of what some may call design flaws) more complex
and more important community modules.

The community made Java what it is today. This system is supposed to support
the community more so. You could say that the problems were created.

Without the community Oracle would not have the resources to sustain Java.

~~~
pjmlp
Without Oracle there wouldn't be any community, who do you think pays the
salaries of most OpenJDK devs?!

~~~
winteriscoming
Don't know about "most" OpenJDK devs, but Red Hat is heavily invested in
OpenJDK and has an entire team of employees working in it.

~~~
pjmlp
Yet they aren't the ones putting money on Hotspot, Graal, G1, AOT compilation,
SubstrateVM, JNI replacement, ....

The only core VM technology has been Shenandoah GC (which isn't production
ready yet)and the Zero Assembly port.

Most of the Red Hat money goes on Java frameworks like JBoss or RichFaces (now
dead).

------
MarkMc
I just used Jigsaw to create a Java 9 runtime for Windows based on a "Hello
World" program. This JRE is only dependent on the 'java.base' module, so it is
as small as possible. Yet the resulting JRE is still 35 MB on disk (13.2 MB
compressed).

I'm a little disappointed that after so much effort to cut bloat in the JRE, a
simple 'Hello World' program still requires 13.2 MB.

~~~
frik
How much does a Hello World programm require elsewhere?

VB6 1.3MB msvbvm60.dll

Java8 150MB C:\Program Files\Java\jre1.8x\

dotNet 250MB C:\Windows\Microsoft.NET\Framework\

~~~
greydius
C 8.6kb

~~~
userbinator
You can get <1KB with the appropriate compiler settings.

(I am aware that you can get smaller binaries for other languages by changing
the compiler settings too, but I doubt _any_ Java binary can reach that size
even with the appropriate settings.)

~~~
tokenizerrr
And what are you linking against, then? I can make a tiny .jar file as long as
I get to completely ignore the size of the JDK, much like you're ignoring the
size of the libraries you're linking against.

~~~
diek
Actually, funnily enough I just went through and built a semi-freestanding exe
to load a jlink'd Java 9 JVM:
[https://gist.github.com/anonymous/cb6e81a36247563d423f36df19...](https://gist.github.com/anonymous/cb6e81a36247563d423f36df19e41f9e)

The only dependencies this particular ex has is on user32.dll and kernel32.dll
so it can call LoadLibrary and GetProcAddress, but if I wasn't interacting
with those I could remove those dependencies (though then the exe wouldn't be
able to do a whole lot of interesting things).

If you look at the file in a hex editor, it's mostly just empty space as it
just has four 1k sections with a little bit of data at the start of each.

------
mbfg
My main concern is that whatever the system, 'normal' people can just ignore
all of it, and continue on as usual. There are use cases for it, specifically
the JDK itself, but i feel like the grand majority of developers have no need
or want of modules. It does seem like you can just ignore all of this, so as
long as that is the case, probably ok.

------
hyperpape
What's not clear to me from the outside is how coupled these decisions are to
the Java 9 release. Supposedly Java 9 is going to ship in less than three
months, but you can't change major functionality in that short of a time
frame. Or is there some way that you can defer work on Jigsaw/the JPMS spec
without upsetting everything else?

------
time4tea
This whole thing is pointless, it seems. If you want an oracle jre use it. If
you want a tiny jre use a vendor that makes one, there are quite a few.
Skelmir for example makes a jre that can be very very small. (I used it, i
dont work for them) Network and storage isnt really a big deal anymore, and
when it is, just see above.

~~~
DamonHD
You maybe haven't seen the nice live demo where you can build (in seconds on a
non-fancy laptop) a tiny JRE on the fly on the command line specifying which
modules to include, as well as which GCs etc to support and whether the images
should be compressed or not on disc for example.

~~~
mbfg
Does 'anyone' care about that? I don't. I suppose you could find someone.
Maybe raspberry people. But for large swathes of devs, not a thing.

------
MarkMc
Can someone describe IBM's main objections? And will this mean that the Java 9
release is delayed?

~~~
candiodari
[https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri...](https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-
deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns)

~~~
frik
It's pretty good summary. It makes it totally understandable that they voted
no.

------
austincheney
JPMS spec -
[http://openjdk.java.net/projects/jigsaw/spec/](http://openjdk.java.net/projects/jigsaw/spec/)

Project Jigsaw -
[http://openjdk.java.net/projects/jigsaw/](http://openjdk.java.net/projects/jigsaw/)

I don't know what the design decisions are behind these technologies, but I
just hope it isn't NPM for Java.

~~~
pebers
I wouldn't worry, Maven Central is already that :)

One of the most-touted goals is to break up the JRE libraries so you could,
for example, deploy it to a headless server without any of the GUI libraries.
That certainly seems like a good direction, although there seem to be a bunch
of other parts to it as well that I didn't know about (e.g. jlink).

My concern is more how they do it in a reasonably transparent way; it seems
like a fairly different process to how it works currently, and having to
implement essentially a second build process for a new version of the language
seems tiresome for downstream tooling.

~~~
needusername
> you could, for example, deploy it to a headless server without any of the
> GUI libraries

That is quite theoretical. The issue is that the GUI libraries are in one huge
module with everything from JavaBeans to sound. It is quite likely that you
have an indirect dependency to JavaBeans so you'll likely end up having to
deploy AWT, Swing, PLAF, sound and what not even if your application is
headless.

~~~
pebers
I've not been following it that closely; that was my understanding of the kind
of thing they were aiming for, and which we'd like to reduce the footprint of
our Java images. If the modules are too tightly coupled for it to make any
difference that will be a little disappointing.

~~~
needusername
With footprint of your Java images you mean the size of your Docker images?

~~~
pebers
Yup, correct. It's not a high priority, just would be nice if it were reduced.
Reducing their memory usage would be of a lot more benefit but it doesn't seem
likely Jigsaw would be able to make a huge difference there.

------
vbezhenar
So, I guess, no modules in Java 9.

~~~
pkolaczk
Without versioning they were almost useless anyway. They don't solve the major
problem: diamond dependency hell.

~~~
Eduard
What do you mean here wrt Java module systems, and when was the last time you
ran into this problem?

------
godmodus
"IBM is also voting "no" which reflects our position that the JSR is not ready
at this time to move beyond the Public Review stage and proceed to Proposed
Final Draft"

The title is a tad misleading. They just want to delay the project, not block
it. (at least i undetstood theyd delay it from initially reading the title)

~~~
Reason077
This may be the death blow for Jigsaw. It's already been a work in progress
for a decade or so and has been delayed and pushed back many times.

~~~
godmodus
I doubt its a deathblow, iot wont go amywhere, niether will java. Where theres
a will theres away and jigsaw wants to focus on security and performance.
Honestly id prefer to wait a bit for something stable tham get another half
arsed exploitable stack. Many here still remember the horrid days of java
past.

