Sun JDK & Android AOSP [LWN.net]

Sun JDK & Android AOSP

Posted Dec 16, 2011 17:59 UTC (Fri) by dlang (guest, #313) [Link]

remember that it is Oracle that is triggering this with their new license. make sure you blame the right people :-)

I suspect that google will modify the Android build system to work with openjdk pretty quickly.

Sun JDK & Android AOSP

Posted Dec 16, 2011 18:48 UTC (Fri) by jspaleta (subscriber, #50639) [Link] (6 responses)

Uhm... just because 3rd party distributors no longer have the right to distribute... doesn't mean the code is unobtainable. Oracle (like Sun before them) will be hosting gratis binaries of Jre6 for linux users. All Oracle has done is rolled back the clock to 2005, when the license Canonical is relying on did not yet exist and redistribution rights had to be negotiated on a case by case basis with Sun.

This blog entry has more context:
http://robilad.livejournal.com/90792.html

If you need the Jre 6 binaries still for whatever reason... they are obtainable from Oracle.

-jef

Sun JDK & Android AOSP

Posted Dec 16, 2011 19:04 UTC (Fri) by mikov (guest, #33179) [Link] (5 responses)

Uh-oh, I don't see a .deb package on Oracle's site.

No use pretending like this is a harmless unavoidable logical step from Oracle. Removing the DLJ has absolutely no benefit for OS distributors, developers or users and it does cause severe problems for everybody ... except Oracle.

If the "official" JDK is so close to OpenJDK, and if Oracle is providing "gratis" packages anyway, where is the harm in allowing Ubuntu/Debian/etc to package them for everybody's convenience??

I can't help but see as the next step in Java's unavoidable death by the hands of Oracle. Especially if they succeed in killing Dalvik as well.

Sun JDK & Android AOSP

Posted Dec 16, 2011 19:28 UTC (Fri) by jspaleta (subscriber, #50639) [Link] (4 responses)

I'm not saying it isn't a headache. I'm saying its exactly like the situation was back in 2005 that everyone prior to the formation of Ubuntu was dealing with already with Java.

It'll be interesting to see what Debian decides to do with the sun-java6-jre package in nonfree which ironically were derived from Canonical's partner repository packages.

And really you shouldn't be too upset that Oracle isn't building debs. Even for those of us who use rpm based distributions, the rpm packages provided by Oracle (and by Sun back in the day) aren't particularly stellar. There's a reason why the jpackage project exists and encourages people to rebuild rpms using their nosrc approach instead of the Sun/Oracle packages to build well formed rpm packages.

And we've already seen examples of Debian doing this sort of workaround when redistribution of the code is not allowed by the license. I'm pretty sure the standard debian and Ubuntu flash-plugin package has historically had to work around a lack of redistribution rights and pull the flash-plugin payload at package install in what is essentially a fake package wrapper that sets up the dependencies correctly and what not. I'm sure a similar deb packaging technical workaround can be found for the oracle jre6 bin if there is enough desire to do it.

-jef

Sun JDK & Android AOSP

Posted Dec 16, 2011 19:53 UTC (Fri) by mdeslaur (subscriber, #55004) [Link] (2 responses)

Debian has already removed it from the archive:

http://sylvestre.ledru.info/blog/sylvestre/2011/10/25/rem...
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646524

Sun JDK & Android AOSP

Posted Dec 16, 2011 20:20 UTC (Fri) by jspaleta (subscriber, #50639) [Link]

With that bit of historic information in hand from Oct, the move by Canonical is even less newsworthy really and should have been expected.

Also worth noting the the deb bugreport discussion stresses migration to openjdk instead of trying to support the download packaging hack used by flash plugin package. Seems all the important considerations are all old news.

-jef

Sun JDK & Android AOSP

Posted Dec 17, 2011 6:25 UTC (Sat) by pabs (subscriber, #43278) [Link]

For Debian stable/oldstable it seems that it will stay around. Although non-free is not supported by the Debian security team, it sounds like they might issue a DSA stating that there are unfixable security issues and strongly encourage switching to OpenJDK.

Sun JDK & Android AOSP

Posted Dec 17, 2011 17:04 UTC (Sat) by jond (subscriber, #37669) [Link]

Prior to the DLJ, there was a "java-package" tool that did exactly what you describe (but imho was much more robust than the flash installer).

Someone may reintroduce it, or support could be grafted into a generic packaging helper tool such as 'game-data-packer' (which could rename and lose the 'game-' prefix).

Sun JDK & Android AOSP

Posted Dec 16, 2011 19:22 UTC (Fri) by tzafrir (subscriber, #11501) [Link] (6 responses)

That's a Google bug, not an Oracle bug.

In the mean time, which (binary) file needs to be patched to work around this stupid limitation?

Sun JDK & Android AOSP

Posted Dec 17, 2011 8:43 UTC (Sat) by geofft (subscriber, #59789) [Link] (5 responses)

One presumes that software authors don't add these kinds of restrictions for their own amusement, so perhaps it'd be more productive to first figure out why this check is present, whether you agree with the reasoning that introduced it, and whether that reasoning still applies, instead of assuming that no such reasoning ever existed.

Sun JDK & Android AOSP

Posted Dec 18, 2011 13:13 UTC (Sun) by ballombe (subscriber, #9523) [Link] (4 responses)

When software authors are grepping version strings it is always correct to assume they do it for a non-technical reason. Otherwise they would check for the specific features they need.

Yes and no...

Posted Dec 18, 2011 13:48 UTC (Sun) by khim (subscriber, #9252) [Link] (3 responses)

When software authors are grepping version strings it is always correct to assume they do it for a non-technical reason.

Sure. It's actually one single non-technical reason: someone must support different versions and waste time and money better spent on other things.

Otherwise they would check for the specific features they need.

Yesh, right. There are approximately bazillion packages which demand from you "you need pkgtool > 0.9", "please install binutils 2.21 or newer", etc. Why AOSP should be any different? They just check that you use tools which are known to work and don't use tools which are known not to work.

I doubt people added this check out of spite: most probably they observed some kind of strange behavior (not necessary "it just refused to build", it may be "some particular rare function started producing incorrect output" or something similar) and instead of trying to fight OpenJDK they just added that check.

Yes and no...

Posted Dec 18, 2011 14:09 UTC (Sun) by raven667 (subscriber, #5198) [Link] (2 responses)

This is more of a philosophical discussion than a technical point, but there are other ways to handle this situation. One could make a bug report t the upstream software maker, or even attempt to fix the bug oneself if they have the energy. One could make a specific capability test and maybe even a workaround although that can clutter a code base or one could blacklist the versions of the environment known to not work. One can also just blacklist the whole thing, that's the easiest for the developer by far but the most inflexible for users preventing them from working around the issue themselves, even preventing it from working when the underlying issue is fixed. It may be broken for even longer than the original issue existed.

Yes and no...

Posted Dec 18, 2011 18:03 UTC (Sun) by gnu_andrew (guest, #49515) [Link] (1 responses)

The final option seems to be what's happened here. Presumably, there were a lot of bug reports of builds using OpenJDK a while ago and it was simply blacklisted as a simple solution. However that means that all new versions are been blocked, including 7 where OpenJDK is the reference implementation.

I can understand the motivation but for those of us working on the code, this kind of thing is quite annoying. It gives OpenJDK a bad press for an issue which may no longer be present and (to my knowledge as IcedTea maintainer and OpenJDK developer) has never been reported.

We do get a number of issues with the javac in OpenJDK 6 because it's some horrible hybrid which has changes that were made for 7 early on (so it's different from the proprietary 6 compiler) but not later fixes (so things that work with 7 don't work with it). On top of that, Oracle, having created this mess, don't seem prepared to support it to a great degree. However, this Android filter also blocks the 7 compiler which should be the same as the one in proprietary versions of 7.

Yes and no...

Posted Dec 22, 2011 13:22 UTC (Thu) by cesarb (subscriber, #6266) [Link]

> However, this Android filter also blocks the 7 compiler which should be the same as the one in proprietary versions of 7.

It seems they do not want to move to Java 7 because of MacOS:

"We don't want to go again to a situation where we allow two different
versions, like we tried to do with 5 and 6, because the people
building with the newer version when they make changes will break the
build for the people still using the older one. As long as MacOS only
has 6, we'll have to use 6 everywhere.

JBQ" - http://groups.google.com/group/android-building/msg/bf9d3...

Sun JDK & Android AOSP

Posted Dec 16, 2011 21:30 UTC (Fri) by ldo (guest, #40946) [Link] (6 responses)

Interesting, because I have successfully built a few Android apps using OpenJDK with the Android SDK.

Sun JDK & Android AOSP

Posted Dec 17, 2011 0:26 UTC (Sat) by alankila (guest, #47141) [Link] (5 responses)

Same. I think I've built even complete OS packages (and ran them on my phone).

I think the alleged incompatibility is being exaggerated somewhere.

Sun JDK & Android AOSP

Posted Dec 17, 2011 17:26 UTC (Sat) by alankila (guest, #47141) [Link] (4 responses)

As alonz said, I can confirm the test in ICS source tree. I've not tried building ICS with OpenJDK, but I have no doubt that it will fail.

Sun JDK & Android AOSP

Posted Dec 17, 2011 18:09 UTC (Sat) by mjw (subscriber, #16740) [Link] (2 responses)

If you try, and it does happen to fail for some reason, please do report a bug. http://icedtea.classpath.org/bugzilla I am sure the IcedTea and/or OpenJDK hackers would be happy to know about any deficiencies compared to the proprietary java implementations.

Sun JDK & Android AOSP

Posted Dec 17, 2011 19:17 UTC (Sat) by alankila (guest, #47141) [Link] (1 responses)

Well, I'm pretty sure that I don't need to do anything. Besides, it's not OpenJDK's fault and they grep for "openjdk" string in java --version and refuse to build if it's there.

Sun JDK & Android AOSP

Posted Dec 18, 2011 14:33 UTC (Sun) by mastro (guest, #72665) [Link]

What happens if the version check is removed? Does the build succeed?

Sun JDK & Android AOSP

Posted Dec 19, 2011 0:48 UTC (Mon) by mgross (guest, #38112) [Link]

ICS and the latest GB update both fail to build using openJDK. Interestingly openJDK *did* build AOSP for quite a while. I know this because a number of co-workers where using openJDK without knowing it and I got to help debug their troubles after an update to AOSP happened.

FWIW I think it craps out in either an SDK or test project. (I don't recall which one was trouble maker)

I recomend folks to get the java from oracle web site and set the shell search path such that the javac used in the build is the one from the oracle JDK install directory and recommend NOT using any distro installed java for building AOSP.

Sun JDK & Android AOSP

Posted Dec 17, 2011 0:37 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Android's SDK works just fine with OpenJDKs, I'm using it with nightly OpenJDK builds in fact.

Though I have to admit that I don't use Eclipse integration or anything fancy since I build everything using Maven ( http://code.google.com/p/maven-android-plugin/ ) and IntelliJ IDEA.

Sun JDK & Android AOSP

Posted Dec 17, 2011 10:16 UTC (Sat) by alonz (subscriber, #815) [Link] (1 responses)

The issue isn't the SDK—it's the AOSP release, which has a specific build-time check (in build/core/main.mk) to prevent building with OpenJDK. The check is new to the ICS release, so it's likely that some people haven't seen it yet…

Sun JDK & Android AOSP

Posted Dec 19, 2011 14:30 UTC (Mon) by jjs (guest, #10315) [Link]

Has anyone edited the check out and seen where the build actually fails?