[gentoo-java] OpenJDK, IcedTea and Package Naming

[gentoo-java] OpenJDK, IcedTea and Package Naming

[Andrew John Hughes]

It seems there has been some confusion over the naming of the ebuilds
for OpenJDK/IcedTea
support within Gentoo, so, at Petteri's request, this e-mail aims to
clear things up and hopefully
alleviate some of these issues.

Understanding the naming really involves understanding the development
of OpenJDK so far.
The release of Sun's reference implementation of the Java SE platform
was completed in May 2007,
and this codebase was known as OpenJDK.  This basically represents the
current state of what
will eventually become Java 1.7 or JDK7, the contents of which are
still unknown as there is no
JSR for this platform as yet.  The platform specification does not
include the plugin or webstart support,
so, given the state of this code, it was not included.  On initial
release, about 4% of the code base
was also missing, having to be replaced by proprietary binary plugs
from one of the proprietary Sun JDKs.
Thus, although we were much closer to a complete Free JDK, there were
three major issues remaining:

* The released code was for 1.7, not the 1.6 release actually in use,
and it couldn't be certified as Java(TM).
* The code couldn't be built Freely, preventing its use in Fedora,
Debian and Ubuntu.
* The plugin and webstart support which users would expect from a JDK
were missing.

Two of these issues were quickly solved by hackers at Red Hat who
started the IcedTea project.  This provided
a way of building OpenJDK using existing Free Java runtimes such as
GCJ and provided replacements for the
encumbrances using code from GNU Classpath.  gcjwebplugin was also
modified to provide plugin support
against Sun's applet code rather than GNU Classpath's, and the
existing NetX project continued its development
as part of IcedTea, providing webstart support.  Resulting binaries
shipped as a package named 'icedtea' in
Fedora Core 8.

Over time, OpenJDK and IcedTea continued to develop.  Sun provided
replacements for some of the encumbrances,
mainly in the area of Java2D such as font and renderer support, and
cryptography.  IcedTea was kept up to date with
each new OpenJDK cooked build, by modification of the existing
patches.  This continues today, with the latest
IcedTea release being 1.7.  Ebuilds for both 1.7 and the live
Mercurial repository are held in java-experimental, as
they provide a snapshot of 1.7 development rather than a completed JDK
aimed at the user.

In early 2008, Sun began the OpenJDK6 project to provide a Free 1.6
implementation, and allowed external developers
(notably Red Hat) access to the Java Compatibility Kit (JCK) so that
the resulting builds could be demonstrated to be
compatible with the existing proprietary JDK6 builds provided by Sun.
OpenJDK6 was created, not from the proprietary
JDK6 tree (which would require another legal review on the epic scale
already undertaken for the JDK7 code), but by
taking the OpenJDK tree and removing new features added by Sun developers.

The issues with building the code and the encumbrances remained with
OpenJDK6 so a matching IcedTea6 tree was launched
to provide the same level of support to the new code base.  It is a
build of IcedTea6 from Fedora that recently passed the JCK,
finally proving that a certifiable Free JDK implementation can exist.
Getting to this point was non-trivial, as the base of OpenJDK
and then additional patching by IcedTea meant that the codebase was
quite distinct from the proprietary JDK6 being shipped by
Sun, notably with some of the Free replacements for the encumbrances
being completely different code from the proprietary version
in JDK6.

In the java overlay, we currently have an ebuild for IcedTea6 1.2.
This matches the name of the upstream project and version.  There
is also a live build in experimental, and 1.3 is likely to become
available in the next few weeks.  On IRC, some have expressed dislike
for this naming, preferring including terms like 'OpenJDK' and the
cooked build on which it is based.  This is further confused by the
binary builds in Fedora, Debian and Ubuntu now being called 'OpenJDK'.
 This isn't because they just felt like changing the name.
Use of the 'OpenJDK' name is subject to the OpenJDK trademark license
and requires fulfilling certain conditions, including the codebase
being almost completely based on the tree from Sun.

In Gentoo, we work at the source level in general, whereas the
approach of Fedora, Debian and Ubuntu is from one of a binary package.
With OpenJDK and IcedTea, this presents some differences.  The most
prominent is the use of the trademark license.  With a binary
build, the distro developer knows what is in the binary and whether it
qualifies to be called OpenJDK.  The source from which these binaries
are built is still IcedTea6, as may be demonstrated via executing
'java -version'.  With Gentoo, the presence of USE flags and local
settings
mean that we don't know what will result from the ebuild in binary
form. Some builds will be roughly equivalent to the builds in Fedora,
Debian
and Ubuntu, but some may not.  There is functionality in IcedTea, such
as the ability to use CACAO instead of HotSpot, that would mean
the resulting binary does not qualify to be called OpenJDK (such
packages are called cacao-oj6 in Debian and Ubuntu for example).

More practically, we need to be able to track bugs and issues with
ebuilds easily. IcedTea6 1.2 is a known quantity. It uses a certain
cooked build of OpenJDK6 and a certain set of patches.  Moving to a
new build drop is non-trivial requiring patches to be added, dropped
or updated.  IcedTea is more than simply a build harness and the
resulting binary is different from what would be obtained from a pure
OpenJDK source base.  In addition to the OpenJDK source tree, it
includes (as of the current Mercurial tree):

* 81 patches to the source code, including one to allow the build to
run with ecj + GNU Classpath.  Not all of these are applied
to every build, but the majority are.
* Gary Benson's zero assembler support which allows OpenJDK to be used
on ppc, ppc64, arm, mips, m68k, ia64, etc.
* Webstart support in the form of NetX
* Plugin support from gcjwebplugin (IcedTea plugin is coming soon with
LiveConnect support)
* Support for building using the CACAO VM instead of HotSpot (again
for other architecture support)
* Gary Benson's platform-independent JIT called Shark based on LLVM
* VisualVM support
* Javascript support via Rhino

  In addition, there is always the option that someone may wish to
