Ubuntu 11.10 VM including OpenJDK Build Image

[Wade Chandler]

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

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. Nothing keeps a developer or a 
"small" company from having an automatic update in place which downloads 
the required pieces from a start up web site which has yet to need to 
scale up and installing them per user alert and action. That could be a 
new JVM for the installed platform or anything. But, that JVM would be 
tested with their software package at a minimum, and any update roll out 
priority would take security updates into consideration.

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.

Thanks for the dialect,

Wade

-- 

=================
Wade Chandler

Software Engineer and Consultant
NetBeans Contributor
NetBeans Dream Team Member

wadechandler.com
netbeans.org