Joshua Marinacci's Blog

Open Source Archives

The big secret revealed! A PDF viewing library!

Last week I told you we had a secret new open source project to release. Think of it as an early Christmas present. A project that you've never heard of and has nothing to do with JavaFX (which is partially untrue, but I'll get to that in a second). Well, it's almost the end of the week so here is the secret. You can listen to MP3 announcement (played on stage at the JavaPosse's JavaPolis session), or simply read on. We are releasing an

Open Source 100% Java PDF Renderer/Viewer

That's right, a 100% Java library which can parse PDF files and draw them to the screen. It's (creatively) named the SwingLabs PDF Renderer, and hosted at pdf-renderer.dev.java.net. It's the same license as the rest of SwingLabs (LGPL) so you can easily embed it in your own applications. Several of us inside the desktop Java team here at Sun have been working hard on getting this released and now it's finally here. Go check it out at pdf-renderer.dev.java.net.

So, you probably have a few questions. First of all:

Why should I care?

You should care because PDF is one of the formats that makes the web go 'round. Soon to be an ISO spec, PDF is the standard way of exchanging non-interactive documents on the web. Everything from tax forms to clip art can be stored in PDFs. Mac OSX makes heavy use of PDF both as an asset format (the many widget images found in Aqua) and also as an ideal archive format using AppleScript workflows. PDF is everywhere.

Once a PDF is created you know with great certainty that it will display and print exactly as you want on any platform. Hmm. Write a PDF once and run it anywhere? Sounds like a good fit for Java! Combined with PDF writing libraries (like iText), you can do pretty much anything you want with PDFs.

What can I do with it?

Anything you want! You can embed a PDF in your Swing app, draw on top of it, and even render to places other than the screen (like PNG images). The awesome guys over at Project Wonderland have even started experimenting with projecting PDFs into their 3D shared universe. Most importantly, we know you'll come up with things we never thought of. That's why we are open sourcing it.

Experimental Project Wonderland support

As another bonus, we plan to use this library to build a PDF imported for the designer tool that I'm working on. So, technically, this does have something to do with JavaFX, but that's not the focus. The focus is general PDF support for Java.

Where did it come from and Who is running it?

The SwingLabs PDF Renderer was originally written in 2003 by researchers at Sun Labs for an internal collaboration tool called Sun(TM) Labs Meeting Suite. It was originally targeted at output from OpenOffice, so you will find it can support most OpenOffice PDF exports.

While the original code drop is from Sun, we want to get the community heavily involved. To make sure that happens we have recruited Tom Oke from Elluminate to run the project. He will act as project owner and lead architect. He is rapidly becoming an expert in the code and looks forward to discussing features with other contributors. And speaking of other contributors..

What about iText and JPedal?

JPedal uses the GPL license, making it non-viable for certain applications. We think that the LGPL is a better fit for a library like this. iText is not a viewer/renderer. iText generates PDFs, it doesn't view them. This makes iText and the SwingLabs PDF Renderer great partners. I look forward to seeing how people combine them.

What are the limitations and how can I help?

As I said, we originally targeted OpenOffice exports, so a few things are missing. It implements most of the PDF 1.4 spec but is missing transparency, fill-in forms, and certain font-encodings. We hope that interested developers in the community will help us fill in these missing features.

If you want to get started then head over to the PDF-Renderer project website, download the code, and join the mailing lists.

NetBeans to become GPL!