provide an ebuild that just builds the OpenJDK
or OpenJDK6 tree.  Note that one thing already being considered among
the IcedTea developers is how to add the IcedTea version to
the java -version output because the lack of this is causing issues
with reporting bugs.  By naming our ebuilds using the IcedTea schema,
and directly relating to our upstream codebase, we have already solved
this issue in Gentoo.  Naming it OpenJDK would not reflect
what is being installed or the upstream being used.

For those who hate the aboration of having the version number as part
of the package name, note that this is intended to be short-lived.
As the discussion above implies, the OpenJDK6 tree is a stop-gap,
created to fulfill the need for a complete implementation now.
When 1.7 is released, IcedTea will become the primary JDK again and
IcedTea6 will cease development.  At present, most of the
maintenance work for OpenJDK6/IcedTea6 is being done by the IcedTea
hackers; Sun only have Joe Darcy working on this. Their
concentration is on 1.7.  Thus, we should really note our appreciation
of this work by naming the IcedTea project rather than
hiding it under the name OpenJDK.

When IcedTea6 hits the main tree, most of this will become irrelevant
anyway, as the virtual dependency should just do the right
thing and pull in IcedTea6.  I don't intend IcedTea or any of the live
builds to go into the main tree, but are there for those who wish to
experiment.

Hope that clarifies things,
--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: [gentoo-java] OpenJDK, IcedTea and Package Naming

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

Andrew John Hughes kirjoitti:
> 
> For those who hate the aboration of having the version number as part
> of the package name, note that this is intended to be short-lived.
> As the discussion above implies, the OpenJDK6 tree is a stop-gap,
> created to fulfill the need for a complete implementation now.
> When 1.7 is released, IcedTea will become the primary JDK again and
> IcedTea6 will cease development.  At present, most of the
> maintenance work for OpenJDK6/IcedTea6 is being done by the IcedTea
> hackers; Sun only have Joe Darcy working on this. Their
> concentration is on 1.7.  Thus, we should really note our appreciation
> of this work by naming the IcedTea project rather than
> hiding it under the name OpenJDK.
> 

A good post and hopefully useful to readers out there but my main 
concern really wasn't the issue of openjdk vs. icedtea but your choice 
of naming it icedtea6 and icedtea (Debian like) instead of doing it the 
Gentoo way with slots.

> With Gentoo, the presence of USE flags and local
> settings
> mean that we don't know what will result from the ebuild in binary
> form. Some builds will be roughly equivalent to the builds in Fedora,
> Debian
> and Ubuntu, but some may not.  There is functionality in IcedTea, such
> as the ability to use CACAO instead of HotSpot, that would mean
> the resulting binary does not qualify to be called OpenJDK (such
> packages are called cacao-oj6 in Debian and Ubuntu for example).

I think we can solve this by having a virtual openjdk ebuild using use 
deps that will force a certain set of features on the icedtea ebuild.

Regards,
Petteri



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-java] OpenJDK, IcedTea and Package Naming

[Andrew John Hughes]

2008/9/12 Petteri Räty <betelgeuse@gentoo.org>:
> Andrew John Hughes kirjoitti:
>>
>> For those who hate the aboration of having the version number as part
>> of the package name, note that this is intended to be short-lived.
>> As the discussion above implies, the OpenJDK6 tree is a stop-gap,
>> created to fulfill the need for a complete implementation now.
>> When 1.7 is released, IcedTea will become the primary JDK again and
>> IcedTea6 will cease development.  At present, most of the
>> maintenance work for OpenJDK6/IcedTea6 is being done by the IcedTea
>> hackers; Sun only have Joe Darcy working on this. Their
>> concentration is on 1.7.  Thus, we should really note our appreciation
>> of this work by naming the IcedTea project rather than
>> hiding it under the name OpenJDK.
>>
>
> A good post and hopefully useful to readers out there but my main concern
> really wasn't the issue of openjdk vs. icedtea but your choice of naming it
> icedtea6 and icedtea (Debian like) instead of doing it the Gentoo way with
> slots.
>

I didn't include this issue because I believed we'd already discussed it ages
ago and I'm surprised to see it come up again.  There is nothing Debian-like
about the naming - in fact, Debian has only packaged IcedTea6 recently,
and does so as OpenJDK - I mentioned this in my original e-mail.  It is
Sun who refer to it as OpenJDK6 or even open6, in the same manner as JDK7, etc.

Anyway, what I'm saying is that this isn't a name change simply based
on versions
but these are completely different projects.  There have different source trees
and can be in completely different states, depending on what has been
merged between
the two.  More practically, there would be version number clashes with
keeping them
both in a 'icedtea' directory, IcedTea 1.7 appearing to be later than
IcedTea6 1.2 for one.

>> With Gentoo, the presence of USE flags and local
>> settings
>> mean that we don't know what will result from the ebuild in binary
>> form. Some builds will be roughly equivalent to the builds in Fedora,
>> Debian
>> and Ubuntu, but some may not.  There is functionality in IcedTea, such
>> as the ability to use CACAO instead of HotSpot, that would mean
>> the resulting binary does not qualify to be called OpenJDK (such
>> packages are called cacao-oj6 in Debian and Ubuntu for example).
>
> I think we can solve this by having a virtual openjdk ebuild using use deps
> that will force a certain set of features on the icedtea ebuild.
>

I don't have a problem with that.  Better still, make this a binary and consider
applying for TCK access to certify it.  This will definitely be needed on lower
spec. machines that will struggle to build IcedTea.  Think in terms of
OpenOffice.org... ;)

