Javalobby - Comments for "SwingSet 3 in JDK 6 u10 Beta"

Just wondering about Sun's

cc1590 — Tue, 08 Apr 2008 02:29:04 -0400

Just wondering about Sun's versioning strategy regarding Java - first we had JRE 6 update N, now it's 6u10.... Does that mean that we have to wait for updates 6 - 9 to be completed before the new consumer JRE is available ? Why is it not just called Java 6.1 (or 1.6.1)?

Though I do admit that Sun has often confused customers in the past about versioning - look at the Solaris versioning confusion for example (3 different terms for the same release at one point).

All fair comments and we'll

af45166 — Tue, 08 Apr 2008 02:08:59 -0400

All fair comments and we'll be tuning for size/performance as we approach the final release of 6u10. We'll be pulling out oscars.xml for lazy retrieval from the server (a better example of a networked app anyways), modifying the demo-cache strategy not to keep handles to all demos that have run, and of course profiling/tuning startup and other sluggish spots. We're in JavaOne crunch mode at the moment, but will be steadily improving SwingSet3 in coming months, so the feedback is appreciated. The beauty is that since it's a java.net project, we can evolve it independent of JDK releases.

SwingSet3 is gorgeous, but

opinali — Mon, 07 Apr 2008 08:29:45 -0400

SwingSet3 is gorgeous, but it's not a great advertisement for people looking at Java6 UpdateN as a RIA platform, for a single reason: massive footprint. If you thought SwingSet2 was bloated and heavy, SwingSet3 is much worse. Launching the demo with default JVM options (i.e., HotSpot Client and all other defaults) produces a process with 35Mb private working set / 69Mb commit set (measured on Windows Vista with Aero enabled, FWIW). But that's just to show its initial screen. After clicking once in every component option, memory usage ramps to 113Mb / 142Mb. After a more complete test - exercising each demo, e.g. dragging some columns in the JTable demo, opening the JColorChooser dialog and so on - reaches 146Mb / 178Mb. In a similar test, SwingSet2 (executed by the same JVM) consumes 108Mb / 143Mb.

Considering all new SFX in SwingSet3, I think the increase in resource usage is justified; the new demo is clearly doing a lot of additional work, and loading more classes and resources. So, I'm not complaining that SwingSet3 is poorly written - I wish all Java APIs had such a great set of demo code. The problem is that we need a lightweight demo of Java SE as a RIA platform. For one thing, SwingSet2/3 apparently consumes a lot of memory with resources (large graphics). SwingSet3.jar is a 5,9Mb file, but it contains 3Mb of images. These are all compressed (GIF / JPEG / PNG), so they will all be much much bigger when decompressed to 32bpp. Oh, there's also a 1,5Mb XML with Oscar prize results, and full source code for the source panes (all of which display formatted sources, in a rich text or HTML pane). I'm not an expert in Swing development, for one thing it's possible that most overhead from images vanishes into the VRAM with VolatileImages. Still, SwingSet3 chews far too much memory for an application that performs so little work - showing a boatload of components. Other competing tookits (including alternative Java ones) have similar, show-off-all-components demos, that exhibit instant loading time and consume a minuscle fraction of SwingSet's footprint...

Very interesting pics form

rick — Sun, 06 Apr 2008 13:45:44 -0400

Very interesting pics form the SwingSet update, thanks for posting them! I think these show signs of solid progress in the arena of desktop applications with Java and Swing.

Hello, I love the new look!

cowwoc — Sun, 06 Apr 2008 10:45:00 -0400

Hello,

I love the new look! I did, however, run into two problems:

1) The scrolling speed is set to 1. Please increase it to a more reasonable value.

2) Nimbus takes a *very* long time to initialize. Try switch between different L&Fs. Nimbus takes 3 seconds to initialize on my new machine and it doesn't get any faster if I repeat the process.

I still find the tabs and

okidoky — Sat, 05 Apr 2008 17:33:13 -0400

I still find the tabs and spit a turn off. Everything seems to have gotten a slight bit of a polish over, but they the tabs and split remain untouched, unfortunately. It's these little things that wil make people want to criticize or praise it.

Also, I wonder if that mandelbrot uses multithreading to take advantage of multicore systems. Silly, perhaps, but having it as a conversation piece might help sell Java. I'd be more than happy to contribute that part. Would it go in if I did?