Re: GCJ with OpenJDK Java API instead of GNU Classpath

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Chris Gray]

Quoth Andrew John Hughes:
> > Huh?  I was assuming Java compatibility was the goal.

Compatibility with the non-existent specification for Java 7, or with the
equally non-existent JCK for Java 7 (for which there is no JSR)? <G, D & R>

Chris Gray      /k/ Embedded Java Solutions

_________________________________________
Scarlet says goodbye to download limits!
ADSL20 NO LIMIT, only € 29,95
Go to www.scarlet.be for more info!

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Andrew John Hughes]

2009/5/7 Chris Gray <chris.gray@kiffer.be>:
>
> Quoth Andrew John Hughes:
>> > Huh?  I was assuming Java compatibility was the goal.
>
> Compatibility with the non-existent specification for Java 7, or with the
> equally non-existent JCK for Java 7 (for which there is no JSR)? <G, D & R>
>
> Chris Gray      /k/ Embedded Java Solutions
>
> _________________________________________
> Scarlet says goodbye to download limits!
> ADSL20 NO LIMIT, only € 29,95
> Go to www.scarlet.be for more info!
>
>

Neither; the JCK for OpenJDK6 which the builds of IcedTea in Fedora have passed:
http://openjdk.java.net/groups/conformance/
-- 
Andrew :-)

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

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: GCJ with OpenJDK Java API instead of GNU Classpath

[Mark Wielaard]

On Thu, 2009-05-07 at 16:28 +0100, Andrew John Hughes wrote:
> 2009/5/7 Chris Gray <chris.gray@kiffer.be>:
> >
> > Quoth Andrew John Hughes:
> >> > Huh?  I was assuming Java compatibility was the goal.
> >
> > Compatibility with the non-existent specification for Java 7, or with the
> > equally non-existent JCK for Java 7 (for which there is no JSR)? <G, D & R>
> >
> Neither; the JCK for OpenJDK6 which the builds of IcedTea in Fedora have passed:
> http://openjdk.java.net/groups/conformance/

I don't think that is a serious option, that is only available under NDA
and only granted to people who sign an SCA with Sun and even then access
is only granted if Sun feels like it.

That said, adopting something like jigsaw for the core class library and
then having the option to switch modules seems a fine idea.
Compatibility is much more about running actually code than some opaque
proprietary test suite.

Cheers,

Mark

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Andrew Haley]

Mark Wielaard wrote:
> On Thu, 2009-05-07 at 16:28 +0100, Andrew John Hughes wrote:
>> 2009/5/7 Chris Gray <chris.gray@kiffer.be>:
>>> Quoth Andrew John Hughes:
>>>>> Huh?  I was assuming Java compatibility was the goal.
>>> Compatibility with the non-existent specification for Java 7, or with the
>>> equally non-existent JCK for Java 7 (for which there is no JSR)? <G, D & R>
>>>
>> Neither; the JCK for OpenJDK6 which the builds of IcedTea in Fedora have passed:
>> http://openjdk.java.net/groups/conformance/
> 
> I don't think that is a serious option, that is only available under NDA
> and only granted to people who sign an SCA with Sun and even then access
> is only granted if Sun feels like it.

So why is it not a serious option?

> That said, adopting something like jigsaw for the core class library and
> then having the option to switch modules seems a fine idea.
> Compatibility is much more about running actually code than some opaque
> proprietary test suite.

It's about *both*.  All the JCK does is make sure you've implemented the
APIs as specified.

Andrew.

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Mark Wielaard]

Hi Andrew,

On Thu, 2009-05-07 at 17:31 +0100, Andrew Haley wrote:
> Mark Wielaard wrote:
> > On Thu, 2009-05-07 at 16:28 +0100, Andrew John Hughes wrote:
> >> 2009/5/7 Chris Gray <chris.gray@kiffer.be>:
> >>> Quoth Andrew John Hughes:
> >>>>> Huh?  I was assuming Java compatibility was the goal.
> >>> Compatibility with the non-existent specification for Java 7, or with the
> >>> equally non-existent JCK for Java 7 (for which there is no JSR)? <G, D & R>
> >>>
> >> Neither; the JCK for OpenJDK6 which the builds of IcedTea in Fedora have passed:
> >> http://openjdk.java.net/groups/conformance/
> > 
> > I don't think that is a serious option, that is only available under NDA
> > and only granted to people who sign an SCA with Sun and even then access
> > is only granted if Sun feels like it.
> 
> So why is it not a serious option?

