NPE in parser->getDOMImplementation() with CNI

NPE in parser->getDOMImplementation() with CNI

[Sam Ruby]

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

I'm trying to develop a JAXP implementation using CNI, but I get a 
NullPointerException when I try to get a DOMImplementation.  I've 
attached a small script (tested on Ubuntu 9.04) which demonstrates the 
problem.

Any help would be appreciated.

- Sam Ruby

[-- Attachment #2: testdomimpl.sh --]
[-- Type: application/x-sh, Size: 1959 bytes --]

Re: NPE in parser->getDOMImplementation() with CNI

[Andrew Haley]

Sam Ruby wrote:
> I'm trying to develop a JAXP implementation using CNI, but I get a
> NullPointerException when I try to get a DOMImplementation.  I've
> attached a small script (tested on Ubuntu 9.04) which demonstrates the
> problem.
> 
> Any help would be appreciated.

Congratulations on this excellent test case.  Next time I want to tell
people how to do it right, I'll point them at your posting.

However, I get

 $ sh ~/testdomimpl.sh
gnu.xml.dom.DomDocumentBuilderFactory@160ecdad
gnu.xml.dom.DomDocumentBuilder@15ffbc45
gnu.xml.dom.DomImpl@15ef0ee5

gnu.xml.dom.DomDocumentBuilderFactory@2df0bea7
gnu.xml.dom.DomDocumentBuilder@2de03d5f
gnu.xml.dom.DomImpl@2dd0bfdf
 $ gcj --version
gcj (GCC) 4.4.0 20090307 (Red Hat 4.4.0-0.23)

Please compile everything -fpic.  IF you don't you can end up with copy
relocs for come classes.  You can compare nm --demangle ./testdomimpl2
with and without -fpic to see the effect of this.

I'm not sure what might be causing the problem you're seeing.  I guess it
must be because something isn't initialized, but I can't reproduce the
problem here.

Andrew.

Re: NPE in parser->getDOMImplementation() with CNI

[Mark Wielaard]

On Sun, 2009-06-21 at 16:46 +0100, Andrew Haley wrote:
> Sam Ruby wrote:
> > I'm trying to develop a JAXP implementation using CNI, but I get a
> > NullPointerException when I try to get a DOMImplementation.  I've
> > attached a small script (tested on Ubuntu 9.04) which demonstrates the
> > problem.
> > 
> > Any help would be appreciated.
> 
> Congratulations on this excellent test case.  Next time I want to tell
> people how to do it right, I'll point them at your posting.
> 
> However, I get
> 
>  $ sh ~/testdomimpl.sh
> gnu.xml.dom.DomDocumentBuilderFactory@160ecdad
> gnu.xml.dom.DomDocumentBuilder@15ffbc45
> gnu.xml.dom.DomImpl@15ef0ee5
> 
> gnu.xml.dom.DomDocumentBuilderFactory@2df0bea7
> gnu.xml.dom.DomDocumentBuilder@2de03d5f
> gnu.xml.dom.DomImpl@2dd0bfdf
>  $ gcj --version
> gcj (GCC) 4.4.0 20090307 (Red Hat 4.4.0-0.23)

I get the same with that version of gcj.
But on an older gcj installation:
gcj (Debian 4.3.2-2) 4.3.2

gnu.xml.dom.DomDocumentBuilderFactory@6992f029
gnu.xml.dom.DomDocumentBuilder@647a3539
gnu.xml.dom.DomImpl@64826fa9

gnu.xml.dom.DomDocumentBuilderFactory@17d5dffb
gnu.xml.dom.DomDocumentBuilder@12bcf52b
java.lang.NullPointerException
   at java.io.PrintStream.println(PrintStream.java:473)

That is somewhat strange since that method seems fine:
  public void println (Object obj)
  {
    print(obj == null ? "null" : obj.toString(), true);
  }

So maybe just upgrading to a newer Fedora and gcc 4.4 will be the
solution, although I don't completely get what goes wrong on the old
install.

Cheers,

Mark

Re: NPE in parser->getDOMImplementation() with CNI

[Andrew Haley]

Mark Wielaard wrote:
> On Sun, 2009-06-21 at 16:46 +0100, Andrew Haley wrote:
>> Sam Ruby wrote:
>>> I'm trying to develop a JAXP implementation using CNI, but I get a
>>> NullPointerException when I try to get a DOMImplementation.  I've
>>> attached a small script (tested on Ubuntu 9.04) which demonstrates the
>>> problem.
>>>
>>> Any help would be appreciated.
>> Congratulations on this excellent test case.  Next time I want to tell
>> people how to do it right, I'll point them at your posting.
>>
>> However, I get
>>
>>  $ sh ~/testdomimpl.sh
>> gnu.xml.dom.DomDocumentBuilderFactory@160ecdad
>> gnu.xml.dom.DomDocumentBuilder@15ffbc45
>> gnu.xml.dom.DomImpl@15ef0ee5
>>
>> gnu.xml.dom.DomDocumentBuilderFactory@2df0bea7
>> gnu.xml.dom.DomDocumentBuilder@2de03d5f
>> gnu.xml.dom.DomImpl@2dd0bfdf
>>  $ gcj --version
>> gcj (GCC) 4.4.0 20090307 (Red Hat 4.4.0-0.23)
> 
> I get the same with that version of gcj.
> But on an older gcj installation:
> gcj (Debian 4.3.2-2) 4.3.2
> 
> gnu.xml.dom.DomDocumentBuilderFactory@6992f029
> gnu.xml.dom.DomDocumentBuilder@647a3539
> gnu.xml.dom.DomImpl@64826fa9
> 
> gnu.xml.dom.DomDocumentBuilderFactory@17d5dffb
> gnu.xml.dom.DomDocumentBuilder@12bcf52b
> java.lang.NullPointerException
>    at java.io.PrintStream.println(PrintStream.java:473)
> 
> That is somewhat strange since that method seems fine:
>   public void println (Object obj)
>   {
>     print(obj == null ? "null" : obj.toString(), true);
>   }
> 
> So maybe just upgrading to a newer Fedora and gcc 4.4 will be the
> solution, although I don't completely get what goes wrong on the old
> install.

I have no problem with 4.3 either.  I think this may be an install
problem or some sort of library path problem.

If you can point me to a failure I can debug I'll have a look.

Andrew.

Re: NPE in parser->getDOMImplementation() with CNI

[Andrew Haley]

Mark Wielaard wrote:
> On Sun, 2009-06-21 at 16:46 +0100, Andrew Haley wrote:
>> Sam Ruby wrote:
>>> I'm trying to develop a JAXP implementation using CNI, but I get a
>>> NullPointerException when I try to get a DOMImplementation.  I've
>>> attached a small script (tested on Ubuntu 9.04) which demonstrates the
>>> problem.
>>>
>>> Any help would be appreciated.
>> Congratulations on this excellent test case.  Next time I want to tell
>> people how to do it right, I'll point them at your posting.
>>
>> However, I get
>>
>>  $ sh ~/testdomimpl.sh
>> gnu.xml.dom.DomDocumentBuilderFactory@160ecdad
>> gnu.xml.dom.DomDocumentBuilder@15ffbc45
>> gnu.xml.dom.DomImpl@15ef0ee5
>>
>> gnu.xml.dom.DomDocumentBuilderFactory@2df0bea7
>> gnu.xml.dom.DomDocumentBuilder@2de03d5f
>> gnu.xml.dom.DomImpl@2dd0bfdf
>>  $ gcj --version
>> gcj (GCC) 4.4.0 20090307 (Red Hat 4.4.0-0.23)
> 
> I get the same with that version of gcj.
> But on an older gcj installation:
> gcj (Debian 4.3.2-2) 4.3.2
> 
> gnu.xml.dom.DomDocumentBuilderFactory@6992f029
> gnu.xml.dom.DomDocumentBuilder@647a3539
> gnu.xml.dom.DomImpl@64826fa9
> 
> gnu.xml.dom.DomDocumentBuilderFactory@17d5dffb
> gnu.xml.dom.DomDocumentBuilder@12bcf52b
> java.lang.NullPointerException
>    at java.io.PrintStream.println(PrintStream.java:473)

I found the problem.

There is an implementation of jaxp in /usr/share/java/jaxp-1.3.jar and
another in /usr/lib/libgcj.so.90.  They are not the same version, and
they are not compatible.

If you link against /usr/lib/libgcj.so.90 then you must compile against
the version of jaxp in that library.

Do this:

gcjh -cp /usr/share/java/libgcj.jar -d headers \
  org.w3c.dom.DOMImplementation \
  javax.xml.parsers.DocumentBuilder \
  javax.xml.parsers.DocumentBuilderFactory

I don't think it's possible to override the version of jaxp that's in
/usr/lib/libgcj.so.90.

Andrew.

Re: NPE in parser->getDOMImplementation() with CNI

[Sam Ruby]

Andrew Haley wrote:
> Mark Wielaard wrote:
>> On Sun, 2009-06-21 at 16:46 +0100, Andrew Haley wrote:
>>> Sam Ruby wrote:
>>>> I'm trying to develop a JAXP implementation using CNI, but I get a
>>>> NullPointerException when I try to get a DOMImplementation.  I've
>>>> attached a small script (tested on Ubuntu 9.04) which demonstrates the
>>>> problem.
>>>>
>>>> Any help would be appreciated.
>>> Congratulations on this excellent test case.  Next time I want to tell
>>> people how to do it right, I'll point them at your posting.
>>>
>>> However, I get
>>>
>>>  $ sh ~/testdomimpl.sh
>>> gnu.xml.dom.DomDocumentBuilderFactory@160ecdad
>>> gnu.xml.dom.DomDocumentBuilder@15ffbc45
>>> gnu.xml.dom.DomImpl@15ef0ee5
>>>
>>> gnu.xml.dom.DomDocumentBuilderFactory@2df0bea7
>>> gnu.xml.dom.DomDocumentBuilder@2de03d5f
>>> gnu.xml.dom.DomImpl@2dd0bfdf
>>>  $ gcj --version
>>> gcj (GCC) 4.4.0 20090307 (Red Hat 4.4.0-0.23)
>> I get the same with that version of gcj.
>> But on an older gcj installation:
>> gcj (Debian 4.3.2-2) 4.3.2
>>
>> gnu.xml.dom.DomDocumentBuilderFactory@6992f029
>> gnu.xml.dom.DomDocumentBuilder@647a3539
>> gnu.xml.dom.DomImpl@64826fa9
>>
>> gnu.xml.dom.DomDocumentBuilderFactory@17d5dffb
>> gnu.xml.dom.DomDocumentBuilder@12bcf52b
>> java.lang.NullPointerException
>>    at java.io.PrintStream.println(PrintStream.java:473)
>>
>> That is somewhat strange since that method seems fine:
>>   public void println (Object obj)
>>   {
>>     print(obj == null ? "null" : obj.toString(), true);
>>   }
>>
>> So maybe just upgrading to a newer Fedora and gcc 4.4 will be the
>> solution, although I don't completely get what goes wrong on the old
>> install.
> 
> I have no problem with 4.3 either.  I think this may be an install
> problem or some sort of library path problem.
> 
> If you can point me to a failure I can debug I'll have a look.

The script I provided fails with Ubuntu 9.04.  The only things one needs 
to add to a fresh install get to the failure is:

   apt-get install gcj libjaxp1.3-java-gcj

gcj -v reports "gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)"

Downloading the latest Fedora-11-i686-Live.iso, the script passes after 
I change the gcjh line to point to /usr/share/java/jaxp_parser_impl.jar.

gcj -v there reports "gcc version 4.4.0 20090506 (Red Hat 4.4.0-4) (GCC)".

Testing on an older version of Ubuntu (Hardy/8.04.2) also works.  Gcj -v 
there reports "gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)".

> Andrew.

- Sam Ruby

Re: NPE in parser->getDOMImplementation() with CNI

[Sam Ruby]

Andrew Haley wrote:
> Mark Wielaard wrote:
>> On Sun, 2009-06-21 at 16:46 +0100, Andrew Haley wrote:
>>> Sam Ruby wrote:
>>>> I'm trying to develop a JAXP implementation using CNI, but I get a
>>>> NullPointerException when I try to get a DOMImplementation.  I've
>>>> attached a small script (tested on Ubuntu 9.04) which demonstrates the
>>>> problem.
>>>>
>>>> Any help would be appreciated.
>>> Congratulations on this excellent test case.  Next time I want to tell
>>> people how to do it right, I'll point them at your posting.
>>>
>>> However, I get
>>>
>>>  $ sh ~/testdomimpl.sh
>>> gnu.xml.dom.DomDocumentBuilderFactory@160ecdad
>>> gnu.xml.dom.DomDocumentBuilder@15ffbc45
>>> gnu.xml.dom.DomImpl@15ef0ee5
>>>
>>> gnu.xml.dom.DomDocumentBuilderFactory@2df0bea7
>>> gnu.xml.dom.DomDocumentBuilder@2de03d5f
>>> gnu.xml.dom.DomImpl@2dd0bfdf
>>>  $ gcj --version
>>> gcj (GCC) 4.4.0 20090307 (Red Hat 4.4.0-0.23)
>> I get the same with that version of gcj.
>> But on an older gcj installation:
>> gcj (Debian 4.3.2-2) 4.3.2
>>
>> gnu.xml.dom.DomDocumentBuilderFactory@6992f029
>> gnu.xml.dom.DomDocumentBuilder@647a3539
>> gnu.xml.dom.DomImpl@64826fa9
>>
>> gnu.xml.dom.DomDocumentBuilderFactory@17d5dffb
>> gnu.xml.dom.DomDocumentBuilder@12bcf52b
>> java.lang.NullPointerException
>>    at java.io.PrintStream.println(PrintStream.java:473)
> 
> I found the problem.
> 
> There is an implementation of jaxp in /usr/share/java/jaxp-1.3.jar and
> another in /usr/lib/libgcj.so.90.  They are not the same version, and
> they are not compatible.
> 
> If you link against /usr/lib/libgcj.so.90 then you must compile against
> the version of jaxp in that library.
> 
> Do this:
> 
> gcjh -cp /usr/share/java/libgcj.jar -d headers \
>   org.w3c.dom.DOMImplementation \
>   javax.xml.parsers.DocumentBuilder \
>   javax.xml.parsers.DocumentBuilderFactory

I still see the problem.  Even after I apt-get remove libjaxp1.3-java-gcj.

> I don't think it's possible to override the version of jaxp that's in
> /usr/lib/libgcj.so.90.

I'd be fine using that version... if only it would work.

> Andrew.

- Sam Ruby

Re: NPE in parser->getDOMImplementation() with CNI

[Andrew Haley]

Sam Ruby wrote:
> Andrew Haley wrote:
>> Mark Wielaard wrote:
>>> On Sun, 2009-06-21 at 16:46 +0100, Andrew Haley wrote:
>>>> Sam Ruby wrote:
>>>>> I'm trying to develop a JAXP implementation using CNI, but I get a
>>>>> NullPointerException when I try to get a DOMImplementation.  I've
>>>>> attached a small script (tested on Ubuntu 9.04) which demonstrates the
>>>>> problem.
>>>>>
>>>>> Any help would be appreciated.
>>>> Congratulations on this excellent test case.  Next time I want to tell
>>>> people how to do it right, I'll point them at your posting.
>>>>
>>>> However, I get
>>>>
>>>>  $ sh ~/testdomimpl.sh
>>>> gnu.xml.dom.DomDocumentBuilderFactory@160ecdad
>>>> gnu.xml.dom.DomDocumentBuilder@15ffbc45
>>>> gnu.xml.dom.DomImpl@15ef0ee5
>>>>
>>>> gnu.xml.dom.DomDocumentBuilderFactory@2df0bea7
>>>> gnu.xml.dom.DomDocumentBuilder@2de03d5f
>>>> gnu.xml.dom.DomImpl@2dd0bfdf
>>>>  $ gcj --version
>>>> gcj (GCC) 4.4.0 20090307 (Red Hat 4.4.0-0.23)
>>> I get the same with that version of gcj.
>>> But on an older gcj installation:
>>> gcj (Debian 4.3.2-2) 4.3.2
>>>
>>> gnu.xml.dom.DomDocumentBuilderFactory@6992f029
>>> gnu.xml.dom.DomDocumentBuilder@647a3539
>>> gnu.xml.dom.DomImpl@64826fa9
>>>
>>> gnu.xml.dom.DomDocumentBuilderFactory@17d5dffb
>>> gnu.xml.dom.DomDocumentBuilder@12bcf52b
>>> java.lang.NullPointerException
>>>    at java.io.PrintStream.println(PrintStream.java:473)
>>
>> I found the problem.
>>
>> There is an implementation of jaxp in /usr/share/java/jaxp-1.3.jar and
>> another in /usr/lib/libgcj.so.90.  They are not the same version, and
>> they are not compatible.
>>
>> If you link against /usr/lib/libgcj.so.90 then you must compile against
>> the version of jaxp in that library.
>>
>> Do this:
>>
>> gcjh -cp /usr/share/java/libgcj.jar -d headers \
>>   org.w3c.dom.DOMImplementation \
>>   javax.xml.parsers.DocumentBuilder \
>>   javax.xml.parsers.DocumentBuilderFactory
> 
> I still see the problem.  Even after I apt-get remove libjaxp1.3-java-gcj.

The problem is not libjaxp1.3-java-gcj, it's libjaxp1.3-java

>> I don't think it's possible to override the version of jaxp that's in
>> /usr/lib/libgcj.so.90.
> 
> I'd be fine using that version... if only it would work.

The key is javax/xml/parsers/DocumentBuilder.h.  Here's the difference
between the bad and the good versiona:

aph@classpath:/tmp$ diff -u headers/javax/xml/parsers/DocumentBuilder.h bad/javax/xml/parsers/DocumentBuilder.h
--- headers/javax/xml/parsers/DocumentBuilder.h	2009-06-22 11:47:28.000000000 +0000
+++ bad/javax/xml/parsers/DocumentBuilder.h	2009-06-22 11:46:37.000000000 +0000
@@ -51,6 +51,7 @@
 public: // actually protected
   DocumentBuilder();
 public:
+  virtual void reset();
   virtual ::org::w3c::dom::Document * parse(::java::io::InputStream *);
   virtual ::org::w3c::dom::Document * parse(::java::io::InputStream *, ::java::lang::String *);
   virtual ::org::w3c::dom::Document * parse(::java::lang::String *);
@@ -62,9 +63,11 @@
   virtual void setErrorHandler(::org::xml::sax::ErrorHandler *) = 0;
   virtual ::org::w3c::dom::Document * newDocument() = 0;
   virtual ::org::w3c::dom::DOMImplementation * getDOMImplementation() = 0;
-  virtual void reset();
   virtual ::javax::xml::validation::Schema * getSchema();
   virtual jboolean isXIncludeAware();
+private:
+  static const jboolean DEBUG = 0;
+public:
   static ::java::lang::Class class$;
 };


