# Thursday, 24 July 2003
« Abstract Windowing Toolkit | Main | PDC 2003 »
GridBagLayout and more AWT

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.
Thursday, 24 July 2003 17:38:07 (W. Europe Daylight Time, UTC+02:00)  #    Comments [2] Tracked by:
"online live poker games" (online live poker games) [Trackback]

Friday, 25 July 2003 18:29:04 (W. Europe Daylight Time, UTC+02:00)
I believe it is possible to code in such a way that overriding either method will work.

If you have two virtual methods A and B that are aliases for each other, put all the functionality in A and have B call A.

Then ensure that everywhere in *your* code, you always *call* B instead of A.

This works in all cases except if client code overrides B and then calls A.
Stuart
Friday, 25 July 2003 21:26:35 (W. Europe Daylight Time, UTC+02:00)
The deprecated method contains the actual functionality. The alias method then calls the deprecated version. I had to do custom AWT components ages ago (1.1/1.2 timeframe) and had worked out that that was necessary.

This was observable in such methods that call out again to user code when running in the Sun JVM, as you can print the stack trace to see the call order.
Brian Sullivan
Name
E-mail
Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Answer:  
Comment (HTML not allowed)  

Live Comment Preview