Skip to main content

How Near, How Far

Posted by editor on March 3, 2009 at 8:32 AM PST


Swing Application Framework revives; will it make JDK 7?

A couple weeks ago, we noted a blog that complained about the lack of activity in the Swing Application Framework, which as JSR 296 is still widely thought to be on the JDK 7 agenda.

Today, there's finally some news, with project owner Alexander Potochkin's first blog in six months.

I know this is not good to disappear for a long time from blogging and SAF mail aliases, I am sorry about that. This happened because Swing team had some urgent temporary tasks to work on. The good news is that most of the tasks are completed and Swing team has returned to its primary goal - Swing library.

I should say that this time I have really come back to SAF and this project is currently #1 priority for the Swing team. We organized a little team to move SAF further and now working on schedule. My team mates asked me what problems with the current SAF code come to my head straightway and how I envision the "ideal Swing Application Framework".

He then goes on to engage the community on a number of design questions the team is wrestling with, including the idea of having one Application instance per JVM (or per class loader), how the View class' concept of the menu bar works with the Mac's "one true menu bar", whether the coupling of SingleFrameApplication to JFrame is appropriate, and more.

If these issues are still in play, will the SAF make the cut for the Java 7 container JSR? Does it help that the framework is now the Swing team's "#1 priority"? What do you want to see come out of this process, or do you believe the desktop is already dead?


Also in Java Today, The Aquarium passes along news that an OpenSSO release schedule has been posted. "As Bert, Daniel and Mark have all blogged over the past couple of days, OpenSSO's release schedule is now online. The schedule lays out the features planned for the next four OpenSSO Express release, culminating in OpenSSO Enterprise 8.1, scheduled for March 2010."

The ubuntu-devel list is currently debating how to package large Java software stacks. Ubuntu's Thierry Carrez writes, "It is difficult to integrate the large recent Java software stacks (Glassfish, Geronimo...) in a Linux distribution in general. The key reason is that most of those stacks require very precise versions of libraries (JARs) to run and to build. They won't work with the latest version of libraries as those might change APIs and/or key behavior. Java developers are used to pick specific JAR versions and assemble the exact needed stack, they don't want to care about sharing their dependencies with other packages, or about dependencies being upgraded. Tools like Maven help them in this endeavor, and they rely very heavily on this external code : dozens of those JARs are usually needed at runtime, hundreds of those at build-time." Thierry seeks help from the community with the challenges of precisely versioning Java dependencies and building entirely from source.


In today's Weblogs, Kohsuke Kawaguchi covers some
Recent Hudson improvements with various OS. "On Unix, Hudson can now authenticate with Unix user database via PAM. For Windows, Hudson can now start a slave on Windows completely non-interactively. For Solaris, Hudson can now convert $HUDSON_HOME to run on ZFS file system, which opens up a lot of possibilities."

Masood Mortazavi has proposed some
Golden Rules for Contribution Based Communities. "Elsewhere, I recently wrote about the Golden Rules for Contribution Based Communities. I think it may be a good idea to post it here, in the blogsphere of the Java community, for your review and comment. The Java community has built many contribution based communities. So, I'm very eager to hear about your comments and suggestions."

Fabrizio Giudici considers his options for bailing on long-running tasks, in Cancelling tasks: Thread.interrupt() fragility. "I came to the conclusion that the Thread.interrupt() mechanism is too fragile. This section is a part of blueMarine that is likely to be expanded (for different kinds of queries) and there's potentially a lot of code that could be called in that thread, potentially by third parties. Having the code to respect the Thread.interrupted() stuff seems too a heavy prerequisite for the contract."


In today's Forums, jaywayjohan points out the security issues of ME record stores, in Re: J2ME RecordStore. "The record store in MIDP 2.0 is not encrypted, you need MIDP 3.0 for that. AFAIK this is not available on any phones on the market today. The MIDP specification does not say anything about where the RMS is stored. On many phones it is stored as a file where it is not reachable by a normal user. However this is not guaranteed. So if somebody hacks your phones file system, it is very easy to read the information from your RMS."

kumarjayanti explains GlassFish access concepts in Re: How are Principals, Groups and Roles related? "A Principal is generally a member of some group(s). Think of your user account on unix systems (it would be part of some group such as user/admin etc). Within GF you can either manually map principals and groups to roles or activate a canonical mapping called default P2R. When you activate default P2R every Group is mapped to a same named Role The result of an authentication should generally be a Principal set, some of the principals could be Group principals among them."

Finally, deepblue2000 asks Can LWUIT apps support GameCanvas in blackberry? "I was wondering if LWUIT apps on Blackberry can support having both a javax.microedition.lcdui.game.GameCanvas as well as the regular LWUIT display. Would there be any issues with this? For example is it possible for me to create forms containing instructions using LWUIT, and then when it comes to graphically intensive screens - that i can switch to javax.microedition.lcdui.game.GameCanvas? If so, how would this be accomplished?"


Current and upcoming Java
Events
:

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
. Also, once this page is no longer featured as the
front page of java.net it will be
archived along with other past issues in the href="http://today.java.net/today/archive/">java.net Archive.

Swing Application Framework revives; will it make JDK 7?

Comments

@evildeathmath additional reasons against webapps: I would never store my office documents at a server at Google or whoever. All my emails, numbers and data! Who else is reading them? When will the server be hacked? You'll never know. And even in times of high speed networks the network/server is down or often very slow, effectively eliminating all productive work with network apps. I even stopped using an online dictionary because of this and switched back to a desktop app. Network apps are a fallback to the times of the terminal and the exact opposite of the personal computer. They only make sense for shallow work with fast changing data like shopping apps. It is the main advantage of Java that you can distribute cross-platform applications via Web-start. These applications also work when the network is slow or down, but are easily updated. This is the main point of desktop Java in my opinion. Therefore Swing is relevant and needs to evolve. And therefore a good Swing Application Framework is very important.

No, the desktop is not dead, and is unlikely to ever be superseded by applications based on the current browser model for the simple reason that the performance of local applications is greater by several orders of magnitude. In cases where this doesn't matter, like a shopping cart app, an e-mail client, or a social networking system, webapps, being immediately usable from any machine with a browser, have long since won the battle. OTOH, web-based office suites are clumsy to use, as HTML/AJAX widgets simply don't have the flexibility of their desktop counterparts, and forget about doing any serious number-crunching software in JavaScript or anything like it. Desktops are here for the long haul for anything where performance is key and connectivity isn't a big part of the equation.