Monday, June 05, 2006

JavaSE 7 a formal request (sort of)

Okay its time to be clear about what I think Java SE 7 should look to do:

  1. Have a standard jar dependency management approach (Ivy or Maven would do)
  2. Have a standard mechanism for defining additional elements to download (might that be JNLP?) and where they can be downloaded from
  3. Have a standard deployment file that indicates the specific elements required for a given application
  4. Have the ability to not require/deploy those elements not specifically included
I think that is it for the mechanism, then the second bit is as follows
  1. Have a core set of required libraries (maybe as little as java.* maybe as much as everything in Java SE 5)
  2. Define a set of standard profiles for three common usage scenarios (server, user desktop, developer desktop) and the ability to dynamically apply profiles (if we can co-host multiple applications then they should each have profiles)
In this way J2EE vendors, and the Spring, Struts, Jini, etc crowds could all define profiles for their applications for different usage scenarios that complement their other deployment efforts, these profiles would indicate what facilities (jar files?) are available to the developers. In this way we could specify SERVER profiles to indicate the facilities available to all, and maybe in time have application profiles to indicate those things that are available to only a specific application.

Now I know some people will argue that in part you could do this using security, but the reality is that most projects work on jar files and then choose what jar files to deploy where, also security means that the jar files are already loaded. So if you think about grid deployments and hydration/rehydration then this gives you the ability to check the deltas that require shifting rather than having to take the whole application context in one go.

Simply put,
  • I want to define that my Java Desktop application uses Matisse, Swing, Axis 2.0 (rather than JAX-WS), Log4J and doesn't include Java2D, MIDI support or any form of scripting.
  • I want to define that my server application uses EJB 3.0, JAX-WS (the one provided by the app server vendor), Log4J, JSF, MyFaces and no Swing, AWT, JAX-WS (as provided in Java SE 6), scripting, MIDI or Java2D

This way Java continues free to innovate (as Bill Joy was famously fond of saying "Most of the smart people in the world don't work for you" something that Sun would do well to remember) while enabling officially endorsed "profiles" and standard mechanisms to enable end users to remain in control of their environment in the way that they need.

For the consumer market sure fine keep pushing the ever bigger bloat out, it will keep the slashdot crowd happy too. But Java is big enough, and professional enough, now and its much bigger than just the JavaSE platform, its time to have a formal recognition of the fact that (to paraphrase Mr Joy) "not all of the best jar files come from Sun".

Technorati Tags: , , ,


Anonymous said...

I totally agree. This profiles thing would be just a tremendous step forward in java development. Big projects nowadays start getting into a jar-hell (thank god we do not have to deal with the dll-hell so much anymore).

Anonymous said...

FYI, some of your requests should be addressed by JSR277, which is targeted to Java 7.

Anonymous said...

I think that the next relase of Java should have some mechanisms which give the possibility to add a listener that trigger every access (also for reading) to class global fields. This can aim the develop of high performance applications that belongs to Future/wait by necessity semantics.