************************************************************************
Please make sure you delete *everything* from the old build.  Especially
the contents of the headers directory.
************************************************************************

If all that still fails, please send the failing script so we can try it.

Andrew.

Re: NPE in parser->getDOMImplementation() with CNI

[Sam Ruby]

Andrew Haley wrote:
> Sam Ruby wrote:
>> Andrew Haley wrote:
>>> Mark Wielaard wrote:
>>>> On Sun, 2009-06-21 at 16:46 +0100, Andrew Haley wrote:
>>>>> Sam Ruby wrote:
>>>>>> I'm trying to develop a JAXP implementation using CNI, but I get a
>>>>>> NullPointerException when I try to get a DOMImplementation.  I've
>>>>>> attached a small script (tested on Ubuntu 9.04) which demonstrates the
>>>>>> problem.
>>>>>>
>>>>>> Any help would be appreciated.
>>>>> Congratulations on this excellent test case.  Next time I want to tell
>>>>> people how to do it right, I'll point them at your posting.
>>>>>
>>>>> However, I get
>>>>>
>>>>>  $ sh ~/testdomimpl.sh
>>>>> gnu.xml.dom.DomDocumentBuilderFactory@160ecdad
>>>>> gnu.xml.dom.DomDocumentBuilder@15ffbc45
>>>>> gnu.xml.dom.DomImpl@15ef0ee5
>>>>>
>>>>> gnu.xml.dom.DomDocumentBuilderFactory@2df0bea7
>>>>> gnu.xml.dom.DomDocumentBuilder@2de03d5f
>>>>> gnu.xml.dom.DomImpl@2dd0bfdf
>>>>>  $ gcj --version
>>>>> gcj (GCC) 4.4.0 20090307 (Red Hat 4.4.0-0.23)
>>>> I get the same with that version of gcj.
>>>> But on an older gcj installation:
>>>> gcj (Debian 4.3.2-2) 4.3.2
>>>>
>>>> gnu.xml.dom.DomDocumentBuilderFactory@6992f029
>>>> gnu.xml.dom.DomDocumentBuilder@647a3539
>>>> gnu.xml.dom.DomImpl@64826fa9
>>>>
>>>> gnu.xml.dom.DomDocumentBuilderFactory@17d5dffb
>>>> gnu.xml.dom.DomDocumentBuilder@12bcf52b
>>>> java.lang.NullPointerException
>>>>    at java.io.PrintStream.println(PrintStream.java:473)
>>> I found the problem.
>>>
>>> There is an implementation of jaxp in /usr/share/java/jaxp-1.3.jar and
>>> another in /usr/lib/libgcj.so.90.  They are not the same version, and
>>> they are not compatible.
>>>
>>> If you link against /usr/lib/libgcj.so.90 then you must compile against
>>> the version of jaxp in that library.
>>>
>>> Do this:
>>>
>>> gcjh -cp /usr/share/java/libgcj.jar -d headers \
>>>   org.w3c.dom.DOMImplementation \
>>>   javax.xml.parsers.DocumentBuilder \
>>>   javax.xml.parsers.DocumentBuilderFactory
>> I still see the problem.  Even after I apt-get remove libjaxp1.3-java-gcj.
> 
> The problem is not libjaxp1.3-java-gcj, it's libjaxp1.3-java

