LWN: Comments on "Ubuntu disabling the Sun Java JDK browser plugin"

Downgrade is the new upgrade

mfedyk — Fri, 27 Jan 2012 19:50:57 +0000

They could have made the package depend on openjdk instead.

Ubuntu disabling the Sun Java JDK browser plugin

rahulsundaram — Tue, 27 Dec 2011 17:21:17 +0000

You might consider reporting the bug upstream and not deal with the distribution maintainer at all. IcedTea which is really what is distributed under the OpenJDK name has its own bug tracker.

Ubuntu disabling the Sun Java JDK browser plugin

steffen780 — Tue, 27 Dec 2011 17:14:52 +0000

This analogy is completely wrong. Key points:
- Physical objects are not AT ALL the same as thoughts/ideas such as software
- Copying software is not the same as stealing an object, since copying doesn't take away the original, whilst stealing an object does.
- Oracle hasn't stopped giving away their JRE, you can still download it free-as-in-free-beer. They're just being assholes to free software for no recognisable purpose, as they do so often.
- The post you replied to never said anything about kicking Ubuntu to get OracleJRE inspite of this being technically illegal - it talked about kicking them to try to track down and fix the bug in OpenJDK

Downgrade is the new upgrade

JanC_ — Thu, 22 Dec 2011 21:29:21 +0000

Synaptic (and I think update-manager too?) can/will show (part?) of the changelog if you actually want to read it.

Downgrade is the new upgrade

jrw — Thu, 22 Dec 2011 13:33:24 +0000

I'll have to look into scripting a replacement using apt/dpkg. Thanks for the heads up!

Yes and no...

cesarb — Thu, 22 Dec 2011 13:22:24 +0000

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

Downgrade is the new upgrade

nix — Thu, 22 Dec 2011 11:35:30 +0000

What I'm asking for is something in-your-face when there's an expected loss of functionality.

The irony is that text-mode updates have had this for something like ten years, thanks to apt-listchanges' NEWS-file reporting. Graphical package managers don't seem to have caught up.

Downgrade is the new upgrade

jrw — Thu, 22 Dec 2011 08:03:14 +0000

The GNOME 3 thing is only forced on you when you perform a version upgrade. I think most people are already aware that many things can change significantly, for better or worse, during a version upgrade. That's one of the reasons I'm still at Ubuntu 10.10.

Also, I'm certainly aware that regressions can happen at any time and there's always some risk when updating. In fact, not so long ago, one of those regressions occurred for me during an upgrade and broke the same application (Netilla). I was not happy about that either, but I believe that it was an accidental regression. It was fixed a few days later.

In this case, the regression was well known (by the package maintainers) in advance, and in fact, the entire reason for the update was to effect a regression! That's what makes this case different and worth discussing.

As to the possibility of restoring previous versions of packages, I believe it would be a welcome step forward if the user could just retrieve and reinstall the exact previous version of the packages he just updated, in the case of a detected regression. That still seems doable in the vast majority of cases. I do understand that in some exceptional cases the changes wrought by a newer package could be so far reaching as to make recovery by reinstallation of the older package unworkable.

I'll have to look into using LVM as a checkpoint mechanism to be able to revert failed updates. But if it can't be scripted up pretty easily, it won't be worth it.

Downgrade is the new upgrade

jrw — Thu, 22 Dec 2011 07:27:53 +0000

I'm not unhappy with Canonical for no longer hosting these packages. That frustration should be properly directed at Oracle.

As has been pointed out elsewhere, there are packaging techniques which allow for dynamically loading third-party hosted software when the outer package is installed. That may be the only remaining alternative if there's any interest in keeping these packages alive. In my case, I can download and install them manually, so that would only be a small convenience to me.

Downgrade is the new upgrade

dlang — Thu, 22 Dec 2011 06:58:10 +0000

I can understand your frustration at not seeing the information on this issue before you did the update, but given that Oracle will not let Cononical distribute the code, how do you expect them to legally let you load it back?

Downgrade is the new upgrade

dlang — Thu, 22 Dec 2011 06:57:53 +0000

> What I'm asking for is something in-your-face when there's an expected loss of functionality. When there's a security fix, it should stand out as a danger if you don't accept the update. When there's an expected downgrade, it should stand out as a danger if you do accept the update.

so when you upgrade to GNOME 3 it should warn you that you are about to loose a lot of functionality?

somehow I don't see this taking place.

remember that every upgrade can contain regressions for somebody under some conditions.

