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]
Thursday June 01, 2006
Tango, Semplice and NET2Java
Filed under: net2java
I contend Java and .NET are the Pepsi and Coke of development platforms today in terms of popularity. (No implied order...)
I've puzzled before about the lack of good tools that let people act on their own conclusions on the Pepsi Challenge equivalent for
development
platforms. That infamous marketing campaign has a fascinating history and folklore.
But for Java and .NET, where are the tools and technologies that let
them intermix the two or migrate skills or applications from one platform to the
other ?No sooner did I scratch my head than we are awash with fascinating Java / .NET projects. I should scratch more often ! Since I have had a number of questions in this area, I'll outline three new projects so you can see what they are, what they're good for and where they're at.
Project Tango: Java and .NET Web Service Interoperability
Tango is for intermixing Java and .NET (C# or Visual Basic) applications, using web services as the boundary. Its for developers working on one development platform (Java or .NET) to be able to interoperate with applications written for the other.
Tango is very unlike the bitter cola wars, because Sun and Microsoft engineers have been working together to make sure that the Java web services stack and the .NET web services stack interoperate. If you thought reading the ingredients on the side of a can of Coke or Pepsi was scary, check out the ingredients list on the side of a stack of web services. But for the normal, the upshot is that the Tango joint interoperability work ensures that messages produced on one side are comprehensible to the other, that the description of a web service on one side is comprehensible to the other, that one side respects the security guaranteed by the other, and the both sides agree on the quality of service guaranteed by the other. All very reassuring if you're managing inventory in a heterogeneous environment, for example.
The Tango engineers are well underway in Glassfish. Here's how to get it.
Project Semplice: Visual Basic for the Java Platform
Semplice is for developers who like the Visual Basic language and want to develop on the Java platform. If you are one of them, you may be a developer already familiar with Visual Basic, or perhaps you're a Java developers attracted to some of the Visual Basic language features.
(I'm with Miss Jean Brodie on the more sugary Visual Basic language features: "For those who like that sort of thing, that is the sort of thing they like".)
At the heart of this early stage technology, is a Visual Basic to Java-bytecode compiler. No small feat, since many of the language constructs in the CLR do not map cleanly onto the Java VM. Semplice also supports VB6 (bringing joy to the disenchanted ?) which has some very un-Java like constructs. I predict that Semplice is going to be most at home when tightly integrated with its development environment Java Studio Creator, which takes care of much of the heavy lifting, leaving the developer to fill in the corners with short bursts of application logic.
Tor demoed this to great success at JavaOne, and I join him and Herbert in beseeching Jon Kline, one of the other team members, to get a blog :-)
NET2Java: Translating .NET source code into Java source code
NET2Java is a .NET (C# or Visual Basic) source to Java source code translation technology. So this is for .NET developers who have already taken the taste challenge and have decided to move their work to the Java platform.
Developed by yours truly, and also in early stage of development, this technology includes language parsers for VB.NET and C#, together with an extensible library of .NET API call to Java API call translations. The ambitious part of this technology is to complete the library, which will require many hands, and is why I made it available recently. There's a NET2Java plugin for NetBeans that integrates it with the IDE so developers can easily switch IDEs while they're switching platforms.
So there you have it, three projects, three technologies, three different goals.
Oh, and by the way, here's the latest on the cola wars.