I have been in the open source world for a long time. Pretty much since I first installed Slackware in my sophomore year of college (I'll leave calculating that year and my age as an exercise to the reader). I have always felt that open source and commercial interests, when managed properly, can have a wonderful balance that benefits both the consumer, developers, and companies. That's one of the reasons I came to work for Sun, in fact. At Sun I get paid to work on open source software, which was pretty much my dream since college.

Anyway, one of my big complaints with the way large companies deal with open source, including sometimes my employer Sun, is the unnecessary proliferation of licenses. The standard licenses are hard enough to understand with their annoying (but necessary) legalese. The last thing we need are more licenses that require coders to become lawyers if they want to use two products together. That's why I'm very happy to tell you that:

NetBeans will be released under the GPL v2 with Classpath Exception

It hasn't happened yet as we are still working out the final plans, but it's official and it's definitely going to happen. This is great for three reasons. First, you'll be able to get NetBeans under the GPL, just like you can get so many other great open source products. Second, GPLv2 + classpath exception is the exact same license that the JDK uses. This means more harmony with the rest of Sun's Java products. Third, this encourages the use of the GPL over other licenses which I hope will one day reduce the number of licenses out there in the world.

Okay, back to coding!

update

I linked to the FAQ in the header above, but I just wanted to make it expilict. Here's the FAQ on the change to GPL. And to further clarify, use of the GPL is optional. You can still use it under the CDDL if that works better for you.

Java FX updated, and a visit to the future of client Java

Open JFX updated

OpenJFX, the open source version of Java FX, was just updated. It has lots of improvements and demos, but the biggest thing is the first compiler, which will compile Java FX Script directly into bytecode rather than interpreting it. This is huge, because it makes FX Script a first class Java language, as well as being several orders of magnitude faster than interpretation.

Another big feature of this release is the better integration with NetBeans. FX Pad can now run directly inside NetBeans, further cementing NB as the Emacs of the 21st century. Now we just need a mail reader and mp3 player. :) I won't go into all of the new features, you can check it out for yourself here. Be sure to take a look at the SVG converter and chat client demo app: Casual. Lots of cool stuff in there.

The future of client Java

I've spent the last week in the bay area at secret clandestine meetings secretly planning the amazing top secret future of client Java and Java FX! Okay, that makes an endless week of meetings sound a lot more interesting than it really is, but there's some truth to it. We promised a lot of things at JavaOne, from designer tools to the consumer release of the JRE, and based on what I've seen in the last week I can say that we are really making all of this stuff happen. In fact, I'm going to come out here and make a bold (and not approved by my employer) statement:

2008 will be the year that client Java starts taking market share from Flash.

There, I said it. By JavaOne we will have completely re-energized client Java. And I mean client Java, not just desktop Java. Everything will be faster, prettier, easier to use, and easier to deploy. We will be better in the browser. We will be better on the desktop. We will be better on the phones. Existing technologies are being updated and new technologies will see their debut at JavaOne, if not earlier.

I'm not going to spoil things by telling you what's coming up. I'll just say that I have never been this excited about the direction client Java is going. Never! Exciting times are ahead for the Java community!

Musings on the new opportunities that Open Source Java brings

I have often said that I don't love Java because I'm at Sun. I'm at Sun because I love Java. I love Java so much that I wanted to work at a place where I can do the most good for the Java community, and Sun is definitely that place. Now that Java is open source I think it means only good things.

The big announcement today: Java will be open sourced under the GPL. I think it makes a lot of sense because it protects Sun's interest in preventing forks and also the community's interest in knowing that Java will forever be available in the public sphere. The GPL has always provided an option to fork just in case someone takes the code in a bad direction. Historically having this option available ensures that it never needs to actually be used, letting the community grow and thrive.

So what does this actually mean? What is the benefit to open source Java? How will things change? Here's what I think will change and what won't. I say this as my own opinion, not an official statement from Sun. I also say this as someone new to Sun, coming to Sun two years ago from an open source background. I'm sure that engineers with more experience than I will have different opinions. So with that, let's hear it:

How will open source change Java

• Real bugs will be fixed faster and non-bugs will be closed faster than ever.
• Java won't fork. Few developers will have incentive to fork Java. It's a lot of work for little gain. Branches for new features or new platform support: yes. A true fork: no. Not even MS has much to gain from this anymore.
• The JCP will grow and change. As before, big decisions about the future of Java will go through the Java Community Process. However, with more interested developers the ranks of the JCP will grow and change in some very good ways.
• Java will have first class support on Linux, Free-BSD, and other 100% open operating systems. This is huge. Hugely, huge. I'm hoping we'll finally get a KDE look and feel as well.
• NetBeans will open the entire JDK sources all at once. It's true, we're working on it for NetBeans 6. With the new editor infrastructure this will be possible. You might not actually want to do this, but it should be possible if you've got enough memory.
• We will see lots of small crazy experimental versions of Java that add different things. Imagine a JDK with Find Bugs, MySQL, SwingX, JDIC, JInput, JOGL, Java3D, Tritonus MP3, jSDL, KDE-Java, Gnome-Java and a bunch of other cool libraries pre-integrated. We might even see an entire downloadable VMWare virtual harddrive with Ubuntu + Super JDK + NetBeans preinstalled for the ultimate prefab development environment.
• More adoption of Looking Glass. Now that Java can be freely run on Linux desktops out of the box, there is incentive to ship Looking Glass bundled in with the OS. There's a lot of good 3D cards out there. Let's use'em!
• More 3D Java Games for all platforms. I expect that people will start shipping an optimized copy of Java embedded in their applications. The end user will never need to know that Java is involved. JOGL + Java3D is now available for Win, Mac, and any copy of Linux with the right X configuration (which is more common than ever).
• Burnable Java. Imagine a tool that burns a photo slideshow application preloaded with your photos, plus a copy of Java, straight to a CD. Hand the CD to your Mom, she pops it into her computer, and the photo slideshow starts right up. You'll never need to worry about the version of Java because it's shipped with your app. You don't need to worry about the OS because you code against Java, not against native APIs. (hmm. perhaps 'burnable java' isn't the right name for this. :)
• Java will grow to fill every available computing niche and finally achieve the goal of total world domination.

