Concerns with JPMS spec and Jigsaw implementation
mail.openjdk.java.net
mail.openjdk.java.net
https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d3...
There are many large applications that can benefit from jigsaw; this is sad.
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.
Simplicity, native language integration and a sane path for a Java linker.
No, they won't. Eclipse runs fine on Java 9 and AFAIK there's even limited interoperability.
There are other issues with many of the tools.
Do you mean that when you compile with javac you see non-exported packages?
> integration with maven was a pain
Were you using Tycho? Were you running in "manifest first" mode and were the issues related to resolving bundles?
> There are other issues with many of the tools.
Can you be more specific?
In the end after successfully using OSGi for distribution, and guaranteeing module separation in a 250kloc project I led, I've decided that separate api and impl modules managed by maven are good enough, with lints to guard against Class.forName() shananegans.
My point is: I personally worked really hard to make OSGi work, it was not fun, I'm sure I was doing something out of the norm, and I'm not a Java novice. So having something baked into the language and jdk would make this experience better. (I am not advocating for Jigsaw over OSGi, btw, just native language and tool support for a modularity).
For a single application / project that is most often the case in my experience.
Do you mean readability?
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!
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.
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.
Curious to know what you don't like about that stack? We use the heck out of ServiceMix/Camel and personally I'm thrilled with it. I consider it a great platform for building backend services (micro or otherwise).
At the end of the day, OSGI is pretty much just Java. I mean, a bundle is a jar with some extra metadata packed in. It's not some radical departure from standard Java.
I think Sun let their pride get in the way 15 years ago, when they refused to just incorporate OSGI into Java as the "official" modularity spec, and instead wasted years of time on all the various failed efforts to define a standard Java module system. And as a result, here we are all these years later, still fighting over this, when OSGI just gets the job done.
OSGi was yet another bad architecture tacked onto java for no real benefit that over-promised, under-delivered, and wasn't even a good fit for the technology at the time.
My OSGi experience comes from Day Software if that was an outlier then maybe I was just burned by them.
http://mail.openjdk.java.net/pipermail/jpms-spec-comments/20...
https://jcp.org/aboutJava/communityprocess/edr/jsr277/index....
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.
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).
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.
Over half of that (21 MB uncompressed) is class files indeed, and those could be trimmed. Another ~40% is native libs (at least on Windows) and surely some of that could be trimmed if unused, granted in Windows the largest is the MSVC runtime.
I would expect projects to crop up (I might make one myself) that subdivide java.base even further.
VB6 1.3MB msvbvm60.dll
Java8 150MB C:\Program Files\Java\jre1.8x\
dotNet 250MB C:\Windows\Microsoft.NET\Framework\
$ echo 'main(){puts("hello, world");}' | cc -fno-PIE -m32 -w -xc - && wc -c a.out
8392 a.out
[1] I tried all the ones listed here, although I didn't try the more exotic methods at the end: http://ptspts.blogspot.com/2013/12/how-to-make-smaller-c-and...
(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.)
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.
In fact, it's the point of the comparison.
That said, unless the C binary was statically linked against the CRT, the size of the CRT should also be included (at least on Windows).
Project 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.
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.
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.
There are already various module systems for Java, most prominently OSGi.
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)