interfaces and sub-class implementations

interfaces and sub-class implementations

[Nic Ferrier]

I found a few problems with source and native compilation where
interface methods not being implemented by the implementing class.

I'll report these later on (probably after the 3.1 release unless
people are desperate for bugs to fix /8-) but here's the jist:


  public interface Thingy
    public void someOperation (int x);
    public int anOperation (String x);

  public abstract class DooDah
    implements Thingy

    public void someOperation (int x)
    { }


  public class ThingumyJig extends DooDah
    public int anOperation (String x)
    {
      return "ha!";
    }


The above (or something analagous to the above) won't source compile.

One can make it compile by adding an abstract implementation of the
missing interface method, eg:

  public abstract class DooDah
    implements Thingy

    public void someOperation (int x)
    { }

    public abstract int anOperation (String x);

will fix the problem.


In certain circumstances native compilation won't happen either.



Just thought I'd let you know, as I say, I'll put a proper bug
together.


Nic

Re: interfaces and sub-class implementations

[Bryce McKinlay]

Nic Ferrier wrote:

>I found a few problems with source and native compilation where
>interface methods not being implemented by the implementing class.
>
>I'll report these later on (probably after the 3.1 release unless
>people are desperate for bugs to fix /8-) but here's the jist:
>
>
>  public interface Thingy
>    public void someOperation (int x);
>    public int anOperation (String x);
>
>  public abstract class DooDah
>    implements Thingy
>
>    public void someOperation (int x)
>    { }
>
>
>  public class ThingumyJig extends DooDah
>    public int anOperation (String x)
>    {
>      return "ha!";
>    }
>
>
>The above (or something analagous to the above) won't source compile.
>


I tried this and it worked for me with 3.2 20020411. I had to modify it 
slightly to get it to compile. If you could post an actual test case 
that fails with the bug report, that would be great. I know that GCJ has 
a few issues with abstract methods and bytecode but I'm not aware of any 
problems with pure source-to-native compilation.

regards

Bryce.

SAX inclusion in libgcj

[nferrier]

I'm just beginning the process of making a native build of
GNU-Paperclips (my servlet container).

Paperclips relies on GNUJAXP which delivers the SAX classes.

Unfortunately, so does libgcj. When I compile the relevant libs and
run the linked code I get this error:

libgcj failure: Duplicate class registration: org.xml.sax.SAXException


Is there a way of dealing with this?


I've mentioned a couple of times that the ClasspathX project has a
full JAXP implementation (apart from the XSLT). Should we include a
regular feed of GNUJAXP in GCJ?

It seems silly to have the SAX classes in 2 places within the GNU
project.

The GNUJAXP implementation is licenced under the GPL+exception (that
was done _specficially_ so the GCJ and Classpath projects could use
it).


Nic


PS why does fastjar not work with the libgcj jar file?!

Re: SAX inclusion in libgcj

[Mark Wielaard]

Hi,

On Tue, 2002-10-22 at 16:20, nferrier@tapsellferrier.co.uk wrote:
> I'm just beginning the process of making a native build of
> GNU-Paperclips (my servlet container).
> 
> Paperclips relies on GNUJAXP which delivers the SAX classes.
> 
> Unfortunately, so does libgcj. When I compile the relevant libs and
> run the linked code I get this error:
> 
> libgcj failure: Duplicate class registration: org.xml.sax.SAXException
> 
> 
> Is there a way of dealing with this?

Interesting. What would you expect? For traditional java programs the
core boot classes normally override anything provided by the program
(unless -bootclasspath is given). Does this behaviour also make sense
for binaries produced with gcj? Note that if you tried to compile with
-static you will probably always have problems linking.

Maybe the compiled classes in an .so file (or only the libgcj.so file)
could be given a slightly different name so that JvRegisterClass could
see the difference between classes loaded from the main program and from
the core classes?
But I know not enough about these issues to come up with a real
solution.

> I've mentioned a couple of times that the ClasspathX project has a
> full JAXP implementation (apart from the XSLT). Should we include a
> regular feed of GNUJAXP in GCJ?
> 
> It seems silly to have the SAX classes in 2 places within the GNU
> project.
> 
> The GNUJAXP implementation is licenced under the GPL+exception (that
> was done _specficially_ so the GCJ and Classpath projects could use
> it).

I think that is a good idea and if the copyright is assigned to the FSF
there should be no problem at all with integrating it. Except for
actually doing it which always takes more time than is available :) But
I thought that Gnu Jaxp was still in beta. Is there an official release
already? Then it would certainly make sense in pull this in.