Because it isn't a thing that a free software community can do
collaboratively in the open and involves requiring proprietary software.
Maybe a third party could do it for their own binary builds, but I don't
see how we as a community can recommend it, nor would I want to
recommend it myself.

> > That said, adopting something like jigsaw for the core class library and
> > then having the option to switch modules seems a fine idea.
> > Compatibility is much more about running actually code than some opaque
> > proprietary test suite.
> 
> It's about *both*.  All the JCK does is make sure you've implemented the
> APIs as specified.

:) Since the JCK is under NDA that claim is not verifiable. But you
could say that the JCK assumes one particular interpretation yeah.
Still, if a secret test suite would say things should work one way, but
actual programs expect things differently I would go with not breaking
existing stuff.

Cheers,

Mark

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Andrew Haley]

Mark Wielaard wrote:
> Hi Andrew,
> 
> On Thu, 2009-05-07 at 17:31 +0100, Andrew Haley wrote:
>> Mark Wielaard wrote:
>>> On Thu, 2009-05-07 at 16:28 +0100, Andrew John Hughes wrote:
>>>> 2009/5/7 Chris Gray <chris.gray@kiffer.be>:
>>>>> Quoth Andrew John Hughes:
>>>>>>> Huh?  I was assuming Java compatibility was the goal.
>>>>> Compatibility with the non-existent specification for Java 7, or with the
>>>>> equally non-existent JCK for Java 7 (for which there is no JSR)? <G, D & R>
>>>>>
>>>> Neither; the JCK for OpenJDK6 which the builds of IcedTea in Fedora have passed:
>>>> http://openjdk.java.net/groups/conformance/
>>> I don't think that is a serious option, that is only available under NDA
>>> and only granted to people who sign an SCA with Sun and even then access
>>> is only granted if Sun feels like it.
>> So why is it not a serious option?
> 
> Because it isn't a thing that a free software community can do
> collaboratively in the open and involves requiring proprietary software.
> Maybe a third party could do it for their own binary builds, but I don't
> see how we as a community can recommend it, nor would I want to
> recommend it myself.

That doesn't make it not a serious option.  It just means that
you don't want to do it, and you don't think that the gcj
community should do it.  It's still a serious option.

>>> That said, adopting something like jigsaw for the core class library and
>>> then having the option to switch modules seems a fine idea.
>>> Compatibility is much more about running actually code than some opaque
>>> proprietary test suite.
>> It's about *both*.  All the JCK does is make sure you've implemented the
>> APIs as specified.
> 
> :) Since the JCK is under NDA that claim is not verifiable. But you
> could say that the JCK assumes one particular interpretation yeah.
> Still, if a secret test suite would say things should work one way, but
> actual programs expect things differently I would go with not breaking
> existing stuff.

This is FUD, plain and simple.  What evidence do you have of programs
that require Java behaviour at odds with the JCK?

Andrew.

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[David Boreham]

Andrew Haley wrote:
> That doesn't make it not a serious option.  It just means that
> you don't want to do it, and you don't think that the gcj
> community should do it.  It's still a serious option.
>   
Not really. The problem is that the test can only be run by special people
under special circumstances.
So only the binaries produced by those special people can be said to have
passed the test. People in general can't run the test, reproduce its 
results,
test bug fixes, and so on. Therefore it's not a useful option for an open
source project.

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Andrew Haley]

David Boreham wrote:
> Andrew Haley wrote:
>> That doesn't make it not a serious option.  It just means that
>> you don't want to do it, and you don't think that the gcj
>> community should do it.  It's still a serious option.
>>   
> Not really. The problem is that the test can only be run by special people
> under special circumstances.

