A few years ago, Elliotte Rusty Harold posted the article Ten Reasons We Need Java 3.0[2], in which he proposed a number of changes to Java that were big enough, and disruptive enough that they would require breaking backwards compatibility for Java code. Maintaining compatibility is one of the most consistent goals of Java, so this was obviously a controversial proposal. Nevertheless, it's hard to see how you get to something like, say, 4-byte chars to better support Unicode, without causing serious breakage.

The idea comes up again in today's Forums[3], in whichabu_abdulla_alhanbali raises the prospect of breaking compatibility with Java 7 for java 1.3[4]: "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[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[6]: "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."

The latest JavaOne Commmunity Corner Podcast[7] is on Open Software Factory[8], an ongoing process to develop a set of tools and a corresponding set of methods for effective Model-Driven Software Development (MDSD). "This talk will begin with a quick overview of basic MDSD concepts. The remainder of the talk will discuss how the Open Software Factory supports MDSD. We will summarize our current achievements and briefly outline our plans for the future. The talk will share our project's experience in both developing Open Software Factory and applying it to develop to simple 2 Demonstration applications."

In Java Today[9]:
Charles Ditzel links to a video with a revelation of a suprising JavaFX feature, in JavaFX PDF Viewer[10]: "I forgot all about this and I shouldn't have - at Chris Oliver's talk on JavaFX Script at JavaOne he showed a very elegant application for viewing PDF files. The way he showed it was quite interesting, he went through a number of slides and then showed a demo of the Swing PDF version - then everyone expected him to show the JavaFX Script version
and he surprised everyone by pointing out that the elegant app he was using for his presentation was the JavaFX PDF viewer..."

In a blog linked from the JDK community, Alex Miller argues for Make static typing work for you[11]: "Java is statically typed and this pervades the design and code written in it (regardless of whether you think that is a good thing). If you try to subvert this using reflection, you are working against the language and losing the major benefits of static typing, such as the ability to refactor, compile-time type checking, etc..."

Hot topics discussed in the 29th episode of the NetBeans podcast[12] include the release of NetBeans 5.5.1; a Glassfish debate and demo; the goldmine of technical articles loaded into the third issue of NetBeans Magazine; and what happens to those who bet against NetBeans. And as always, the NetBeans Puzzler.

In today's Weblogs[13], David Herron considers theBadness of open source business models[14]: "Dave Gilbert has an interesting blog entry, The Badness of JFree, quoting an email he received complaining about the business model he uses with JFreeChart. This points to a bigger issue of different ways to monetize work on an open source project."

Evan Summers has a tutorial blog on Java SSL Sockets[15]: "We build a trivial client/server demo using SSLServerSocket and SSLSocket
as provided by the Java Secure Socket Extension (JSSE).
We create a self-signed public key certificate for the server
using keytool, and install this on the client."

Registered users can submit event listings for the
href="http://www.java.net/events">java.net Events Page using our
href="http://today.java.net/cs/user/create/e">events submission form.
All submissions go through an editorial review before being posted to the
site.

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed[27]. Also, once this page is no longer featured as the
front page of java.net[28] it will be
archived along with other past issues in the
href="http://today.java.net/today/archive/">java.net Archive.

Should JDK 7 be allowed to break earlier Java code?

Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.