> Regards,
> Petteri
>
>
>



-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: [gentoo-java] OpenJDK, IcedTea and Package Naming

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]

Andrew John Hughes kirjoitti:
> 2008/9/12 Petteri Räty <betelgeuse@gentoo.org>:
>> Andrew John Hughes kirjoitti:
>>> For those who hate the aboration of having the version number as part
>>> of the package name, note that this is intended to be short-lived.
>>> As the discussion above implies, the OpenJDK6 tree is a stop-gap,
>>> created to fulfill the need for a complete implementation now.
>>> When 1.7 is released, IcedTea will become the primary JDK again and
>>> IcedTea6 will cease development.  At present, most of the
>>> maintenance work for OpenJDK6/IcedTea6 is being done by the IcedTea
>>> hackers; Sun only have Joe Darcy working on this. Their
>>> concentration is on 1.7.  Thus, we should really note our appreciation
>>> of this work by naming the IcedTea project rather than
>>> hiding it under the name OpenJDK.
>>>
>> A good post and hopefully useful to readers out there but my main concern
>> really wasn't the issue of openjdk vs. icedtea but your choice of naming it
>> icedtea6 and icedtea (Debian like) instead of doing it the Gentoo way with
>> slots.
>>
> 
> I didn't include this issue because I believed we'd already discussed it ages
> ago and I'm surprised to see it come up again.  There is nothing Debian-like
> about the naming - in fact, Debian has only packaged IcedTea6 recently,
> and does so as OpenJDK - I mentioned this in my original e-mail.  It is
> Sun who refer to it as OpenJDK6 or even open6, in the same manner as JDK7, etc.
> 
> Anyway, what I'm saying is that this isn't a name change simply based
> on versions
> but these are completely different projects.  There have different source trees
> and can be in completely different states, depending on what has been
> merged between
> the two.  More practically, there would be version number clashes with
> keeping them
> both in a 'icedtea' directory, IcedTea 1.7 appearing to be later than
> IcedTea6 1.2 for one.
> 

The version number clashes can be solved with using <upstream 
drop>.<iced tea>. I really don't think this situation is much different 
from for example kde 3.5 and 4. Both trees are in active development and 
in different slots. It's still the same upstream project as far as 
upstream infra like home page goes.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-java] OpenJDK, IcedTea and Package Naming

[Robert Burrell Donkin]

On Fri, Sep 12, 2008 at 12:35 AM, Andrew John Hughes
<gnu_andrew@member.fsf.org> wrote:
> It seems there has been some confusion over the naming of the ebuilds
> for OpenJDK/IcedTea
> support within Gentoo, so, at Petteri's request, this e-mail aims to
> clear things up and hopefully
> alleviate some of these issues.
>
> Understanding the naming really involves understanding the development
> of OpenJDK so far.
> The release of Sun's reference implementation of the Java SE platform
> was completed in May 2007,
> and this codebase was known as OpenJDK.  This basically represents the
> current state of what
> will eventually become Java 1.7 or JDK7, the contents of which are
> still unknown as there is no
> JSR for this platform as yet.  The platform specification does not
> include the plugin or webstart support,
> so, given the state of this code, it was not included.  On initial
> release, about 4% of the code base
> was also missing, having to be replaced by proprietary binary plugs
> from one of the proprietary Sun JDKs.
> Thus, although we were much closer to a complete Free JDK, there were
> three major issues remaining:
>
> * The released code was for 1.7, not the 1.6 release actually in use,
> and it couldn't be certified as Java(TM).
> * The code couldn't be built Freely, preventing its use in Fedora,
> Debian and Ubuntu.
> * The plugin and webstart support which users would expect from a JDK
> were missing.
>
> Two of these issues were quickly solved by hackers at Red Hat who
> started the IcedTea project.  This provided
> a way of building OpenJDK using existing Free Java runtimes such as
> GCJ and provided replacements for the
> encumbrances using code from GNU Classpath.  gcjwebplugin was also
> modified to provide plugin support
> against Sun's applet code rather than GNU Classpath's, and the
> existing NetX project continued its development
> as part of IcedTea, providing webstart support.  Resulting binaries
> shipped as a package named 'icedtea' in
> Fedora Core 8.
>
> Over time, OpenJDK and IcedTea continued to develop.  Sun provided
> replacements for some of the encumbrances,
> mainly in the area of Java2D such as font and renderer support, and
> cryptography.  IcedTea was kept up to date with
> each new OpenJDK cooked build, by modification of the existing
> patches.  This continues today, with the latest
> IcedTea release being 1.7.  Ebuilds for both 1.7 and the live
> Mercurial repository are held in java-experimental, as
> they provide a snapshot of 1.7 development rather than a completed JDK
> aimed at the user.
>
> In early 2008, Sun began the OpenJDK6 project to provide a Free 1.6
> implementation, and allowed external developers
> (notably Red Hat) access to the Java Compatibility Kit (JCK) so that
> the resulting builds could be demonstrated to be
> compatible with the existing proprietary JDK6 builds provided by Sun.
> OpenJDK6 was created, not from the proprietary
> JDK6 tree (which would require another legal review on the epic scale
> already undertaken for the JDK7 code), but by
> taking the OpenJDK tree and removing new features added by Sun developers.
>
> The issues with building the code and the encumbrances remained with
> OpenJDK6 so a matching IcedTea6 tree was launched
> to provide the same level of support to the new code base.  It is a
> build of IcedTea6 from Fedora that recently passed the JCK,
> finally proving that a certifiable Free JDK implementation can exist.
> Getting to this point was non-trivial, as the base of OpenJDK
> and then additional patching by IcedTea meant that the codebase was
> quite distinct from the proprietary JDK6 being shipped by
> Sun, notably with some of the Free replacements for the encumbrances
> being completely different code from the proprietary version
> in JDK6.
>
> In the java overlay, we currently have an ebuild for IcedTea6 1.2.
> This matches the name of the upstream project and version.  There
> is also a live build in experimental, and 1.3 is likely to become
> available in the next few weeks.  On IRC, some have expressed dislike
> for this naming, preferring including terms like 'OpenJDK' and the
> cooked build on which it is based.  This is further confused by the
> binary builds in Fedora, Debian and Ubuntu now being called 'OpenJDK'.
>  This isn't because they just felt like changing the name.
> Use of the 'OpenJDK' name is subject to the OpenJDK trademark license
> and requires fulfilling certain conditions, including the codebase
> being almost completely based on the tree from Sun.
>
> In Gentoo, we work at the source level in general, whereas the
> approach of Fedora, Debian and Ubuntu is from one of a binary package.
> With OpenJDK and IcedTea, this presents some differences.  The most
> prominent is the use of the trademark license.  With a binary
> build, the distro developer knows what is in the binary and whether it
> qualifies to be called OpenJDK.  The source from which these binaries
> are built is still IcedTea6, as may be demonstrated via executing
> 'java -version'.  With Gentoo, the presence of USE flags and local
> settings
> mean that we don't know what will result from the ebuild in binary
> form. Some builds will be roughly equivalent to the builds in Fedora,
> Debian
> and Ubuntu, but some may not.  There is functionality in IcedTea, such
> as the ability to use CACAO instead of HotSpot, that would mean
> the resulting binary does not qualify to be called OpenJDK (such
> packages are called cacao-oj6 in Debian and Ubuntu for example).

