Yes and no...

Posted Dec 18, 2011 13:48 UTC (Sun) by khim (subscriber, #9252)
In reply to: Sun JDK & Android AOSP by ballombe
Parent article: Ubuntu disabling the Sun Java JDK browser plugin

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