Most Read This Week
Developer Viewpoint: Open-Source Not Java Itself...but "JRT"
Developer Viewpoint: Open-Source Not Java Itself...but "JRT"
By: James Strachan
Aug. 2, 2004 12:00 AM
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 disgruntled 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.
So whats the (.)net result?
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 and 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 and 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 to Mono
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 and 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. It's 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 / classloader bugs).
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 wan to get their job done and use one 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 on!
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 and incomplete.
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 - it's just not really supported or possible, again due to licensing issues.
A Proposed Solution
So what should Sun do to help both of these massive communities of developers? Firstly its clearly Sun's fault as it's Sun 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 should set up an open source project called JRT. It's not Java, it's not a Java platform - it's something else, it's JRT. It's a bunch of Java source code for some java.* and javax.* APIs and implementation classes which are used 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 it's 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 and 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 and BSD open source projects or inside commercial 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...
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 no one is saying it is Java - no one is allowed to say it is Java.
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. it's 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 - that's their choice. Choice is good. JRT platforms are not necessarily a Java platform, so it's a little risky and there might be a few bugs and suchlike, 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 and 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 and 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 and tune JRT instead. Win-win!
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 comes up with to ensure developers have complete confidence that 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 person!
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
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 let's avoid unnecessary platform wars.
The only folks who could possibly be hurt by this are MS since they would not be locking anyone into .NET any more. However they're free to innovate and compete by building better APIs and tools to tempt folks to use MS-only stuff. This is fine and competition is healthy and we all win. Let's have an open playing field with no artificial barriers!
So please Sun, go for it. Make the first step and open source JRT. It's 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'd all love you for it! We'ld help you develop, support, document, and tune JRT for free. You'd 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 would't cost you a penny.
Once you've taken 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.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters