Ubuntu 11.10 VM including OpenJDK Build Image
henri.gomez at gmail.com
Wed Feb 22 20:52:59 UTC 2012
Hi to all
I follow this thread for some time now and I'm wondering if OpenJDK 7
is not a candidate for multi-OS (Windows, Solaris, Linux, BSD, OSX)
and Linux cross distributions package and deliver initiative.
It's something already available for VirtualBox for example, why not
doing the same for it ?
2012/2/22 Andrew Haley <aph at redhat.com>:
> 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
>> 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.
>>>> 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
>>> 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
> 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?
More information about the discuss