Sun yanks FreeBSD's Java license [LWN.net]

Sun yanks FreeBSD's Java license

Posted Jan 11, 2005 22:29 UTC (Tue) by mrshiny (subscriber, #4266)
In reply to: Sun yanks FreeBSD's Java license by mmarq
Parent article: Sun yanks FreeBSD's Java license

Are you saying that we should virtualize existing languages? Or that we should make cross-platform java? I'm not really sure what you mean about doing it "the other way around".

My point is that the actual performance of the running product is FASTER in some cases when you use Java than when you use C++ or C or Perl or whatever. Not all cases. But as runtime compilation techniques improve, you will see more and more stuff 'virtualized', whether it's C or whatever. But Java is already doing this today. It may not be faster for everything, but people who use Java know how fast it is, and what it's good for. Compiling java code to a native format would not provide any advantage for me, so why should I do it? Free software idealism? No thanks. I'm in favour of a Free-software implementation of the JVM, but GCJ will not be useful to me until it performs as well as the JVM.

And "Write once, run anywhere" is ONE benefit, but not the only benefit of Java. Java is also a nice programming language; I like it much better than python or C or C++ or Visual Basic. Java has a very nice class library and lots of good, enterprise open-source products. Java makes lots of things easy, like reflection, remote-debugging, etc.

Finally, tailor-made vs economy of scale... I think Open-source can accomplish both. And I think Java is a good tool to use for both kinds of jobs. Some popular client apps are java, such as Limewire (not hugely popular, but still fairly popular). Limewire isn't open-source, but then there aren't lots of open-source desktop programs that aren't gtk or QT. A notable exception is Eclipse: a very popular IDE for Java and C++ development that is written in Java. It's a great program and lots of developers use it; IBM even resells a closed-source version as their primary development environment. Also, lots of custom-made software is Java. Some of that is open-source. Basically it's all about using the right tool for the job. And Java is a very nice tool, and to a lot of people it's definitely the right tool.

So I'm not sure how arguments about custom software vs off-the-shelf software are relevent to the whole "Java or not" question. I'd say the question should be about the technology. But unfortunately Sun are turning into crackpots and I am worried that they may harm the Java platform with their politics. But rest assured that if Sun goes down in flames, someone will rescue Java, one way or another.

(Log in to post comments)

Sun yanks FreeBSD's Java license

Posted Jan 12, 2005 2:00 UTC (Wed) by mmarq (guest, #2332) [Link]

" Are you saying that we should virtualize existing languages? Or that we should make cross-platform java? I'm not really sure what you mean about doing it "the other way around". "

No !!... the other way around is that the compiled native form of Java can be made to run as fast or much faster than the bytecode form on a VM... it isn't today with GCj but it could very well be. It needs to improve dramaticly the executable native form "code" that the compiler spits.

For the developer this is an almost interely transparent change. The same applyes to C#.

" My point is that the actual performance of the running product is FASTER in some cases when you use Java than when you use C++ or C or Perl or whatever. "

When it comes to time sharing computation it is possible that a very optimized form of virtualized code, like Java bytecode on an VM or JIT, dont take any mesurable penaltys over a native compiled form. But when it comes to real time solutions, soft or hard real time solutions, when applications need to do data streaming(video, audio, animation) without hicups, or even when they do intensive graphics, like in next generation 3D Desktops. Then a VM or a JIT, be it of Java or of any other language yet to be invented or not, seems to me to be an inadquate approach. Why wast resources on another layer of indirection, be it a VM or a JIT ?, why take the overhead ?...

And real time aware applications, intensive graphics, streaming data, with integration of VoIP, videoconference, whiteboarding in groupware solutions, *real* 3D Desktops and application, streaming music and movies over the internet... will be just everywhere in server, desktop and embeded!

All this dont displace Java. It only means that a powerfull native form compiler would be a very well comed addition to all those that love and program in Java, not out of idealism but out of necessity.

Sun yanks FreeBSD's Java license

Posted Jan 12, 2005 8:47 UTC (Wed) by piman (subscriber, #8957) [Link]

> It needs to improve dramaticly the executable native form "code" that the compiler spits.

The kind of optimizations in question can't be done in the "bare metal" compiler. The kinds of problems range from simple things like complex instructions sets such as SSE, to runtime profiling and adaptation to avoid branch mispredictions, to automatic generation of optimized per-type versions of generic function calls. None of these can be done at the traditional compile time, they all depend on very specific implementation details of the CPUs in question, and even on the runtime datasets.

You can push these off if you like, but all that happens is that the slack gets picked up in the hardware end -- branch prediction is a primitive example of this, or on a more advanced level the Transmeta Crusoe which runs everything on a transparent JIT of sorts.

The trend is for JIT compilers to get faster and faster, and as more of the above techniques come into play, there's no reason to assume native code can keep up.

Sun yanks FreeBSD's Java license

Posted Jan 12, 2005 21:39 UTC (Wed) by mmarq (guest, #2332) [Link]

" None of these can be done at the traditional compile time, they all depend on very specific implementation details of the CPUs in question, and even on the runtime datasets. "

Are you telling that Java the Platform dosent allow to take advantage of all those special CPU features, different from architecture to architecture, as it can be done with the C compiler... so a "compiled to the metal" dosent take any mesurable advanyage over the VM bytecode ?

I'm not a Java programer or expert, but isn't that because the language is so focused in "crossing-platforms" by a "lowest common denominator" that is the JVM ?...

So perhaps changing Java the Platform(not only an open source VM implementation), in a way that the generated bytecode will be compatible with *TODAY* JVMs out there, and the native code can take advantage of all CPU features. And all this without changing the language sintax, and inventing a new language altogether?... no !?

Can of worms?... but isn't there already a can of worms in the mess of Java implementations? And with SUN going for the moon back and foward, things trend to get worst.

The advantadge is to link 'earlyer' to all those other pices of code that run in the metal like the OSes, Qt or GTK toolkits, OpenGL primitives,etc.. and make Java aplications swift and time aware, being able to make real time Java applications. The cross-platform will be assured by a compatible API/ABI across the different OSes and CPU architectures, and the 'old' Java (JVMs) behavior will be achived *simply* by compiling to bytecode and linking 'late' with all the pieces compatible.

Yes,... except for Web-services and other highly dynamic and mobil applications the VM importance and possibilitys will be void,... but isn't that already ? The change will be a major improvement to all those that love and program in Java.

"" At the end of the day, can or cannot, a Java program in an "optimized" binary executable form, linking ignored, be made to be as fast or "much" faster than the form in optimized bytecode, being the source code "equal" in both cases ??... ""

Sun yanks FreeBSD's Java license

Posted Jan 12, 2005 22:44 UTC (Wed) by mmarq (guest, #2332) [Link]

A late one...

" The trend is for JIT compilers to get faster and faster, and as more of the above techniques come into play, there's no reason to assume native code can keep up. "

But isn't that Microsoft dream ? Make "cross- platform" in a layer below the OS (instead of the natural above OS API/ABI runtimes and librarys), and all 'possible' languages depending on a *common runtime* (CLI), specialized in 'NONE' particular computacinal task. So far it has proved to make a lot of applications sluggish, specialy the OS...

IMHO, is more like a pipe dream, because Microsoft is a control company that hasen't been able to control effectivelly the Hardware Industry. But if they manage to pass about *all* applications to the new JIT platform, then perhaps they can spark the *rush* in the industry, in a new CPU war, to make CPUs that run the JIT internally, instead of the normal optimized microcode. And then Microsoft, because they effectvily control the JIT functionaly no matter if the runtime is pseudo open sourced, could not only charge royalties from every CPU made, but also have the chance to exclude applications and OSes they dont like!!...

SUN had an identical dream, and because they have the facilityes, they even have made CPUs, the Java CPUs, that run the bytecode directly in metal, i belive. They have failed rotundly, and one of the reasons is performance penaltys, because optimized microcode is a totaly different story..

There are the opposite where Assembly is just about making microcode directly into a programing language, but that would make programming worst then a nighmare,...if you have to build an Office package. So it seems that all this layers from microcode to "no lines of code needed" programming IDEs and languages, have the nasty tendency to stay inside their optimized borders, and VMs and JITs, no matter the language sintax and structures, are only real usefull for a 'fast and easy' cross-platform business,... internet has been one of such bussineses of sucess. With streaming and real time needed applications VMs and JITs, IMHO, will trend to lose a lot of usefulness.