The Light Before We Land
Readying Swing for a high DPI future
Kirill Grouchnikov has an interesting blog today that calls on desktop developers to get ready for a looming change that most aren't really prepared for: the high-DPI future.
The problem is that if our GUI toolkits measure everything in terms of pixels -- especially if those pixels are counted in integers -- and every year there are more pixels in the same amount of screen space, then the GUI's will continue to get smaller and smaller as users buy increasingly higher-resolution monitors.
In Kirill's blog, Java on the desktop - trail behind or lead forward?, he notes Chet Haase's mini-survey, during a presentation at the Desktop Matters conference, of possible new Swing features. Chet got few takers for a feature request to better handle higher resolution (or ideally, to just be resolution-independent).
Even more interesting was Chet's phrasing of the question - it went something like "In a hundred years, when everybody has 9000 DPI monitors, how important is it for Java to support this?" Well, it won't be in a hundred years, it's already here and will only get bigger, and without immediate action Java once again will be left behind (providing it in another eight years circa Java SE 10).
Chris Campbell's comment to Kirill's blog nails the non-discussion of this issue perfectly:
I too was surprised at the small show of hands at Desktop Matters. I suspect that this is one of those areas that most developers don't realize will have a big impact on their user interfaces in the near future (kind of like software developers in 1987 couldn't care less about Y2K).
Kirill announces that the next version of his Substance look-and-feel will address this issue head-on, with some help from the JGoodies Looks project, and his blog offers a preview of scaled widgets under a resolution-aware Substance. Niiiiiice.
Also in a desktop vein, today's Weblogs features JohnÂ O'Conner's
Call for Submissions: Top 10 Desktop Sessions at JavaOne.
"The 2007 JavaOne Conference is right around the corner, May 8 - 11. JavaOne is the largest Java technology conference of the year. Drop the excuses, you have to be there."
@nnotation type or type @nnotation, RémiÂ Forax asks
"What is the best syntax to allow anootation on types ? I will not answer to that question but you can try to convince me."
Portlet tools kick off the Java Today section:
Did you ever think of creating your own portlet ? Did you find a portal to deploy the portlet created? Did you try playing around with the Tools available? Did you find the right tool? The tutorial PortalPack: Portlet Creation made easy says "the NetBeans Portlet Plugin will make portlet development as easy as writing a normal Java application, with all the features of portlets made available.
It helps in faster development , deployment and testing of portlets."
Providing another Java wrapper to OS X-specific functionality, the JMacAddressBook project "aims to deliver Java APIs that can pass communication to Apple's C-based address book APIs. This would enable developers to have a Java API similar to apple's C ones, in order to access, control and modify the address book." While the initial code relies on OS X's Java-AppleScript bridge, future versions will use JNI.
The Bits.Bytes blog notes The Demise Of J#. "There was a very interesting announcement at the Microsoft Visual J# Page ... to the effect of the immediate retirement of J#. I can't say I'm surprised really. The lack of properties was always going to be a headache. Plus Microsoft didn't seem all that fond of Visual J# either -- there was no support for Compact Framework applications, for instance, and all code examples are invariably C# then VB.NET."
This week's Spotlight is on the ROME project, "an open source (Apache license) set of Atom/RSS Java utilities that make it easy to work in Java with most syndication formats: RSS 0.90, RSS 0.91 Netscape, RSS 0.91 Userland, RSS 0.92, RSS 0.93, RSS 0.94, RSS 1.0, RSS 2.0, Atom 0.3, and Atom 1.0." ROME includes a set of parsers and generators for the various flavors of syndication feeds, as well as converters to convert from one format to another. Check out the Powered By ROME wiki page to get an idea of how many sites are using ROME for their feed needs.
In today's Forums,
gunderman is trying to figure out
Asynchronous non-blocking clients:
"I have an interest in writing a JMS transport implementation and peeked into the asynchronous client bindings. From what I've read, it looks like the AsyncMethodHandler will always delegate down to the SyncMethodHandler. So outbound calls will execute in a separate thread from the caller, but this new thread must still block waiting for a response. Is there a way to use what looks like asynchronous code on the client side and not block at all? The Transport layer would be responsible for resuming the code path when the response came in. I can write a non-blocking JMS adapter. I'm not sure how it fits into the Fiber and Tube infrastructure but surely there is a way. Blocking for a JMS response is sub standard. But from what I've read, the request path must always block. Is that true?"
tjquinnexplains some interesting GlassFish behavior in
Re: newbie classloader problems.
"Some background: When GlassFish prepares a class loader for use by an app, it uses its own EJBClassLoader which has some useful behavior that the JDK's URLClassLoader does not have. In particular, it has a done() method which the app server invokes to indicate that it does not intend to use that class loader any more. The EJBClassLoader can then clean up a number of things, such as open JARs, that it needed while it was being used. GlassFish invokes this done() method when the app is undeployed, disabled, or when the server is shutting down, and done() records the current stack trace internally so it knows what code invoked done()."
Patrick Wright explains where Swing Labs sample code is supposed to go, in
Re: Renderer snipps for JButton JCheckBox JLabel:
"I believe that, to date, the reason why there is no "samples" section is because swinglabs-demos was supposed to serve that role. It sort of does. The incubator does as well, but the code in there is not really organized so you have to spend some time with it to find things. Anyway, the problem with S/D is that it was also a sort of public showcase for SwingLabs, which meant there was a conflict of interest --collecting samples and showing how things work, on the one side, and showing off the dogs and the pony, on the other side. So, don't ascribe to malice what can be explained by ponies."
Current and upcoming Java
- MarchÂ 21-23 - TheServerSide Java Symposium 2007
- MarchÂ 23-25 - Greater Nebraska Software Symposium 2007
- AprilÂ 13-15 - Twin Cities Software Symposium 2007
- AprilÂ 16-20 - J2EE Training Philippines
- AprilÂ 20-22 - Greater Oregon Software Symposium 2007
- AprilÂ 20-22 - Greater Quebec Software Symposium 2007
- AprilÂ 27-29 - Northern Virginia Software Symposium 2007
- MayÂ 4-6 - Rocky Mountain Software Symposium 2007
- May 8-11 - JavaOne 2007
- June 24-28 - Jazoon'07
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
Archives and Subscriptions: This blog is delivered weekdays as
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.
Readying Swing for a high DPI future