Ubuntu 11.10 VM including OpenJDK Build Image

[Andrew Haley]

On 02/22/2012 05:18 PM, Wade Chandler wrote:
> On 02/21/2012 01:42 PM, Andrew Haley wrote:
>> On 02/21/2012 05:07 PM, Wade Chandler wrote:
>>> On 02/17/2012 04:38 AM, Andrew Haley wrote:

>>>> OpenJDK is installed as the default in every free OS, as far as I
>>>> know.  I don't know much about proprietary operating systems, but
>>>> I presume people download proprietary binaries from Oracle.  So,
>>>> I presume you're talking about some group of people who don't
>>>> want to use the proprietary binaries for some reason but instead
>>>> want to use OpenJDK.  And not just OpenJDK, but a particular
>>>> version of it, because their software is dependent on that
>>>> version.

> I should have added here, yes, exactly, people who want to include 
> OpenJDK as part of their solution. Too, those don't have to be folks 
> writing large scale enterprise applications. They can be custom desktop 
> or small scale network applications.

OK.

>>> Per various differences, people download the Oracle JVM for Linux
>>> and Windows to build on top of it; different bugs, plugin issues
>>> etc.  Various Linux distros have older versions of openjdk too btw
>>> depending on their update strategy, so unless you want to
>>> immediately move to their latest release for a fix in openjdk you
>>> would get those yourself.  Free/unfree OS doesn't play into it
>>> either way.

>> Well, maybe.  From my perspective, before OpenJDK was installed by
>> default on the OS things were just a mess.  There would be any number
>> of random JVMs installed, and if something didn't work, perhaps
>> because of some configuration error or whatnot, yet another JRE would
>> be installed.  And God help you if you needed a security update.

> Any given security update and how it is applied depends on
> context. Some security updates don't impact a given application. It
> all depends on how it is used. For instance, a stand alone desktop
> application not loading remote code and not running in a browser
> isn't affected by any numerous numbers of issues as something else
> may be.

OK, so we're OK iff the application is not security sensitive.  That
cuts out a lot of Java applications, but I'll go with that.

>>> As it relates to bundling a particular version of a runtime with
>>> your software, whether it openjdk, python, perl, etc many do it. The
>>> same with statically linking C/C++ libraries into ones application
>>> or distributing shareable libraries in their own folder which gets
>>> prepended to the search path as to not be influenced by other
>>> applications.

>> Well, yes.  And God help you if you need a security update.  For this
>> reason alone shipping versions of standard libraries is a disaster.

> This too depends on context and if the code is used in situations where 
> it can be compromised or not. All kinds of various issues can be at 
> play. Depends on update strategies as well.

Fair enough, as above.

>>> In consumer software there is nothing much more frustrating than
>>> trying to debug various updates to a 3rd party system which is only
>>> affecting certain groups of ones users since they could modify a
>>> specific component of the system you have designed or pieced
>>> together with a single click of an update reminder. It is all about
>>> time and money.
>>>
>>> It comes down to a simple reality. Users don't care nor have the
>>> understanding as to why JRE or JDK 1.6_u19 versus 1.6_u21 causes an
>>> issue in some "unrelated" software. I know it isn't necessarily
>>> unrelated, but try explaining to an arbitrary K-12 teacher why another
>>> software vendor told them they had to upgrade to a different version of
>>> the JRE/JDK and it broke another application or vice versa.

>> Well, yes.  An arbitrary K-12 teacher is exactly the kind of person
>> who shouldn't be installing JREs.  Did I mention security updates?

> No but they could certainly be installing a software package which
> isn't part of an OS update. Depends on the school, funding, user
> permissions, home schooling, etc and so forth. Everything isn't a
> large scale solution, and in my opinion, it shouldn't be. Users and
> system administrators should have to know that application X
> requires this JVM and application Y requires this one in all
> cases. It depends on the organization as well as update strategy.
>
> At one of my businesses, considering the network etc and the
> required uptime requirements of some applications, updates are not
> just something I want done automatically, nor do I have the
> resources for a giant roll out. Updates are tested on one machine,
> and if successful, then this is done across the board, and this for
> various applications; across the board is only a hand full of
> machines. There is no large management software in play.

OK, so you have a properly managed update strategy, with someone whose
job it is to handle updates.  I'm not sure how this is going to work
if you just downloaded a binary from the Community OpenJDK site,
though.  I suppose it is possible that such a site has the people and
infrastructure to handle the update process, just like the GNU/Linux
distros do.  Effectively they'd *be* a distro, but an OpenJDK distro,
not a full system.

>>> I have experienced that from both sides. So, one of their vendors has to
>>> get in an upgrade before they are happy, and they are upset at both.
>>> Segregate those things so they are only a component of your designed
>>> system, and you don't have to deal with such things. What you tested is
>>> what you have running. Yes, OS updates etc can still cause issues, but
>>> at least one can minimise those changes.
>>
>>> It is what RedHat does with their professional JBoss offerings and
>>> Apache. It makes it a turn key solution.
>>
>> Well, that's a bit different.  You're talking about organizations with
>> enterprise-scale build and distribution networks who can automagically
>> update those components when they need to.  They certainly don't need
>> to grab pre-built binaries from anywhere.
> 
> Depends. That doesn't have to be the case; enterprise-scale build
> and dist networks. For any given platform and any given installer a
> packaged prebuilt binary can be included easily enough. Getting all
> the sub-components and building ones own JVM isn't exactly something
> someone writing business logic to use a JVM should be worried about
> doing unless they specifically want or need to.

Absolutely not, no.  And grabbing binaries that are not fully
supported from a web site isn't something that they should be doing
either.

IMO this can work if the site that hosts the builds (or its
volunteers) does full testing and update support on the binaries they
host.  Otherwise, people shouldn't use those binaries.  Sure, it'll be
fine for experimentation.

> I feel we are approaching this discussion from two different angles:
> large scale enterprise versus small business and individual users;
> commercial enterprise versus commercial consumer software. I'm
> arguing the large scale enterprise approach excludes a lot of
> developers in various ways.

If there were a proposal on the table for a site that hosted fully
tested, TCKd and supported binaries built from OpenJDK, and had the
infrastructure to do updates where needed, that might make some sense.
Otherwise, you're just adding risk.

Consider, for example, the situation where a security flaw was found
that affected the last N OpenJDK releases.  This site supports
versions of OpenJDK going back M releases, so you now have to do
max(N,M) patching and rebuild cycles.  Either that, or you leave
binaries with a known security hole on the site, which would be
criminal.  So what would you do?

Andrew.