Ubuntu does mark some upgrades as being security related. I generally use the command line not the GUI tools, so I can't point you directly at the place to look, but what I remember seeing in passing is that when presented with the list of packages to upgrade, there is a category of security patches.

> I would think that the bulk of what I'm looking for could be achieved by just keeping the previous packages around so they can be reapplied. If a rollback is required, remove the packages that have been added and reapply the packages that have been removed.

you are overestimating the smarts of the packaging tools.

a package contains several pieces, the bulk of the package is the files to install on the system.

However the complicated part of the package are the parts that prepare the system, or change the system as part of the upgrade (frequently modifying config files). These are scripts that can do anything to the system, but these scripts only know about the version of the software that's you are installing (or uninstalling for scripts that make changes when you uninstall a package), they don't know what version used to be on the system, and they cannot possibly know about what changes a newer version may have made to config files to convert them back.

This makes a package based upgrade backout _extremely_ hard to do, and given that a large percentage of upgrade problems have to do with failures of these scripts (not converting config files perfectly), relying on them to be perfect in doing a downgrade is silly.

you may be thinking "well, just make backup copies of the config files then", but this isn't limited to config files, this process can modify _anything_ on your system, databases, files, directories, ANYTHING. This is why installing packages from an unknown source can be so dangerous.

Downgrade is the new upgrade

jrw — Thu, 22 Dec 2011 06:16:51 +0000

>> If I knew where to find this information, I would read it.

> what tool do you use to do your upgrades? every one of the GUI tools I have seen allows you to look at each package being upgraded and see the description of the package.

I misread your original comment here. I use Update Manager and I have never found its detailed information useful. In this case I didn't read the detailed information. I browsed through the list of things to be updated, didn't find anything especially interesting in the list of packages, and authorized the update. I didn't find out until I rebooted one or two days later and tried to use Netilla that java had been removed.

What I'm asking for is something in-your-face when there's an expected loss of functionality. When there's a security fix, it should stand out as a danger if you don't accept the update. When there's an expected downgrade, it should stand out as a danger if you do accept the update.

>> I also noted that some kind of checkpoint system would be very helpful in dealing with updates. I would love to see an auto-checkpoint updating system that allows me to roll back an update. I have had occasion to wish for it several times in the past.

> this is something that many people would like to see, but actually implementing it is very hard, and can take a non-trivial amount of storage to do so (and how do you decide how long to keep this?)

I would think that the bulk of what I'm looking for could be achieved by just keeping the previous packages around so they can be reapplied. If a rollback is required, remove the packages that have been added and reapply the packages that have been removed.

> If you really want this, run your system on top of LVM and take a snapshot just before you upgrade so that you can revert back to it.

Perhaps LVM could be helpful here, if the LVM snapshot could be applied to just the OS partitions. Do you know of a How To for using LVM snapshots to rollback OS updates?

Downgrade is the new upgrade

jrw — Thu, 22 Dec 2011 05:58:16 +0000

I'm not complaining because they put out an update. I'm glad they put out security updates. I'm complaining because their update was a downgrade, and they didn't tell me about it in advance, so I could skip it, and they didn't provide me any way to restore the packages after they had been neutered.

Downgrade is the new upgrade

raven667 — Thu, 22 Dec 2011 05:41:07 +0000

How much would you have complained if canonical had left the vulnerabilities be an you had to rebuild all the systems you have access to.because you were compromised?

Downgrade is the new upgrade

dlang — Thu, 22 Dec 2011 05:31:22 +0000

> If I knew where to find this information, I would read it.

what tool do you use to do your upgrades? every one of the GUI tools I have seen allows you to look at each package being upgraded and see the description of the package.

> I also noted that some kind of checkpoint system would be very helpful in dealing with updates. I would love to see an auto-checkpoint updating system that allows me to roll back an update. I have had occasion to wish for it several times in the past.

this is something that many people would like to see, but actually implementing it is very hard, and can take a non-trivial amount of storage to do so (and how do you decide how long to keep this?)

If you really want this, run your system on top of LVM and take a snapshot just before you upgrade so that you can revert back to it.

Downgrade is the new upgrade

jrw — Thu, 22 Dec 2011 03:47:04 +0000

> remember that the existing version of java has security holes that are currently being exploited.

After the update broke my java, my research did discover this rationale. However, if I had been given the choice, I would have had no qualms about leaving the active/exploitable security holes in place on my personal desktop, which I keep relatively tight control over, rather than having java removed altogether and losing a critical application.

> So Canonical has the options of leaving it in place and having the desktops hacked, or removing it.

