Ubuntu 11.10 VM including OpenJDK Build Image

Andrew Haley aph at redhat.com
Tue Feb 21 18:42:20 UTC 2012

On 02/21/2012 05:07 PM, Wade Chandler wrote:
> On 02/17/2012 04:38 AM, Andrew Haley wrote:
>> On 02/16/2012 08:57 PM, Wade Chandler wrote:
>>> I agree. I feel like this is a major contributor to Open JDK not
>>> being used as much; well, until now since the OS distribution
>>> license is going away, but individually I think this type thing will
>>> still push individual developers and small companies away. There
>>> needs to be a central location where one can go and download various
>>> version for their various platforms. As a developer using a product
>>> to build a solution, myself and many others, do not want every
>>> project we use to be a big ordeal to get going on various platforms
>>> we need to deliver solutions.  It is a simple numbers game on time.
>>> If OpenJDK is going to be successful as other OSS projects, then
>>> this is going to have to be a must sooner or later and preferably
>>> sooner.
>> I don't really understand this.  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.
> 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.

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

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

We have moved on such a long way since OpenJDK was released.  When we
find things that don't work in, say, Fedora, we can build and
distribute OpenJDK releases in a reasonably organized way.  But it's
not instant, and if people still want to do things the old way, that's
up to them, of course.

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


More information about the discuss mailing list