Bingo!  apt-get remove libjaxp1.3-java... problem solved!  Thanks!

- Sam Ruby

Re: NPE in parser->getDOMImplementation() with CNI

[Sam Ruby]

Andrew Haley wrote:
> 
> Congratulations on this excellent test case.  Next time I want to tell
> people how to do it right, I'll point them at your posting.

Hopefully that earned me the right to ask a dumb question.

Generating a header file for javax::xml::xpath::XPathExpression produces 
a file that looks like the following:

http://git.etherboot.org/scm/people/mcb30/gcc/libjava/javax/xml/xpath/XPathExpression.h

Attempting to include this file produces:

headers/javax/xml/xpath/XPathExpression.h:16: error: expected identifier 
before ‘namespace’
headers/javax/xml/xpath/XPathExpression.h:42: error: expected identifier 
before ‘namespace’
headers/javax/xml/xpath/XPathExpression.h:42: error: expected ‘,’ or 
‘...’ before ‘namespace’

Presumably somebody has encountered this before, and there is an obvious 
solution...

- Sam Ruby

Re: NPE in parser->getDOMImplementation() with CNI

[Andrew Haley]

Sam Ruby wrote:
> Andrew Haley wrote:
>>
>> Congratulations on this excellent test case.  Next time I want to tell
>> people how to do it right, I'll point them at your posting.
> 
> Hopefully that earned me the right to ask a dumb question.
> 
> Generating a header file for javax::xml::xpath::XPathExpression produces
> a file that looks like the following:
> 
> http://git.etherboot.org/scm/people/mcb30/gcc/libjava/javax/xml/xpath/XPathExpression.h
> 
> 
> Attempting to include this file produces:
> 
> headers/javax/xml/xpath/XPathExpression.h:16: error: expected identifier
> before ‘namespace’
> headers/javax/xml/xpath/XPathExpression.h:42: error: expected identifier
> before ‘namespace’
> headers/javax/xml/xpath/XPathExpression.h:42: error: expected ‘,’ or
> ‘...’ before ‘namespace’
> 
> Presumably somebody has encountered this before, and there is an obvious
> solution...

