There's been lots of debate this year over whether or not Sun should
open source Java. I've talked at OSCon to quite a few Java guys, many
long term Apache developers, who are really pissed at Sun for not open
sourcing Java. I totally share their frustration as Sun have done
95-99% of all the right things, part of the frustration is there's only
a little step further to go, we're all so close.
I think Sun's done a fantastic job of growing and protecting the Java
platform. There's just one more step they need to take - to open source
some Java source code - and we're all happy. However up to now I think
the problem has been that noone's managed to explain to Sun why they
should do it or even what 'open sourcing Java' means in real practical
Sun are clearly very concerned that any kind of move in this direction
could undermine the Java platform, leading to fragmenting of the
platform and brand etc. I guess this reluctance should be seen as a
very good thing - they are being very careful and protecting Java.
However sometimes a parent can smother a child and wrap it in too much
So here's hoping this proposal can help show why & how they could do it, making lots of open source hackers very happy and growing the Java platform even more, especially faced with stiff competition from .Net / Mono.
Whats more I'm not even proposing they open source Java but something a little different. Lets start out with a couple of use cases...
Use Case A
You're a developer in a large company or ISV or consultancy of some
kind. You develop enterprise applications for your customers, using the
right tools for the job etc. Now lets assume that you like Java
and develop most of your enterprise software in Java due to the
diversity of tools, technologies (open source & commercial)
available and so forth. (So here we're talking about most of the
developers in the Java community today).
However increasingly you're finding that X% of the time you need to
write or interface closely with some .Net / Mono code. e.g. you need to
put some code inside Word/Excel/Access/InfoPath to write some rich
client thingy. Or maybe you need to hack some existing .Net/Mono
The value of X might not be very big. I know many large companies where
X will be zero. For some I know it'll be 5-10%. I know of some
companies where this will be much higher - though in the circles I move
its not very big, but YMMV. (BTW you could argue web services is a
solution here, but really sometimes you just need to hack inside the
Whatever the value of X, lets assume that for a reasonable amount of
people its gonna be greater than zero & a significant value. Now to
build code that works on .Net / Mono today, there's only really one
safe option - ditch Java, the language, the JVM, the tools, the
frameworks and jump wholesale into the .Net / Mono world using C# and
VisualStudio and all that stuff MS is doing.
This means you've now 2 platforms & code bases to work on, 2 sets
of build tools, libraries and so forth. This is not ideal. Indeed I can
imagine many companies, to save having both .Net experts and Java
experts and having 2 sets of tools and internal Java v .Net wars, will
try and just pick one and use that one tool for everything. I can
therefore imagine quite a few of these developers just switching to
.Net / Mono. Why might they do this?
Maybe there are other reasons to switch. From the Java camp, who cares what the reasons are, people will switch.
- they need to hack on windows-only technology like Office
- using one platform saves money
- moving to .Net is seen as an easier choice, since once you've
made that choice you get everything you need from MS - no need to
choose the best IDE, the best build tool, the best app server, web app
framework and all those things - just use what MS gives you. Some folks
in technology just want an easy life, even if its not the best tool for
the job, its an easy life & noone ever got sacked for choosing MS
- they may get their heads turned by some wizzy new rich client UI
stuff that MS/.Net has (like InfoPath or neato Office stuff if MS were
to innovate in office again or who knows, maybe some of this Longhorn
stuff isn't just catchup-to-OS X, but might actually be new &
innovative :). At least now MS has an incentive to innovate
- VB looks easy to hack stuff together
So whats the (.)net result :).
Clearly this is not good for Sun, the Java platform or the users in Use Case A. But its great for MS and Mono!
- Java the platform loses users & grows less popular
- there's a clear pressure on developers to switch to .Net / Mono especially by their business who love Excel or whatnot
- for those users who don't switch completely, they now have 2
platforms to support which is a PITA and adds more cost &
complexity to their job
- for users who do switch to the .Net/Mono they've just lost alot
of their choice, they've lost alot of the benefits of the Java platform
& open APIs & community and are now mostly vendor locked into
MS with no plan B
Use Case B
This one is pretty much the same as above, except you're a highly
linux/C focussed developer. You may work with lots of C code, work on
open source linux C projects or you may even be some kind of linux
distributor. Either way you'd like to use a language & tools that
make your job easier yet work nicely in your C / GPL environment.
Something that can fit right in, turn easily into shared libraries /
DLLs or executables and be easily distributed to your users.
Java is not as easy as it might be at integrating into C code or linux
worlds or being easy to redistribute in typically Linux/GPL worlds.
There's another option - Mono. This is welcoming the linux platform
& developers with open arms. Java could be a possible solution in
this space (as a language, set of tools, standard APIs etc). However
due to restrictions on licensing issues, Mono seems a much better
option for linux folks to use today - purely due to licensing
restrictions rather than any technical issue.
The net result to Java for this situation? Linux/C based developers
don't move to Java (or move away from Java) and move to Mono. A kinda
knock on benefit for .Net as it looks like .Net is more popular thanks
So we've just described 2 massive communities of developers above and
why the current licensing of Java is causing them pain and how its
badly affecting the Java platform to the benefit of .Net / Mono.
For Use Case A; developers could stick on the Java platform. They could
keep their investment in the Java tools, languages, frameworks and so
forth. But for those times where they need to be inside .Net for neater
Office integration or to work inside a .Net/Mono project, they could
compile their Java code & any dependent code they use to .Net IL.
Java is mostly bytecode which is easily translatable and the .Net CLR
is very similar to the JVM so its not that hard to do.
Indeed IKVM does exactly this today. We can today use .Net as a
platform on which to run Java code. The downside is, IKVM isn't allowed
to use the rt.jar thats part of the JDK / JRE due to licence
restrictions. So it must use GNU classpath, which is a little buggy and
not totally compliant with its real, certified JVM / JRE equivalent code.
Its pretty good - eclipse works fine inside IKVM for example, but there
are buggy areas. (e.g. Geronimo doesn't run yet inside IKVM due to IO /
Now the users in Use Case A are not trying to subvert the Java brand or
fool anyone into thinking that .Net / Mono is a Java platform. They
just wanna get their job done and use 1 set of languages and tools, to
save money and have an easier life and try avoid being caught in the
cross-fire of a developer mindshare war.
Hey, one of Java's goals is to write once run anywhere. Yet this
clearly does not yet include running inside .Net / Mono! These should
be valid platforms for folks to use Java!
Similarly for users in Use Case B; developers could use the Java
platform, yet turn all their Java code/libraries into shared libraries,
DLLs and executables. They can do this completely today with gcj. It
works fine, however like above it must use GNU classpath which is buggy
Again the WORA vision is broken since C libraries are not considered to
be a platform on which Java should run - which thanks to gcj it could
be - its just not really supported or possible, again due to licensing
My Proposed Solution
So what should Sun do to help both of these massive communities of
developers? Firstly its clearly their fault as its their licensing
agreements which are the problem here. So here's what Sun can do to
both protect the Java platform from fragmentation and to grow the Java platform into these 2 large areas of developers while still keeping a steely grip on the Java platform and brand...
Sun setup an open source project called JRT. Its not Java, its not a
Java platform - its something else, its JRT. Its a bunch of Java source
code for some java.* and javax.* APIs and implementation classes which
to implement part of the JDK / JRE - basically the source code which
when compiled to bytecode makes the rt.jar which goes into the JVM.
Parts of this are already open sourced (XML parsers, DOM, SAX etc). So
its already been done in part. We're just making a bigger chunk of this
code open source.
Note its not the JVM though - there's lots of C code for implementing
that and there's all that really cool hotspot stuff too - I'm not
proposing any of this is open sourced (yet :) - though that could be kinda
cool, the Mono guys could really help out & reuse that stuff).
So JRT is just an open sourced Java project - under a very liberal
licence, say Apache 2.0 licenced so folks can use it inside GPL &
BSD open sourxe projects or inside commerical products if need be. Note
that the JRT project also includes a few C header files
for when JRT's Java code has to call out to native C functions that any
VM must implement.
Now Sun is sole committer on JRT; they decide what goes into JRT when.
However now that a huge bulk of the code for the JVM is out there now
we all benefit because...
So far, nothing too earth shattering or risky for Sun. They're already
done part of this (for XML). They've not open sourced Java, the JVM or
the platform. They've just open sourced some Java source code (&
some C header files) that are used to create rt.jar.
- more eyeballs are now looking closely at the code
- previous GNU-classpath developers can now work with Sun developers to help maintain and improve JRT
- folks can easily submit patches
- this has no effect on the Java brand or platform, since JRT != Java, its just some java code for some of the java libraries
- Sun keeps the Java trademark, brand and compatibility tests so 'Java' is protected
Now what this now means is that the IKVM and the gcj guys can reuse JRT
freely. They can redistribute JRT source code or compile it into some
format and call it anything they like. (There would be restrictions,
like you can't modify JRT and call it JRT, or you can't claim that you
are a Java platform unless you pass Sun's TCK etc). Redistributing JRT
doesn't affect the Java brand, since noone is saying its Java - noone
is allowed to say its Java etc.
However now the IKVM & gcj guys don't have to try keep GNU
classpath in sync with JRT; they can just share the code. This then
means they can make .Net / mono / gcj into a platform on which java
code can be run. Lets call this a JRT-platform. JRT-platform = a
platform which your java code is likely to run, but it might not. i.e.
its not a certified Java platform but it might be close.
Now developers have a choice; they can write their code in Java and
deploy on any Java platform, or they could try their luck on a JRT
platform too - thats their choice. Choice is good. JRT platforms are
not necessarily a Java platform, so its a little risky and there might
be a few bugs and such like but hey it might work. (It already does for
eclipse and so could well work for many projects). It doesn't have to
work for everyone; so long as it works for some folks, we've all gained.
So far so good. We've already got Java platforms, officially sanctioned
& certified platforms on which developers can have total
confidence. Or there could be these new JRT platforms, which have
specific close integration with .Net stuff or C or whatnot which could
be used too. This is good - we've got more choice now & everyone's
happy. There are other non-Java platforms developers can try if they
want to and the GNU-classpath guys can just help fix & tune JRT
But wait. The IKVM or gcj guys could try certify their JRT platforms as
fully fledged 'Java platforms'. This is by no means necessary; things
would be OK if there were Java and JRT platforms, but the ideal would
be for IKVM and gcj to both certify so that they become Java platforms
too, passing any certification tests Sun come up with to ensure
developers have complete confidence their stuff will run. This would be
a truly great step and I think both these platforms could get
there without too much work (since they're really close now and the JRT
code is the missing link). IKVM for example is the work of mostly one
Think about that for a second. We could test and certify that .Net /
Mono (with IKVM) and gcj would completely pass all of Sun's
compatibility tests and so could then call themselves a fully fledged
Java platform and JVM! If we get there then
This is a win-win for Java, Sun, developers and Mono/gcj too. We can
all now standardise on 1 set of languages, tools, frameworks, IDEs,
APIs yet when we need to work closely with lots of C or lots of Mono /
.Net stuff, we don't have to switch platforms & tooling, we can
stay on the Java platform (if they are certified, or use a JRT-platform
with a little more work/risk).
- we have one really massive Java platform now; all of the
JVMs available today plus .Net, Mono, Rotor and gcj. That makes pretty
much anything a possible Java platform (which may not use the Java VM
but use another VM, like the CLR - who cares how it works so long as
- Sun protects the Java brand still, defines the TCKs and for
anyone who tries to pass off a non-compliant Java platform as a Java
platform it can sue & protect us all from Java brand fragmentation
- folks who don't have the resources to go the whole hog &
certify as a Java platform, can be a 2nd class JRT-platform but still
be useful to Java developers even though they are not a real, true,
compliant Java platform
- we'd get more competition in the VMs; who knows the .Net VM migth
one day run Java code better than Sun's? Or maybe Mono? Or vice versa -
the Sun JVM might run .Net / Mono code better? e.g. Mono users could take advantage of hotspot. Competition is good!
- folks who are using C / gcj / .Net / Mono today could be tempted to use some of the great stuff available in the Java ecosystem inside their platform (since their platforms could now be certified as Java platforms). i.e. folks could start switching to not from Java
- we could end all these ports of Java open source projects to C#
just to get clean integration with .Net / Mono, we could just use Java
code to run on both platforms. (Or we could write a C# compiler for the
JVM similarly, to reuse any C# open sourced code - of which there's
little today but that might change in the future)
From time to time we might switch APIs from java.something to
System.whatnot when it makes sense to do so. But hey, healthy
competition for APIs is a good thing. Use the right tool for the job
and lets avoid unnecessary platform wars.
The only folks who could possibly be hurt by this are MS since they're
not locking anyone into .Net any more. However they're free to innovate
& compete by building better APIs and tools to tempt folks to use
MS-only stuff. This is fine & competition is healthy and we all
win. Lets have an open playing field with no artificial barriers!
So please Sun, go for it. Make the first step and open source JRT. Its
no biggie and doesn't affect the Java brand. There are many people in
the open source world who'd bend over backwards to help you do it.
We'll all love you for it! We'll help you develop, support, document
and tune JRT for free. You'll keep ownership of the IPR and
sole rights over it and I'm sure Apache or codehaus would happily host
the project for nothing - it won't cost you a penny. Once you've done
that first step, some of us could then try help turn .Net, Mono and gcj
into Java platforms and then we'd all really win.