Yes.

> So only the binaries produced by those special people can be said to have
> passed the test. People in general can't run the test, reproduce its
> results,
> test bug fixes, and so on. >

Agreed.

> Therefore it's not a useful option for an open
> source project.

That doesn't follow.

The question is whether getting the JCK and using it is a serious
option.  It certainly is a serious option for anyone who needs it:
they get the JCK, run it on their build, and by doing so check Java
compatibility.

It's a useful option for those who are prepared to get the JCK, and
when they put their changes back into the common sources, everyone
benefits.

No, it's not the paradigm of open development, and it's not an
ideal situation.

Andrew.

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Mark Wielaard]

Hi Andrew,

On Thu, 2009-05-07 at 18:20 +0100, Andrew Haley wrote:
> Mark Wielaard wrote:
> > On Thu, 2009-05-07 at 17:31 +0100, Andrew Haley wrote:
> >> Mark Wielaard wrote:
> >>> On Thu, 2009-05-07 at 16:28 +0100, Andrew John Hughes wrote:
> >>>>>
> >>>> Neither; the JCK for OpenJDK6 which the builds of IcedTea in Fedora have passed:
> >>>> http://openjdk.java.net/groups/conformance/
> >>> I don't think that is a serious option, that is only available under NDA
> >>> and only granted to people who sign an SCA with Sun and even then access
> >>> is only granted if Sun feels like it.
> >> So why is it not a serious option?
> > 
> > Because it isn't a thing that a free software community can do
> > collaboratively in the open and involves requiring proprietary software.
> > Maybe a third party could do it for their own binary builds, but I don't
> > see how we as a community can recommend it, nor would I want to
> > recommend it myself.
> 
> That doesn't make it not a serious option.  It just means that
> you don't want to do it, and you don't think that the gcj
> community should do it.  It's still a serious option.

I think we agree. Let just s/serious//. It is an option. Just not one
that is IMHO feasible nor desirable for a free software project.

> > :) Since the JCK is under NDA that claim is not verifiable. But you
> > could say that the JCK assumes one particular interpretation yeah.
> > Still, if a secret test suite would say things should work one way, but
> > actual programs expect things differently I would go with not breaking
> > existing stuff.
> 
> This is FUD, plain and simple.  What evidence do you have of programs
> that require Java behaviour at odds with the JCK?

That is exactly my point. And you cannot prove the other way, that the
JCK tests behavior that is actually specified and not just a test for an
implementation detail. So we would be raising some smoke screen with no
way for the end user or our fellow hackers to do anything with except to
just trust those behind the NDA. They won't even be able to tell if it
is something that just happens on the particular setup that runs the TCK
or not.

Cheers,

Mark

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Andrew John Hughes]

2009/5/7 Mark Wielaard <mark@klomp.org>:
> Hi Andrew,
>
> On Thu, 2009-05-07 at 18:20 +0100, Andrew Haley wrote:
>> Mark Wielaard wrote:
>> > On Thu, 2009-05-07 at 17:31 +0100, Andrew Haley wrote:
>> >> Mark Wielaard wrote:
>> >>> On Thu, 2009-05-07 at 16:28 +0100, Andrew John Hughes wrote:
>> >>>>>
>> >>>> Neither; the JCK for OpenJDK6 which the builds of IcedTea in Fedora have passed:
>> >>>> http://openjdk.java.net/groups/conformance/
>> >>> I don't think that is a serious option, that is only available under NDA
>> >>> and only granted to people who sign an SCA with Sun and even then access
>> >>> is only granted if Sun feels like it.
>> >> So why is it not a serious option?
>> >
>> > Because it isn't a thing that a free software community can do
>> > collaboratively in the open and involves requiring proprietary software.
>> > Maybe a third party could do it for their own binary builds, but I don't
>> > see how we as a community can recommend it, nor would I want to
>> > recommend it myself.
>>
>> That doesn't make it not a serious option.  It just means that
>> you don't want to do it, and you don't think that the gcj
>> community should do it.  It's still a serious option.
>
> I think we agree. Let just s/serious//. It is an option. Just not one
> that is IMHO feasible nor desirable for a free software project.
>
>> > :) Since the JCK is under NDA that claim is not verifiable. But you
>> > could say that the JCK assumes one particular interpretation yeah.
>> > Still, if a secret test suite would say things should work one way, but
>> > actual programs expect things differently I would go with not breaking
>> > existing stuff.
>>
>> This is FUD, plain and simple.  What evidence do you have of programs
>> that require Java behaviour at odds with the JCK?
>
> That is exactly my point. And you cannot prove the other way, that the
> JCK tests behavior that is actually specified and not just a test for an
> implementation detail. So we would be raising some smoke screen with no
> way for the end user or our fellow hackers to do anything with except to
> just trust those behind the NDA. They won't even be able to tell if it
> is something that just happens on the particular setup that runs the TCK
> or not.
>