> PS why does fastjar not work with the libgcj jar file?!

I was not aware of that. It is certainly a bug. Could you file a bug
report for this.

Thanks,

Mark

Re: SAX inclusion in libgcj

[Nic Ferrier]

Mark Wielaard <mark@klomp.org> writes:

> > I've mentioned a couple of times that the ClasspathX project has a
> > full JAXP implementation (apart from the XSLT). Should we include a
> > regular feed of GNUJAXP in GCJ?
> >
> > It seems silly to have the SAX classes in 2 places within the GNU
> > project.
> >
> > The GNUJAXP implementation is licenced under the GPL+exception (that
> > was done _specficially_ so the GCJ and Classpath projects could use
> > it).
> 
> I think that is a good idea and if the copyright is assigned to the FSF
> there should be no problem at all with integrating it. Except for
> actually doing it which always takes more time than is available :) But
> I thought that Gnu Jaxp was still in beta. Is there an official release
> already? Then it would certainly make sense in pull this in.

Why would we need a copyright assignment? It's just a downstream
provider isn't it?

GNUJAXP is ready for release. It's simply about when I have the time
to make the announcement and change the webpage, etc...


> > PS why does fastjar not work with the libgcj jar file?!
> 
> I was not aware of that. It is certainly a bug. Could you file a bug
> report for this.

I'll try and do that tommorow.


Nic

Re: SAX inclusion in libgcj

[Mark Wielaard]

Hi,

On Thu, 2002-10-24 at 20:57, Nic Ferrier wrote:
> Mark Wielaard <mark@klomp.org> writes:
> 
> > I think that is a good idea and if the copyright is assigned to the FSF
> > there should be no problem at all with integrating it. Except for
> > actually doing it which always takes more time than is available :) But
> > I thought that Gnu Jaxp was still in beta. Is there an official release
> > already? Then it would certainly make sense in pull this in.
> 
> Why would we need a copyright assignment? It's just a downstream
> provider isn't it?

Normally all code in the main Classpath distribution (and this is true
for all FSF projects) is only accepted when the copyright is assigned to
the FSF. Since I thought GNU JAXP was a GNU project I thought this was
already the case. There are of course exceptions, but since the XML
classes will probably be integrated tightly with other core packages
such as e.g. java.util.prefs and java.util.logging (only in Classpath at
the moment) and the new java.beans framework also has an XML storage, it
would be nice to keep all the copyright assigned to the FSF.

See also:
http://www.gnu.org/licenses/why-assign.html
http://www.gnu.org/software/classpath/doc/hacking.html#SEC2

> GNUJAXP is ready for release. It's simply about when I have the time
> to make the announcement and change the webpage, etc...

OK, great! I will wait for the official announcement then. Someone on
the kaffe mailinglist just emailed that it already seems to work nicely
with kaffe.

Cheers,

Mark

Re: SAX inclusion in libgcj

[Nic Ferrier]

Mark Wielaard <mark@klomp.org> writes:

> Hi,
> 
> On Thu, 2002-10-24 at 20:57, Nic Ferrier wrote:
> > Mark Wielaard <mark@klomp.org> writes:
> >
> > > I think that is a good idea and if the copyright is assigned to the FSF
> > > there should be no problem at all with integrating it. Except for
> > > actually doing it which always takes more time than is available :) But
> > > I thought that Gnu Jaxp was still in beta. Is there an official release
> > > already? Then it would certainly make sense in pull this in.
> >
> > Why would we need a copyright assignment? It's just a downstream
> > provider isn't it?
> 
> Normally all code in the main Classpath distribution (and this is true
> for all FSF projects) is only accepted when the copyright is assigned to
> the FSF. Since I thought GNU JAXP was a GNU project I thought this was
> already the case. There are of course exceptions, but since the XML
> classes will probably be integrated tightly with other core packages
> such as e.g. java.util.prefs and java.util.logging (only in Classpath at
> the moment) and the new java.beans framework also has an XML storage, it
> would be nice to keep all the copyright assigned to the FSF.

To be a GNU project "project" you DO NOT have to assign (c) to the
FSF. Projects run by the FSF of course require that.

Many other projects require assignment because it allows the FSF to
act as the legal owner which is important in any (c) dispute.


I agree that it might be a laudable aim for the ClasspathX project, we
have a very limited set of authors on the GNUJAXP implementation code
and so it will be easy to assign to the FSF should we need to.


Is this the position then? Unless we assign the (c) of ClasspathX
code to the FSF we cannnot distribute it with GCJ?

