Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Java Open Source News

Red Hat Devs Working On ARM64 OpenJDK Port 63

Posted by Unknown Lamer from the that's-quite-the-hotspot dept.
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."
This discussion has been archived. No new comments can be posted.

Red Hat Devs Working On ARM64 OpenJDK Port More

Red Hat Devs Working On ARM64 OpenJDK Port

Comments Filter:

  • will sue.

    • Re: (Score:3, Interesting)

      by Billly Gates ( 198444 )

      RedHat has an agreement with Sun that Oracle inherited. They can't do anything about it at this point.

    • Re:Orcale (Score:5, Interesting)

      by SplashMyBandit ( 1543257 ) on Thursday October 25, 2012 @05:58PM (#41771873)

      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.

      • 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.

        • > Longer than Oracle Java, I'd bet good money.
          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)

        by Raenex ( 947668 )

        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.

    • 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)

    by SplashMyBandit ( 1543257 ) on Thursday October 25, 2012 @05:50PM (#41771795)

    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.

    • Um, I already have Debian Kit installed into my rooted Android mobile with ARM CPU (Samsung Galaxy Ace). And Debian does include OpenJDK, although 32 bit. I can compile & run console Java applications just fine. I even have some experimental X windows server there, but most X apps still either crash or run out of memory. Xeyes runs fine though. I read somewhere that people had better luck with headless X windows server and Android VNC client displaying whatever is displayed on that server. I'll have to

    • Re: (Score:2)

      by pnot ( 96038 )

      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...)

      • 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.

    • Java is fucking awesome!

      I am a systems engineer and java takes a ass load of hardware to run on. Job Security!

      • lol. I've had to write Java applications to run on cheap single board computers that have the same amount of RAM as a PS3 (that is, fsck all by modern standards - so little you'd have trouble buying such a small amount for a PC these days). The Job Security is the fact it runs anywhere (both a large run of hardware scales, and operating systems).

    • Re: (Score:2)

      by devent ( 1627873 )

      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)

    by Anonymous Coward

    What's stopping them from doing this for 32bit ARM while their at it?

    • Re: (Score:2)

      by pavon ( 30274 )

      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)

      by Anonymous Coward

      There already is a JIT for 32 bit OpenJDK.

  • I wonder how they're planning to prevent Oracle releasing a more sophisticated proprietary JIT for 64 bit ARM?

  • 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)

      by Anonymous Coward

      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

  • 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

  • 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.

  • 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

Slashdot Top Deals

We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to be assimilated.

Close