David Herron's Blog

David Herron has worked for 7 years in the J2SE Quality Engineering team. He has developed test suites and GUI test automation tools, and was a co-author of the java.awt.Robot class. His prior experience is in development roles, in cross-platform GUI toolkits, and electronic mail systems. David graduated from the University of Kentucky in 1988.

Browser makers walled javascript garden

Why JavaFX should be inlineable with HTML raises an interesting question in my mind. He's making a number of suggestions about JavaFX and many boil down to the power of "View Source" and perhaps JavaFX script code should be directly runnable as part of the source of a web page.

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?

OpenJDK in 10 yrs?

Frans Thamura asks an interesting question... What do you think of OpenJDK 10 years from Now? .. gosh. Okay, we first have to ignore the wags cluck-clucking over Sun's stock price and issuing warnings of doom. But hey it's a great question, what will be the significance of the OpenJDK 10 yrs from now?

Clearly the OpenJDK could reach "everywhere" .. all along this process of opening the OpenJDK I've been confident that it could have a significance similar to GCC where GCC provides compiler coverage for essentially every CPU and operating system. I'm a little surprised that Frans's vision is only on desktop & server environments as there is growing capabilities for the small devices to be able to run OS & graphics capabilities that have formerly been only for desktop or laptop computers.

e.g. I just bought a Chumby and it's an amazing peek into the future of small computerized gadgets. It's a small embedded Linux computer with a touch sensitive screen and wifi support allowing you to have an Internet-aware gadget displaying highly graphical applications in more places than before. The Chumby GUI is programmed in Flash but an equivalent device could be made which is programmed in JavaFX (whenever we finish JavaFX).

The OS's of interest need not be limited to Linux. There are other OS's of interest some which are more attuned to embedded devices. Also the JNODE project shows the possibility of an embedded device using Java as the OS.

Another idea would be that a wide range of languages would have great support on the OpenJDK JVM. Of course the Java platform has long been able to run lots of languages but with some focused effort in the multi-language VM project the story could be much better.

10 years is a long time in Internet years and it's quite conceivably possible we'll reach ubiquity by then. It's not guaranteed, of course, that it will happen. I'm confident it's possible.

R.I.P Usenet: 1980-2008 ?? Huh?

R.I.P Usenet: 1980-2008 ?? Surely you jest, surely this is one of those "the rumors of my death are greatly exaggerated" moments? Ah, but, there is some kernels of truth to the story..

Namely, well, I haven't dipped into any Usenet groups in years but the need for Usenet has IMHO been bypassed by the Web. I believe though that we've lost something in that Usenet's discussion was shared widely. In any case the story about the death of Usenet is that the junk in the binaries groups has been skewed heavily to warez and porn, especially kiddie porn, and that the ISP's have largely stopped carrying Usenet newsgroups because of the "why take the risk" and "why bother" memes.

There may be, as the article suggests, continued clusters of NNTP servers sharing a few newsgroups back and forth. But the Usenet of old is clearly gone.

I first found Usenet in (as near as I can remember) late 1985. It might have been 1986. I was a system administrator for a set of 4.2BSD Vaxen at the U of Kentucky. One of the others in the team graduated and went to work for AT&T; Bell Labs, and began sending us mag tapes containing newsgroups and mailing list archives. As they used to say, never under-estimate the bandwidth of a station wagon full of mag tapes. Fascinated by the unix-wizards mailing lists and that ilk, I set about finding out how to get more.

At that time.. the U of Kentucky was not connected to external networks, no BITNET, no ARPANET, etc. Well, there was this Kentucky-wide "network" named KECNET which gave dialup terminal access to computer systems at various universities around the state. While it allowed for some interesting connections, with unix-wizards in my hands I had bigger fish in my sights. And there were!interesting!strange!clues!which!led!to!cbosgd and one Mark Horton. I was able to arrange for Usenet to be delivered to the U of Kentucky, and got 'ukma' to have a presence on Usenet.

But.. that ended up saddling the department with a large phone bill. Eventually the department chairman noticed the phone costs and raised a stink. I'm afraid the subterfuge of 'motss' didn't hide anything from him and still remember his sneer when he heard the phone bill was being spent bringing in 'motss' material. I ended up creating a shell script to help collect data about how widely the newsgroups were being read by the local users, and was able to show enough usage that the powers that were allowed our Usenet connection to keep running. Good thing, because by that time I was totally addicted. Oh, and that shell script? Brian Reid picked it up and used it as the data collection mechanism for the Usenet Arbitron service. hmmm...

Wow... just thinking about the kind of things which went on in Usenet-land. What fond memories. I feel privileged to have known Usenet during it's golden years, and to have been on the Usenet backbone committee.

