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.
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.
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.
I find Eclipse PDE to be stellar when it comes to OSGi development. Only the services tooling is a bit lacking. I do not understand what you mean with JDK integration of OSGi isn't great.
My biggest complaint is that javac is unaware of the claspath restrictions. I made an attempt at writing a custom compiler extension on top of the javac API, but gave up, do to various issues. One really annoying one; integration with maven was a pain, not the JDKs fault, but still...
It's been a while. I can't be much more specific. I remember I had a lot of trouble with tycho, so I gave up on that. I used the BND tool for generating all module manifests.
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).
> 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.
For a single application / project that is most often the case in my experience.
The link in the mail https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri... 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"
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!
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.
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.
Last time I had to deal with it was years ago with Apache Camel/Service Mix and I didn't like it.
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.
Have you ever wanted to run out of permgen really really effectively? Have you ever wanted to run a bunch of stuff inside of a single jvm and have an even harder time than normal ensuring that all of your apps are actually up and running? Do you like re-inventing wheels with concepts that were dated and overly complex five years ago? OSGI!
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.
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:
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.
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.
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.
It should be noted that the compressed value is inside a jmod JAR so it doesn't usually need to get decompressed before use I wouldn't think (granted java.exe is buried in there last I checked).
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.
And you could do that all along using ProGuard on rt.jar (without redistributing it). I remember this being in the 30 MB range, too, so Jigsaw really seems to be utterly useless in reducing the minimum footprint. They could have just allowed vendors to split rt.jar officially.
(Other code generation and linker options,[1] GCC instead of Clang, different C/C++ standards, printf(3) or write(2) instead of puts(3) and `void main()` instead of `int main()` all had no effect on the binary size).
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.)
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.
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.
I like,and use, Java, but the fact that the C hello world requires no "interpreter" (JREs almost always also include one or two JIT compilers, and sometimes no interpreter at all) doesn't make the comparison unfair.
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).
Right but the other things in that list were interpreted languages. A purely compiled language is certainly going to be smaller, but that's slightly apples to oranges.
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.
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?
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.
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.
Summary: Jigsaw suffers from a low usefulness-to-complexity ratio, and wants to reinvent all the wheels rather than building on and standardising existing conventions.
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.
> 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.
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.
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.
"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)
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.
