I think it will have a lot of value. My answer here is based on experience of using a modular server application based on OSGi... bear in mind that in the OSGi world we have been building modular applications now for years, so pushing a module system down into the JRE itself is simply the last logical step. Of course we have some issues with the way Sun seems to be going about it (i.e. why don't they use the existing proven module system rather than inventing a new one?), but let's set them aside for now since your question was about principles rather than implementation details.
As David mentioned (and Dick also noted in the podcast), a module system can replace the concept of the "classpath". It really is a dinosaur of a concept and the sooner it dies the better. Some problems are not solvable at all with classpath, for example when using two third-party libraries (let's call them A and B) that have dependencies on another third-party library C, *but* A depends on version 1 of C whereas B depends on version 2 of C. Using a module system with graph- based dependencies this problem is solvable. As an OSGi user I have not found it necessary to set a classpath for many years, and I hope many more Java developers will soon enjoy this benefit too. There are many arguments for modularity, but why modularity directly in the JRE? You're right that omitting unneeded modules (such as Swing/ AWT for a server app) is of minimal value on a machine with 16Gb RAM and Terabytes of disk. Instead think about versioning and evolution. One of the biggest complaints about the Java language at the moment is its glacial rate of change, with deprecated APIs never being removed from the JRE. Once we have modules with explicit versioning, and dependencies on version *ranges* rather than on single point versions, libraries will be able to put an upper bound on the version of each Java library they support, enabling the JRE libraries to evolve. Also, crucially, it will enable different parts of the JRE APIs to evolve at different rates. In Java today we need a release of the entire JRE in order to get a bug fix or enhancement in one part of it. This will require some cooperation from Java programmers, but it will lead to more robust and maintainable libraries and applications. Currently when we say a library needs version x of Java, we are referring to the entire JRE and also we also assume compatibility with *all* higher versions. That will have to change. In the future we will say that our library requires javax.swing version 3.2 through 4.0, org.w3c.dom version 2.3 through 2.5, java.net 1.1 through 3.0 and so on. Another potential benefit for server-side apps is hot updates of individual modules. A good module system like OSGi enables this, and in my experience with running OSGi-based servers it is almost never necessary to shut down the entire JVM. This is NOT about applications automatically downloading components on demand (though that could be an option for somebody who wants to do that) but allowing administrators in full control to update modules with fixes and new features without interrupting the operation of the server. To take your example of the guy installing a JRE instead of a JDK... the point of the modular JRE is that distinctions like JDK vs JRE melt away. The JDK will be simply the JRE plus some extra modules, so you can fix the "problem" trivially by downloading the extras. In fact you'll probably be able to get them using rpm or apt-get or one of those kinds of tool. Regards, Neil On Dec 28, 11:34 pm, "Robert Lally" <[email protected]> wrote: > I've been trying to understand if the proposed modular JRE architecture will > bring any benefits to those who predominantly develop sever-side > applications. I can imagine that startup times might be slightly reduced, > potentially memory footprint might be reduced, but other than that I can't > see many big advantages. On the down side, I imagine that there will be more > application failures when an app that appears to be working tries to access > a library that isn't in this particular installation. I've heard all about > how the JRE might go and download the components it needs, on demand; to > which I respond .. not in my secure hosting environment you won't. > > Is my FUD here misplaced? Are we really trading the security of the > traditional server-side Java stalwarts to make Java more attractive on the > client side? I'm sure that there'll be an 'All-in-one' download available - > I'm also sure that I've lost times of the occasions when an SA, with > profound knowlege of UNIX, but little knowledge of Java, installed a JRE > instead of a JDK. Adding more choices can't make life easier for them, and > by extension .. me. > > It is, of course, certainly possible that I'm getting nervous over nothing. > > R. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
