I did some work on the GNU Classpath GridBagLayout and it is now almost done (a large part was already done by Michael Koch). Obviously, writing the GridBagLayout code requires a good understanding of how it works. I never bothered to really understand the GridBagLayout, but I did use it quite frequently, a couple of years ago. I remember it was mostly a process of trial and error. After taking the time to figure out how it works, I must say that I actually really like it. It has a somewhat bad reputation in the Java community, but I think it's quite nice.

I can't leave it on that positive note, of course I have to criticize it as well. Sun has this really nasty habit of renaming virtual methods (adding aliases). This is not a good idea, to put it mildly. In JDK 1.4 they introduced: getLayoutInfo, adjustForGravity, getMinSize and arrangeGrid. These methods offer no new functionality, they are "replacements" for GetLayoutInfo, AdjustForGravity, GetMinSize and ArrangeGrid. So just because someone didn't abide by the method naming rules, some idiot now decides to enormously complicate the class.

You might think, what's the big deal? The problem is that when you're overriding a virtual method that has two names, you don't know which one you should override. Overriding both usually doesn't work either because you usually want to call the super class implementation one of which in turn usually calls the other version of the method, thus resulting in infinite recursion.

Anyway, I made new snapshots. Source and binaries.

What's new?

• More AWT support, still nowhere near usable. But see these screenshots for some non-trivial stuff that is (partially) working.
• Statically compiled classes are now annotated with a custom attribute for each interface they implement. This enables the Class.getInterfaces() to work correctly for statically compiled classes.
• Fixed a bug in Method.getModifiers() for constructors in statically compiled classes, that caused them to appear final.

Originally I had titled this item "Afwul Windowing Toolkit", but then I decided to look up the dictionary definition of abstract. It's one of those words, like its close relative virtual, that we (programmers) like to use a lot using our own private (to our group) definition, but what else does it mean?

Here are some definitions courtesy of yourDictionary.com

I always thought that the abstract in AWT referred to meaning 4, which is closest to our programmer definition, but maybe the joke's on us and did the original designers (and I use the term loosely) of AWT have meanings 2, 3 and 6 in mind

As you probably guessed from the above, I did a little work on AWT support. Here are two trivial test apps that I got working:

AwtTest.java. Getting FontMetrics, Graphics and Frame insets working. 

 
FlowLayoutTest.java. Button, TextField, Label, Panel, FlowLayout and BorderLayout. Also helped me figure out how ambient properties (don't) work.

Please note that only a very small percentage of AWT is implemented at the moment, so don't expect any useful applications to actually work.

What else is new?

• ikvmc now uses local variable name debugging information (if available) to name method arguments.
• Updated to work with current GNU Classpath CVS.
• Added SO_TIMEOUT and SO_REUSEADDR support to PlainDatagramSocketImpl.

BTW, the included classpath.dll contains a few Classpath AWT patches that haven't been committed to Classpath CVS yet.

Updated the binaries and source snapshots.

Mark Wielaard did some benchmarks of some of the free JVMs available.

I noted on the Classpath mailing list that the IKVM floating point performance is probably overstated, because IKVM doesn't implement FP correctly. It uses the .NET framework FP instructions and methods and those in turn are implemented using the x86 FP instructions.

The original JVM specification was very strict in specifying floating point operations. Basically, it mapped 100% onto the Sparc floating point model and this caused spec compliant FP code to be slow on Intel. I don't think any of the early VMs correctly implemented the spec so this wasn't really a problem. I don't know why early the VM implementers didn't implement the spec, maybe they felt the performance cost was too high or maybe they just didn't find it an interesting issue (the "problem" is that the Intel FP results are actually too accurate).

In JDK 1.2 Sun introduced the strictfp keyword and corresponding JVM method and class access flag. Interestingly, they loosened the default FP requirements and specified the original FP behavior for methods (or classes) marked with the strictfp keyword.

IKVM doesn't implement strictfp at the moment, but this isn't the whole story. For trigonometric* functions (e.g. Math.sin()) IKVM uses the equivalent .NET Math functions and those are (probably) implemented using the x86 FP instructions and these are not compliant with the JVM specification and I think that in this case the Intel instructions are not more accurate than required, but actually less accurate. So this is a real problem that should be fixed at some point in the future.

*This probably also applies to other Math functions, like Math.exp, Math.log, Math.sqrt, etc.