Are there benefits to a modular JVM for server-side development?

[Robert Lally]

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.

[David Linsin]

On the latest episode Dick mentioned, that the configuration of the
Java module system could potentially replace the classpath. IMHO, that
would bring some benefits to the server side. It's still a pain to
track down classpath related errors.

with kind regards,

David Linsin
- - - - - - - - - - - - - - - - - - - - - - - -
email: dli...@gmail.com
blog: http://dlinsin.blogspot.com

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com
> To unsubscribe from this group, send email to javaposse+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/javaposse?hl=en
> -~----------~----~----~----~------~----~------~--~---
>

[Neil Bartlett]

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

[Tom Hawtin]

On Dec 28, 11:34 pm, "Robert Lally" <rob.la...@gmail.com> 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,

One thing it might do is avoid security updates. If there is a
vulnerability in a module not on your server, you can discount the
problem without even looking at it and avoid having to upgrade.

Modules probably aren't going to be a panacea without technical issues
[1]. You can easily write a classpath on a command line. For modules
we have pretty, simplified powerpoint graphs. The graphs contain much
more information and different sorts of relationships, but look easy
because you haven't been shown the text representation.

Tom Hawtin

[1] http://faqs.irishferries.com/sailingupdate/SailingUpdate.aspx?route=Dublin%20/%20Holyhead&date=1&routeid=3

[newgeekorder]

I would expect that it will bring
- faster startup/reload times
- smaller jvm footprint
- module reloads for fixes and upgrades without having to do a server
restart.
- hopefully we might get better small scale java hosting to rival the
current php offerings.

the downloading of modules refers more to applets. A server jvm will
load from the local source.

ngo

On Dec 28, 11:34 pm, "Robert Lally" <rob.la...@gmail.com> wrote:

[Christian Catchpole]

Its always bugged me that Java is a monolith. That the language is
also tied to the API. Why CAN'T I compile it statically for an AVR
micro-controller with no GC? How do it I get it to run on the mid-
weight resources of my breakdancing submarine robot?

I would expect (hope?) that Sun will release a version of the JDK/JRE
which has all standard modules pre-installed - thus being equivalent
to what we have now. Problem solved. :)

[robilad]

On Dec 29 2008, 9:20 pm, Christian Catchpole <christ...@catchpole.net>
wrote:

> Its always bugged me that Java is a monolith.  That the language is
> also tied to the API.  Why CAN'T I compile it statically for an AVR
> micro-controller with no GC?

There is no AVR port in the OpenJDK, and there is no ahead of time
compiler in there either. That means you could contribute one, if you
want to.

cheers,
dalibor topic

[Christian Catchpole]

Yeah, its easy to complain I know. :) I started on a half-assed
solution.. All I need now is more time.. :)