AIUI and IMNSHO *NO* local build from source qualifies. gentoo
*SHOULD* *NOT* expose users to risk by using trademarks etc for *ANY*
source build even from the sun tree.

BTW i'm on AMD64 which has very poor support from the sun java
codebase. are there any plans to add support for the harmony VM?

- robert

Re: [gentoo-java] OpenJDK, IcedTea and Package Naming

[Andrew John Hughes]

2008/9/13 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
> On Fri, Sep 12, 2008 at 12:35 AM, Andrew John Hughes
> <gnu_andrew@member.fsf.org> wrote:
>> It seems there has been some confusion over the naming of the ebuilds
>> for OpenJDK/IcedTea
>> support within Gentoo, so, at Petteri's request, this e-mail aims to
>> clear things up and hopefully
>> alleviate some of these issues.
>>
>> Understanding the naming really involves understanding the development
>> of OpenJDK so far.
>> The release of Sun's reference implementation of the Java SE platform
>> was completed in May 2007,
>> and this codebase was known as OpenJDK.  This basically represents the
>> current state of what
>> will eventually become Java 1.7 or JDK7, the contents of which are
>> still unknown as there is no
>> JSR for this platform as yet.  The platform specification does not
>> include the plugin or webstart support,
>> so, given the state of this code, it was not included.  On initial
>> release, about 4% of the code base
>> was also missing, having to be replaced by proprietary binary plugs
>> from one of the proprietary Sun JDKs.
>> Thus, although we were much closer to a complete Free JDK, there were
>> three major issues remaining:
>>
>> * The released code was for 1.7, not the 1.6 release actually in use,
>> and it couldn't be certified as Java(TM).
>> * The code couldn't be built Freely, preventing its use in Fedora,
>> Debian and Ubuntu.
>> * The plugin and webstart support which users would expect from a JDK
>> were missing.
>>
>> Two of these issues were quickly solved by hackers at Red Hat who
>> started the IcedTea project.  This provided
>> a way of building OpenJDK using existing Free Java runtimes such as
>> GCJ and provided replacements for the
>> encumbrances using code from GNU Classpath.  gcjwebplugin was also
>> modified to provide plugin support
>> against Sun's applet code rather than GNU Classpath's, and the
>> existing NetX project continued its development
>> as part of IcedTea, providing webstart support.  Resulting binaries
>> shipped as a package named 'icedtea' in
>> Fedora Core 8.
>>
>> Over time, OpenJDK and IcedTea continued to develop.  Sun provided
>> replacements for some of the encumbrances,
>> mainly in the area of Java2D such as font and renderer support, and
>> cryptography.  IcedTea was kept up to date with
>> each new OpenJDK cooked build, by modification of the existing
>> patches.  This continues today, with the latest
>> IcedTea release being 1.7.  Ebuilds for both 1.7 and the live
>> Mercurial repository are held in java-experimental, as
>> they provide a snapshot of 1.7 development rather than a completed JDK
>> aimed at the user.
>>
>> In early 2008, Sun began the OpenJDK6 project to provide a Free 1.6
>> implementation, and allowed external developers
>> (notably Red Hat) access to the Java Compatibility Kit (JCK) so that
>> the resulting builds could be demonstrated to be
>> compatible with the existing proprietary JDK6 builds provided by Sun.
>> OpenJDK6 was created, not from the proprietary
>> JDK6 tree (which would require another legal review on the epic scale
>> already undertaken for the JDK7 code), but by
>> taking the OpenJDK tree and removing new features added by Sun developers.
>>
>> The issues with building the code and the encumbrances remained with
>> OpenJDK6 so a matching IcedTea6 tree was launched
>> to provide the same level of support to the new code base.  It is a
>> build of IcedTea6 from Fedora that recently passed the JCK,
>> finally proving that a certifiable Free JDK implementation can exist.
>> Getting to this point was non-trivial, as the base of OpenJDK
>> and then additional patching by IcedTea meant that the codebase was
>> quite distinct from the proprietary JDK6 being shipped by
>> Sun, notably with some of the Free replacements for the encumbrances
>> being completely different code from the proprietary version
>> in JDK6.
>>
>> In the java overlay, we currently have an ebuild for IcedTea6 1.2.
>> This matches the name of the upstream project and version.  There
>> is also a live build in experimental, and 1.3 is likely to become
>> available in the next few weeks.  On IRC, some have expressed dislike
>> for this naming, preferring including terms like 'OpenJDK' and the
>> cooked build on which it is based.  This is further confused by the
>> binary builds in Fedora, Debian and Ubuntu now being called 'OpenJDK'.
>>  This isn't because they just felt like changing the name.
>> Use of the 'OpenJDK' name is subject to the OpenJDK trademark license
>> and requires fulfilling certain conditions, including the codebase
>> being almost completely based on the tree from Sun.
>>
>> In Gentoo, we work at the source level in general, whereas the
>> approach of Fedora, Debian and Ubuntu is from one of a binary package.
>> With OpenJDK and IcedTea, this presents some differences.  The most
>> prominent is the use of the trademark license.  With a binary
>> build, the distro developer knows what is in the binary and whether it
>> qualifies to be called OpenJDK.  The source from which these binaries
>> are built is still IcedTea6, as may be demonstrated via executing
>> 'java -version'.  With Gentoo, the presence of USE flags and local
>> settings
>> mean that we don't know what will result from the ebuild in binary
>> form. Some builds will be roughly equivalent to the builds in Fedora,
>> Debian
>> and Ubuntu, but some may not.  There is functionality in IcedTea, such
>> as the ability to use CACAO instead of HotSpot, that would mean
>> the resulting binary does not qualify to be called OpenJDK (such
>> packages are called cacao-oj6 in Debian and Ubuntu for example).
>
> AIUI and IMNSHO *NO* local build from source qualifies. gentoo
> *SHOULD* *NOT* expose users to risk by using trademarks etc for *ANY*
> source build even from the sun tree.
>