Okay, so maybe that last one is a stretch, but it's true that this will help to bring More Java to More Places.

So now we have a free runtime, competition between three groups to make the best IDE in the world, and a language that scales from cellphones to desktops to super-cluster-matrix-grids-thingy's. It's a good time to be a software developer!

Update on Bug 6477341,the '...' Windows Combobox bug.

Thanks to the hard work of several teams inside Sun (the development, testing, integration, and approval teams) combined with the persistence of the outside Java community, I am happy to say that the bug 6477341 will be fixed. More importantly it will be fixed in Java 6 final, not in an update release. The fix was just integrated into b103, which should be going up soon.

I'd like to thank all of you in the community to helped drive this bug to be fixed. Especially those of you who voted for it in the bug database. It really does help!

I also want to ask you all to go download Java 6 b103 when it's available. Even with a small change like this there is still a chance of a regression. I certainly hope it won't happen, but it's possible. People subclass Swing components in all sorts of weird ways. And on this note, I have to acknowledge the fact that this fix is conditional on it not causing any new regressions. At this late stage in the release, the most likely solution to a new regression is the removal of the code that caused it. So let's get all the extra testing we can, as soon as possible!

There are two lessons that we can learn from this. First, that I need to be more careful when working on multiple bugs that touch the same file. I have recently taken to creating sub-child-workspaces. This means I check out a workspace to fix the first bug. I then make a child of that workspace to fix the second bug. This makes merging a seamless process and avoids these kinds of conflict errors. It of course requires a version control system which supports an arbitrary hierarchy of workspaces. That's why we are very carefully evaluating what system we will use for the open source release of Java.