The clause in the OpenJCK6 license which restricts its use to projects
'substantially derived' from OpenJDK (judgement of which is made
secretly by Sun as part of the decision process) makes me very dubious
about it being a test of the specification.  It's very clearly a test
of compatibility with the reference implementation provided by Sun and
only JDKs derived from this reference implementation have ever passed
it.  There are places where the specification is unclear and the TCK
will resolve them in favour of how Sun chose to interpret the
specification.  I'm not saying this is a bad thing, but let's also not
fool ourselves that this is all there is to being able to run Java
applications.  For me, keeping the tests a secret and only allowing
them to be run against approved JDKs just makes me distrust the whole
process.  We know from our work on GNU Classpath and GCJ that many
applications can be run without passing the TCK or even having a
complete implementation of every API imaginable.  Similarly, we know
from working on IcedTea that there are issues above and beyond the
bounds of TCK testing.

> Cheers,
>
> Mark
>
>



-- 
Andrew :-)

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

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: GCJ with OpenJDK Java API instead of GNU Classpath

[Andrew Haley]

Andrew John Hughes wrote:
> 
> The clause in the OpenJCK6 license which restricts its use to projects
> 'substantially derived' from OpenJDK (judgement of which is made
> secretly by Sun as part of the decision process) makes me very dubious
> about it being a test of the specification.  It's very clearly a test
> of compatibility with the reference implementation provided by Sun and
> only JDKs derived from this reference implementation have ever passed
> it.

I don't believe this to be true, BTW: I know IBM have a clean room
implementation, and I think others do too.

> There are places where the specification is unclear and the TCK will
> resolve them in favour of how Sun chose to interpret the
> specification.

Right.

> I'm not saying this is a bad thing, but let's also not fool
> ourselves that this is all there is to being able to run Java
> applications.

Who would?  This looks like a strawman argument to me.

> For me, keeping the tests a secret and only allowing them to be run
> against approved JDKs just makes me distrust the whole process.  We
> know from our work on GNU Classpath and GCJ that many applications
> can be run without passing the TCK or even having a complete
> implementation of every API imaginable.  Similarly, we know from
> working on IcedTea that there are issues above and beyond the bounds
> of TCK testing.

Of course.

Andrew.

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Mark Wielaard]

On Fri, 2009-05-08 at 11:12 +0100, Andrew Haley wrote:
> Andrew John Hughes wrote:
> > 
> > The clause in the OpenJCK6 license which restricts its use to projects
> > 'substantially derived' from OpenJDK (judgement of which is made
> > secretly by Sun as part of the decision process) makes me very dubious
> > about it being a test of the specification.  It's very clearly a test
> > of compatibility with the reference implementation provided by Sun and
> > only JDKs derived from this reference implementation have ever passed
> > it.
> 
> I don't believe this to be true, BTW: I know IBM have a clean room
> implementation, and I think others do too.

Of the VM and compiler yes, but no alternative core library
implementation not derived from Sun's code has ever passed the TCK. In
fact Sun has till now refused to even provide the TCK to any alternative
core library implementation not derived from their own code.

Cheers,

Mark