Some genius (?) has a namespace called "namespace" :-)

I think you'll have to edit the header file by hand.

Andrew.

Re: NPE in parser->getDOMImplementation() with CNI

[Chris Burdess]

Andrew Haley wrote:
> Sam Ruby wrote:
>> Generating a header file for javax::xml::xpath::XPathExpression  
>> produces
>> a file that looks like the following:
>>
>> http://git.etherboot.org/scm/people/mcb30/gcc/libjava/javax/xml/xpath/XPathExpression.h
>>
>>
>> Attempting to include this file produces:
>>
>> headers/javax/xml/xpath/XPathExpression.h:16: error: expected  
>> identifier
>> before ‘namespace’
>> headers/javax/xml/xpath/XPathExpression.h:42: error: expected  
>> identifier
>> before ‘namespace’
>> headers/javax/xml/xpath/XPathExpression.h:42: error: expected ‘,’ or
>> ‘...’ before ‘namespace’
>>
>> Presumably somebody has encountered this before, and there is an  
>> obvious
>> solution...
>
> Some genius (?) has a namespace called "namespace" :-)

That would be Sun. And in Java "namespace" is not a keyword so it's a  
perfectly legal package name.

> I think you'll have to edit the header file by hand.


Should this not be handled by some automatic munging/unmunging in gcjh/ 
gcj? It may prove to be a problem in other places where names are not  
keywords in Java but might be in C/C++/whatever.
-- 
Chris Burdess

