Okay its time to be clear about what I think Java SE 7 should look to do:
- Have a standard jar dependency management approach (Ivy or Maven would do)
- Have a standard mechanism for defining additional elements to download (might that be JNLP?) and where they can be downloaded from
- Have a standard deployment file that indicates the specific elements required for a given application
- Have the ability to not require/deploy those elements not specifically included
- Have a core set of required libraries (maybe as little as java.* maybe as much as everything in Java SE 5)
- 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)
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".
3 comments:
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).
FYI, some of your requests should be addressed by JSR277, which is targeted to Java 7.
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.
Post a Comment