Maybe that's being a bit over cautious, but the problem generally is
Sun thought of this with binary distribution in mind, not source.
As with any legal agreement, the best solution is to consult a lawyer.
I'm not one.

> BTW i'm on AMD64 which has very poor support from the sun java
> codebase. are there any plans to add support for the harmony VM?
>

What 'poor support'? IcedTea6 works fine for me here on amd64.  Feel free
to package Harmony, but I don't see how that will solve your problems, given
it doesn't yet have a complete implementation of even 1.5.

> - robert
>
>

-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: [gentoo-java] OpenJDK, IcedTea and Package Naming

[Philipp Riegger]

On Fri, 2008-09-12 at 00:35 +0100, Andrew John Hughes wrote:
[...]

Thanks for this great piece of wisdom. I really enjoyed reading it. You
should make sure, that it appears on planet.g.o and in the next GMN.

Anyway... I tried installing IcedTea (JDK7) and the source file could
not be downloaded. There is a beta 35 (in case b stands for this) from
this month.

Thanks,
	Philipp

Re: [gentoo-java] OpenJDK, IcedTea and Package Naming

[David Herron]

No, 'b' means 'build' as in 'b35' is 'build 35'

Philipp Riegger wrote:
> On Fri, 2008-09-12 at 00:35 +0100, Andrew John Hughes wrote:
> [...]
>
> Thanks for this great piece of wisdom. I really enjoyed reading it. You
> should make sure, that it appears on planet.g.o and in the next GMN.
>
> Anyway... I tried installing IcedTea (JDK7) and the source file could
> not be downloaded. There is a beta 35 (in case b stands for this) from
> this month.
>
> Thanks,
> 	Philipp
>
>
>   

Re: [gentoo-java] OpenJDK, IcedTea and Package Naming

[Robert Burrell Donkin]

On Sun, Sep 14, 2008 at 2:21 AM, Andrew John Hughes
<gnu_andrew@member.fsf.org> wrote:
> 2008/9/13 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:

<snip>

>> AIUI and IMNSHO *NO* local build from source qualifies. gentoo
>> *SHOULD* *NOT* expose users to risk by using trademarks etc for *ANY*
>> source build even from the sun tree.
>>
>
> Maybe that's being a bit over cautious,

i agree that sun is unlikely to sue any users over java ATM but
trademarks must be defended or cease to exist. sooner or later sun
will have to either lose the java trademark or act against
unauthorised users.

> but the problem generally is
> Sun thought of this with binary distribution in mind, not source.

the JCP is set up to manage binaries, not source. IMO this is the
fatal flaw in this system. (i'll avoid going OT by repeating the
argument again here.)

> As with any legal agreement, the best solution is to consult a lawyer.
> I'm not one.

does gentoo have a agreement with sun?
if so, is it available on line?
if not, what agreement is being relyed on?

>> BTW i'm on AMD64 which has very poor support from the sun java
>> codebase. are there any plans to add support for the harmony VM?
>>
>
> What 'poor support'? IcedTea6 works fine for me here on amd64.

eclipse and sun don't play well. however, i haven't tried switching to
the iced tea build on gentoo so maybe i'll give that a try next time.

> Feel free to package Harmony, but I don't see how that will solve your problems,

harmony runs eclipse fine. every couple of months when gentoo changes
something, i have to devote a couple of hours fixing stuff so that
eclipse works or else switch to harmony until everything's fixed.

> given it doesn't yet have a complete implementation of even 1.5.

if sun had honoured it's agreement to allow access to the TCK by open
source projects,  then harmony (and the free JVMs) would have had
certified 1.5 implementations a year ago and (most likely) 1.6 ones as
well by now. this is a political issue, not a code one.