My complaint is with my not being given this choice. Canonical made this choice for me. And consequently broke my system in a way that cost me 3-4 hours to fix at an inconvenient time. Not happy about having to deal with that. Luckily for me, I didn't have an immediate critical need to use Netilla to remote into the servers I am responsible for, or I would have had to drive to the office in the middle of the night.

> the upgrade process doesn't have the ability to do the type of notification that you would like

I'm aware of this, but I'm not happy about it. Using the mechanism they do have available (an upgrade), they deliberately broke my desktop, in a way that had ramifications to me they couldn't possibly have understood. I wrote this post and several others on the ubuntu forums and bugs.launchpad to bring attention to this issue.

> I'll bet that if you were to dig down into the system to see what was upgraded with the new package, it would tell you exactly what was going to happen and why. but nobody bothers to read those details.

If I knew where to find this information, I would read it. If they had provided me a warning, in advance, that I was about to disable part of my system, I would have read it. If they had given me a choice, I would have made the right one for me. For me, a large part of the linux/unix culture is all about choice. I like many things about the way upgrades are handled in Ubuntu, especially how the user is given a meaningful choice about when/if to take an upgrade. But I think they dropped the ball on this one.

Hopefully, Canonical (and other distributions) will improve their tools so that they can offer such a choice in the future. I detailed what I believe is the right way of handling a priori known breakage (give the user an informed, in-your-face, choice). I also noted that some kind of checkpoint system would be very helpful in dealing with updates. I would love to see an auto-checkpoint updating system that allows me to roll back an update. I have had occasion to wish for it several times in the past.

Downgrade is the new upgrade

dlang — Thu, 22 Dec 2011 03:09:58 +0000

remember that the existing version of java has security holes that are currently being exploited.

So Canonical has the options of leaving it in place and having the desktops hacked, or removing it.

the upgrade process doesn't have the ability to do the type of notification that you would like, I'll bet that if you were to dig down into the system to see what was upgraded with the new package, it would tell you exactly what was going to happen and why.

but nobody bothers to read those details.

Downgrade is the new upgrade

jrw — Wed, 21 Dec 2011 17:28:15 +0000

I just spent several hours last night, researching on the web and trying different possible solutions, after updating Ubuntu and discovering, the next time I booted, that I had downgraded myself out of a critical desktop app (in my case, Netilla, used for remote logins). Aside from the mess created by Oracle, I'm sure Canonical has managed to alienate many users who were depending on java or its related plugin to run their apps, and found after updating that they no longer had any java at all.

This needs to be handled better, from a user's point of view, including:
- putting the known-downgrade in the user's face before updating
- informing the user of the possible choices
- offering to install a replacement
- allowing an easy way to keep some back-level packages, while updating others.

Perhaps most importantly, it would be nice to have some kind of "OS checkpoint" capability to allow for a rollback if the update fails.

Sun JDK & Android AOSP

jjs — Mon, 19 Dec 2011 14:30:55 +0000

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

Ubuntu disabling the Sun Java JDK browser plugin

nhippi — Mon, 19 Dec 2011 11:28:14 +0000

> Or kick Ubuntu / OpenJDK guys even harder. ... Sometimes it really sucks to be a Linux guy.

Option 8, find other Linux users with same bank and collect a fund to contract someone to fix OpenJDK applet code to work with your online bank.

It may suck to be a Linux guy if you solely depend on goodwill of others. Sure, there is lot of goodwill around, but you can't depend on it. Free software really shines when people scratch their own itches and contribute back the results.

Sun JDK & Android AOSP

mgross — Mon, 19 Dec 2011 00:48:16 +0000

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.

Ubuntu disabling the Sun Java JDK browser plugin

ceplm — Sun, 18 Dec 2011 23:52:24 +0000

But I would add (and yes, I am a Red Hat employee, although I have personally nothing to do with OpenJDK maintaining) that this bug shows we are trying hard to make OpenJDK really working. Glad to see it.

Ubuntu disabling the Sun Java JDK browser plugin

geuder — Sun, 18 Dec 2011 20:24:24 +0000

Thanks mjw and gnu_andrew for your concrete pointers and suggestions.

I'll come back to them when I have a bit more time and can overcome my reluctance to address that nasty banking stuff again... I guess chances are still good that I'll do it before migrating to Windows permanently ;)

> A lot of the issues with fixing problems with the plugin and
> banking sites has been that we can't reproduce the problem as
> we obviously don't have an account

Absolutely: I have actually contacted my bank last time when I was fighting with the problem and asked them to provide a demo account. Unfortunately without any concrete results. They promised to retun to the issue later, which they haven't done. Some banks here have a demo account just to show how great their pages are. But the guys with the Java stuff don't.

