Sun's JDK has been around since the first public release of Java some fifteen years ago. Since that time, the JDK has accumulated a very large number of APIs. Many of the newer APIs leverage older JDK APIs in order to maximize code reuse. Such dependencies, however, make it harder to create a modular JDK, writes Alan Bateman, a Sun engineer working on JDK 7, in Is the JDK losing its edge(s)?:
One of the goals for JDK 7 is to get us to a modular platform... A more modular JDK should get us closer to our goals to improve performance (download and startup time), enable the platform to scale-down, and more...
Getting there will be hard as it's a very interconnected code base with many undesirable dependencies between APIs and different areas of the implementation. These dependencies have built up over many years and releases.
Bateman gives an example of such dependencies:
Suppose you are using the Logging API (meaning java.util.logging). Logging requires NIO (for file locking) and JMX (as loggers are managed). JMX requires JavaBeans, JNDI, RMI and CORBA (the JMX remote API mandates that the RMI connector support both JRMP and IIOP). JNDI requires java.applet.Applet (huh?) and JavaBeans has dependencies on AWT, Swing, and all things client. Not satisfied with this, JavaBeans has persistent delegates that create dependencies on JDBC and more...
Think of it more like dinner for two except that she hires a fleet of buses to bring her extended family and friends to wait outside the restaurant...
Bateman explains the process that the JDK 7 teams is following to remove such dependencies:
At this time we have a tentative base module that is essentially the core libraries (think lang/io/net/util/nio/security). The dependencies that used to exist from the classes in this module on JNDI, deployment code, AWT, the preferences and logging APIs, and JMX have been removed or inverted. There is a remaining dependency on XML parsing (from java.util.Properties) and that will be solved in time.
All things Swing, AWT, 2D, etc. are grouped into a tentative client module. The APIs in this module are deeply interconnected and so pose a big challenge. There are still a few dependencies from other modules (like web services) on client that will require work but ultimately it should be possible to chop off the head, say when deploying on an embedded device.
What do you think of the goal of creating a more modular JDK for version 7? To what extent do you think it will benefit you?
Harmony already showed how to break apart the JDK, in much finer grained modules than 'client' and 'server'. To be honest, it's a bit too little, too late; not to mention the fact that the version number semantics of the modularisation proposal are nothing more than a random number generator. Sadly, none of the experience or benefit of wisdom is being used in the modularisation of the JDK at this stage; merely cleaving it in two is not going to be the answer.
I think the lesson here is dependencies have costs. If you ignore these costs you will eventually find yourself hopelessly trapped.
Another lesson here is that you have to think about modularity before you need it. Once you really need it, the difficulty of adding it will be much much greater.
> finer grained modules than 'client' and 'server'. To be Did you miss the fact that the dependencies on JNDI, JMX, Corba and others had also been removed.
I'd think this is normal evolution in a software system: it is not uncommon starting a project with n-lines of code and as long the project aim clears, ending with a final code base that is smaller and clearer. Probably the "extensions" could see an increase in size.
At least the craze with the LOC = productivity is now a thing of the past: probably over-specified system will follow in the near future.
But again a logging system depending on CORBA is a bad idea although at the writing time it looked right (depending on the specs requested I suppose).
Keeping the focus on a problem is the largest most difficult thing to do: libraries are often over or under specified for this reason.
> I think the lesson here is dependencies have costs. If > you ignore these costs you will eventually find yourself > hopelessly trapped.
Considering that the JDK has been very successful for more than 10 years, is "hopelessly trapped" such a bad thing? I question the "need" for modularization. RT.jar is 42 megabytes - huge by the standards of the 1980s but that's about 10 cents of disk and $1 of RAM today.
I have never been a big proponent of decoupling or "layering". (Same for MVC) Yes, in the abstract, it's a good thing. In some applications, where it is very likely you will want to change implementation, say of an XML parser or a networking layer, it is essential. But, in general, it is merely a "nice" thing that often goes counter to the many other principles of good programming, such as encapsulation, DRY, etc...
The coupling is usually there for a good reason. If you decouple Foo and Bar by creating a FooBarController, all too often I've seen the code turn into COBOL, where Foo and Bar become ignorant JavaBeans and all the logic goes into the Controller.
A couple of examples. People usually cite MVC as "essential" because otherwise the model may get tied to a specific GUI framework, like Swing. They say "well, what if we want to switch to SWT or HTML or Flash or...". It sounds good, but, in my experience, I have never seen a project successfully migrate from Swing to something else. You always have too much invested in Swing code, third party goodies, or programmer training. YMMV.
Is another case the company "infrastructure" code was really super-modular, divided into over 100 jar files. Which ones do you install? The short answer is all of them. So no advantage over one huge jar file. I think the idea was to be able to do updates better. Sounds good. But how do you keep track of which versions of jar #1 work with jars #2-100? Or if jar #57 is even needed? Consider the reasonable case where each jar has 3 versions. So, for each jar, there are 4 options: the 3 versions and "none". You have 4**100 possible configurations. That's getting close to the number of particles in the Universe.
> > I think the lesson here is dependencies have costs. If > > you ignore these costs you will eventually find > yourself > > hopelessly trapped. > > Considering that the JDK has been very successful for more > than 10 years, is "hopelessly trapped" such a bad thing? > I question the "need" for modularization. RT.jar is 42 > 2 megabytes - huge by the standards of the 1980s but > that's about 10 cents of disk and $1 of RAM today.
For desktops and servers this is not an issue. For devices, this can be a big problem.
There are lots of things that are not needed in a given environment. For example, if I want to put a java runtime in a robot, I don't need gui components. You can't use the Java language without getting all of these other things.
> Is another case the company "infrastructure" code was > really super-modular, divided into over 100 jar files. > Which ones do you install? The short answer is all of > f them. So no advantage over one huge jar file. I think > the idea was to be able to do updates better. Sounds > good. But how do you keep track of which versions of jar > #1 work with jars #2-100? Or if jar #57 is even needed? > Consider the reasonable case where each jar has 3 > 3 versions. So, for each jar, there are 4 options: the 3 > versions and "none". You have 4**100 possible > configurations. That's getting close to the number of > particles in the Universe.
OSGi addresses this. I've not had enough experience to know whether it is manageable but it does address this.
> environment. For example, if I want to put a java runtime > in a robot, I don't need gui components. You can't use > the Java language without getting all of these other > things. In which case you should probably be considering something like the Squawk VM rather than a full desktop JRE.
> > environment. For example, if I want to put a java > runtime > > in a robot, I don't need gui components. You can't use > > the Java language without getting all of these other > > things. > In which case you should probably be considering something > like the Squawk VM rather than a full desktop JRE.
Right. Doesn't that support the argument for modularity? Another example is that I work on environments where that either don't need or can't support GUI. Why should I have to have those in order to use Java in these environments?
> Another example is that I work on environments where that > t either don't need or can't support GUI. Why should I > have to have those in order to use Java in these > environments?
Are those environments sufficiently constrained that the size (on disk or equivalent) of the unused code is a problem? As far as I can see,in most cases which are that constrained, you would be using one of the special Java variants (ME, Squawk, etc) that are already more modular or simply don't have many features.
> Are those environments sufficiently constrained that the > size (on disk or equivalent) of the unused code is a > problem? As far as I can see,in most cases which are that > constrained, you would be using one of the special Java > variants (ME, Squawk, etc) that are already more modular > or simply don't have many features.
But that just supports the argument for modularity. Basically you are saying that 'normal' Java won't run on anything that isn't 'large'. I don't know much about Squawk but running ME means running a 20th century version of Java.
With regard to not needing the GUI packages on these platforms, that's just most of the time. There are uses of the GUI packages to create image files so in some cases they would be needed, but not normally. Probably there should be a way that doesn't require the entire Java GUI stack but that's the result of the lack of modularity. When everything comes in the JDK, these dependencies appear to be free so there less impetus to keep things clean.
It's probably too late for Java but this is precisely the reason that the use of 'normal' Java is basically confined to the server and desktop and only when startup speeds are not crucial.
Previous Topic
