In my previous post Open Source JAVA : Step by step, I said there should be a unique and simple way to submit bug fixes to Sun’s JDK. I was assuming that the only way was to go through the Bug Parade.
In fact, with JDK 6.0, the way to send a bug fix is to go to JDK Contributions. On this site, Sun let’s us submit fixes that are outside of the scope of the JCP.
This picture taken from java.net site shows with transparency how the JDK team will react to any submission : 
This is the kind of move that will make JAVA more open sourced.
Blog
Java
In this article, you can learn how to compile the Swing sources without doing a full compilation of the JDK. This way, you can fix Sun’s bugs yourself and even send the bug fix to the Bug Parade.
Interestingly enough, the original post comes from Bino George who is a member of the Swing Team. I think this is the kind of post that makes us closer to an Open Sourced Java. At least the way Sun sees it: Open but still controlled.
Talking about Open Sourcing Java, take a look at Jonathan Schwartz’s Blog. At the end of the article he says that there is much to come. Any ideas ?
I think that Sun should :
- Make it possible for commercial products and Open Source project to distribute/use/install a JDK more easily.
see here.
- Make it easy to submit bug fixes and not only reports on the Bug Parade.
- Release the JDK test suite so that anybody can test its own bug fix.
- Open source some parts of the JDK like the Swing look and feels while still keeping the control on integration into the standard JDK
Its only my view. Some want full open source with forking opportunities and full control on Java life. Some would prefer no Open source but more staff at Sun to fix things quicker (Bugs, Look&Feel, …)
Blog
Java
More and more tools are taking the train to Java Annotations. Most of them to ease code and xml descriptors generation. Look at XDoclet. It was supporting dozens of tools way before the introduction of metatadata annotations in Java 5 with JSR 175.
The main reason why we, developpers, like to use these annotations is that they help us concentrate on the Business logic, not on the framework, not on the proxies, implementations, descriptors, pick any… Code becomes clearer, safer and faster to write.
However, we have to be very careful on what we are using these annotations for. We shouldn’t express runtime information here. By runtime information, I mean data that one could change to adapt to its runtime environment. Let’s take an example : It’s ok to say which fields of you classes have to be saved in the database. It’s not ok to say which table to use. If we put the table name in the annotations, we’ll have to recompile and redeploy the application to change the table names. With standard XML descriptors and a dynamic implementation of our framework, we can change only the xml file.
If the future is to put everything in the code with annotations, maybe we should give the sources to the application server and let it choose between recompile or impact changes in the annotations.
Blog
Annotations, Java