The idea comes up again in today's Forums, in which abu_abdulla_alhanbali raises the prospect of breaking compatibility with Java 7 for java 1.3: "I just want here to discuss the issue of breaking the compatibility for Java 7 to run application written in Java 1.3 or less. In addition what about breaking the compatibility for the OS (i.e. Windows 98, 2000 - Linux kernel 2.2 - Solaris 8) What we will gain for this in terms of memory, performance, size, enhance language architecture, ..."

What do you think? Are there needed changes worth breaking compatibility for? Is the need to break compatibility just illusory? Jump in the forum and tell us what you think.

Also in the forums, tsegaselassie is developing an ME app with NetBeans and needs direction on Loading Fonts in Netbeans 5.5: "Here's my deal, I'm trying to make a localized SMS message application using a certain font. Now when I was using the default J2ME toolkit provided by SUN, I knew how to load the file. I just changed the default font for the emulator and I worked like magic. However after sometime I can across Netbeans Mobility and I wanted to port my application to the IDE. The application works fine but since the font is not specified with in the application all I see are just hollow squares. So what I need is to know how to load the font in my application and bundle it in my application as a resource."

rah003 disputes a proposed SwingX painter-caching change in Re: Painters are no longer cached by default: "IMHO shouldUseCache() should by default return whatever isCacheable() returns whether there are any filters or not. This method should be protected so that overriding classes can implement their own caching policy following whatever business need they have. Or it could be externalized completely by having PainterCachingPolicy set in AbstractPainter and letting that (PCP) class to decide whether cache should be used or not."