April 1 every year was a special time. What rich tricks were played upon the hapless. The yearly posting from kremvax, priceless. One year I decided to forge a posting on comp.sys.amiga to look like it came from Dave Haynie, one of the lead designers of the Amiga. It said something like "I'm tired of boinging around, does anybody know of a good COBOL compiler for the Amiga so I can go back to writing business software"? That was a riot, especially when someone piped up saying he really did need a COBOL compiler for the Amiga.

So, okay, Usenet, dead? It's been a joke for such a long time. Tell me it ain't so. But, really, Usenet being still alive in this time frame would itself be a cruel joke. It's best to remember Usenet of the golden age, I guess, than to try and preserve it's antiquated ways which don't fit todays Internet.

cbosgd!ukma!david

Getting closer...

We've been working legal ropes for awhile to get this result: Sun Approved: Merge from BSD Java to OpenJDK. There was a funky little legal snarl in that the BSD Java team has been working on Java ports to xyzzyBSD for years but it was under the JRL or SCSL license and they couldn't directly offer their changes to the OpenJDK project. One little bit of interesting is the SoyLatte work by Landon Fuller, which was based on that very same BSD Java port. The legal unwrangling now allows Landon to post this: Sun has approved merging the JRL-licensed BSD Java to the GPLv2+ClassPath OpenJDK-6. That means that all of the BSD Java changes, including the SoyLatte Mac OS X port, can now be sent to the OpenJDK project, and an official BSD porters group can be proposed:

Cheers and 13949712720901ForOSX

But wait, that's not all... Dalibor noted a couple days ago that Openjdk 6 is in Debian Main... and our esteemed Linux strategist, Barton George notes OpenJDK 6 is heading into OpenSUSE 11. And there appears to be interest to include OpenJDK in Mandriva.

Thoughts on Rich Internet Applications

The latest javaposse episode had an interesting go around what is a 'rich internet application'. BTW, guys, I'm really bummed you're not having the 200th episode recording on Sun's campus, I was really looking forward to it. In any case given their confusion over what an RIA is, it indicates there's lots of confusion out there in the world over what RIA's are. So in an effort to solve this problem let me tell you what RIA's are.

Let's start by distentangling the words in the phrase:

Rich refers to a GUI application with lots of bling and sizzle

Internet refers to the network infrastructure on which the Web lives

Application is a $2000 word for 'software' or 'program'

Clearly what we're talking about is a GUI application that has fancy sizzle and makes strong use of the Internet. Maybe it was Macromedia who cooked up this phrase to apply it to Flash, but that means they practiced marketerspeak and misapplied words in a way which violates normal grammar and meaning rules. The above interpretation is the correct way to interpret this phrase.

Proper understanding of Rich Internet Application requires distinguishing the "Internet" from the "Web" as in Freeing the Internet from the Web 'jail'. The Web is simply one service which runs on the Internet. The Internet has a zillion potential services which can run across it, and the Web only uses port 80 and sometimes port 8080 or related ports. Obviously the Internet can do a lot more than the Web and I think it's a shame that the Web Browser takes up so much of the mindspace of using the Internet that we think the Internet has to be limited to the capabilities of the Web Browser.

This clearly means that it is completely incorrect to think an RIA is something running inside a web browser. An RIA could run inside a web browser, but because the Internet is much larger than the Web it is preferred to run RIA's outside a web browser. An RIA running outside a web browser will have more capabilities than one stuck within the confines of a web browser.

No matter how blingy a web app is, it's still a web app, and still is limited by the browser model.

An RIA is distinguished from normal applications by the amount of blingy sizzle, and by using Internet protocols. Notepad is clearly not an RIA (no bling no internet) whereas iTunes clearly is (a little bit of sizzle, and big time use of Internet protocols).

A web browser can be considered as an RIA, by the way. Especially something like an extensively customized firefox.

I hope this clears up everybody's confusion.

Free Java is nothing to yawn about

Neil McAllister asks Java is free at last. Now what? and seems to take the position that while Java is a very successful technology that since "The Linux community, in particular, has long viewed Java with ambivalence" that perhaps achieving this milestone of Fedora's OpenJDK/IcedTea implementation passing the JCK may not be all that big a deal. Huh?

There are other ways of looking at this.. such as this post by 'ctrambler' and this earlier post discussing the coming tsunami unleased by the OpenJDK.

Yeah, there are many in the Linux community who don't seem to care about Java. I've heard this several times from many people ... such as last month when I attended the Ubuntu Developer Summit (in Prague) and while there were many people interested that OpenJDK was coming to Ubuntu it didn't unleash huge excitement and fanfare. At least they didn't yawn in my face and instead they were very friendly (I really enjoyed UDS.. it was great great fun).