Re: NPE in parser->getDOMImplementation() with CNI

[Bryce McKinlay]

On Tue, Jun 23, 2009 at 10:39 AM, Chris Burdess<dog@bluezoo.org> wrote:

>> Some genius (?) has a namespace called "namespace" :-)
>
> That would be Sun. And in Java "namespace" is not a keyword so it's a
> perfectly legal package name.
>
>> I think you'll have to edit the header file by hand.
>
>
> Should this not be handled by some automatic munging/unmunging in gcjh/gcj?
> It may prove to be a problem in other places where names are not keywords in
> Java but might be in C/C++/whatever.

Yes it should. The "old" gcjh certainly did this, but perhaps some of
the C++ keyword handling got lost a while back when gcjh was rewritten
in Java. The code is in
libjava/classpath/tools/gnu/classpath/tools/javah if you want to take
a look.

Bryce

Re: NPE in parser->getDOMImplementation() with CNI

[Andrew Haley]

Chris Burdess wrote:
> Andrew Haley wrote:
>> Sam Ruby wrote:
>>> Generating a header file for javax::xml::xpath::XPathExpression produces
>>> a file that looks like the following:
>>>
>>> http://git.etherboot.org/scm/people/mcb30/gcc/libjava/javax/xml/xpath/XPathExpression.h
>>>
>>>
>>>
>>> Attempting to include this file produces:
>>>
>>> headers/javax/xml/xpath/XPathExpression.h:16: error: expected identifier
>>> before ‘namespace’
>>> headers/javax/xml/xpath/XPathExpression.h:42: error: expected identifier
>>> before ‘namespace’
>>> headers/javax/xml/xpath/XPathExpression.h:42: error: expected ‘,’ or
>>> ‘...’ before ‘namespace’
>>>
>>> Presumably somebody has encountered this before, and there is an obvious
>>> solution...
>>
>> Some genius (?) has a namespace called "namespace" :-)
> 
> That would be Sun. And in Java "namespace" is not a keyword so it's a
> perfectly legal package name.
> 
>> I think you'll have to edit the header file by hand.
> 
> Should this not be handled by some automatic munging/unmunging in
> gcjh/gcj? It may prove to be a problem in other places where names are
> not keywords in Java but might be in C/C++/whatever.

Yes, that's right.

gjavah does have code to handle this, but it isn't being called.

Here, in CniPrintStream.java is where the package names are emitted:

    // Open new parts.
    for (int j = commonIndex; j < pkgParts.length; ++j)
      {
        indent(out, j + 1);
        out.print("namespace ");
        out.println(pkgParts[j]);

This line should be

        out.println(Keywords.getCxxName(pkgParts[j]));

but there are many places where identifiers are emitted but getCxxName is
not called.  This is very odd: for correctness, getCxxName must be called
whenever an identifier is emitted.

Andrew.

namespace namespace (was: NPE in parser->getDOMImplementation() with CNI)

[Sam Ruby]

Bryce McKinlay wrote:
> On Tue, Jun 23, 2009 at 10:39 AM, Chris Burdess<dog@bluezoo.org> wrote:
> 
>>> Some genius (?) has a namespace called "namespace" :-)
>> That would be Sun. And in Java "namespace" is not a keyword so it's a
>> perfectly legal package name.

namespace also happens to be the name of a concept in XML...

>>> I think you'll have to edit the header file by hand.

To what?  Specifically, what should namespace "namespace" be mapped to? 
  Presumably these names matter to the linker, so this should match what 
is in the library.  nm doesn't provide me any insight when run against 
libgcj.so.90, but greping my way through the output of strings, I can't 
figure out what namespace is mapped to... actually I see things like 
_ZN5javax3xml9namespace5QName6class$E which lead me to believe that 
namespace isn't mapped???