I don't think it can be: the W3C classes and the SAX classes are not
(c) assigned to the FSF.


Nic

Re: SAX inclusion in libgcj

[Mark Wielaard]

Hi Nic,

On Sat, 2002-10-26 at 15:26, Nic Ferrier wrote:
> To be a GNU project "project" you DO NOT have to assign (c) to the
> FSF. Projects run by the FSF of course require that.
> 
> Many other projects require assignment because it allows the FSF to
> act as the legal owner which is important in any (c) dispute.

You are of course right. But both GNU Classpath and GCC are run by the
FSF. I just thought that ClasspathX was also an official FSF run
project.

> I agree that it might be a laudable aim for the ClasspathX project, we
> have a very limited set of authors on the GNUJAXP implementation code
> and so it will be easy to assign to the FSF should we need to.

That would indeed be nice since then it is far easier to mix and match
parts of each others projects. This is also what was done for the GNU
Crypto project.

> Is this the position then? Unless we assign the (c) of ClasspathX
> code to the FSF we cannnot distribute it with GCJ?
> 
> I don't think it can be: the W3C classes and the SAX classes are not
> (c) assigned to the FSF.

Again yes. But for such things we need to clear all legal issues with
the FSF. Brian Jones and/or the GCC steering committee normally do such
things.

Since I am not an official GNU maintainer of any of these projects I
cannot (and don't want to) integrate anything before I am sure that all
legal/copyright issues are handled correctly. But that also means that
this not The Position, it is just my position as a volunteer developer
on these projects. I like the fact that not only I but also RedHat, IBM,
Intel, etc. assign the copyright to the FSF. That makes all players
equal and gives me the warm fuzzy feeling that all legal issues are
taken care of. So that everyone can be sure that what the FSF
distributes is and always will be Free Software. I do understand that
others might have different opinions on that.

Cheers,

Mark

Re: SAX inclusion in libgcj

[Tom Tromey]

>>>>> "Nic" == Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

Nic> I've mentioned a couple of times that the ClasspathX project has a
Nic> full JAXP implementation (apart from the XSLT). Should we include a
Nic> regular feed of GNUJAXP in GCJ?

All other things being equal, I think we should prefer GNU
implementations to non-GNU ones.

Are all other things equal?  I don't really know the SAX code.  Could
you compare and contrast the GNU implementation with the one currently
in the tree?

Nic> PS why does fastjar not work with the libgcj jar file?!

How does it not work?

Tom

Re: SAX inclusion in libgcj

[Tom Tromey]

>>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:

Mark> Interesting. What would you expect? For traditional java
Mark> programs the core boot classes normally override anything
Mark> provided by the program (unless -bootclasspath is given). Does
Mark> this behaviour also make sense for binaries produced with gcj?

Yes, but I think we'll need Bryce's binary compatibility code for this
to work.

Tom

Re: SAX inclusion in libgcj

[Tom Tromey]

>>>>> "Nic" == Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

Nic> Is this the position then? Unless we assign the (c) of ClasspathX
Nic> code to the FSF we cannnot distribute it with GCJ?

I don't think that's a requirement, given that we already do this.

I think Mark's point about the increasing ties between java.* and the
XML code is a good argument for the inclusion of GNU JAXP in Classpath
itself.  That would make assignment preferable.

Tom

Re: SAX inclusion in libgcj

[nferrier]

Tom Tromey <tromey@redhat.com> writes:

> >>>>> "Nic" == Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
> 
> Nic> I've mentioned a couple of times that the ClasspathX project has a
> Nic> full JAXP implementation (apart from the XSLT). Should we include a
> Nic> regular feed of GNUJAXP in GCJ?
> 
> All other things being equal, I think we should prefer GNU
> implementations to non-GNU ones.
> 
> Are all other things equal?  I don't really know the SAX code.  Could
> you compare and contrast the GNU implementation with the one currently
> in the tree?


A couple of clarifications here:

1. The SAX API code is importable anywhere because it's free.


2. (c) assignment of SAX API is (I believe) unrealistic because a lot
   of different people have hacked on it.

3. You guys have the SAX code, but not JAXP interfaces or an
   implementation.

4. ClasspathX has an implementation and the SAX and DOM API
   interfaces, with the exception licence.



I don't believe these things should be in the GCJ tree. It's just
marketing that does that surely? Is there some way we could offer
bundled versions (like Sun do) but not tie them completly together?


 
> Nic> PS why does fastjar not work with the libgcj jar file?!
> 
> How does it not work?

Haven't had time to submit a bug report... I'll get round to it.


Nic