Thursday October 12, 2006
Sampling Java SE 6 Features
Filed under: javase6
As if you didn't need any more reasons to go get JDK 6, we've made some changes and additions to the samples and demos we include in the JDK.
For those of you who are historically minded, the original bouncing doodad style applets appeared in the first JDK as demonstrations of what the, then, new technology could do. In later releases our thinking changed somewhat, so we stopped trying to do flashy (I know, but applets WERE flashy in 1996), and started adding samples that made the APIs easy to get your head around.
NetBeans Projects
You'll notice the first change if you use NetBeans (did I ever tell you I do ?). Because Ivan added Netbeans project files for the samples and demos ! (Now why didn't we think of that before...) Anyway, you can still build everything on the command line if you want to, as always. But building, running and browsing though the sample and demo code is so much nicer in NetBeans. As I was just doing (screenshot) to help me write an article about the new features in Java SE 6 for JavaPro (should appear later this month !).
Fresh Samples
We also added some new samples to help people out who are interested in the new APIs we added in Java SE 6. Load 'em up in NetBeans and hit run.
Real Web Services
 |
Rajiv designed really
nice sample for the new web services APIs we added to Java SE 6. Its in
two pieces, one is a server application that pretends to be eBay,
and exposes a simple web service for browsing items for auction. The
other piece is a client application that can browse the items in the
dummy server. But its
all web services, so the neat thing is that the client application, by
editing a property or two, can
also browse items that are REALLY at the REAL eBay (or in the developer sandbox, if
you prefer). Like I did - here's a snapshot or something intriguing I
found at eBay. I nearly bought it as well. Its so me. |
Scripting
Sundar cranked out a neat little application masquerading as a notepad text editor. Except its a JavaScript console written in Java, where you can type in some JavaScript and run it. Showing of course the new scripting support in Java SE 6. You can also have it load up some example JavaScript if you like - also known as the "here's one I made earlier" didactic tool. Here's what happened when I played around with it, hacking up some simple GUIs in JavaScript and then asking Scriptpad to run it
 The script... |
 ...this is what happens when you run it |