- robert

Re: [gentoo-java] OpenJDK, IcedTea and Package Naming

[Andrew John Hughes]

2008/9/14 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
> On Sun, Sep 14, 2008 at 2:21 AM, Andrew John Hughes
> <gnu_andrew@member.fsf.org> wrote:
>> 2008/9/13 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
>
> <snip>
>
>>> AIUI and IMNSHO *NO* local build from source qualifies. gentoo
>>> *SHOULD* *NOT* expose users to risk by using trademarks etc for *ANY*
>>> source build even from the sun tree.
>>>
>>
>> Maybe that's being a bit over cautious,
>
> i agree that sun is unlikely to sue any users over java ATM but
> trademarks must be defended or cease to exist. sooner or later sun
> will have to either lose the java trademark or act against
> unauthorised users.
>

I wasn't talking about the Java trademark, I was talking about the OpenJDK
trademark.  Use of the Java trademark requires passing the
certification process,
and this isn't possible for a source build.  Only binaries can pass
the TCK and thus
be certified.

>> but the problem generally is
>> Sun thought of this with binary distribution in mind, not source.
>
> the JCP is set up to manage binaries, not source. IMO this is the
> fatal flaw in this system. (i'll avoid going OT by repeating the
> argument again here.)
>

Yes, the JCP still needs work, being centered around proprietary
binary distribution for the most part.

>> As with any legal agreement, the best solution is to consult a lawyer.
>> I'm not one.
>
> does gentoo have a agreement with sun?
> if so, is it available on line?
> if not, what agreement is being relyed on?
>

Not as far as I know, but other than naming and trademarks, OpenJDK is just
like any other FOSS project.

>>> BTW i'm on AMD64 which has very poor support from the sun java
>>> codebase. are there any plans to add support for the harmony VM?
>>>
>>
>> What 'poor support'? IcedTea6 works fine for me here on amd64.
>
> eclipse and sun don't play well. however, i haven't tried switching to
> the iced tea build on gentoo so maybe i'll give that a try next time.
>
>> Feel free to package Harmony, but I don't see how that will solve your problems,
>
> harmony runs eclipse fine. every couple of months when gentoo changes
> something, i have to devote a couple of hours fixing stuff so that
> eclipse works or else switch to harmony until everything's fixed.
>

That's interesting.  I don't know anything about the proprietary Sun
builds on amd64, I've
never used them.  But I also don't run Eclipse.  Have you filled
appropriate bugs?
Certainly try IcedTea and, if you get failures, report them to our bug
database at
http://icedtea.classpath.org/bugzilla.

>> given it doesn't yet have a complete implementation of even 1.5.
>
> if sun had honoured it's agreement to allow access to the TCK by open
> source projects,  then harmony (and the free JVMs) would have had
> certified 1.5 implementations a year ago and (most likely) 1.6 ones as
> well by now. this is a political issue, not a code one.
>

I seriously doubt that, given it took OpenJDK a year to pass the 1.6
TCK, despite
being based on a codebase, the majority of which has passed as part of
the proprietary work.

> - robert
>
>



-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: [gentoo-java] OpenJDK, IcedTea and Package Naming

[Robert Burrell Donkin]

On Sun, Sep 14, 2008 at 3:26 PM, Andrew John Hughes
<gnu_andrew@member.fsf.org> wrote:
> 2008/9/14 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
>> On Sun, Sep 14, 2008 at 2:21 AM, Andrew John Hughes
>> <gnu_andrew@member.fsf.org> wrote:
>>> 2008/9/13 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
>>
>> <snip>
>>
>>>> AIUI and IMNSHO *NO* local build from source qualifies. gentoo
>>>> *SHOULD* *NOT* expose users to risk by using trademarks etc for *ANY*
>>>> source build even from the sun tree.
>>>>
>>>
>>> Maybe that's being a bit over cautious,
>>
>> i agree that sun is unlikely to sue any users over java ATM but
>> trademarks must be defended or cease to exist. sooner or later sun
>> will have to either lose the java trademark or act against
>> unauthorised users.
>>
>
> I wasn't talking about the Java trademark, I was talking about the OpenJDK
> trademark.  Use of the Java trademark requires passing the
> certification process,
> and this isn't possible for a source build.  Only binaries can pass
> the TCK and thus
> be certified.

yes

thanks for clarifying

>>> but the problem generally is
>>> Sun thought of this with binary distribution in mind, not source.
>>
>> the JCP is set up to manage binaries, not source. IMO this is the
>> fatal flaw in this system. (i'll avoid going OT by repeating the
>> argument again here.)
>>
>
> Yes, the JCP still needs work, being centered around proprietary
> binary distribution for the most part.

the binary distributions only rule is a consequence of the closed TCK.
the TCK is closed to ensure a revenue stream for the spec leader.

i'll be interested to see whether the JCP survives. sun broke the
basic premise over the harmony TCK (all participants whether open
source or not hold contracts with sun who acts as an independent
judge). given that most open source projects can't afford to sue sun,
the legal framework needs extensive revision. it would be cleaner for
the JCP to issue a license covering any works that pass an open source
TCK for everything except branding rights including the mutual patent
grants. branding rights are only really required for commercial binary
implementations so an additional secret TCK and payment could be
required to unlock those.

>>> As with any legal agreement, the best solution is to consult a lawyer.
>>> I'm not one.
>>
>> does gentoo have a agreement with sun?
>> if so, is it available on line?
>> if not, what agreement is being relyed on?
>>
>
> Not as far as I know, but other than naming and trademarks, OpenJDK is just
> like any other FOSS project.

trademarks are the important point (bit like firefox)