Indeed, if I create my own trivial app and examine the executable I see 
a namespace named namespace:

$ nm --demangle hello  | grep Hello
0000000000601390 d _CD_namespace_HelloWorld
00000000006013a0 d _CT_namespace_HelloWorld
0000000000601340 d _MT_namespace_HelloWorld
0000000000400bc2 T void 
namespace::HelloWorld::main(JArray<java::lang::String*>*)
0000000000601400 D namespace::HelloWorld::class$
0000000000400d88 R namespace::HelloWorld::class$$
0000000000400ba0 T namespace::HelloWorld::HelloWorld()
00000000006012e0 D vtable for namespace::HelloWorld
00000000006013c0 d _catch_classes_namespace_HelloWorld

$ nm hello  | grep Hello
0000000000601390 d _CD_namespace_HelloWorld
00000000006013a0 d _CT_namespace_HelloWorld
0000000000601340 d _MT_namespace_HelloWorld
0000000000400bc2 T 
_ZN9namespace10HelloWorld4mainEJvP6JArrayIPN4java4lang6StringEE
0000000000601400 D _ZN9namespace10HelloWorld6class$E
0000000000400d88 R _ZN9namespace10HelloWorld7class$$E
0000000000400ba0 T _ZN9namespace10HelloWorldC1Ev
00000000006012e0 D _ZTVN9namespace10HelloWorldE
00000000006013c0 d _catch_classes_namespace_HelloWorld

It is beginning to appear to me that gcj/g++ will do name mangling of 
Java packages without regard to C++ reserved words, resulting in entry 
points that can't conveniently be referenced in C++ using CNI.

>> Should this not be handled by some automatic munging/unmunging in gcjh/gcj?
>> It may prove to be a problem in other places where names are not keywords in
>> Java but might be in C/C++/whatever.
> 
> Yes it should. The "old" gcjh certainly did this, but perhaps some of
> the C++ keyword handling got lost a while back when gcjh was rewritten
> in Java. The code is in
> libjava/classpath/tools/gnu/classpath/tools/javah if you want to take
> a look.

Where can I find the "old" gcjh?  The current code is in Java, which 
presumably does *not* have the mapping:

http://cvs.savannah.gnu.org/viewvc/classpath/tools/gnu/classpath/tools/javah/?root=classpath

> Bryce

- Sam Ruby

Re: namespace namespace

[Andrew Haley]

Sam Ruby wrote:
> Bryce McKinlay wrote:
>> On Tue, Jun 23, 2009 at 10:39 AM, Chris Burdess<dog@bluezoo.org> wrote:
>>
>>>> Some genius (?) has a namespace called "namespace" :-)
>>> That would be Sun. And in Java "namespace" is not a keyword so it's a
>>> perfectly legal package name.
> 
> namespace also happens to be the name of a concept in XML...
> 
>>>> I think you'll have to edit the header file by hand.
> 
> To what?  Specifically, what should namespace "namespace" be mapped to?

   namespace$

> It is beginning to appear to me that gcj/g++ will do name mangling of
> Java packages without regard to C++ reserved words, resulting in entry
> points that can't conveniently be referenced in C++ using CNI.

That's right.  It should be fairly easy to fix this, though.

> Where can I find the "old" gcjh?  The current code is in Java, which
> presumably does *not* have the mapping:
> 
> http://cvs.savannah.gnu.org/viewvc/classpath/tools/gnu/classpath/tools/javah/?root=classpath

But this is easily fixable, as I pointed out in my previous massage.

The old gcjh is very out of date.  I'd just fix the current code.

Andrew.

Re: namespace namespace

[Sam Ruby]

Andrew Haley wrote:
> Sam Ruby wrote:
>> Bryce McKinlay wrote:
>>> On Tue, Jun 23, 2009 at 10:39 AM, Chris Burdess<dog@bluezoo.org> wrote:
>>>
>>>>> Some genius (?) has a namespace called "namespace" :-)
>>>> That would be Sun. And in Java "namespace" is not a keyword so it's a
>>>> perfectly legal package name.
>> namespace also happens to be the name of a concept in XML...
>>
>>>>> I think you'll have to edit the header file by hand.
>> To what?  Specifically, what should namespace "namespace" be mapped to?
> 
>    namespace$
> 
>> It is beginning to appear to me that gcj/g++ will do name mangling of
>> Java packages without regard to C++ reserved words, resulting in entry
>> points that can't conveniently be referenced in C++ using CNI.
> 
> That's right.  It should be fairly easy to fix this, though.

Just so that I'm clear: what you are saying is that *both* gcj/g++ and 
gcjh need to be fixed.

I believe that doing such, while necessary, would break the binary 
interface: in particular code which is compiled today to call into JAXP 
would not work with new versions of JAXP that are compiled with a 
version of gcj/g++ which has this fix.

Is that OK?

>> Where can I find the "old" gcjh?  The current code is in Java, which
>> presumably does *not* have the mapping:
>>
>> http://cvs.savannah.gnu.org/viewvc/classpath/tools/gnu/classpath/tools/javah/?root=classpath
> 
> But this is easily fixable, as I pointed out in my previous massage.
> 
> The old gcjh is very out of date.  I'd just fix the current code.

Is that "I'd" or "I'll" :-)

Is there something more I can provide?  Will gcj/g++ also be fixed?

> Andrew.

- Sam Ruby

Re: namespace namespace

[Bryce McKinlay]

> Just so that I'm clear: what you are saying is that *both* gcj/g++ and gcjh
> need to be fixed.

gcj already does proper mangling, or at least it should - see gcc/java/mangle.c

> I believe that doing such, while necessary, would break the binary
> interface: in particular code which is compiled today to call into JAXP
> would not work with new versions of JAXP that are compiled with a version of
> gcj/g++ which has this fix.

This isn't an issue for Java code. Code compiled with
--indirect-dispatch does not use C++ symbols for linking.

Bryce

Re: namespace namespace

[Andrew Haley]