Annotation Processing
Joe, when not being interviewed by all and sundry, checked in a nice little annotation processor for checking the naming conventions described in the Java Language Specification are being followed. So if you've always been looking for a polite way to tell your best developer friend that the over/under-capitalisation in their class and method naming is just beyond embarrassing for you, feel free to compile the source code to this annotation processor sample and slip it into their build script overnight to avoid a tearful confrontation.
JMX
Daniel added a great sample to show how to use JMX to instrument applications to make them manageable. Well more a blueprint really because its a natural follow on to all the guides and tutorials we have in this area. What the sample is is a mini-scandisk application. You know, the kind of thing you can ask to look for obsolete files and clean them up, and that you might leave instances running on several machines so they can can do peroidic scans. And of course its instrumented with some JMX beans so you can control all the processes centrally from jconsole. Mwaa ha ha.
Did I forget anything ?...oh yes we started to dust off some of the older samples too. I'm afraid that the sample code in the JDK hasn't always kept apace of the new features in the language. But take a look at the source code in the 2D Demo - best viewed in NetBeans - and you'll see we're very much more up to date. Props to Nicholas (get-a-blog) Sterling for that.
We hope to do more in future releases. And Lance, I know you're busy, but don't forget I'd love a nice JDBC sample too. I'll have my people call your people...
Posted by dannycoward ( Oct 12 2006, 05:37:48 PM PDT ) Permalink Comments [2]
Tuesday August 01, 2006
Reason #199 to Upgrade to Java SE 6
Filed under: javase6
One of the exciting things about working on the Java SE platform
is that what we do
to it affects not only the Java SE developers, but all the Java EE ones
too. That's obvious when we think about what language
changes to make, or what core libraries we might
add. But there are some APIs that enable better development
experiences and runtime attributes higher up the software stack. Even
when some
can't see it yet.Case in point being JSR 199 the JavaTM Compiler API which we're adding in Mustang. There may be some of you who want to use this in a J2SE application. But you are probably doing something fairly unusual. Its more likely that you are a J2EE developer who will notice a pleasurable and important side-effect up the stack.
The Glassfish folks can hardly believe how much faster it enables their JSP engine to be.
So reason #199 for you to upgrade (your web server) to Java SE 6 in October is the Java Compiler API.
Posted by dannycoward ( Aug 01 2006, 03:17:18 PM PDT ) Permalink Comments [4]
Friday June 23, 2006
Java SE Deployment Demystified
Filed under: javase6
I've seen and heard how my dad installs software on his computer. He pencils notes from the messages that appear on dialogs and puts them next to the phone for when he and I speak next.
When prompted for a
decision during
an installation, he swings manically between over cautious, and wildly
reckless. He has to take breaks when it gets too much. My mum has to
take breaks when my dad's breaks get too much. In bleaker moments,
questions like "Do you really want to exit ?" become deep, fraught and
existential. As a published and
decorated expert on 18th century French philosophers, there is some
irony there.One of the reasons that web applications have become so popular, is that the user experience side of their deployment, which is of course the only experience that really matters, is invisible. This simplicity opened up all sorts of avenues to continuously evolving services that would have been otherwise impossible to deploy on a CD. Despite the loss of technical self-worth my dad has endured in the face of various scrapes with word processing software, he has no trouble installing the latest version of the application that gets him cheap flights to France several times a year.
He knows how to click on a link.
Now, some people's assessment of the interaction model afforded to web applications by the browser, is that enough is as good as a feast. Other designers crave to provide tastier suppers for their end users, and turn to rich client models for the user interaction. Whereas the deployer's 'todo' list for a web application reads:
1. Make sure user has a browser (DONE !)
2. Deploy current version of application to server (ONGOING),
for a rich client, the deployer's todo list becomes a little more daunting:
1. Make sure users have necessary client software pre-installed
2. Get the application to users
3. Get upgrades and bugfixes to users
4. Remove old application from users' computers when done,
especially since a less than perfect score from your users on any one of these can lead to a nasty bout of indigestion.
In the case of Java SE, depending on whether you wish to deploy your application as an Java applet or an Java application (decided by asking: does the app need to live a life outisde the confines of a web page ?), you have twin technologies in Java SE: Java Plugin and Java Web Start plus some help from NetBeans, that aim to bring much of the simplicity of web application deployment to Swing application deployment. Launching equals clicking a link. Let's take a look at your deployer todo list in this case.
1. Make sure all users have correct Java SE runtime.
The industry has done a lot of work on this over the years; about 9 out of 10 of every new PCs now coming prebundled with the JRE. But for the 1/10 case or for the cases where your application requires a different version of the JRE, we've added the Java Auto update facilities to Mustang. This means with a little extra work on the launch page (either like this, or like this) we've made sure you can make sure my dad has the right Java SE runtime, or help him to install one if not. Of course, since he's on his windows PC, he may need to accept an ActiveX control, so let's hope he's feeling optimistic.
2. Get Java SE application to users
Now once my dad clicks on the link to your application for the first time, he may be presented with some dialogs. OK, some may be there for reassurance, and others may present choices, for example if you need the application to access resources on the computer, or ask my dad to confirm he trusts the source of the application (fingers crossed !). For Mustang, we gave them a pretty good makeover. Plus thanks to a number of desktop integration features, my dad should be able to start your application (faster) next time like he does other applications. Maybe he won't get distracted by something else in the middle of the process because the download might be a little faster.
3. Get application upgrades and bugfixes to users
Of course if you chose to go the applet route, I don't need to explain to you how this works. For applications deployed with Java Web Start, Mustang smooths this update path with an improved update policy. The old policy risked freaking out my dad out by suddenly going online when he started your application because it was doing an update check. Apart from anything else, my mum might have been using the phone. Yes, they are still on dial-up.
4. Remove Java SE application from users' computers when done
I will confess, this is something my dad will never need to know, and in any case for Java applets this happens every time my dad moves away from the web page that launched it. Or when the applet cache finally gets cleared. But for those who do care, Mustang improves the integration between applications installed via Java Web Start and the Windows Add/Remove software management tool. So if you found the entries pretty cryptic for J2SE 5.0, take another look once you've moved to Mustang for a pleasant surprise.
Deployment of a rich client application is still more work than for a web
application, so I hope your users like the richer model when they run
it. I think for Mustang we've made some important incremental
improvements that should keep my dad from scratching his head. Did you
need another
reason to upgrade ?However you deploy your applications, just don't forget that for every user like my dad, who generally assumes any technical problem is a mystery of his own making, there's one who will kick your application to the curb, there's one other who will burn off any money you hoped to make from the application by sitting on hold on your support line, and there's another who knows how to escalate his or her frustration to your boss.
And finally, they are all just people. As Voltaire said, "All men are born with a nose and ten fingers, but no one was born with a knowledge of God.".
Friday June 16, 2006
Java SE 6 Mustang Enters Third Trimester
Filed under: javase6
Since there's been a big birthday this week, I want you to know that Java SE 6 'Mustang' is entering its final trimester with the release of beta 2, and mom is
doing fine. We're on track for the October delivery of a bouncing baby colt. Stay tuned to this blog for all the details.
This upcoming addition to your and my Java SE family will be the most publicly scanned, tested, ultrasounded release-ahead-of-delivery in JDK history.
And yet we still managed to surprise some of you !
Posted by dannycoward ( Jun 16 2006, 05:29:26 PM PDT ) Permalink Comments [2]
Friday May 19, 2006
Mastering Mustang, Developing Dolphin
Filed under: javaone javase6 javase7
Here are the slides for the presentation Mark and I gave on the upcoming and future release of the Java SE platform here:
Mastering Mustang, Developing Dolphin (PDF, 2.4mb)
Enjoy !
So as the last orange backpack leaves Moscone, we see the end of another JavaOne. Something odd happens each JavaOne, despite all the best efforts of the presenters and attendees to control the messaging, what ends up being memorable takes on a life of its own as the week progresses. For me, the two stars of the show were both technical (yay), and were
- the Ugly-Duckling-to-Swan story of Java EE 5 (which Bill
describes here)
- the activities bringing scripting languages onto Java SE (which I
have talked
about before)