>>>> BTW i'm on AMD64 which has very poor support from the sun java
>>>> codebase. are there any plans to add support for the harmony VM?
>>>>
>>>
>>> What 'poor support'? IcedTea6 works fine for me here on amd64.
>>
>> eclipse and sun don't play well. however, i haven't tried switching to
>> the iced tea build on gentoo so maybe i'll give that a try next time.
>>
>>> Feel free to package Harmony, but I don't see how that will solve your problems,
>>
>> harmony runs eclipse fine. every couple of months when gentoo changes
>> something, i have to devote a couple of hours fixing stuff so that
>> eclipse works or else switch to harmony until everything's fixed.
>>
>
> That's interesting.  I don't know anything about the proprietary Sun
> builds on amd64, I've
> never used them.  But I also don't run Eclipse.  Have you filled
> appropriate bugs? Certainly try IcedTea and, if you get failures, report them to our bug
> database at
> http://icedtea.classpath.org/bugzilla.

cool

>>> given it doesn't yet have a complete implementation of even 1.5.
>>
>> if sun had honoured it's agreement to allow access to the TCK by open
>> source projects,  then harmony (and the free JVMs) would have had
>> certified 1.5 implementations a year ago and (most likely) 1.6 ones as
>> well by now. this is a political issue, not a code one.
>>
>
> I seriously doubt that, given it took OpenJDK a year to pass the 1.6
> TCK, despite
> being based on a codebase, the majority of which has passed as part of
> the proprietary work.

you'd be surprised :-)

at least one major corporation has taken a derived work based on
harmony codebase through the TCK

and ask yourself if google would have based andriod on harmony unless
it worked...

- robert

Re: [gentoo-java] OpenJDK, IcedTea and Package Naming

[Andrew John Hughes]

2008/9/14 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
> On Sun, Sep 14, 2008 at 3:26 PM, Andrew John Hughes
> <gnu_andrew@member.fsf.org> wrote:
>> 2008/9/14 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
>>> On Sun, Sep 14, 2008 at 2:21 AM, Andrew John Hughes
>>> <gnu_andrew@member.fsf.org> wrote:
>>>> 2008/9/13 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
>>>
>>> <snip>
>>>
>>>>> AIUI and IMNSHO *NO* local build from source qualifies. gentoo
>>>>> *SHOULD* *NOT* expose users to risk by using trademarks etc for *ANY*
>>>>> source build even from the sun tree.
>>>>>
>>>>
>>>> Maybe that's being a bit over cautious,
>>>
>>> i agree that sun is unlikely to sue any users over java ATM but
>>> trademarks must be defended or cease to exist. sooner or later sun
>>> will have to either lose the java trademark or act against
>>> unauthorised users.
>>>
>>
>> I wasn't talking about the Java trademark, I was talking about the OpenJDK
>> trademark.  Use of the Java trademark requires passing the
>> certification process,
>> and this isn't possible for a source build.  Only binaries can pass
>> the TCK and thus
>> be certified.
>
> yes
>
> thanks for clarifying
>
>>>> but the problem generally is
>>>> Sun thought of this with binary distribution in mind, not source.
>>>
>>> the JCP is set up to manage binaries, not source. IMO this is the
>>> fatal flaw in this system. (i'll avoid going OT by repeating the
>>> argument again here.)
>>>
>>
>> Yes, the JCP still needs work, being centered around proprietary
>> binary distribution for the most part.
>
> the binary distributions only rule is a consequence of the closed TCK.
> the TCK is closed to ensure a revenue stream for the spec leader.
>
> i'll be interested to see whether the JCP survives. sun broke the
> basic premise over the harmony TCK (all participants whether open
> source or not hold contracts with sun who acts as an independent
> judge). given that most open source projects can't afford to sue sun,
> the legal framework needs extensive revision. it would be cleaner for
> the JCP to issue a license covering any works that pass an open source
> TCK for everything except branding rights including the mutual patent
> grants. branding rights are only really required for commercial binary
> implementations so an additional secret TCK and payment could be
> required to unlock those.
>
>>>> As with any legal agreement, the best solution is to consult a lawyer.
>>>> I'm not one.
>>>
>>> does gentoo have a agreement with sun?
>>> if so, is it available on line?
>>> if not, what agreement is being relyed on?
>>>
>>
>> Not as far as I know, but other than naming and trademarks, OpenJDK is just
>> like any other FOSS project.
>
> trademarks are the important point (bit like firefox)
>
>>>>> BTW i'm on AMD64 which has very poor support from the sun java
>>>>> codebase. are there any plans to add support for the harmony VM?
>>>>>
>>>>
>>>> What 'poor support'? IcedTea6 works fine for me here on amd64.
>>>
>>> eclipse and sun don't play well. however, i haven't tried switching to
>>> the iced tea build on gentoo so maybe i'll give that a try next time.
>>>
>>>> Feel free to package Harmony, but I don't see how that will solve your problems,
>>>
>>> harmony runs eclipse fine. every couple of months when gentoo changes
>>> something, i have to devote a couple of hours fixing stuff so that
>>> eclipse works or else switch to harmony until everything's fixed.
>>>
>>
>> That's interesting.  I don't know anything about the proprietary Sun
>> builds on amd64, I've
>> never used them.  But I also don't run Eclipse.  Have you filled
>> appropriate bugs? Certainly try IcedTea and, if you get failures, report them to our bug
>> database at
>> http://icedtea.classpath.org/bugzilla.
>
> cool
>
>>>> given it doesn't yet have a complete implementation of even 1.5.
>>>
>>> if sun had honoured it's agreement to allow access to the TCK by open
>>> source projects,  then harmony (and the free JVMs) would have had
>>> certified 1.5 implementations a year ago and (most likely) 1.6 ones as
>>> well by now. this is a political issue, not a code one.
>>>
>>
>> I seriously doubt that, given it took OpenJDK a year to pass the 1.6
>> TCK, despite
>> being based on a codebase, the majority of which has passed as part of
>> the proprietary work.
>
> you'd be surprised :-)
>
> at least one major corporation has taken a derived work based on
> harmony codebase through the TCK
>