The second thing we can learn from this, I think, is that the system works. We have an open development model right now (not yet open source, but that's coming soon). We found this regression because lots of people had been downloading Java 6. Without the help of early adopters like you we wouldn't have found it until Java 6 shipped. The other half is that we wouldn't have been able to classify the bug as a showstopper and get it into the final release without readers and bloggers like you complaining about it. We really do listen to the community. We read the blogs, bugtrack votes, forum threads, and SDN comments. When it became clear this was a showstopper to the people who matter, you, we were able to officially classify it as a showstopper and get it fixed.

I think this was a definite success for our open development model and I know it will get even better once Java is completely open source. I feel very privileged to work on such a great product in a great, open community. I don't think I'd feel the same way if I was working on, say, Vista or Leopard.

My new opensource project: Flying Saucer, an all Java XHTML renderer.

I normally try to be even handed, un-biased, and bi-partisan; but today I'm going to shamelessly use my muchly vaunted position as a highly skilled blogologist in field of java.net to plug my new project: Flying Saucer, an all Java XHTML + CSS renderer.

When I was doing research for my two part series on HTML renderers for Swing (pts 1 & 2) I got to thinking Why are there so few renderers, and almost none that are opensource? Is it really that hard?. Initially I tried to fix some of the bugs in the HTMLEditorKit that comes with Swing, but found a slew of private methods that prevented me from improving it through subclassing. I also tried editing the Swing code itself during a four hour cross country flight, but to no avail. And even if I had made the changes I couldn't have released them with the current Swing license. With so little to go on I struck out on my own. I mean, really, how hard could it be? :)

Two months of hacking an hour here and there I found out how hard. It was both easier and harder than I expected.. To make life easier on me I decided to leave out everything that didn't directly have to do with rendering HTML on the screen. I dropped the idea of making a complete browser with a UI, javascript, debugging, bookmarks, history, etc. Those are all important but not the hard part. Since CSS and XML parsing are already provided by other libraries I reused them instead of reinventing the wheel. It's not that I dislike wheel inventing, it just that I have to be realistic about what one programmer can do in his spare time.

With that out of the way it was still too big. The core renderer of Mozilla took years to develop and the full time work of several top notch programmers. Gotta cut it down. Thinking about it, though, I don't need a complete webbrowser like IE or Mozilla. Since this is for embedding in my own programs most of the content will be generated by my own code. I don't need to deal with every browser bug and every malformed webpage out there. I could get by with strictly compliant pages and worry about quirks handling in a compatibility library. (to be built later, of course. :)

Now, if I'm going to write a new renderer from scratch I should go for the gold, ie: complete XHTML + CSS 2.0 (now 2.1). It's actually not as hard as I thought. The W3C makes some completely exhaustive specifications. The CSS 2 spec in particular is huge, but it does describe in great and explicit detail how each feature should behave (giving Internet Explorer no excuse for it's bugs).

So what do we have. I've written a renderer that takes a org.w3c.dom.Document object with inline styles and renders it into a scrollable JPanel. Most of plain HTML is supported, as are the full box model, tables, and images. Parts of relative, absolute, and fixed positioning work. The main issue is the bugs in float/clear, and the lack of forms support. Oh yeah, and it's really, really, really slow (Need some help with that. I used regexs for the text parsing). But it works and the supported features are pretty compliant.

I was actually surprised at how much I've done by myself. Still, I know the limits of one programmer, which is why I'm launching it as an open source project right here on Java.net. And I need your help!

This is a challenging project that needs some top-notch people. If you feel you are up to it then sign on to the project and join the dev mailing list. In particular I want to start breaking it up into modules and find owners for each:

• Rendering compliance (research the latest standards, build it, test it)
• CSS (parsing, converting, optimizing, rendering new features)
• HTML->XHTML converter (support for HTML 3/4.0 pages)
• Browser component (a standalone webbrowser based on Flying Saucer)
• Javascript support (how do we plug in rhino?)
• I18N efforts (how do we make sure the whole thing is i18n-able)
• forms (input, select, text area, etc)
• object and plugin support (SVG, xforms, flash, pdf)
• printing module (we can't print anything yet!)
• network module (ssl, redirects, image loading, etc.)
• performance and memory optimization (how do we make the whole thing as fast and light as possible)

I really think that a complete XHTML renderer is a vital component of any modern programming toolkit, and I'd like to see Flying Saucer become the best of breed implementation for Java. It's a lot of work but it's going to be rewarding. Come on in. The water's fine!

Oh, to just play with it quickly check the source out of cvs or download this zipfile. You only need Ant and the 1.4 JDK. Run ant test to launch the test program. Select different tests from the Test menu.

Update: I forgot some links. the project is here and the mailing list is here.

Java's got a Bad Rep: The Rebuttal

So it's been a week and I've seen a lot of response to my last entry. One commentor in particular asked for a point by point rebuttal; which struck me as a spectacularly good idea. Here are the bulk of the arguments and my responses.

The Arguments

• Java isn't Free / Open Source / GPL / RMS-friendly
• Why use Java when there are plenty of native languages / environments to choose from.
• Java is missing templates / preprocessors / lambda functions / other advanced language feature that only backwards cave-dwelling languages lack.
• There aren't any applications written in Java. It must be a failure.
• Java / Swing is slow, looks bad, and doesn't feel native, doesn't let me do cool stuff like animation, 3D, or sound.

Here we go.

The Rebuttal

(1) Since it's such a huge (and apparently controversial) topic, I am covering the open sourcing issue separately in this other post. However, in summary, opensourcing doesn't solve our problems and buys us very little, in exchange for a lot of new problems. Follow the link for a full analysis.

(2) Why use Java when there are plenty of native toolsets to choose from? Well, first of all, it's better than a lot of them. If you want to write an application (not a script or a device driver) then Java provides you with a good toolset, great libraries, and a clean language which learned from the mistakes of the past. It's simply a good applications language that can make your programmers more productive.

Java can also be "write once, run anywhere". For people who need to support multiple platforms, especially more esoteric ones where you could never hire a native expert (say the palm pilot, or win 98), or if you simply don't want the headache of dealing with bizarre version issues, then Java provides you with a consistent platform to code against. It's compile once, run anywhere features are especially important in the age of ubiquitous networks with code flying over the wire. Java Webstart has been a godsend to companies with locked down desktops spread over the globe. (potentially running eight different versions and patch levels of Windows).

So why use Java? Because its better than a lot of the alternatives for writing applications.

(3) Java is missing language features. This is probably more a matter of taste than anything else, but Java isn't lacking features because no one thought to add them. Nothing in Java is new. Every part of the system, from language to library to VM, was carefully considered against the 20 year history of OO languages. Preprocessors were left out for a reason. So were pointers. Java is missing a lot of the more esoteric features, but most of those features aren't used in day to day programming anyway. A few of them, like generics, are slowly becoming more mainstream, and Sun is adding them as people ask for it. Remember, computer languages evolve slower than hardware or software platforms. It took 20 years for inheritance and polymorphism to become common place (and it's till not as common as you might think). The features Java is supposedly lacking we really shouldn't miss. And if there's something you just have to have, then you can use one of many addons to provide it like XDoclet and Shark, safe in the knowledge that if it compiles to Java bytecode then everyone can use it.

(4) Nobody uses Java. This simply isn't true. Probably 99% of Java applications are either serverside (where the user doesn't know or care what the application is written in) or are made for internal corporate use. As Eric Raymond pointed out: "there is empirical evidence that approximately 95% of code is still written in-house". Most Java applications, even Swing apps, are for corporate use. In these environments the robustness, productivity, and easy of deployment more than make up for Java's other flaws. There are plenty of high quality applications that people don't know are written in Java, and that's really the problem. Especially on the desktop I'd like to see more highlighting of Java success stories (and more ways to get the word out!)

(5) Java is slow, ugly, and doesn't do modern native things. I've saved this for last because I think it's the biggest problem. Java has this impression because, well, it was slow and ugly. Back when Java debuted nothing worked properly, applets were slow to load, and AWT used a horrid subset of the available widget set on each platform, all of which looked different and ugly.

Today the situation has changed. Swing has gone through several revisions to become a powerful toolkit, if complex. The speed issues have mostly gone away from improving the libraries and a decade of faster processors. Even on my now aging iBook I run jEdit quite nicely and have written tens of thousands of lines of code with it.

Swing itself has also matured (and gotten prettier). Most of the big bugs have been fixed. Quite a few attractive Look and Feels are available from Sun and 3rd parties. A lot of the missing functionality from the early days is finall in place. It is entirely possible to make great desktop applications, even consumer apps, with Java. We just need to get people to realize it.

The plan

Despite all of my argument preceding, Java still has an image problem. People still think that you can't write good desktop applications in Java because they don't see them. So what can we do? Show them! And keep building more!

First, we need to show off the good apps. Get the word out. I think we need a place to highlight great applications. Perhaps a sidebar on Java.net with a new application each day. The only requirement is that it be a desktop application with a downloadable demo. This spot should have it's own RSS feed and archive. Then we have to start the publicity. Get other sites to link. Make a download.com for Java apps.

Second, create a place to collect all of the tips and tricks it takes to make a quality desktop application. I've started a Wiki node here with a framework of what we should pull together: exe packaging, good look and feels, swing tutorials and articles, how to work with different kinds of media. Contribute whatever you know. We need to fill out the missing pieces.

Third, start a contest for quality Swing applications along the lines of O'Reilly's MacOSX app contest. We should have different categories for commercial and open source, full applications and mini programs, and maybe further sub-classification (word processing, media and graphics, personal organization). We'll probably need to get a corporate sponsor for this.

We all know that Java can make great software on the server. It's time to reclaim the desktop. (Wiki Here)

An Analysis of Open Sourcing Java

I'm going to try to really tackle the issue of opensourcing Java and state my opinion of why it's a bad idea. Then I'll propose a way would could do it without all of the problems. It's a long one but please read to the end and provide your feedback. This is an issue that many feel strongly about and has the potential to influence Java's long term future. And as a career Java developer, it's something that personally concerns me.

Note, I don't want this to become a Microsoft slam. I think they have made many fine products over the years in addition to some really bad ones and some very questionable business practices. I do have to respect them for the fact that they never give up. They keep working on a good idea, even if it takes five revisions before their product is succesful. In this post I am only discussing Microsoft's actions in relation to Java. Who knows, had I been in the shoes of a VP trying to grow the desktop market (which is hard with 95% penetration) I might have done similar things.

I'd also like to mention that here I use Java and JVM interchangably. I am more than familiar with the difference between the language, the VM, and the libs that make up the runtime (and dear god, please don't make me explain again the difference between Java and JavaScript. :); but for the purposes of this discussion I will consider them all part of what makes up Java. I think this makes sense for the kind of highlevel issues we are talking about.

The Debate: Open Sourcing Java

A lot of people have been talking about the war of words between Sun, IBM, and related parties on the issue of open sourcing Java. Even James Gosling and the Slashdot crew have gotten in on the act. But what would open sourcing Java actually do? What kind of benefits would we, as a community, get?

As a Java developer, and I'm assuming that most of my audience for this post is a Java developer, I really don't care about the politics of a license. RMS may opine that without a free Java you can't implement a completely free desktop, but I really don't care about an abstract sense of free. I care about what an open source Java would actually mean, and how it would actually affect me. To me it breaks down like this.

The Benefits of Open Source Java:

• Multiple eyeballs fix all bugs
• The ability to fork Java if you want to add new features or fix bugs
• The ability to take Java (non-forked) in new directions that Sun wouldn't think of
• Keeping Java alive if Sun tanks
• The ability to make sure no one else can 'take Java away from us', ala Microsoft's embrace and extend policy

The Problems with Open Source Java:

• Multiple incompatible Javas (both language and environment)
• People from one team not listening to other teams. Standards wars.
• Someone else co-opting the entire system to make it proprietary without a large company to defend it.
• A monoculture of VMs (which is not incompatible with the idea of multiple VMs)

Now, as a developer, I don't care about competing with the Jones' (.NET, perl, C) or about the politics of freeness (RMS). I care about making and deploying great applications, and deploying them everywhere. For this reason I love the advantages of open sourcing Java. It makes Java better and lets me play with it. Still, I really hate the disadvantages. #1 on the list is multiple incompatible environments. The current JVM situation, with multiple revisions and platform specific bugs, is bad enough. Imagine if there were 10 or 20 JVMs out there each with their own idea of what "Java" is. Chaos for the developer. I think this is the number one reason that J2ME has failed. There are too many propriatary extensions and platform incompatibilities to make it easy (or even feasible) to develop J2ME software. I'd hate to see that happen on the desktop or server. That makes my life as a Java developer, (and let's face it, we are the only ones who really care this passionately about a programming language), simply hell. In the end we would still need a validation to ensure that all widely deployed Java environments are compatible, and we'd basically be where we are now, with Sun's compatibility tests and control over the spec, only with more fighting and less work getting done.

So what else do we have here. Multiple eyeballs fix all bugs. Well, you can already download the source and fix a bug if you want to. You can even submit the fix to Sun. You just can't get the fix to your users (or the rest of the world) in a timely manner. This is a problem but one that doesn't require GPL'ing Java. In a world with Open Source Java we could still have these problems. The only solution is an active developer team with an interest in accepting feedback. (more on this down below).

Next up, the ability to add custom features. People have been doing that for years with custom JVMs and compiler extensions. GPLing won't change that. Taking Java in new directions already happens with the JCP. The process may have some problems with infighting and general slowness to decide anything, but open sourcing would mean we'd have even more people bickering about trivial issues. (And if you think that's bad, trying sitting in on a city council meeting sometime.) This would make the problem worse, not better.

Next is the issue of Sun going out of business. I think that Java would be fine without Sun. It's a language, carefully spec'd out, with multiple implementations from many organizations, some with billions of dollars. (Hint. It's a TLA). If Sun went out of business tomorrow we'd be fine. I can't say the same about MFC and Win32.

One really odd issue is the monoculture problem. We could have all JVMs derived from a common source (and why not since it's freely available, and in fact the GPL encourages a single source), so one flaw would affect them all. This is the danger of a monoculture. This is a problem even if we have multiple JVMs with incompatibilites. Having multiple implementations of a single spec helps prevent this. I like the idea that a bug in the Windows VM doesn't necessarily affect the OSX one, just as I like being immune to Outlook viruses by using a different IMAP compatible email client.

Finally, open sourcing, particularly with the GPL, would protect Java from an embrace and extend attack from a hostile company, which pretty much means Microsoft. I don't think that it would since they have already done it twice. The GPL wouldn't have stopped what they did. First was an incompatible JVM. Lawsuits happen, years pass, MS settles, and the damage is already done. The GPL wouldn't change this. Second, MS takes the good ideas of Java and makes their own in the form of C#, adding lots of cool new research. Again, the GPL wouldn't stop that. No license (or contract, or law), will stop a determined foe. Only humans with their own interests can stop other humans. Any license can be powergamed around.

So now we can see that opensourcing Java doesn't solve anything. We have problems, and I'd like to see some changes in the way that Sun handles things, but by and large they do a good job and just GPLing it all would introduce great headaches for very little gain. I urge anyone who thinks otherwise to submit an opposing analysis. This really is an important issue and I'd like to have some frank realworld discussions about it.

As a final note (and I'll stop bugging you, I promise) remember that open source excels at building software where the solution is already known (like most of the Unix utilities we take for granted. No one wants to reimplement grep) or where the advantages of customization out weigh the costs of usability, installation, or integration (like Apache). I think this may apply to some parts of Java but not to others.

So I have one suggestion: I would like to see Sun partially open source parts of Java. Development of new standards and specs are pretty well taken care of by the JCP, but I'd like to see them open up the implementation to Swing (my personal interest). I want them to basically put the whole thing into CVS and start taking patches. Make a few Sun employees the architects and lead product managers. They still make the final decision about what makes it into an official release (JRE 1.6, 1.7, etc), and non official releases can't be sold or distributed as Java, but we'd still the the advantages of faster turnaround, multiple eyeballs, and customized versions for certain situations. This would sort of be like what happens with the Win LAF, (a project created to fix the problems with Swing's built in Windows look and feel), but more official and with the ability to move Swing along faster. There's a large community of people who want to make Swing better (and soon).

Does Java have a bad reputation?

I recently read on Slashdot (something I promised myself I was going to do less) about Miguel de Icaza's comments on Longhorn. It was a pretty interesting read and makes me think I should read up on XAML and Avalon, Microsoft's new technologies for making advanced rich web applications. What struck me as particularly jarring, however, was this thread where someone asked about Java as a webapplication stack to compete with Microsoft or an as yet unwritten opensource toolkit. Most of the readers jumped on this and attacked Java from all sides. What particularly worries me was not that so many of these readers are opposed to Java, but that their arguments are almost completely wrong. Take a look at some of these comments:

Stock Java is not an option because it lacks a few things: the easy-to-build functionality of a web page (XAML) and the advanced graphics and rendering of Avalon.

However, it really does not matter what is going on in the java world. Java had its chance, and failed. Java the language has outgrown the Java the (virtual) machine. Java the language is now being extended in weak syntatic ways, think of generics where it is possible to corrupt generic containers because the support is only syntax deep.

Java is faster now, and computers are faster now, but technical analyses of .NET and the CLR tend to indicate that it is better thought out than Java. No wonder, since it came substantially later than Java, but that doesn't change the fact.

If Sun brings us a Java 3 in the near future which addresses these performance and scalability issues (among others) then this post will be irrelevant (well I guess it is already, welcome to slashdot right?) but right now it makes more sense to emulate the CLR and the non-Windows portions of .NET. Since Java is not open source, and the open source world would like to have something like Java but open, and .NET and the CLR are superior to Java (arguably anyway) why not implement .NET? If Microsoft changes their implementation to a point which destroys compatibility, there is still room for Mono to provide a cross-platform runtime environment which will run on Windows.

The main problem that I, personally, see with Java-based apps, is the non-native widget set. I have to admit, I honestly detest Swing/AWT stuff. Swing even more. Not only is the default theme ugly IMO, but even if you make it *look* like WinXP or Gtk or whatever, it doesn't *feel* like it.

Java is a minor cleanup of a horrible set of object oriented extensions of a 35 year old high level assembler. Perl/Python/Eiffel/Tcl-Tk show what Java could have been and where it could have gone. Furthermore, even as a cleanup of C++ it got too many things wrong, as illustrated by the numerous minor bug patches in Java "the next generation", more commonly known as C#

I'm starting to really wonder why Java, or at least Java on the desktop, has such an image problem? If you are talking about rich web enabled applications that run on your desktop and on the web, then Java should be at the top of the list. Do we need a PR agent or something?

This work is licensed under a Creative Commons License.