Slashdot Mirror
Red Hat Devs Working On ARM64 OpenJDK Port
hypnosec writes "Developers over at Red Hat are busy porting OpenJDK to ARM's latest 64-bit architecture — the ARMv8, also known as the AArch64. The current OpenJDK ARM situation is rather unsatisfactory: for the current 32-bit ARM processors, there are two versions of the HotSpot JVM for OpenJDK — Oracle's proprietary JIT, and a less sophisticated free JIT that performs poorly in comparison. To avoid a similar situation for the 64-bit platform, the developers are working on an entirely Free Software port of HotSpot to 64-bit ARM."
RedHat has an agreement with Sun that Oracle inherited. They can't do anything about it at this point.
http://saveie6.com/
This is excellent news.
It will also be awesome when OpenJDK is ported to Android (it'll probably never make it to iOS due to Apple blocking it, which is a real shame). The IcedRobot project is attempting to do this. Just image, if you could write your application in Java and it would work nearly seamlessly on all the Windows, Linux, Unix, Mac, BSD and Android devices you have to look after. Sure, there are gotchas on each platform but you are usually 99% of the way there (at least, that has been my experience) and your unit and integration tests allow you to quickly find and address any platform quirks.
For all its flaws (and it certainly has them) Java's goal of having a single enterprise-quality language (and, far more importantly, a broad amount of *standardized* libraries ) available on all platforms is a great thing. Only those companies with an vested interest in keeping the IT world silo-ed in islands resist such standardization. Sure, innnovate in your own languages but don't try and balkanize or block standard Java on your platform. Most of us want to amortize their development investment across multiple platforms (and the broadest swathe of the market), and making us use niche tools just for only your platform is painful for us. Our ideal is to develop once and sell everywhere. Portability is what made C great, and for modern development is the single most important feature of Java as a language for huge-scale development projects (nothing else comes close; other languages are portable but their libraries are often not).
Go RedHat!
ps. queue the Java haters. For me the language is less important than the goal: Write Once Run Everywhere (& Test Everywhere, this is the real world after all). Skilled Java developers can get pretty damn close to this ideal.
Incorrect. They cannot sue OpenJDK. Sun had an explicit grant in the license for their JDK which allows compatible implementations to use all their patents. OpenJDK was created under these conditions. The restriction is that the trademark "Java" cannot be used unless you have passed the Test Compatibility Kit to ensure that the Java Write Once Run Anywhere promise is upheld. This is what shafted Microsoft's incompatible implementation in year's past (since it broke that promise to users).
Google were sued by Oracle for breaching copyright (in a clearly ridiculous case). This does not apply to OpenJDK because it was created under the Gnu General Public License (GPL). So OpenJDK will remain free forever - which is the whole point of the GPL (companies can't change their mind and shaft users; Stallman foresaw that possibility after his printer driver travails with Xerox way back in 1980).
So be happy, you can confidently rely on OpenJDK being around for decades.
Jezelle is slow and is not intended for performance. It was intended for low power execution.
The HotSpot JVM is and adaptive compiler. Java Byte codes are converted into native instructions during executions. Over time, critical paths will become fully optimized. "Hot spots" in the execution will be further dynamically executed.
You see, running native is fast. There's no difference between what the JVM can compile to native and, say, a c compiler. In light of being able to simply parse and convert byte code directly to the underlying assembly, something like Jazelle really doesn't offer much. It's not like it has magic instructions that will somehow be faster then the execution units in the CPU.
Of course, the compiling costs time and therefore power. Something less good, perhaps, on mobile. (Though caching the binaries from a first run isn't that hard.) On an ARM server you wouldn't care about the compile time spent, because execution time is better in native.
It's also important to point out that most ARM implementations only support Jazelle at the ISA level. That is, they don't map directly to any kind of Java-execution hardware. Instead, microcode simply maps it to regular arm to get simple instructions. This is quite a bit slower than what the JVM would produce, since it does no dynamic optimizations based on the run time profile. (additional loop unrolling, method inlining where appropriate, etc)
I am intrigued by your ideas, and want to subscribe to your newsletter detailing how to switch a SQL based storage system to a DNS based storage system.
Would that qualify as a NoSQL system, by any chance? I hear that is a frightfully innovative buzzword, and should ideally be applied to all new processes, to ensure "hipsterness" and "webscale", whatever that means. It would also means that our investors would contribute with even bigger gobjaws of money, and you just can't have enough money, you know.
It's The Golden Rule: "He who has the gold makes the rules."