Canonical Will Remove Java From Ubuntu

[Dr Andrew John Hughes]

On 14:12 Thu 22 Dec     , Dennis Jacobfeuerborn wrote:
> On 12/21/2011 06:52 PM, Andrew Haley wrote:
> > On 12/21/2011 05:09 PM, Matej Cepl wrote:
> >> On 20.12.2011 19:30, Dennis Jacobfeuerborn wrote:
> >>> Probably because OpenJDK and SunJDK aren't really that compatible.
> >
> > Well, hold on.  Both the proprietary JDK and OpenJDK meet the
> > specification, and we try very hard to be compatible with all
> > the things that Java programmers assume.  And we fix compatibility
> > bugs if we can.
> 
> I wasn't saying that this was the fault of people involved in OpenJDK. The 
> problem is that the applications rely on behavior that is part of the 
> platform but not mentioned in the specifications. You cannot expect 
> different implementations to behave the same way when it comes to things 
> that weren't specified in the first place.

Yes, we know this from experience working on gcj/GNU Classpath.  But OpenJDK
and the proprietary Oracle JDK are (according to Sun/Oracle) ~96% the same code.

> 
> >> I am afraid that most of these problems are caused by stupid developers
> >> who are using (against all advices they were given) com.sun.* classes
> >> (which I am said is the most common source of problems). There is no
> >> protection against stupid programmers, I am afraid.
> >
> > There really is very little difference between the com.sun.* classes
> > in OpenJDK and the proprietary JDK, as far as I know.  Of course, I
> > haven't really checked, but...  ;-)
> 
> The more important question is if Sun didn't want people to use the 
> com.sun.* classes then why did they include them in the platform?
> 

Assuming you mean 'platform' as in http://docs.oracle.com/javase/7/docs/api/
they didn't.

There *has* to be some classes that aren't part of the API to actually make
things work (e.g. providing implementation of services provided by the API).
You'll find just the same thing in the gnu.* namespace for GNU Classpath & gcj.

> In my opinion the root cause for these incompatibilities is that the 
> platform simply isn't defined well. If you want to make good on the claim 
> "write once run anywhere" then you actually have to make an effort to come 
> up with a robust core. Injecting vendor specific stuff in there is pretty 
> much doing the opposite of that.
> 

Seems pretty well defined to me.

> Regards,
>    Dennis
> -- 
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20111222/36514ff5/attachment.sig>