Summary:
Among the most significant new JDK 6 features are improvements to Swing and related client-side Java APIs. In this interview with Artima, Sun Java Client Group architect Chet Haase discusses how performance gains, new APIs, and closer integration with the native desktop help developers write more appealing and better performing Swing applications.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: March 9, 2007 11:41 AM by
Chet
|
|
In this interview, Chet Haase predicted that rich-client Java, and applets in particular, will co-exist with, and complement, Ajax and other rich-client technologies. To what extent do you agree with Haase that Java can become an important part of a solution that includes HTML, JavaScript, Flex, and other client-side tools? http://www.artima.com/lejava/articles/state_of_swing.html
|
|
|
|
|
Is the year wrong on this article? shouldn't it be 2007, not 2006?
|
|
|
|
|
The slowness in loading an applet is not to do with the disk cache. As any Java developer will tell you having run eclipse and lots of other Java apps has no effect on applet start times. The java plugin is much much slower to start than a regular Java app.
More important though, is the fact it freezes the browser. Windows media player does the same thing, but flash does not. If flash can do it, then why can't Java? (IMO this is a major reason why most websites are moving to flv video)
|
|
|
|
|
> The slowness in loading an applet is not to do with the disk cache.
I thinkn it's more correct to say that the disk cache is not the only startup problem. I believe it's the most egregious, since the startup at first launch time is something like an order of magnitude slower than startup when the VM is warmed up.
I should also point out that for this comment:
> having run eclipse and lots of other Java apps has no effect on applet start times
you're not necessarily comparing the right things here. For example, if you run a Java app with its own JRE (for example, I assume that Eclipse uses its own private JRE), then having loaded that VM has nothing to do with loading the VM of the default JRE for the browser. So you can run these other Java apps all day and not affect the coldstart/disk-cache issues mentioned in the interview.
However, the other factors mentioned are also important.
- Plugin: There is extra overhead to loading the plugin itself, beyond loading the VM. In practice, this tends to be on the order of a second. I would like to see this improve, and some work that we're doing for the next JDK should help here. But I would still argue that this second is less significant than the ~5-10+ seconds for a coldstart launch of an applet.
- freeze: The current plugin model in Internet Explorer loads the plugin in the native thread of the browser itself, which causes the browser to hang during loading. I agree that this ends up with a pretty awful experience, especially in the coldstart cases I mentioned (any app hanging for 10 seconds for no obvious reason is Not Good). The work going on for plugin above also includes looking into changing this model to separate the plugin thread from the browser thread; I hope that we can do this successfully. But in the meantime, the work on improving coldstart as well as plugin loading overall should make any browser freezing during load less of an issue.
|
|