My theorizing is that the the state of Java-for-Linux before OpenJDK precluded Java from being widely distributed on Linux, and that installation hurdle kept many from installing Java on their Linux boxes, and that this kept Java a stranger on Linux which then led to the "don't care about it" attitude of some Linux folk. There's also some mangled history such as the transition from Blackdown's Java to Sun's and while that's pretty old history it may have left a bad memory in some peoples minds.

The Operating System Distributor License for Java (DLJ) project (FWIW for which I am now the tech lead) was an attempt to broaden Java distribution on Linux and OpenSolaris. The DLJ bundles are still a closed source binary but they are under terms which allow for redistribution and many Linux distros have chosen to redistribute DLJ-derived JDK bundles. Even so the DLJ-derived JDK is not distributed in all distros and the ones who do distribute DLJ derived JDK's are putting them in their non-free repositories because, hey, it's not under a free license.

Getting back to my theorizing ... the history up until this moment ... Sun's JDK RPM bundles .. the DLJ-derived DLJ bundles .. at no time until OpenJDK were fully useable and compatible JDK's available under terms which could be widely distributed in Linux distros. Comparatively other languages like Perl/Python/PHP/Ruby were under licenses that allowed wide distribution in Linux distros. Of course Linux people might not care about Java because they already have some languages they can use without having to deal with the hurdle of downloading and installing an RPM that isn't distributed through their regular packaging system.

2+ years ago when the DLJ project started it was like a breath of fresh air on Ubuntu to go from the nightmare install process it used to require on Ubuntu to the simplicity of "apt-get install sun-java5-jdk". As OpenJDK is more widely distributed in Linux it ought to, over time, make for enough familiarity to change the story of Java-for-Linux. In other words, familiarity and time may well do the trick.

It's not that today we are in a state of nirvana with Java-for-Linux. But I think we're on a very positive path and over the next couple years we should end up in a very good place. Uh, that is, unless the opensource-antibodies that supposedly infest Sun have their way ... (wink) Hmm.. We're 2+ years into the process of open sourcing Java and I have yet to see opensource-antibodies.

On the evolution of the Java plugin

Ted Neward on the demise of Java applets is an interesting look back in history (interview on the Sparkling Client podcast). The Java Applet was the first of the RIA platforms, long before Flash became the king of RIA, long before Silverlight was a sparkle in anybody's eye, long before DHTML and AJAX became suitable as a rich internet applications platform, the Java applet was there. But Ted is quoted saying that Applet's suffered from incompatibilities and then they became frozen in time.

My post last august, Java is doomed to failure went over some of the history, that blog title came from a 1997 CNET article predicting the death of Java due to a proliferation of incompatibilities.

It's not quite correct to say that the Plugin itself was frozen in time. But that's not to say the plugin experience was not frozen in time. I'm listening to the podcast and what Ted really said was the JVM shipped by Microsoft was frozen in time due to the wranglings of Sun/MS lawsuit. Yeah, okay, and I can see how that would have constrained application authors in that they had to assume the majority of their users were on internet explorer w/ the MS JVM frozen at 1.1.4.

Applet's certainly didn't play out the way they were originally portrayed. There was this long strange road which we traveled with Java and Ted gives an interesting take on that history. The Client side of Java was clearly not given as high priority for many years as the Server side. I do like what Ted quoted in this podcast, that HTML in a web browser was equivalent to a 3270 terminal with fancy graphics. You youngsters may not understand the reference, but the 3270 terminal paradigm by IBM was..ah..primitive.. and the HTTP request paradigm is very similar.

However the plugin itself continued to receive bug fixes, performance improvements, etc. However we even have seen the light and Java 6 update 10 includes a completely rewritten Plugin which offers amazing new featureitis. And then there's that little thing named Java FX ...

Should we, as Ted suggest in the podcast, relegate Java to the server?? That's a hard one to determine which is the best answer. Clearly however we intend to have success in the client space with Java FX. And there is this little fact that the "Client space" is much more than browsers on a desktop computer. Java is deeply entrenched in the cellphone market and there is this rise of interesting new mobile devices with more power that can make for a rich internet explerience, and which are not desktops running a browser.

It's clearly going to be interesting to watch this unfold over the coming years.

In the meantime I thought it would be useful to link these two articles from 1997 which go over the nitty gritty details of the incompatibilities in the Microsoft JVM. It seems every time I post about the MSJVM it draws people who think Microsoft was unfairly portrayed ... just look at the comments on my earlier post, but the fact is that Microsoft did ship an incompatible JVM.

Microsoft sheds its Java skin

How to avoid potential pitfalls of Microsoft's non-standard SDK for Java

Great milestone reached by OpenJDK on Fedora