GCJ with OpenJDK Java API instead of GNU Classpath

[Sal]

Forgive me if this is a silly question - but I wanted to ping the list 
before spending any time/effort here.

Grabbing GCJ's standard source releases, one can see that GNU classpath 
is integrated.   I've actually used classpath a lot and its a very 
stable API for me.

However - given recent events, particularly the 'freeing' of Java 
sources by Sun - is it a good idea to attempt to use Sun's 'official' 
Java API sources instead?  This would give the option of maximum Java 
API compatibility but also giving the ability to precompile native code 
using GCJ (which you cant do with OpenJDK afaik)

So my questions:

- Has anyone already attempted building the OpenJDK java sources with 
GCJ/and/or tried to swap out classpath for those classes?
- if not are people interested in going down this path? I am willing to 
put some efforts here.
- Are there licensing issues with linking OpenJDK to other code via GCJ? 
 From what I remember 'linking' is a touchy area with some FOSS licenses.

Thanks much in advance for any tips!!

- Sal

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Andrew Haley]

Sal wrote:
> Forgive me if this is a silly question - but I wanted to ping the list
> before spending any time/effort here.
> 
> Grabbing GCJ's standard source releases, one can see that GNU classpath
> is integrated.   I've actually used classpath a lot and its a very
> stable API for me.
> 
> However - given recent events, particularly the 'freeing' of Java
> sources by Sun - is it a good idea to attempt to use Sun's 'official'
> Java API sources instead?  This would give the option of maximum Java
> API compatibility but also giving the ability to precompile native code
> using GCJ (which you cant do with OpenJDK afaik)
> 
> So my questions:
> 
> - Has anyone already attempted building the OpenJDK java sources with
> GCJ/and/or tried to swap out classpath for those classes?
> - if not are people interested in going down this path? I am willing to
> put some efforts here.
> - Are there licensing issues with linking OpenJDK to other code via GCJ?
> From what I remember 'linking' is a touchy area with some FOSS licenses.

It's all GPL + exception, so there are no licence difficulties.

This would be an excellent thing to do, but it would be difficult.  In
particular, class loading and class initialization are done in very
different ways, and this would all need to be rewritten.

I'd love someone to do this, but I don't want them to be under any illusion
about how difficult it might be.

Andrew.

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Bryce McKinlay]

On Thu, May 7, 2009 at 10:17 AM, Andrew Haley <aph@redhat.com> wrote:

> It's all GPL + exception, so there are no licence difficulties.
>
> This would be an excellent thing to do, but it would be difficult.  In
> particular, class loading and class initialization are done in very
> different ways, and this would all need to be rewritten.
>
> I'd love someone to do this, but I don't want them to be under any illusion
> about how difficult it might be.

I don't think this is quite as hard as Andrew suggests. Certainly,
making GCJ work with low level OpenJDK classes like Object, Class, and
ClassLoader would be a lot of work - but pretty much everything above
that should work out-of-the-box, and provide the vast majority of the
compatibility benefits.

There's also no reason why the merge can't be done gradually, ie one
package at a time. We did that with the original libgcj-Classpath
merge.

Bryce

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Andrew John Hughes]

2009/5/7 Bryce McKinlay <bmckinlay@gmail.com>:
> On Thu, May 7, 2009 at 10:17 AM, Andrew Haley <aph@redhat.com> wrote:
>
>> It's all GPL + exception, so there are no licence difficulties.
>>
>> This would be an excellent thing to do, but it would be difficult.  In
>> particular, class loading and class initialization are done in very
>> different ways, and this would all need to be rewritten.
>>
>> I'd love someone to do this, but I don't want them to be under any illusion
>> about how difficult it might be.
>
> I don't think this is quite as hard as Andrew suggests. Certainly,
> making GCJ work with low level OpenJDK classes like Object, Class, and
> ClassLoader would be a lot of work - but pretty much everything above
> that should work out-of-the-box, and provide the vast majority of the
> compatibility benefits.
>
> There's also no reason why the merge can't be done gradually, ie one
> package at a time. We did that with the original libgcj-Classpath
> merge.
>
> Bryce
>