Sam Ruby wrote:
> Andrew Haley wrote:
>> Sam Ruby wrote:
>>> Bryce McKinlay wrote:
>>>> On Tue, Jun 23, 2009 at 10:39 AM, Chris Burdess<dog@bluezoo.org> wrote:
>>>>
>>>>>> Some genius (?) has a namespace called "namespace" :-)
>>>>> That would be Sun. And in Java "namespace" is not a keyword so it's a
>>>>> perfectly legal package name.
>>> namespace also happens to be the name of a concept in XML...
>>>
>>>>>> I think you'll have to edit the header file by hand.
>>> To what?  Specifically, what should namespace "namespace" be mapped to?
>>
>>    namespace$
>>
>>> It is beginning to appear to me that gcj/g++ will do name mangling of
>>> Java packages without regard to C++ reserved words, resulting in entry
>>> points that can't conveniently be referenced in C++ using CNI.
>>
>> That's right.  It should be fairly easy to fix this, though.
> 
> Just so that I'm clear: what you are saying is that *both* gcj/g++ and
> gcjh need to be fixed.

If you want to be able to access namespace namespace from CNI, yes.

> I believe that doing such, while necessary, would break the binary
> interface: in particular code which is compiled today to call into JAXP
> would not work with new versions of JAXP that are compiled with a
> version of gcj/g++ which has this fix.
> 
> Is that OK?

Yes.

>>> Where can I find the "old" gcjh?  The current code is in Java, which
>>> presumably does *not* have the mapping:
>>>
>>> http://cvs.savannah.gnu.org/viewvc/classpath/tools/gnu/classpath/tools/javah/?root=classpath
>>
>> But this is easily fixable, as I pointed out in my previous massage.
>>
>> The old gcjh is very out of date.  I'd just fix the current code.
> 
> Is that "I'd" or "I'll" :-)

I'd.

> Is there something more I can provide?  Will gcj/g++ also be fixed?

Well, I already suggested how you might fix gcjh.  It's a matter of
whether you want to be able to access namespace namespace from CNI or
merely not have header files that choke C++.  Why not try the fix?

Do you really need CNI access to namespace namespace ?

Andrew.

Re: namespace namespace

[Sam Ruby]

Andrew Haley wrote:
> Sam Ruby wrote:
>> Andrew Haley wrote:
>>> Sam Ruby wrote:
>>>> Bryce McKinlay wrote:
>>>>> On Tue, Jun 23, 2009 at 10:39 AM, Chris Burdess<dog@bluezoo.org> wrote:
>>>>>
>>>>>>> Some genius (?) has a namespace called "namespace" :-)
>>>>>> That would be Sun. And in Java "namespace" is not a keyword so it's a
>>>>>> perfectly legal package name.
>>>> namespace also happens to be the name of a concept in XML...
>>>>
>>>>>>> I think you'll have to edit the header file by hand.
>>>> To what?  Specifically, what should namespace "namespace" be mapped to?
>>>    namespace$
>>>
>>>> It is beginning to appear to me that gcj/g++ will do name mangling of
>>>> Java packages without regard to C++ reserved words, resulting in entry
>>>> points that can't conveniently be referenced in C++ using CNI.
>>> That's right.  It should be fairly easy to fix this, though.
>> Just so that I'm clear: what you are saying is that *both* gcj/g++ and
>> gcjh need to be fixed.
> 
> If you want to be able to access namespace namespace from CNI, yes.
> 
>> I believe that doing such, while necessary, would break the binary
>> interface: in particular code which is compiled today to call into JAXP
>> would not work with new versions of JAXP that are compiled with a
>> version of gcj/g++ which has this fix.
>>
>> Is that OK?
> 
> Yes.
> 
>>>> Where can I find the "old" gcjh?  The current code is in Java, which
>>>> presumably does *not* have the mapping:
>>>>
>>>> http://cvs.savannah.gnu.org/viewvc/classpath/tools/gnu/classpath/tools/javah/?root=classpath
>>> But this is easily fixable, as I pointed out in my previous massage.
>>>
>>> The old gcjh is very out of date.  I'd just fix the current code.
>> Is that "I'd" or "I'll" :-)
> 
> I'd.

OK, so you would.  The next question is who will?

>> Is there something more I can provide?  Will gcj/g++ also be fixed?
> 
> Well, I already suggested how you might fix gcjh.  It's a matter of
> whether you want to be able to access namespace namespace from CNI or
> merely not have header files that choke C++.  Why not try the fix?