Yes and no...

gnu_andrew — Sun, 18 Dec 2011 18:03:49 +0000

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.

Ubuntu disabling the Sun Java JDK browser plugin

gnu_andrew — Sun, 18 Dec 2011 17:50:10 +0000

I'd suggest that too. A lot of the issues with fixing problems with the plugin and banking sites has been that we can't reproduce the problem as we obviously don't have an account with them to login and the code tends to be obfusticated. However, with a responsive reporter who's responsive and willing to try things, some progress may be possible. If you don't get a response in a reasonable time there either, ping either dbhole (the IcedTea-Web maintainer) or me (gnu_andrew) on IRC (#openjdk on OFTC).

Note that the plugin is one of the areas where Sun/Oracle have not released their code as FOSS and, along with the accompanying javaws, the only one not to have any replacement in OpenJDK itself.

Ubuntu disabling the Sun Java JDK browser plugin

mjw — Sun, 18 Dec 2011 16:41:14 +0000

> I created a bug report in launchpad and offered my help to debug it but got no reaction from any maintainer.

You might want to file a bug report upstream against IcedTea-Web if the package maintainer is unresponsive: http://icedtea.classpath.org/bugzilla

Ubuntu disabling the Sun Java JDK browser plugin

teknohog — Sun, 18 Dec 2011 15:42:48 +0000

> maybe just download OracleJRE from Oracle directly

This is how it already works in Gentoo, along with a lot of other proprietary software. You have to download the tarball yourself, but Portage takes care of setting it up.

Sun JDK & Android AOSP

mastro — Sun, 18 Dec 2011 14:33:00 +0000

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

Yes and no...

raven667 — Sun, 18 Dec 2011 14:09:50 +0000

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

khim — Sun, 18 Dec 2011 13:48:27 +0000

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.

Sun JDK & Android AOSP

ballombe — Sun, 18 Dec 2011 13:13:29 +0000

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.

Ubuntu disabling the Sun Java JDK browser plugin

tkiss80 — Sun, 18 Dec 2011 11:58:19 +0000

I totally understand your problem, but for the "inter-company legal nonsense, which I wouldn't care about" part I'd like to add the following:

Imagine you have a neighbour who has a contract with a chocolate factory: he gets the chocolate for free, in order to distribute it (e.g. for marketing purposes, it's irrelevant in this example). You get as many as you want from him, and you can be sure it's always fresh and properly packaged (your neighbour takes care of it). What happens when the chocolate factory eliminates the contract? Do you expect your neighbour to steal the chocolate so he can continue distributing? Do you think if you knock harder on his door he will be able to give you chocolate?

Ubuntu disabling the Sun Java JDK browser plugin

geuder — Sun, 18 Dec 2011 09:43:20 +0000

Well, I would have preferred to use OpenJDK with my banking applet. But it didn't work. I created a bug report in launchpad and offered my help to debug it but got no reaction from any maintainer. I investigated on which irc channel Ubuntu's maintainers are supposed to hang out, but no reaction there either. So I eventually installed Sun JRE and have at least been able to use my bank for a bit more than a year now.

Now it looks I'm have to change bank (which I should have done anyway because of their incompetent IT strategy), but it has all kind of economical consequences. Or kick Ubuntu / OpenJDK guys even harder. Or just use the one and only PC in the household that is able to dual boot to Windows. 3 not so tempting choices. Sometimes it really sucks to be a Linux guy.

(well there is the 4th choice that the problem has just disappeared by itself in a bit more than a year, need to check again)

(and as I'm whining here a 5th choice comes to my mind, maybe just download OracleJRE from Oracle directly. If I understood the article correctly Canonical does not distribute the new version with security fixes because of some inter-company legal nonsense, which I wouldn't care about)

Ubuntu disabling the Sun Java JDK browser plugin

rbrito — Sun, 18 Dec 2011 00:03:27 +0000

Thanks for the hint. This is very important for those that have to access Banco do Brasil's website.

Sun JDK & Android AOSP

alankila — Sat, 17 Dec 2011 19:17:05 +0000

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

mjw — Sat, 17 Dec 2011 18:09:48 +0000

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

alankila — Sat, 17 Dec 2011 17:26:30 +0000

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

jond — Sat, 17 Dec 2011 17:04:27 +0000

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

alonz — Sat, 17 Dec 2011 10:16:41 +0000

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

geofft — Sat, 17 Dec 2011 08:43:15 +0000

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.