Java is finally Free and Open .. hey, The Fedora/IcedTea team have reached a great milestone. Their build of the OpenJDK has passed the (extensive) JCK test suite. I bet they now have a huge appreciation the extent to which we took the slogan "Compatibility Matters!".

Since this inspired Rich to take a walk down memory lane... in May 2006 I was in the audience for the JavaOne keynote. I was real excited because a project I'd been working on intensely was about to be announced by Jonathan Schwartz and Mark Shuttleworth from the stage. This project, the Operating System Distributor License for Java (DLJ) was our latest hope to improve the state of Java on Linux by giving the world the JDK's rebundled with a more permissive license. It was going to usher in an age of nirvana and happiness, but it seems that Jonathan Schwartz and Rich Green had a different idea in mind. Jonathan and Mark did announce the DLJ project that day, and DLJ derived JDK's have been shipping in several Linux's and Solari since then. However Jonathan and Rich a few minutes after the DLJ announcement completely upstaged it with "It's not a matter of if but when" (or something like that).

Thus ensued a huge amount of work. The initial open sourcing happened on the first Java Freedom day, November 13, 2006. The second Java Freedom Day happened at JavaOne 2007 when the rest of the OpenJDK was released ... except... there was two issues, first that some code was encumbered and we weren't able to open source it right away. This made for a more complex build situation where replacement code was available as binary to plug in the holes left by the encumbered source. The second is we never got to open sourcing the plugin or java web start.

I see the slashdot thread, IcedTea's OpenJDK Passes Java Test Compatibility Kit, has it's usual set of mistakes and misconceptions so I'll be answering some of them as I go through the rest of this.

The IcedTea project formed almost immediately and initially its purpose was to reuse Classpath code to fill the gaps of the encumbered code. At some point in (?late?) 2007 they had a complete unencumbered IcedTea build derived from the OpenJDK7 source tree. At the same time in the OpenJDK team work was done to replace the encumbered code by various means. For some code we were able to get permission to release it under open source, in other cases we chose open source alternative implementations. For example a remaining encumbrance is the font rendering code, and in the OpenJDK we are using open source font rendering code (FreeType) but the closed source code is continuing to be used in the commercial JDK builds.

Performance .. the OpenJDK uses the exact same HotSpot as is used in regular JDK builds. Performance should be 99.9% the same. Since some of the GUI rendering code differs the GUI performance is likely different.

"Only 4% of the Sun Java code wasn't released. So IcedTea only had to implement the 4% of Java that wasn't GPLed." This is no longer true... the OpenJDK6 source tree is 100% unencumbered.

OpenJDK7? OpenJDK6? In the beginning there was OpenJDK, and it was pleasing to Richard Stallman and he smiled. However there was a promise made to have an open source implementation compatible with Java 6, and thus was OpenJDK6 born. OpenJDK6 is an example of making reverse progress by moving forward into the past ... OpenJDK6 is a fork of OpenJDK7 where features and code was removed until it could pass the JCK tests. If you look in the IcedTea project there are two branches, the one derived from OpenJDK7 and the one derived from OpenJDK6. It's the OpenJDK6 which the IcedTea/Fedora project have made pass the certification tests.

What's the big deal? This is Sun's own code base so of course it's going to pass the compatibility tests ???

Not so fast, as there are some differences from any other release which passed JCK6a. The last version to pass JCK6a was the Java6 release (which is up to Java 6u6). Remember that OpenJDK 6 started life as a fork of OpenJDK 7. While OpenJDK7 started from the JDK6 source tree ... some changes had been made. There was 20 builds worth of Java7 new feature development and bug fixes, and there was source tree rejigglings related to open sourcing. Further there were changed introduced by removing the encumbrances, and there were changes introduced by IcedTea/Fedora. This means there's a lot of ways a conformance failure could have been inserted.

Hey, great news and I hear there is some celebration at FUDCON. Wish I'd been able to attend.

August 2008

Search this blog:

Categories

Archives

August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005

Recent Entries

Browser makers walled javascript garden

OpenJDK in 10 yrs?

R.I.P Usenet: 1980-2008 ?? Huh?

Articles

j1-2k7-mtW09: OpenJDK Quality Team Introduction and Discussion
It takes a village to grow an open source project. Any open source project lives from a wide range of contributions, not just bug fixes, new features, and other changes to the software, but evangelism, user groups, artwork, and more. The OpenJDK Quality Team is being formed by Sun's Java SE quality team to inspire collaboration with the public related to OpenJDK and Java SE quality. The quality team gives you opportunities to create tests, perform test execution, give feedback on current test plans, and more. In this java.net Community Corner mini-talk from JavaOne 2007, David Herron introduces the OpenJDK quality team. Jun. 13, 2007

All articles by David Herron »

This work is licensed under a Creative Commons License.