There's actually no need to do a wholesale replacement of everything.
GCJ already overrides quite a number of classes from GNU Classpath
with its own versions (including Object IIRC).  Quite a number of
packages in Classpath are just pure Java and are used as is in GCJ.
This even extends to Swing, where the native JNI code from Classpath
is used (GCJ usually prefers CNI).

It really depends what you want the end result to be.  Having some
hybrid with all the packages is probably an easier goal than trying to
pass the TCK with the result... ;)
I'd certainly be interested in any such efforts as well.
-- 
Andrew :-)

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

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: GCJ with OpenJDK Java API instead of GNU Classpath

[Andrew Haley]

Andrew John Hughes wrote:

> There's actually no need to do a wholesale replacement of
> everything.  GCJ already overrides quite a number of classes from
> GNU Classpath with its own versions (including Object IIRC).

Indeed, and these are broken in a number of interesting ways.  That's
why they'd need rewriting.

> Quite a number of packages in Classpath are just pure Java and are
> used as is in GCJ.  This even extends to Swing, where the native JNI
> code from Classpath is used (GCJ usually prefers CNI).
>
> It really depends what you want the end result to be.  Having some
> hybrid with all the packages is probably an easier goal than trying
> to pass the TCK with the result... ;)

Huh?  I was assuming Java compatibility was the goal.

Andrew.

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Bryce McKinlay]

On Thu, May 7, 2009 at 2:43 PM, Andrew Haley <aph@redhat.com> wrote:
> Andrew John Hughes wrote:
>
>> There's actually no need to do a wholesale replacement of
>> everything.  GCJ already overrides quite a number of classes from
>> GNU Classpath with its own versions (including Object IIRC).

I agree. GCJ-OpenJDK could be built following a very similar approach.

>> Quite a number of packages in Classpath are just pure Java and are
>> used as is in GCJ.  This even extends to Swing, where the native JNI
>> code from Classpath is used (GCJ usually prefers CNI).
>>
>> It really depends what you want the end result to be.  Having some
>> hybrid with all the packages is probably an easier goal than trying
>> to pass the TCK with the result... ;)
>
> Huh?  I was assuming Java compatibility was the goal.

Sure, it won't be perfect. But this approach gets you ~90% of the
compatibility with ~10% of the effort!

Bryce

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Sal]

Andrew Haley wrote:

> It's all GPL + exception, so there are no licence difficulties.
> 
> This would be an excellent thing to do, but it would be difficult.  In
> particular, class loading and class initialization are done in very
> different ways, and this would all need to be rewritten.
> 
> I'd love someone to do this, but I don't want them to be under any illusion
> about how difficult it might be.
> 
> Andrew.
> 

So it should be challenging then, great :)

Thanks for all the feedback, I'm glad to hear there are others who seem 
to like the idea as well.  I wasn't sure if this hadn't been started yet 
due to some legal issues, or otherwise.  Sounds like its just something 
that needs a little elbow grease.

I started some preliminary work - just to get a feel for what might be 
entailed.  What I was thinking as a general plan of attack:

	1) - Obtain/extract a copy of the Java sources from a standard/official 
Sun release. Just to start working from a clean slate since it is an 
effort towards maximum compatibility. I've noticed that not all classes 
are actually from a simple source-tree extract, some are  generated by 
the build process (so I'm still trying to get through this...)

	2) - Isolate a subset of the sources to get gcj-openjdk port started. 
possibly: java.lang.* (and all dependancies) at first, then the other 
fundamental things; java.io.*, java.util.* etc. Although open for 
suggestions here of course.

	3) - Compile the pieces from 2) with GCJ, add in more packages as 
things build.

	4) - Somehow, maintain releases for it all as things progress, so 
people can grab current work and collaborate.  I can do so much as to 
zip/upload snapshots when stuff starts working... but maybe others have 
much better ideas or resources here?  I've got a feeling it won't be an 
overnight process, so it would be a big help to allow for as many hands 
on deck as possible.

--

