Quite a few years ago now, SUN came up with this really cool idea, make a language and a runtime environment that are portable to almost any platform, and that would allow transfering binaries between platforms and run them directly by means of using bytecode.

The problem with JAVA is that while in theory it will run on any modern platform, and with proper licensing, you can build it on most platforms (given you have a working JAVA implementation to bootstrap the build.... isn't that a bit odd?)... the reality is that unless SUN decided to make binaries available for a platform with an end-user license, there is no practical way of getting JAVA on a machine.

Now, SUN of course has such binaries for Windows, Solaris and Linux and some other systems, but for example not for FreeBSD/OpenBSD.

On the other side, it is quite possible to reliably and automatically build JAVA on a FreeBSD machine provided you have the sources.

The real problem is that such a version that is built from source can not be distributed, resulting in having to rebuild the same thing and wasting half a day for each and every customer that needs JAVA. This is not very usable in a production environment.

Now, this concerns FreeBSD so you'll say: switch to Linux. That sounds like an option if not for the fact that I run into a similar problem.

First of all, few Linux distributions seem to have managed to include a JAVA runtime environment at all, in all other cases I have to download it from SUN. More problematic however is that when maintaining a Linux machine, you may end up having to install newer versions of libraries, which at times introduces compatibility issues. It is however not trivial to just recompile JAVA and link against the new libraries.

I understand why SUN wants tight control but I also see why it is very clearly not a good thing in the world as it is now.

If SUN wants JAVA to last, and insists on not making an Open Source version, they should at least ensure they don't obstruct actually using it, and stop putting up all kinds of silly restrictions on distribution and recompilation of the runtime environment, esp. for a relevant server platform.

Failure to do so may result in one or both of two things:

• An alternative Open Source JAVA gets created over time
• JAVA becomes irrelevant

Bottomline, bothering the end-user or server admin with their development issues and strategy is a very unwise policy, and SUN should really look into keeping it away from the end-user if it doesn't work in the advantage of the end-user.

This is even more true when looking at server-side JAVA, since it is a more centralized thing, it is easier to replace with something else, and good alternatives do exist already.

My personal server is fast enough to build new JAVA versions regularely, so I have the FreeBSD JAVA runtime installed there from a local build. The same applies to my workstation, but I find it extremely silly from SUN to expect people to let their machines spend a night on a recompile just because they need a specific fix or feature, and do so on each individual machine. (for comparison, I use a dedicated PC for recompiling my local FreeBSD builds, this is an Athlon XP 2600+ which can build the 3 differently optimized versions that I use in less then 6 hours. That is less time then a single build of JAVA takes on my server. If I could use that for building and distributing JAVA for my network and customers that would simply save me days if not weeks in CPU time each time I need a new release, and it would be a lot less bothersome.

At any rate, I hope SUN fixes this before it has become utterly irrelevant, it would be a waste of an otherwise very usefull tool, and would remove one of the last strongholds they happen to have in the software market.

The recent settlement between SUN and Microsoft doesn't bode well for getting a solution for this.