Red Hat Devs Working On ARM64 OpenJDK Port 63
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."
Orcale (Score:1)
will sue.
Re: (Score:3, Interesting)
RedHat has an agreement with Sun that Oracle inherited. They can't do anything about it at this point.
Re: (Score:1)
Who's Orcale?
A killer whale of a company.
Re:Orcale (Score:5, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
Look here: MaraDNS [maradns.org]. It is a fork of MySQL, incorporates all free available changes from MySQL and makes some improvements.
Re: (Score:1)
Re: (Score:2)
It rather use PowerDNS, as it supports DNSSEC. It also uses PostgreSQL a superior solution in many situations. PowerDNS supports many backends it can also serve from bind zone files for example.
Re: (Score:3)
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.
Re: (Score:2)
You are so right. I meant of course MariaDB [mariadb.org] the fork of MySQL. I don't know why I wrote MaraDNS, maybe because they sound a-like. I'm sure one of the poster have corrected me already.
Re: (Score:2)
This does not apply to OpenJDK because it was created under the Gnu General Public License (GPL).
I'd like to look in on the mirror universe sometime where Google decided to base Davlik on OpenJDK and avoided the whole lawsuit thing and had a performant vm to boot.
So be happy, you can confidently rely on OpenJDK being around for decades.
Longer than Oracle Java, I'd bet good money.
Re: (Score:2)
There is very little actual difference between 'Oracle' Java and OpenJDK. They share the same source base. The primary difference is legal: license conditions and ownership.
Re: (Score:2)
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).
They also sued over patents, but those are also covered by the license for the JDK. Even better, Oracle lost on both the copyright and patent fronts in its lawsuit against Google.
Re: (Score:2)
as long as its gpl oracle can shove it because they were stuck with the licence sun chose for it
Great idea (Score:5, Interesting)
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.
Re: (Score:2)
Re:Great idea (Score:4, Insightful)
Why would I want Java shit eating up my iPhone battery?
Good point, since because of deliberate designed obsolescence you can't replace it or carry a spare. A lot of people might want to run Java applications on their phones. A lot of those people have the option to carry spare batteries or, heaven forbid, get an extended life battery. Pity that Apple doesn't allow that on their iShiny devices.
Re: (Score:2)
No he is correct it is why iphone apps smoke the android apps for performance. The overhead introduced by java just means you need at least 20% more cpu,ram etc just to get equal performance.
Re: (Score:2)
No he is correct it is why iphone apps smoke the android apps for performance. The overhead introduced by java just means you need at least 20% more cpu,ram etc just to get equal performance.
Yeah that's why most apps on Android don't benefit much if at all when native code (like the NDK lets you write) is used. Keep drinking that KoolAid though. It must be delicious.
I have an iPhone and an Android tablet. Both are pretty quick and there is no noticeable difference between the platforms. Well that's not true. The Asus tablet is noticeably faster but that's not fair because it's a quad core Tegra 3 with twice the RAM.
Java is already on Android, kinda (Score:2)
Re: (Score:2)
For me the language is less important than the goal: Write Once Run Everywhere (& Test Everywhere, this is the real world after all).
Indeedy. But these days you can use the Java platform without using the Java language. Next time I'm writing something for the JRE, I'm going to give Scala a shot. (And if it's riddled with gotchas, I can always come back to Java...)
Re: (Score:3)
Interviewed with a gamer shop recently and they where telling me how unstable their platform was. They where hoping I could help them out, then proceeded to tell me they where using scala for production work. My response was this, hmm no thanks I cannot help you.
Re: (Score:2)
Hey no need for attacks, and far from unemployed and far from being a small gamer company. Hey I am not knocking scala if you want to write in it go ahead. I am just saying it does not exactly have a long proven history as of yet. Just like I love node.js it is bad ass, however I would hesitate to run it in a critical production system as I have experienced instability with it. Just sayin I tend to play it a bit safer when it comes to production work.
Re: (Score:2)
As a practitioner in the field I have to disagree with you. Too bad you're an AC so we can't debate this properly and you can provide better evidence for your assertion. The rest of your post is without merit - it is hyperbole, since it either applies to all software or ignores the fact that the Free Software OpenJDK is where the real innovation is and Oracle has been shown not to hold the reigns.
Re: (Score:1)
Java is fucking awesome!
I am a systems engineer and java takes a ass load of hardware to run on. Job Security!
Re: (Score:2)
Re: (Score:2)
It's a shame that even Sun did not believed in the "Write Once Run Everywhere" of Java.
They could have had something like Android years before of Google, in fact Google approached Sun to create Android together (see Oracle vs. Google). But instead Sun created JavaME.
Why just 64bit? (Score:1)
What's stopping them from doing this for 32bit ARM while their at it?
Re: (Score:2)
Also, RedHat doesn't care about mobile devices; they care about ARM servers. 64bit will be more more relevant in that area, as java backend code often needs as much memory as you can give it.
Re: (Score:1)
There already is a JIT for 32 bit OpenJDK.
Avoiding a similar situation (Score:2)
I wonder how they're planning to prevent Oracle releasing a more sophisticated proprietary JIT for 64 bit ARM?
Re: (Score:2)
Secret ARM opcodes can execute JVM bytecode (Score:2)
Many ARM-based chips include the "Jazelle DBX" (Direct Bytecode eXecution) hardware CPU extension, which lets "95% of [JVM] bytecode" be executed directly by the CPU -- without need for recompilation to 'native' ARM/Thumb instructions. (See http://en.wikipedia.org/wiki/Jazelle [wikipedia.org] )
However, unlike most of the ARM universe which is fairly open, Jazelle DBX's specs, implementation, and operating details are apparently a closely held secret, shared by ARM only with select JVM implementors. I'll be interestin
Re: (Score:2, Informative)
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
Java comeback (Score:2)
If we look more practically it has never left, it just returns to desktop environment. Tons of very useful Java applications are made and used by millions of users. Main sales point - yes, one binary works (with tweaks and testing) on at least 10 different platforms. For example, OpenStreetMap has an excellent editor for advanced mappers JOSM - while Linux for example has their native editors for OSM, JOSM wins hands down in portability and universality. That means a developer can hack together a plugin for
But will it be hardware accelerated? (Score:2)
I hope it will be hardware accelerated. I have also wondered if Android's Dalvik VM took advantage of built-in hardware acceleration in ARM processors. It seems to be a waste if it's not used.
Terribly good news for me. (Score:2)
Regardless of technicals and wherever you use arm64 or not, this means that there will be a well qualified team of engineers working on OpenJDK besides Oracle. This is Good News (TM), folks ! For last three years I was worried that Larry will do with Java what he does with all other products and technologies he puts his hands on - specifically, turn it into crap (uh, yes - money producing one - yet total crap from engineer/dev/admin perspective). Oracle might be good money sucking entity, yet it is a remark