Never Going Back Again
Run, don't walk, away from
The downside of Javadoc is that there are general techniques that can't be understood by just looking at all the available classes and methods. This was one of the blockers I found when trying to learn QuickTime for Java many years ago: you'll never use 95% of its method calls, and the important 5% aren't adequately documented.
What might be worse is the "false friend" situation, where what you seem to need exists as a straightforward method call, but isn't the best way to achieve what you want. This is the case explored by today's Feature Article, in which author Chris Campbell explains The Perils of Image.getScaledInstance().
On its face,
getScaledInstance() seems to answer a perfectly straightforward need: scaling your images up or down. The problem is how you want your image manipulated, and it turns out that Java 2D has outgrown the simple solutions possible with this call, and you're better off mastering the options available with
Lots of developers have grown accustomed to the nice quality
SCALE_SMOOTH) over the years, but the general complaint is about poor performance. Due to the overly complicated
(in my opinion) design of the image handling APIs in JDK 1.0 and
1.1 (e.g., having to deal with asynchronous loading, animated GIFs,
and the whole consumer/producer model), it is very difficult to
optimize this code path, so performance of this case has improved
little over the years.
Fast forward to JDK 1.2 and the introduction of the Java 2D
API. The redesigned API offered shiny new classes like
Graphics2D, as well as
more flexibility in the form of
like the old scaling "hints" in the
RenderingHintsclass provides a number of similar
switches to help developers control the quality of image scaling in
a number of situations, like when calling the "http://java.sun.com/javase/6/docs/api/java/awt/Graphics.html#drawImage(java.awt.Image,%20int,%20int,%20int,%20int,%20java.awt.image.ImageObserver)">
scaling variant of
Read on to find out how to optimize your performance/quality choices with a better understanding of the
In Java Today,
Java SE 6 Update 1 is now available for download. A release notes page details the bugs fixed in this release, including many relating to Swing, and others dealing with US Daylight Savings Time changes that had previously been addressed by a separate patch.
java.net will be down for 24-48 hours on Wednesday for an upgrade to the latest edition of CollabNet's Community Edition software, as described on an upgrade page The upgrade will offer better performance, online authoring of project pages, and updates such as Subversion 1.4.3. You can test the new site on the staging server by adding "stage." before the "dev." in your project URL; note that you'll be looking at a snapshot of your project from a few weeks ago. If you find a bug on the staging server, report it via the upgrade page and you could win one of two iPods. Thursday's WebEx discussion of the upgrade is available as the java-net project's Upgrade - Find-a-bug Win-an-iPod file.
Issue 285 of the NetBeans Newsletter is out. Contents include: NetBeans @ FISL, NetBeans Day St. Petersburg and Sao Paulo, new modules on Update Center, GWT Support Plug-in, Charlie Nutter on Ruby, JRuby, and JRuby on Rails, Tips and Tricks Contest, 6.0 keyboard shortcuts, using IRB in NetBeans,using a drop down list to display data, instant Rails with NetBeans and much more...
In today's Forums,
shan_man has a long-awaited announcement in
"Alright folks, this is it... drumroll please...! After learning *way* more than I wanted to about software licensing, I've made it through alive (and with many to thank along the way). The Beans Binding project is finally public on java.net with a 0.5 release! http://beansbinding.dev.java.net As I've spent most of my time on the project over the last few weeks dealing with licensing issues, I can't claim to be an expert on the code yet. In fact, what I've released is in the same state that Scott passed it along to me (which probably means it's excellent, knowing Scott). So this is where Scott finishes, and I begin. We'll learn the ins and outs together, and hopefully you can suggest ways to make it better."
linuxjavadetails an interesting EDT-management technique for
Gettin' work done in Swing.
"Quick check here on how I'm doing things: I have a Swing app that does a bunch of stuff to a database. We all know, don't do anything like that from the event dispatch thread (EDT). So here's what I have: I create Actions, like a SaveAction, which saves stuff to the database. The actionPerformed() method of that is a SwingWorker, which has a doInBackground() method which does the database access. It also has a done() method which updates the GUI to reflect the results of the operation (success, failure, etc). Usually before the SwingWorker.execute() is called, the button that was clicked is disabled, so the user can't click it again while the operation is in progress. The button is re-enabled in the done() method Is this the right programming model? It seems like almost everything I do would fit into a model like that..."
dhunter21has a workaround for a
Heap Space Issue in JAX-WS:
"Our WSDL includes a byte array that is base64 encoded, and when a client sends us data ~50MB, we notice that it takes 950MB of heap space for JAXWS to read in this data. We also notice a large impact when the file size is just 3MB. Using a profiler, I tracked the problem down to some code in Stax that is using a StringBuilder to read in the byte array. It is constantly creating and copying byte arrays (as is the behavior of StringBuilderwhen not initialized to a good size). In order to fix this, we wrote a Servlet Filter that snarfs the byte array before it is sent to jaxws. Using this method we can ensure that a 50MB byte array only needs 50MB of heap space."
In today's Weblogs,