9 ms·

Concerns with JPMS spec and Jigsaw implementation

94 points by chris_overseas 10y ago

nullnilvoid 10y ago
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 10y ago
  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.
  - needusername 10y ago
    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.
    - bluejekyll 10y ago
      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... There are other issues with many of the tools.
      - needusername 10y ago
        > My biggest complaint is that javac is unaware of the claspath restrictions. 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?
        bluejekyll 10y ago
        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).
        needusername 10y ago
        > 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.
  - mindcrime 10y ago
    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 10y ago
      > 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.
    - bluejekyll 10y ago
      Read my thread with needusername. That pretty much sums it up.
    - needusername 10y ago
      > and create something that breaks existing OSGI implementations No, they won't. Eclipse runs fine on Java 9 and AFAIK there's even limited interoperability.
- jeremyjh 10y ago
  This looks more like a reaction from threatened incumbents than a genuine effort to reach consensus in everyone's best interest. https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d36dd6f https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d3...
- deleted 10y ago
  [deleted]
- andersonk 10y ago
  >Despite all the flaws of Java such as verbosity Do you mean readability?
austincheney 10y ago
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 10y ago
  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 10y ago
    > 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 10y ago
      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 10y ago
        With footprint of your Java images you mean the size of your Docker images?
godmodus 10y ago
"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)
- agumonkey 10y ago
  Agreed
- Reason077 10y ago
  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 10y ago
    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.
vbezhenar 10y ago
So, I guess, no modules in Java 9.
- pkolaczk 10y ago
  Without versioning they were almost useless anyway. They don't solve the major problem: diamond dependency hell.
  - Eduard 10y ago
    What do you mean here wrt Java module systems, and when was the last time you ran into this problem?
- needusername 10y ago
  Oracle is going to push through Jigsaw no matter what. There are already various module systems for Java, most prominently OSGi.
ognyankulev 10y ago
The link in the mail https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns 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"
- chris_overseas 10y ago
  Here is a response with a somewhat opposing view: https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d36dd6f https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d3...
  - DamonHD 10y ago
    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!
- nisa 10y ago
  How is having cyclic dependencies a good thing?
sorokod 10y ago
Redhat also voted No. http://mail.openjdk.java.net/pipermail/jpms-spec-comments/2017-April/000087.html http://mail.openjdk.java.net/pipermail/jpms-spec-comments/20...
MarkMc 10y ago
Can someone describe IBM's main objections? And will this mean that the Java 9 release is delayed?
- candiodari 10y ago
  https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri...
  - frik 10y ago
    It's pretty good summary. It makes it totally understandable that they voted no.
- Reason077 10y ago
  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.
MarkMc 10y ago
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 10y ago
  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 10y ago
    C 8.6kb
    - verroq 10y ago
      Since it's dynamically linked against the runtime library most of the time you need to include how big msvcrt*.dll is.
    - MBCook 10y ago
      That's an unfair comparison, C doesn't have to bundle an entire interpreter.
      - Sindisil 10y ago
        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).
        10y ago
geodel 10y ago
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 10y ago
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 10y ago
  Without Oracle there wouldn't be any community, who do you think pays the salaries of most OpenJDK devs?!
  - winteriscoming 10y ago
    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 10y ago
      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).
tannhaeuser 10y ago
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 10y ago
  > 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.
time4tea 10y ago
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 10y ago
  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 9y ago
    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.
spullara 10y ago
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.html https://jcp.org/aboutJava/communityprocess/edr/jsr277/index....
- deleted 10y ago
  [deleted]
hyperpape 10y ago
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?
mbfg 10y ago
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.

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 10y ago
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.
- needusername 10y ago
  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.
  - bluejekyll 10y ago
    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... There are other issues with many of the tools.
    - needusername 10y ago
      > My biggest complaint is that javac is unaware of the claspath restrictions. 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?
      - bluejekyll 10y ago
        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).
        needusername 10y ago
        > 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.
- mindcrime 10y ago
  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 10y ago
    > 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.
  - bluejekyll 10y ago
    Read my thread with needusername. That pretty much sums it up.
  - needusername 10y ago
    > and create something that breaks existing OSGI implementations No, they won't. Eclipse runs fine on Java 9 and AFAIK there's even limited interoperability.
jeremyjh 10y ago
This looks more like a reaction from threatened incumbents than a genuine effort to reach consensus in everyone's best interest. https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d36dd6f https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d3...
deleted 10y ago
[deleted]
andersonk 10y ago
>Despite all the flaws of Java such as verbosity Do you mean readability?

austincheney 10y ago

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 10y ago
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 10y ago
  > 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 10y ago
    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 10y ago
      With footprint of your Java images you mean the size of your Docker images?

godmodus 10y ago

"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)

agumonkey 10y ago
Agreed
Reason077 10y ago
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 10y ago
  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.

vbezhenar 10y ago

So, I guess, no modules in Java 9.

pkolaczk 10y ago
Without versioning they were almost useless anyway. They don't solve the major problem: diamond dependency hell.
- Eduard 10y ago
  What do you mean here wrt Java module systems, and when was the last time you ran into this problem?
needusername 10y ago
Oracle is going to push through Jigsaw no matter what. There are already various module systems for Java, most prominently OSGi.

ognyankulev 10y ago

The link in the mail https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns 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"

chris_overseas 10y ago
Here is a response with a somewhat opposing view: https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d36dd6f https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d3...
- DamonHD 10y ago
  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!
nisa 10y ago
How is having cyclic dependencies a good thing?

sorokod 10y ago

Redhat also voted No. http://mail.openjdk.java.net/pipermail/jpms-spec-comments/2017-April/000087.html http://mail.openjdk.java.net/pipermail/jpms-spec-comments/20...

MarkMc 10y ago

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

candiodari 10y ago
https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri...
- frik 10y ago
  It's pretty good summary. It makes it totally understandable that they voted no.
Reason077 10y ago
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.

MarkMc 10y ago

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 10y ago
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 10y ago
  C 8.6kb
  - verroq 10y ago
    Since it's dynamically linked against the runtime library most of the time you need to include how big msvcrt*.dll is.
  - MBCook 10y ago
    That's an unfair comparison, C doesn't have to bundle an entire interpreter.
    - Sindisil 10y ago
      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).
      - 10y ago

geodel 10y ago

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 10y ago

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 10y ago
Without Oracle there wouldn't be any community, who do you think pays the salaries of most OpenJDK devs?!
- winteriscoming 10y ago
  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 10y ago
    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).

tannhaeuser 10y ago

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 10y ago
> 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.

time4tea 10y ago

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 10y ago
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 9y ago
  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.

spullara 10y ago

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.html https://jcp.org/aboutJava/communityprocess/edr/jsr277/index....

deleted 10y ago
[deleted]

hyperpape 10y ago

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?

mbfg 10y ago

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.