Chaotic Java

The best way to see what JDBC 4.0 is going to offer is to look at DataSet<T>’s documentation. There are some examples there that really make you want to try it out, even if you don’t work with direct database access at the moment.

For me - I can’t, and this relates to my on going rant about the fact that the beta of the new Java platforms is never released for Macs. I guess I should just install a Linux machine and get on with it. Until then, I can only theoritically talk about the coming Mustang.

Now, about JDBC 4.0 - It offers great simplicity for data traversal, encapsulating the data retrieved from the database for you inside struct-like objects. However, at this point there is no option to automagically define a relation between two of these classes and have JDBC do the plumbing for you.
Continue reading »

JSR 202, JavaTM Class File Specification Update, is one of the JSRs being added to Mustang, the next J2SE which is to be released this August, according to its current roadmap.

The JSR will introduce faster class loading during runtime thanks to a technique found by the CLDC team, as said in the JSR:

As part of the development of the Connected Limited Device Confguration (CLDC) the CLDC team wished to avoid the time and space penalties of performing full verification within small devices. They therefore developed a “split verifier” which split the verification process into two phases:

• The first phase can be performed when the class file is being created. It performs a scan of the class file and adds additional “StackMap” attributes to the class file for use by the second phase.
• The second phase is performed at run-time. The run-time verifier uses the additional StackMap attributes to perform the final class file verification efficiently. The run-time verifier does not rely on the StackMap attributes being valid and will detect and reject any false information.

Unfortunately, I couldn’t find any more information on this by merely googling.

The JSR adds some other improvements to the class file, but this seems to be the major improvement in it. My question is: Why not add Generic type information to the class file? This could serve a lot of purposes, the most important ones being:

• Reflection Adding the ability to identify which types the generified type is holding, much like an Array reflector knows what is the component type of its cells.
• Run-Time efficiency Using this information during compilation, some of the casting caused by erasure could be removed, providing faster code.

I wonder why it’s not added.. I’ve downloaded the JSR’s public review document, and I will try and see if I can find a reason. For now, I’ve learned for the first time that the “magic number” of class files (claimed to be the class file’s version - However, it has minor and major version properties) is equal to 0xCAFEBABE. Get it? Cafe babe? Pff.. Engineers..

I was going to implement my @WeakReference, I really was! However, the current apt tool doesn’t really cut it.

For example, it doesn’t seem to allow for processing inside code portions, only on declarations such as method declarations and class declarations. Another annoyance is with the way the apt API is supplied: The annotation processing API and mirror API are both in some com.sun.mirror.* package. Last but not least, there is no ant task for apt processing. This ensures a headache when creating build scripts.

That said, I am not sure the new API will allow me to implement my @WeakReference still, as I need my annotation processor be called for every instance of a previously annotated field/variable declaration. As far as I understand, currently only the declaration itself is called upon.

Some cute new features in the JSR 269 include easier annotation processor writing: Instead of writing a factory and a processor, such as in the current tool, you just write your processor and annotate it with whatever the factory would have returned.

This does not break the type safety the interface provides, as the annotatiosn are used to determine what values are returned from the factory’s interface methods. You can compare code examples of the old and of the new.

Another thing to take note is that annotation processing does not take place in an external tool such as apt, but are now done as part of javac’s work. This solves the ant task, I suppose.