David Herron's Blog

J2SE Archives

JRE / Google toolbar now live on java.com

Remember that vague announcement last week with cooperation between Google and Sun? The concrete piece of that announcement was for Sun to bundle the Google toolbar with the Windows JRE download.

Now, a week+ later, the combined JRE+Toolbar download is available.

The windows install help page discusses it, showing that the installation of the toolbar happens as part of the JRE Installer. Since I use a Linux system I haven't tried the Windows installer, but it appears you would go to the java.com JRE download page, select the Windows installer, and awaaaay you go. (Hurm, the install help linked from that page doesn't mention the toolbar installer, while the other help page clearly does....? I'll have to ask my teammate who's been testing this what's up.)

And, no, I don't know better than the rest of you what the Google+Sun cooperation means for the long term. The speculation about the possibilities sure is fun though.

Building JDK 6.0 on Windows

One of the things we've been doing is opening up the processes around Java, and distributing buildable source that's updated as we develop the 6.0 release. We really want feedback from the public as to whether we're going in the right direction, if you see any quality issues in your applications, whether we've broken anything, etc.

We are, of course, continuing to do the testing the Quality Team has been doing all along. But we know that we can do only so much, and that the real test is where the rubber hits the road, so to speak. In other words, where the JDK is run against your applications.

While we provide prebuilt binaries, you may also want to build your own. The licenses allow you to do so, and under certain limitations to redistribute modified JDK's. For example you might want to try submitting bug fixes, in which case you need to build a JDK to implement and your fixes.

With that, let me point you to this blog entry: Building the JDK 6.0 on Windows XP

This is a fairly comprehensive description on how to set up to build the JDK on Windows XP. There's a few simple requirements, such as having Visual Studio and such. It's all explained in the posting.

Tools to fit the work, and what's in a look and feel?

I just watched a long video shot by Scoble about the Sparkle product that Microsoft is brewing up. It gave me several thoughts to share.

But first, a coule links:

What is Sparkle and is it a "Flash Killer?" (arsTechnica review of Scobles move)

Manuel Clement and others - Introducing Sparkle (Scoble's posting on Channel 9 allowing the Sparkle team to demo the code)

My first thought is remembering a comment I heard at Java ONE a couple years ago. This was in a BOF about a technique for making animated cartoons that can be displayed on a cell phone. There was a lot of low level technical gruntwork there, such as a special image encoding due to the limitations of cell phones. But the speaker had a very good point he made.

It's great when the software tools match the needs of the person doing whatever task is at hand.

That is, a software coder has a different mindset and needs than the graphic designer. The sparkle example in the movie demonstrates this very well. When designing a user interface, whether it's in a web browser or a desktop application or a gaming box or whatever, you're gonna clash two worlds. Those two worlds are graphics designers and coders.

The world of coders is very textual. Software code is written as text, hence the part of our minds that gets exercised is textual. But creating graphics is hard from a software coders standpoint, speaking as one.

The world of graphics design is very different. It's a different mindset, different tools, etc. It doesn't work to give a graphics designer a textually oriented toolset because those kind of tools won't help them. They aren't oriented to their task. Likewise a musician needs to deal with notes, beats, chords, etc.

Hence, when you're developing your UI the team is speaking from different modes of work, and using different kinds of tools.

The other thought is, doesn't this Sparkle thing kinda throw out standard look and feel out the window?

Oh, and this applies very much to Java and Swing. One of the arguments against Swing is we've not done a great job with the application looking like a native application. Okay, that's a decent assessment and I can't argue very much with it.

However let me make an observation. The strict adherence to look and feel has been eroding over the years. On the Windows side the look and feel of applications has been varying all over the place. I'm typing this from my Mac OS X system, and I see windows in front of me using various look and feels. I have Safari and Windows Media Player, both using this brushed metal look. And I have terminal windows using the older lickable OS X look. I'm using Firefox right now with its attempt at the lickable OS X look. And I have some Java apps whose look and feel are something different.

And, with this Sparkle thing, the application designers can diverge even further from the standard look and feel. With Sparkle it's weaving wild graphics capabilities, both 2D and 3D, into the design of desktop applications. There's no way the result of Sparkle's capabilities is going to stay within any rigid lines of look and feel guidelines.

You could see this buried in the gleaming WOW'ness in the eyes of the Sparkle team.

Obviously Swing doesn't do what they're doing, and that's not my point. Instead my point is, doesn't the changing world say something about what Swing should be doing? Does it matter anylonger whether Swing is pixel-for-pixel matching the native look and feel standard? I see the wide variety of looks on the applications I use every day, and I think ... the user population has learned to cope with skinnable applications.

Of course there's a need to improve Swing. For example in Mustang we have a project to improve the readability of text rendering, making it more like native rendering. We'll continue to do those things just as we'll continue our effort to look like whatever the native look and feel is.

But as time progresses, and graphics support on desktop systems becomes more and more powerful, the OS vendors are building fancier display methodologies into their native look and feel. The native look is going to become even more divergent than it already has. I think the end user audience is going to become even more accustomed to dealing with applications using a variety of look and feel concepts.

A cool HTML editor applet

I've been wanting to find an HTML editor that's an Applet suitable for integrating with the "content management systems". I've used several of the javascript-only editor applet's (should it be called an "applet" when it's written in Javascript?), and while they're okay I know that Java and Swing ought to be able to do better. I was hoping to find a java HTML editor applet to be able to do a fair comparison.

Enter, Kafenio.editor: a platform independent, open-source HTML-WYSIWYG-Editor. (note: it's still in beta)

There's both screenshots and a demo on the web site. It looks really good.

I did find a couple small issues using it on my Mac. e.g. the common issue of using CTRL-B for selecting bold rather than COMMAND-B. It's just beta software so we can expect a couple rough edges.

Looks to be a good start.

This work is licensed under a Creative Commons License.