For the moment, I'm doing the equivalent of sed scripts to post process 
the header files (actually, I'm using Ruby -pi -e).

I can certainly fix gcjh locally, but I want to share my results with 
others, and ultimately the fix should go into cvs.  I'm certainly 
willing to do my share of the work, but you already identified the 
actual fix.  What's the next step?

> Do you really need CNI access to namespace namespace ?

What I am working on is the a Ruby extension that calls out to a HTML 5 
parser that happens to be written in Java and exposes a JAXP interface. 
  Along the way, I will have a need to create and access, via CNI, 
objects of the type javax::xml::namespace::QName.  I didn't create that 
class, nor can I change it.

http://intertwingly.net/blog/2009/06/23/Validator-Nu-on-GCJ-Update

> Andrew.

- Sam Ruby

Re: namespace namespace

[Andrew Haley]

Sam Ruby wrote:
> Andrew Haley wrote:
>> Sam Ruby wrote:

>>> Is there something more I can provide?  Will gcj/g++ also be fixed?
>>
>> Well, I already suggested how you might fix gcjh.  It's a matter of
>> whether you want to be able to access namespace namespace from CNI or
>> merely not have header files that choke C++.  Why not try the fix?
> 
> For the moment, I'm doing the equivalent of sed scripts to post process
> the header files (actually, I'm using Ruby -pi -e).
> 
> I can certainly fix gcjh locally, but I want to share my results with
> others, and ultimately the fix should go into cvs.  I'm certainly
> willing to do my share of the work, but you already identified the
> actual fix.  What's the next step?

Someone must apply the change, make a patch, and test the results.

>> Do you really need CNI access to namespace namespace ?
> 
> What I am working on is the a Ruby extension that calls out to a HTML 5
> parser that happens to be written in Java and exposes a JAXP interface.
>  Along the way, I will have a need to create and access, via CNI,
> objects of the type javax::xml::namespace::QName.  I didn't create that
> class, nor can I change it.
> 
> http://intertwingly.net/blog/2009/06/23/Validator-Nu-on-GCJ-Update

OK, I see.  I was wondering whether this was a theoretical problem that
might just come up or something real.  I was also wondering whether this
was relevant to free software.

Given that this looks real, and it is relevant to free software, I can
have a look.  However, I can't go back in time, so any change that I make
will not affect the gcj that's in distros for some time to come.

Andrew.

Re: namespace namespace

[Sam Ruby]

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

Andrew Haley wrote:
> Sam Ruby wrote:
>> Andrew Haley wrote:
>>> Sam Ruby wrote:
> 
>>>> Is there something more I can provide?  Will gcj/g++ also be fixed?
>>> Well, I already suggested how you might fix gcjh.  It's a matter of
>>> whether you want to be able to access namespace namespace from CNI or
>>> merely not have header files that choke C++.  Why not try the fix?
>> For the moment, I'm doing the equivalent of sed scripts to post process
>> the header files (actually, I'm using Ruby -pi -e).
>>
>> I can certainly fix gcjh locally, but I want to share my results with
>> others, and ultimately the fix should go into cvs.  I'm certainly
>> willing to do my share of the work, but you already identified the
>> actual fix.  What's the next step?
> 
> Someone must apply the change, make a patch, and test the results.

Hopefully the attached test case will help?

I will confess that I don't feel confident enough to dive into the code 
and work out a suitable patch to the namespace mangling portion of the 
g++ compiler.  Proposing a patch to gcjh is something I could have 
handled, but you already have done the bulk of this work.

>>> Do you really need CNI access to namespace namespace ?
>> What I am working on is the a Ruby extension that calls out to a HTML 5
>> parser that happens to be written in Java and exposes a JAXP interface.
>>  Along the way, I will have a need to create and access, via CNI,
>> objects of the type javax::xml::namespace::QName.  I didn't create that
>> class, nor can I change it.
>>
>> http://intertwingly.net/blog/2009/06/23/Validator-Nu-on-GCJ-Update
> 
> OK, I see.  I was wondering whether this was a theoretical problem that
> might just come up or something real.  I was also wondering whether this
> was relevant to free software.

I discovered this bug trying to use the classes provided with libgcj for 
the purposes that these classes were intended.  My code is public and 
(if successful) will be a part of a package which is made available 
under a MIT license.

> Given that this looks real, and it is relevant to free software, I can
> have a look.  However, I can't go back in time, so any change that I make
> will not affect the gcj that's in distros for some time to come.

Understood.  But "download and build the latest" is still marked 
progress over "merge this patch, built it, and hope it works".  And 
within a year or so of being committed the fix should be in the 
distributions I care about.  Meanwhile, I have workarounds.

> Andrew.

- Sam Ruby

[-- Attachment #2: testqname.sh --]
[-- Type: application/x-sh, Size: 1293 bytes --]

Re: namespace namespace

[Bryce McKinlay]

On Wed, Jun 24, 2009 at 12:52 PM, Sam Ruby<rubys@intertwingly.net> wrote:

> I will confess that I don't feel confident enough to dive into the code and
> work out a suitable patch to the namespace mangling portion of the g++
> compiler.  Proposing a patch to gcjh is something I could have handled, but
> you already have done the bulk of this work.

Just to be clear, there's no need to change anything in g++. It's just
gcj and gcjh that need to agree on the mangling.

Bryce

Re: namespace namespace

[Andrew Haley]

Sam Ruby wrote:
> Andrew Haley wrote:
>> Sam Ruby wrote:
>>> Andrew Haley wrote:
>>>> Sam Ruby wrote:
>>
>>>>> Is there something more I can provide?  Will gcj/g++ also be fixed?
>>>> Well, I already suggested how you might fix gcjh.  It's a matter of
>>>> whether you want to be able to access namespace namespace from CNI or
>>>> merely not have header files that choke C++.  Why not try the fix?
>>> For the moment, I'm doing the equivalent of sed scripts to post process
>>> the header files (actually, I'm using Ruby -pi -e).
>>>
>>> I can certainly fix gcjh locally, but I want to share my results with
>>> others, and ultimately the fix should go into cvs.  I'm certainly
>>> willing to do my share of the work, but you already identified the
>>> actual fix.  What's the next step?
>>
>> Someone must apply the change, make a patch, and test the results.
> 
> Hopefully the attached test case will help?
> 
> I will confess that I don't feel confident enough to dive into the code
> and work out a suitable patch to the namespace mangling portion of the
> g++ compiler.  Proposing a patch to gcjh is something I could have
> handled, but you already have done the bulk of this work.

OK.

> I discovered this bug trying to use the classes provided with libgcj for
> the purposes that these classes were intended.  My code is public and
> (if successful) will be a part of a package which is made available
> under a MIT license.

OK, so it's worth my time fixing this.

>> Given that this looks real, and it is relevant to free software, I can
>> have a look.  However, I can't go back in time, so any change that I make
>> will not affect the gcj that's in distros for some time to come.
> 
> Understood.  But "download and build the latest" is still marked
> progress over "merge this patch, built it, and hope it works".  And
> within a year or so of being committed the fix should be in the
> distributions I care about.  Meanwhile, I have workarounds.

I've spent a little while this morning looking at this.  gcj's name
mangling logic is broken: it doesn't detect C++ keywords everywhere, just
in member names.  Even when it does find a C++ keyword and attempts
to append '$' it does so incorrectly, and generates an illegal mangled
name.  There's no way that any of this can ever have worked.

I'll fix it.

Andrew.