Sun (soon Oracle) is the owner and for the process to work out well the owner has to be enlightened enough to serve the needs of others as well as their own needs. In reaping rewards from building an ecosystem requires having the wisdom that your benefit comes from everybody happily using your ecosystem, and always acting to nurture the ecosystem you've built. Some styles of gardening (Permaculture) recognize this principle. However administrations change and while one set of people overseeing Java might be enlightened the next set might be money grubbing short sighted opportunists. I'm not pointing fingers at anybody, just outlining a general principle.
The question is.. is it appropriate to have the foundational pieces of the Java ecosystem in the hands of one company? Or is it better for those foundational pieces to be in the hands of a consortium whose purpose is the benefit of all?
Open process - When Java was first developed in the mid 90's the open source software world was nowhere as mature as it is today. In 1995 the open source software scene was very primitive even if some specific pieces of that scene were well developed and widely used. The JCP was born in that environment and historically has served mostly big business and mostly acted behind closed doors and secrecy. In todays world where the open source software scene is much more developed and accepted, is closed door secrecy of any use now? Of course the JCP has been undergoing reforms, a good thing. Also a language specification, VM specification, etc, those are not open source software, they are specifications. The IETF is an example of a standards organization developing standards out in the open in a way I longingly remember from the early 90's when I was still an electronic mail expert.
The JCP setup is tailored to the old model of iterating the Java platform. There is a platform JSR to define the Java <n+1> and a passle of specific JSR's for each feature in Java n+1 are formed to steer those features through the design and development process. This tied well with Sun's traditional 18 month or so development cycle of delivering a huge amount of change in 18-24 month cycles.
Does that model still serve us? Or is there are model with shorter cycles which would serve us better? For that matter Sun has been successfully delivering feature changes in the "6 update" train, going against their former rules of not adding features in update releases. (updates were only for bug fixes)
Having short cycles offers a lot of potential benefits. Witness what the Ubuntu, Fedora, etc projects have been able to do with short cycles. It means rapid adjustment of direction with changing conditions. It means a bug fix has a greater chance of getting into the platform than previously. etc.
]]>
The overall message is to convince developers that the Java platform is compelling, that Sun is providing this compelling ecosystem for developing applications, and that the developers can become uber-rich by developing applications for the Java platform.
It's a cool message.. Anyway it struck me how non-community-oriented this message is. It's delivered in a push model, that "we Sun are developing this platform for you <the developer>" rather than a community oriented message of "we came up with this cool thing, let's work together to make it totally great". At one point Jonathan said something about delivering compelling technologies that engage developers who are going to build the next eBay. This phrase "the next eBay" is emblematic of a problem Sun has in general, in that they develop lots of great technologies not all of which are lines of business that can do $1B per year. Sun's management however can only contemplate billion dollar business decisions and is incapable of working with smaller scale business decisions. Example in point: SunSpot which is going to remain an unexploited business opportunity because it's too small. Sun is leaving a lot of $$$'s on the table by being unable to exploit small business units along with the large ones.
In any case I want to get back to this distinction between the push model of developing technology to give to developers, versus setting up collaboration projects to develop technology ideas.
This is important in regard to the trending at Sun towards Open Source software projects. While the official definitions of open source projects focus on the licensing terms and freedoms granted by the license, it's widely recognized that community oriented development is a requirement for success in open source software projects. There are a lot of resources out there with guidelines for successful communities and how it exists within open source software projects. Yesterday @ CommunityOne the Ubuntu community manager, Jono Bacon, gave an excellent presentation on community (artofcommunityonline.org), for example. Basically a community is a cluster of people interacting with one another. It help's bring community into existence when the people gain value of some kind from participating in community processes.
It seems obvious to me the push model of delivering technology does not lead to community creation. The push model isn't very collaborative, not engaging people into interaction. How can the community form if there is not a compelling reason for people to interact with one another?
Perhaps this is a core reason behind a number of WTF issues related to Sun and Java .. Sun makes excellent technologies like Java, so why hasn't Sun been able to be successful as a business.
During the Keynote the tail end was led by the new overlord, Larry Ellison. There was a little dance on the stage which wasn't explained but reminded me of the 2006 JavaOne keynote which was Jonathan's first time as CEO giving the keynote. He and Scott were on stage and they explained that the widget used by the presentation leader to control the slides, that the official name for that widget was "The Pickle". They made a big hooraw about Scott handing The Pickle to Jonathan in a symbolic passing of the torch of authority from Scott to Jonathan.
During this keynote there was a similar passing of the Pickle. It went first from Jonathan to Scott who did a bit of joking around about reasons why Sun+Oracle makes sense, and then Scott passed it to Larry.
During this section Larry & Scott addressed the obvious concerns we might be having about the Sun+Oracle deal and specifically what it means for Java. It sounds good in that for example Oracle's middleware is 100% Java. Oracle's product line-up is a database engine plus a whole big slew of apps running on top of the database, all of which are written in Java. It's clear that Java is important to Oracle.
What isn't clear is whether the OpenJDK community is important to Oracle.
Nowhere in Larry's talk did he mention open source, community, OpenJDK, etc. Instead he talked in this same push model.
Larry also said a few oddball things ...
He's been meeting with various teams within Sun to discuss product plans. This makes perfect sense in that Oracle buying Sun is clearly going to mean a direction change for what has been Sun's product line. A specific weirdo thing he said is he hopes for "JavaFX Libraries from the OpenOffice team".
Uh... say what?
I've long been wanting that very thing. It makes perfect sense to me that an Applet to display OpenOffice documents would be extremely useful. And with JavaFX it's very plausible this could be a great user experience.
This would be known as Rich Enterprise App's. Rich applications need not be limited to consumer app's. There are plenty of examples of needing Rich applications for other purposes than immersive gaming. An obvious example is finance.yahoo.com and the like where stock information is presented as a fancy charting application.
It's nice that Oracle sees the need for Rich Enterprise app's.
However a couple years ago I had a chance to talk with a Marketing leader within the OpenOffice team, and brought up this very idea. That led to an interesting conversation.
Because of the OpenOffice architecture any display app to show an OpenOffice document would end up dragging in pretty much every OpenOffice component. OpenOffice's file format is a compressed ZIP file with XML files in a known/standard ODF format. This is why it seems compellingly possible that an applet could simply read the XML files and render them.
But OpenOffice has an embeddable object module so that e.g. you can embed a spreadsheet in a presentation to display charts or tables. Because of that any OpenOffice document can reference OpenOffice objects from any of the applications. Because of that even a simple viewer applet would be essentially the whole of OpenOffice.
Another fly in the ointment here is the various licenses involved. One of the big huge values of OpenOffice is it's open source license that e.g. allows OpenOffice to be in Ubuntu/Debian Main and have equivalent status on other operating system distributions. But JavaFX is not using an open source license making it infeasible to put JavaFX into those operating systems. If OpenOffice were to be rewritten in JavaFX that would put a dependency on JavaFX making it impossible for OpenOffice to continue being delivered in open source operating system distributions. That is, if JavaFX continues being closed source. Maybe JavaFX will be fast tracked into being open sourced?
An open question is whether Larry's statement means a demand to rewrite OpenOffice into Java/JavaFX .. or whether he only meant some kind of library. For example it might be possible to embed (JNI) OpenOffice native libraries as Java(FX) objects without biting the bullet of rewriting OpenOffice in Java. It would also be incredibly expensive to undertake an OpenOffice rewrite and also be very risky.
In other words I was left scratching my head and going WTF is he thinking.
Before you think I was turned off by the keynote, no, I wasn't. It was exciting the various ideas and things presented. For example they showed fabulous things with JavaFX TV, JavaFX BluRay, the new Authoring tool, and store.java.com. Very cool.
]]>
Rich UI requirements:
Richer user experience is more compelling to user more likely to be bought by users. Users want their device to be theirs, their own colors, making it work the way they want. Operators need to brand the device. Usability enhancements possible with rich UI.
JavaFX is a cross platform RIA stack, JavaFX Script is the language, JavaFX Mobile is for cell phones. "All the screens of your life" are defined as "Desktop", "Mobile" and "TV" (what about digital cameras?). JavaFX Mobile runs on top of Java ME. Same language, same API, for the core profile.
Tools: Netbeans; JavaFX plugin for Illustrator and Photoshop (Production Suite)
Capuchin: Bridge between JavaME and Flash Lite. Design UI in Flash with Java providing services. Combine two well known and widely spread technologies, Flash and Java. Capuchin API presented to joint MIDlet which contains both .swf content and MIDlet class(es). Flash can request from Java class, Java class can notify flash UI. "MXP" components provide services e.g. to access native services like calendar, accelerometer, contacts, etc, these components also available through relevant JSR's.
To aid developers to expose an Java service, they have an API generator tool which helps generate MXP components. They did not create their own GUI authoring tool, because Adobe's Flash is a perfectly fine IDE. SWF2JAR. http://developer.sonyericcson.com Requires Adobe CS.
There's an interesting strategy conundrum.. would it have been better for Sun to join forces with Flash Lite? Or is it better for Sun to attempt to own the whole stack with JavaFX.
For the demo they show a "Car Shop" application developed in both JavaFX and using Capuchin. It shows you can use two different technology stacks to provide very similar applications. The reason I posed that strategy conundrum is due to the expense of developing JavaFX and to ask whether that expense was worthwhile. Why not instead collaborate with Adobe to provide rich UI experiences on mobile devices? Clearly Sun chose to develop JavaFX.
Future? Sun's direction is clearly JavaFX and they decide JavaFX's direction. For Capuchin: SonyEricsson has 12+ devices now, also Symbian phones will have Capuchin. They will continue exposure of services, apparently promise to continue developing their stack.
Their demo showed JavaFX can run on SonyEricsson phones.
]]>There's a meme in that article that's been in my mind a lot, especially with Stephen Colbourne's series of articles dissecting the JCP. Maybe the JCP doesn't properly represent what the community wants regarding Java.
Many in the community regard Sun as the "steward of Java" and there are many questions over whether Sun is a good steward over Java.
But does Sun think of itself as the "steward of Java" ?? As an employee inside the Java SE team I heard different statements from different people. Sometimes we were positioned as Stewards, other times we were positioned as Owners. The role of a Steward is different than the role of an Owner, right? Sun's true vision of its role in the Java ecosystem is what flavored what Sun did for/to that ecosystem. Similarly Oracle will soon (?likely?) finish the purchase of Sun and then it will be their vision of their role in the Java ecosystem that will flavor what they do for/to that ecosystem.
Some of the criticism of Sun was not properly monetizing its software, such as Java. But would a Steward monetize fully? Or would they hold back for the good of the community? Is full monetization is something an Owner would do? Think: Microsoft and Windows and programmers tools for Windows. The big 8,000,000 lb gorilla in programmers tools for Windows is, so far as I know, Microsoft.
But monetization is only part of Owner versus Steward. Another part is feature choice, right? I never got involved with the EE end of the Java universe, so I'll trust The Register article when it says most of the focus of Enterprise Java developers is not the EE stack but the various smaller scale open source frameworks and tools. Hibernate, Spring, Maven, etc. This says to me that at the EE end the community is not developing the preferred technology through the JCP but through other mechanisms (primarily open source projects). That points to a failure of the JCP to properly represent what the community really wants.
That touches on concerns I've had for a long time. The decision making for Java SE, as I saw it occur, seemed focused on satisfying the needs of huge organizations over smaller ones. I always heard it stated as these huge organizations are big customers of Sun, buying lots of Sun hardware/services etc, and of course we should pay attention to their needs. Similarly it's well known that the JCP is run by the Executive Committees, and that the EC seat's are predominately held by corporate JCP members rather than individuals.
Does Java exist to enrich its owners? Or does Java exist to enrich us all? Who is to be making the decisions about the Java ecosystem?
Sun employees were the inventor of Java and that means (because software is a work-for-hire arrangement) that Sun has had the right choose how Java is delivered to the market, and what to do with this thing. For better or worse Sun's positioning of Java was as an open playing field for everybody to partake in (Sun==Steward). Maybe Sun's true vision is Sun==Owner and that distinction may be the source of much of the friction in the Java ecosystem.
What Oracle do we consult to learn what Oracle's vision is? And if the JCP truly doesn't serve our needs perhaps it needs to be killed, but what would or should replace it? Does it serve us best for significant pieces of the Java ecosystem to continue being developed outside a shared standards process? Or does the existing open source projects better serve the shared needs of the Java ecosystem? And should the core pieces of the Java ecosystem, the ME/SE/EE stacks, also be defined via open source projects rather than the closed source style of the JCP? Unfortunately we in the Java ecosystem/community cannot make some of the required choices, as they rest with the corporate overlords.
]]>To me the potential hookup seems like a bad idea. Sun plays a useful role in the computer industry as an independent company, that would be lost if woven into IBM. And the tremendous overlap between Sun+IBM leaves me scratching my head over what they could be thinking. Unfortunately Sun has run into some more serious trouble than they were already in.
Whatever the business stuff is being done.. the real puzzle is whether IBM will be a better steward of Java than Sun has been.
I really don't know.. Wonder what is on everybody's mind.
Here's a few items I'm finding in recent blog/news searches..
Dana Blankenhorn talks about The failure of McNealy's ponytail strategy .. the enterprise storage forum thinks IBM-Sun Merger Appears Near (with an announcement on monday) .. In JavaWorld they interviewed a bunch of folk about If IBM owns Java ... James Gosling is quoted warning of James Gosling warns of ‘culture clash’ if IBM buys Sun ... Forbes.com is predicting IBM And Sun: There Will Be Blood ... And C|NET's staff have written several articles about Envisioning Sun on IBM's horizon
]]>There are circuitous historical reasons for this but the fact is that OpenJDK 6, as good as it is, does not correspond to JDK 6uN for any value of N. OpenJDK 6 began as a fork of OpenJDK 7, and the team stripped out code from the OpenJDK 7 fork until it became compatible with the Java6 specification as verified by the JCK 6 test suite.
Joe Darcy has posted several blogs about this OpenJDK 6 Genealogy, OpenJDK 6 and 6u10 features, OpenJDK 6: Logistics of Partial Merge with 6u10, and the most important of these is: Forward to the Past: Toward OpenJDK 6
If you're scratching your head going "huh??", well, I don't blame you, just read Joe Darcy's blog postings and it will be clear as, well, uh, I just hope it's clear why.
The bottom line is that OpenJDK 6 works rather well, several Linux distros are using it as their JDK, it can be built to pass the JCK6b test suite, meaning OpenJDK 6 can be used to build a compliant JDK, and unfortunately it is this evolutionary sidetrack which we hope will be relatively short-lived. It serves a purpose, namely of having an fully open OpenJDK compliant with Java6 ....
It seems some people really like typing "./configure" rather than setting up environment variables and running "make". The IcedTea project originally began due to incompleteness in the OpenJDK (gaps due to encumbrances) and the community requirement of a fully open source toolchain and code base. IcedTea has long been a set of patches applied to OpenJDK, along with a different build system that is "./configure" based as I just said.
In OpenJDK we've replaced the encumbered code such that there are no gaps any longer. As we've done so I believe the IcedTea project has shrunken the number of patches they use. One nice thing seems to be that the IcedTea configure script makes it easy to build OpenJDK in many different modes such as using the Zero Assembler port to support compiling on non-x86/sparc chipsets, etc.
A big piece IcedTea provides is a plugin/java-web-start infrastructure. We haven't been able to open source our plugin and of course for 6u10 we completely rewrote the plugin. It is hoped we will open source the new plugin into the OpenJDK project but to my knowledge that decision has not been made concrete set in stone.
I don't spend much of my time looking at IcedTea so don't be alarmed if I've missed something ...
Okay, given that there is not a Java7 JSR and all the JCP stuff related to that issue ... Hopefully all that will be straightened out and we do have a proper Java7 JSR, so for the following please assume that's the case, that Java7's JSR status is straightened out ... the plan is that beginning with OpenJDK7/JDK7 that the code bases will be nearly identical. It is obviously expensive to maintain a fork, and if JDK7 were to diverge strongly from OpenJDK7 it would do two things: a) be very expensive, b) undermine our efforts at an open source ecosystem.
But "nearly identical" does mean it's likely there will be some differences.
Remember those gaps due to encumbrances? Some of those gaps were simply code we couldn't open source as of May 2007 but have since done so, other gaps are for code we still have to gain approval on (e.g. SNMP), but there is some code where there are open source replacements where we still use the old closed source code. This is primarily in font and graphics rasterization. The old closed source rasterisation code, while being encumbered, has had 10+ years of bug fixing and fine tuning etc and, for any open source replacement to displace that code in productized JDK builds, it would have to be provably as fast and stable and good quality as the existing closed code.
If we had followed normal release patterns JDK7 would be shipping about now. That is, Java6 shipped in December 2006 and our normal pattern is 18-24 months between major releases meaning the JDK7 launch would have been 2-5 months ago. What happened? Well, clearly there was a resource crunch on several angles.
For example getting the nearly complete OpenJDK source release in May 2007 took a lot of effort from lots of people. But there was also certain announcements at JavaONE in May 2007 (a little thing named JavaFX) which also turned into a major rethink of Java (as some have said, this ain't yer Dad's Java) and also a major piece of work to accomplish.
In other words instead of producing JDK7 we did JDK6u10 and JavaFX.
]]>I wanted to demonstrate first a few core bits.
I have a fair bit of experience writing feed aggregators in Groovy using the ROME library so of course for this JavaFX based tool I again turned to ROME. Maybe all feeds lead to ROME?
Because JavaFX fits into the Java ecosystem this means your rich media whizzbang RIA app can directly make use of the full breadth of Java libraries which are out there. ROME being just one of them. Take that Flash. ;-)
Referencing the ROME library is done in the familiar way
import com.sun.syndication.io.SyndFeedInput;
import com.sun.syndication.io.XmlReader;
import com.sun.syndication.feed.synd.SyndFeed;
import com.sun.syndication.feed.synd.SyndEntryImpl;
import com.sun.syndication.feed.synd.SyndEntry;
import com.sun.syndication.feed.synd.SyndEnclosure;
Then to read in a feed into your program:-
var inputter : SyndFeedInput = new SyndFeedInput();
var theurl : URL = null;
var feed : SyndFeed = null;
...
public function setFeed(url : String) : Void {
setFeed(new URL(url));
}
public function setFeed(url : URL) : Void {
theurl = url;
feed = inputter.build(new XmlReader(theurl));
...
}
Other than the slightly different syntax this isn't terribly different than how code would be written in the Java version.
One unpleasant fact is that a) RSS/Atom feeds tend to contain HTML, b) JavaFX doesn't have a direct way to display HTML. There is a Text widget but it doesn't have a mode to display HTML. One could incorporate a Swing JTextArea configuring it for HTML but then the app would not be portable to a mobile device. Sooooo.... I suppose the last option is to strip out HTML codes before displaying it in the app. I haven't implemented this in my app yet as it's suboptimal but it's really the only choice.
The last thing I want to discuss here is a pragmatic about displaying the content of a feed. I'm still learning this language but the following appears to be the most convenient way of displaying the items in a feed in an app.
var items = Group {
content: bind
for (entry in feed.entries) {
Text {
x: 10
y: (indexof entry) * 20;
content: bind entry.title
}
}
}
Unfortunately the ROME SyndFeed object is not conveniently implemented this way and a little bit of conversion is required.
Given a suitable definition of an Entry object
public var entries : Entry[];
Then use this method for conversion
function setupEntries() : Void {
var list : Entry[];
var i : Integer = 0;
for (entryy in feed.getEntries()) {
var entry : SyndEntry = entryy as SyndEntry;
var newentry : Entry = Entry {
author: entry.getAuthor(),
link: entry.getLink(),
description: entry.getDescription().getValue(),
enclosures: convertEnclosureList(entry.getEnclosures()),
title: entry.getTitle(),
date: entry.getPublishedDate().toString(),
entry: entry
};
insert newentry into list;
}
entries = list;
}
function convertEnclosureList(list : List) : Enclosure[] {
var newlist : Enclosure[];
for (item in list) {
var encl : SyndEnclosure = item as SyndEnclosure;
insert Enclosure {
type: encl.getType(),
sURL: encl.getUrl(),
encl: encl
} into newlist;
}
return newlist;
}
This is a big deal in some ways in that it is a radical departure from the past image Java has carried. Graphics and animation and media, oh my. Somewhere I heard this phrase This ain't yer dad's Java and it's accurate here. I've long thought if only we put as much attention into client Java as we have server Java that the whole thing would be in a whole 'nother league. We've finally done it, and I hope that we're not too late -- e.g. competitive marketing positioning could mean JavaFX fails to succeed due to nontechnical reasons..
So: 1.11 Will JavaFX be supported on Linux and Solaris? JavaFX 1.0 is supported on Windows and Mac OS X. Linux and Solaris support will be provided in a future release. Read into that what you will. Wei Qi Gao has a thing or two to say on this... and pushing pixels delves into the codecs
A question that isn't on the FAQ is whether this thing will be open source, or not. Much as I want this to be open source that isn't how it stands, at the moment. Whether this means we're going back to old proprietary habits remains to be seen.
Sun Frees Rich Internet Applications from Browsers, Releases JavaFX 1.0 - news coverage by JDJ.. and Sun Brews Up Rich JavaFX by 'technewsworld.com' ... and cote has some indepth coverage... and techpulse360
James Clarke has a little demo ... JavaFX - Inverting text color with a changing background. ... John O'Connor has a hint on installing JavaFX through netbeans ... basically, go into the plugin manager and request the javafx plugins to be installed. Couldn't be easier.
Alan Zeichick asks JavaFX: Do we need another rich Internet platform?.. that's a real good question. Wish I knew the answer. For better or worse we've spent the time, money, resources and manpower to create this thing so we'd better make the best of it. I think there is potential for some advantage because of the cross platform nature of the thing. Further in my opinion if it were open source it could unleash a lot of latent development interest which could democratize availability of rich multimedia experiences (since Flash has a pretty firm lock-hold on the market for providing rich multimedia experiences through the web).
Simon Brocklehurst has a different take ... that Applets could well be back! The bottom line is: even in 1.0 form, JavaFX looks good enough for us to evaluate for use in a real project where we don’t need Mac OS X support right now. but with some interesting counterpoints: While the video playback works fine on Windows (see above), the quality doesn’t seem to be quite there yet (as compared to Flash). well, we're just out the starting gate... hopefully this can be cleaned up... The default “JavaFX loading” animated graphic is ugly, and poorly conceived. hurm, interesting thought especially as he goes on to suggest there be no branding at all. I can imagine the typical marketer reaction is to demand everything be branded but I do recall seeing recently that flash applets have no branding during startup, so that's some precedent, and further that website designers really want to control the branding that appears on their site. Soooo...hmmm... Something weird is going on for JavaFX video playback - the web-page that loads is OS-dependent, so you get a different web page on Windows than you do on Safari. Does that mean not everything is the same for Windows and Mac OS X for video playback? If would be a problem if every page containing JavaFX video had to have different versions for different desktop OSes. Yeah, that would be a problem. I can say that the JavaFX code which plays video is the same across platforms (for some definition of 'same') however one issue is that each platform has its own preferred set of CODEC's. Such as playback of WAV doesn't work on a Mac, right?
Thomas Ng has some tips on developing javafx apps for different deployment modes. Included with the JavaFX SDK is a command line tool, javafxpackager, which can package an app for either desktop use, applet use, JNLP use, or as a .jad/.jar for a MIDP JavaME device (the latter function exists only in the Windows SDK). Your customers do not themselves have to have JavaFX installed, though you do need it installed so you can compile the app. The packager bundles everything required into the app packaging, and the Netbeans plugins for JavaFX do the same.
There is a javafx blog with a very tricky look & feel strikingly similar to the javafx.com site.. sigh..
Terrence Barr has a discussion of JavaFX 1.0 is here: On your desktop, in your browser, and on your mobile phone and gives detailed steps on getting an app packaged to run on a mobile phone.
]]>The role of the JCP is to oversee and coordinate specifications related to Java technologies. As Terrence said "Fundamentally, the JCP is a very open organization" and a large portion of the JCP membership is made up of individuals. However the EC's, especially in Java ME, are dominated by industry heavyweights. While the industry heavyweights do have a reason to be at the table and represented in decisions regarding Java technology directions, so too is there a reason and need for individuals to be represented in those same decisions. For some things the viewpoint of the individual, rather than the industry heavyweight, is very important to have in the deliberations.
Terrence makes a good case for Sean Sheedy, but since I don't know him I can't say whether or not Sean is a good choice. I do agree wholeheartedly that having individual independent developers represented in the JCP is vital for the JCP to be more representative of the whole of the Java ecosystem.
On Windows applications usually deploy as a .exe which hopefully doesn't contain a virus and which you run an installer which weaves registry entries and drops .DLL's into the DLL Hole and so on ..
On Linux you have several packaging paradigms, from .tar.gz to .rpm to .deb .. The Linux distros have varying policies for packaging Java app's and dropping them on the file system. And while there is a long standing issue about whether the Java VM implementations are LSB compliant at least with OpenJDK the distros can take care that the VM is installed correctly on the OS.
On Solaris is a similar problem but the package format is different.
On Mac there's several ways to install an app, usually a .dmg and you drag a .app to /Applications. It's real simple. For Java the installation of the Java VM is more than a little screwy but there is a JDK style directory tree buried somewhere under /System/Library/Frameworks
My point here is there doesn't seem to be any standard way to deploy a Java app (and have it properly integrated with the OS) .. and that it the root cause is outside the hands of the Java ecosystem to resolve. The root cause is that the OS vendors do not have a universal application delivery mechanism. The OS vendors all have their own ideas of how best to package and install and deploy applications.
For most cases a Java app can be deployed as a .jar (depending on the requirements of external dependencies) and running the app is done with "java -jar file.jar" or in some cases you can double click it's desktop icon. Maybe this is the 'standard way to deploy a Java app' ?? If so this way to deploy is not nicely integratable with the OS preferred way to deploy applications.
With 6u10 we have this idea of deploying a Java app via a packaged JNLP which you drag onto the desktop. That may improve the deployment of applications for some cases.
A set of slides have been posted discussing what's new. This release started out as Consumer JRE and became more, and more, and more, etc.. It's a relief to have this out in the public. The DLJ bundles for 6u10 are also available.
What does this mean?
It means that client side Java has been getting some long long long needed attention and improvement. There were years when, obviously, the attention was on server side Java and, obviously, client side Java suffered. It is a relief to have attention on client side issues because in truth Java was the first RIA platform (long before this term was invented by a different company) but it was hampered in playing a significant role in RIA by, uh, shortcomings in the client side (sigh). 6u10 fixes a lot of issues and enables the underlying graphics changes needed for JavaFX.
But what does this mean for the OpenJDK project? As was pointed out in an openjdk.java.net mailing list a couple days ago, 6u10 represents a proprietary fork of code we're working on opening. Um, well, okay, uh, that's certainly true from one point of view. As good as the new features in 6u10 are it is a split between the JDK and OpenJDK, and unfortunately it's still unknown if/when we'll be able to move that code into open source. There was a sequence of great conversation in September on the discuss@openjdk.java.net list in which we made it clear that no decision has been made about if/when/where/how the new stuff in 6u10 would be made open source. Please stay tuned and maybe we'll have good open news relatively soon.
]]>That's an interesting suggestion and maybe it would work well. It remains to be seen whether that equation could be implemented from a technical standpoint. However there's a non-technical control point which is in the way.
The browser makers so far have forced the web side programmers of the world into using exactly one language for scripting web pages: Javascript
Maybe this is dangerous ground to walk because of all the history. But it really strikes me as a walled garden which prevents other technologies from taking part in scripting behavior on web pages. Javascript a.k.a. ecmascript isn't a bad language, and clearly a lot of things can be accomplished with it. But why is that the only language which can be used?