Is this the TreeMap? If so, it's one class which they modified heavily
themselves
so that it worked as part of 1.6.

> and ask yourself if google would have based andriod on harmony unless
> it worked...
>

I didn't say it didn't work, I said it wasnt' likely to pass the TCK
without a lot of work.
You could of course link the Harmony class library up to HotSpot,
apply for the OpenJDK6 TCK
to certify that combination and prove me wrong.

> - robert
>
>



-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: [gentoo-java] OpenJDK, IcedTea and Package Naming

[Robert Burrell Donkin]

On Sun, Sep 14, 2008 at 5:01 PM, Andrew John Hughes
<gnu_andrew@member.fsf.org> wrote:
> 2008/9/14 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
>> On Sun, Sep 14, 2008 at 3:26 PM, Andrew John Hughes
>> <gnu_andrew@member.fsf.org> wrote:
>>> 2008/9/14 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
>>>> On Sun, Sep 14, 2008 at 2:21 AM, Andrew John Hughes
>>>> <gnu_andrew@member.fsf.org> wrote:
>>>>> 2008/9/13 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:

<snip>

>>>>> given it doesn't yet have a complete implementation of even 1.5.
>>>>
>>>> if sun had honoured it's agreement to allow access to the TCK by open
>>>> source projects,  then harmony (and the free JVMs) would have had
>>>> certified 1.5 implementations a year ago and (most likely) 1.6 ones as
>>>> well by now. this is a political issue, not a code one.
>>>>
>>>
>>> I seriously doubt that, given it took OpenJDK a year to pass the 1.6
>>> TCK, despite
>>> being based on a codebase, the majority of which has passed as part of
>>> the proprietary work.
>>
>> you'd be surprised :-)
>>
>> at least one major corporation has taken a derived work based on
>> harmony codebase through the TCK
>>
>
> Is this the TreeMap? If so, it's one class which they modified heavily
> themselves
> so that it worked as part of 1.6.

no: one of the major alternative TCK'd JVMs is derived from harmony code

>> and ask yourself if google would have based andriod on harmony unless
>> it worked...
>>
>
> I didn't say it didn't work, I said it wasnt' likely to pass the TCK
> without a lot of work.
> You could of course link the Harmony class library up to HotSpot,
> apply for the OpenJDK6 TCK
> to certify that combination and prove me wrong.

would that i could :-)

sun has been saying 'not yet' to harmony certification for a number of
years. (just FTR it's not just harmony but any alternative FOSS JVM.)

- robert

Re: [gentoo-java] OpenJDK, IcedTea and Package Naming

[Andrew John Hughes]

2008/9/14 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
> On Sun, Sep 14, 2008 at 5:01 PM, Andrew John Hughes
> <gnu_andrew@member.fsf.org> wrote:
>> 2008/9/14 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
>>> On Sun, Sep 14, 2008 at 3:26 PM, Andrew John Hughes
>>> <gnu_andrew@member.fsf.org> wrote:
>>>> 2008/9/14 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
>>>>> On Sun, Sep 14, 2008 at 2:21 AM, Andrew John Hughes
>>>>> <gnu_andrew@member.fsf.org> wrote:
>>>>>> 2008/9/13 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
>
> <snip>
>
>>>>>> given it doesn't yet have a complete implementation of even 1.5.
>>>>>
>>>>> if sun had honoured it's agreement to allow access to the TCK by open
>>>>> source projects,  then harmony (and the free JVMs) would have had
>>>>> certified 1.5 implementations a year ago and (most likely) 1.6 ones as
>>>>> well by now. this is a political issue, not a code one.
>>>>>
>>>>
>>>> I seriously doubt that, given it took OpenJDK a year to pass the 1.6
>>>> TCK, despite
>>>> being based on a codebase, the majority of which has passed as part of
>>>> the proprietary work.
>>>
>>> you'd be surprised :-)
>>>
>>> at least one major corporation has taken a derived work based on
>>> harmony codebase through the TCK
>>>
>>
>> Is this the TreeMap? If so, it's one class which they modified heavily
>> themselves
>> so that it worked as part of 1.6.
>
> no: one of the major alternative TCK'd JVMs is derived from harmony code
>

Well I take it this isn't a Free JVM, as IcedTea6 is the only one I
know of that has
passed a JCK.  As you say JVM and not JDK, I take it we are talking about the
same TCK i.e. the JCK?

There was a JDK that had passed the JCK from which IcedTea6 was very
'substantially derived'.  It didn't mean there was no work to be done.

>>> and ask yourself if google would have based andriod on harmony unless
>>> it worked...
>>>
>>
>> I didn't say it didn't work, I said it wasnt' likely to pass the TCK
>> without a lot of work.
>> You could of course link the Harmony class library up to HotSpot,
>> apply for the OpenJDK6 TCK
>> to certify that combination and prove me wrong.
>
> would that i could :-)
>

You can; check the OpenJDK TCK FAQ.  Using HotSpot as the VM
would count as substantially derived from OpenJDK.

> sun has been saying 'not yet' to harmony certification for a number of
> years. (just FTR it's not just harmony but any alternative FOSS JVM.)
>

I know; GNU Classpath went through all this before Harmony even existed.

> - robert
>
>



-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8