I'm currently trying to make it all the way through the openjdk build 
process, to get at the .java sources, and isolate the JNI parts needed 
for a working library.  Possibly if anyone has already done this let me 
know - as it doesn't seem other parts are very critical - (hotspot, 
etc.) to get running, since we're just replacing Classpath initially.

Looking forward to any ideas/comments!

Thanks much,

- Sal

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Robert Schuster]

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

Hi Sal,

Sal schrieb:
> 
> I'm currently trying to make it all the way through the openjdk build
> process, to get at the .java sources, and isolate the JNI parts needed
> for a working library.  Possibly if anyone has already done this let me
> know - as it doesn't seem other parts are very critical - (hotspot,
> etc.) to get running, since we're just replacing Classpath initially.
> 
> Looking forward to any ideas/comments!
The CacaoVM is currently one of the virtual machines that can be
combined with either GNU Classpath or the OpenJDK class library. The
IcedTea build environment even supports using Cacao's libjvm.so instead
of building it itself.

So if you can make a suitable libjvm.so out of GCJ (or better gij, the
interpreter) you can most likely reuse what IcedTea provides for Cacao.

The Cacao project's development mailing list is here:

  cacao <cacao@complang.tuwien.ac.at>

Just in case you have any questions regarding OpenJDK integration. :)

Good luck with your project!

(Btw: Wouldn't this have been an excellent GSoC idea?)

Regards
Robert


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

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Andrew Haley]

Sal wrote:

> Thanks for all the feedback, I'm glad to hear there are others who seem
> to like the idea as well.  I wasn't sure if this hadn't been started yet
> due to some legal issues, or otherwise.  Sounds like its just something
> that needs a little elbow grease.
> 
> I started some preliminary work - just to get a feel for what might be
> entailed.  What I was thinking as a general plan of attack:
> 
>     1) - Obtain/extract a copy of the Java sources from a
> standard/official Sun release. Just to start working from a clean slate
> since it is an effort towards maximum compatibility. I've noticed that
> not all classes are actually from a simple source-tree extract, some
> are  generated by the build process (so I'm still trying to get through
> this...)

Sure, but once you've done the build you've got everything you need.
Some classes are generated differently, depending on the word size
of the target machine.

>     2) - Isolate a subset of the sources to get gcj-openjdk port
> started. possibly: java.lang.* (and all dependancies) at first, then the
> other fundamental things; java.io.*, java.util.* etc. Although open for
> suggestions here of course.

The core classes and class loaders are all gcj custom and highly
intertwined, so you'd better avoid those.

>     3) - Compile the pieces from 2) with GCJ, add in more packages as
> things build.
> 
>     4) - Somehow, maintain releases for it all as things progress, so
> people can grab current work and collaborate.  I can do so much as to
> zip/upload snapshots when stuff starts working... but maybe others have
> much better ideas or resources here?  I've got a feeling it won't be an
> overnight process, so it would be a big help to allow for as many hands
> on deck as possible.

I think it would probably be best to host this at Sourceforge.  Alternatively,
we could use classpath.org, but that machine is rather heavily loaded
already.

Andrew.

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Mark Wielaard]

On Wed, 2009-05-06 at 15:41 -0600, Sal wrote:
> - Are there licensing issues with linking OpenJDK to other code via GCJ?

The only legal issue is that GNU Classpath is GPLv2+ and OpenJDK is
GPLv2 only, so you loose GPLv3 compatibility.

Cheers,

Mark

Re: GCJ with OpenJDK Java API instead of GNU Classpath

[Robert Schuster]

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

Hi,

Mark Wielaard schrieb:
> On Wed, 2009-05-06 at 15:41 -0600, Sal wrote:
>> - Are there licensing issues with linking OpenJDK to other code via GCJ?
> 
> The only legal issue is that GNU Classpath is GPLv2+ and OpenJDK is
> GPLv2 only, so you loose GPLv3 compatibility.
maybe a project wanting to use OpenJDK under GPLv2+ would create the
incentive for Sun to look into fixing this incompatibility.

Regards
Robert


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