Sun JDK vs OpenJDK - Sun JRE vs OpenJDK JRE

[David Herron]

Dalibor Topic wrote:
> Geir Magnusson Jr. wrote:
>   
>>> * they contain Sun's own proprietary code that has not been / could not
>>> be opened up so far
>>>       
>> Like what?  And why can't it be opened up?
>>     
> The old plugin, for example. One could go and invest money and time into
> readying it up for an open source release, but from an economic
> perspective, given that the code has been rewritten for 6u10, it may be
> hard to justify spending resources to do the legal and technical work on
> liberating the old plugin, I think.
>   
>>> b) deployment code:
>>>       
>> Seriously though... why not just OSS it?
>>     
> Companies traditionally have processes, accountability, and all that
> interesting stuff, which all take a little while to maneuver through to
> make sure the right things happen in the right way with all the right
> people participating.
>
> Given that the new deployment code wasn't started and developed in the
> open, it means a lot of the decisions that may appear obvious from
> outside have to be made explicitly and carry a non-trivial
> implementation cost, for example in lawyer-time, or syncing between
> OpenJDK 7 and Closed 6 - so there is a pretty good economic argument to
> be made for finishing off the work on 6u10 first, and getting the new
> deployment code out of 'beta', before a decision to push it into the
> OpenJDK 7 tree can be made.
>   

As was answered a couple days ago there isn't a specific plan at this 
time to open source either the new or old plugin/JWS.

However it sure seems that the most expedient path is for the new 
plugin/JWS to be open sourced and not bother to open source the old 
plugin/JWS.  It takes a tremendous amount of time and people resources 
to work through the open sourcing process. 

There are other 3rd party encumbrances used to build the ClosedJDK6/7 
code.  I don't have a precise list of them but if you had studied the 
binary plugs we shipped last year it should give you a hint or two about 
the nature of those 3rd party encumbrances. (graphics, fonts, sound, 
SNMP, ...)

Among the consideration of 3rd party encumbrances is whether an open 
source equivalent is a) available, b) as good quality, c) has as small a 
footprint, d) executes as rapidly, e) has as few security holes, ...
>> Is the latter true?  I've never been able to grok where the JDK 7
>> stuff comes from.  I'd have thought all work would be done out here in
>> the opendjk community (after all, it's been *years* since Sun
>> announced the project...) but...
>>     
> The encumbered third party stuff will need to linger around for the life
> time of Closed 6, and that implies some Sun repo where the maintenance
> work on the encumbered stuff is done, and feeds into Closed 6 releases
> containing it.
>   
It's not just ClosedJDK6 which would continue having encumbered 3rd 
party code.  Until there are encumbrance replacements which are as good 
as the encumbered code it will continue to appear to be "better" to use 
the encumbered code in the productized JDK build.
>> I don't know about VisualVM, but the rest is free/open  software.  Why
>> not just include those as well?
>>     
http://visualvm.dev.java.net