Re: Java Patches: -fno-org-xml-sax and -fno-org-w3c-dom

Re: Java Patches: -fno-org-xml-sax and -fno-org-w3c-dom

[Jeff Sturm]

On 30 Nov 2002, Anthony Green wrote:
> We recently discussed moving org.xml.sax and org.w3c.dom into their own
> shared libraries, and adding a compiler flag to turn off linking them in
> by default.  After some reflection it seems like a single flag isn't
> really a good idea.  The -fno-jaxp idea isn't really workable as jaxp
> will change over time.  The scheme implemented below seems flexible
> enough...

What would be the harm in _not_ linking these libraries by default?

With this patch, I either have to alter all my makefiles, or accept that
each binary I link requires two new DSOs.

Alternatively, if -l-org-xml-sax and -l-org-w3c-dom aren't linked
automatically, existing binaries are unaffected and no front-end changes
are required.  Those who need the libraries can just add the linker flags
(or use xerces).

In any case I think breaking org.xml and org.w3c out of libgcj.so is a
great idea.

> + org/xml/sax/helpers/NewInstance.java \

BTW this class doesn't appear to be in the tree.

Jeff

Re: Java Patches: -fno-org-xml-sax and -fno-org-w3c-dom

[Per Bothner]

Anthony Green wrote:

> We recently discussed moving org.xml.sax and org.w3c.dom into their own
> shared libraries,

That makes sense, though it might make sense to put them in
a single shared library.

>  and adding a compiler flag to turn off linking them in
> by default. 

This is not OK, IMO.  It's a bad precedent.  We can't keep
adding random flags for specific packages.

First, note it's not just linking, but also compiling - i.e.
controlling which jar(s) that the compiler searches.  By
default the compiler should search the jars in the extension
directory.

Secondly, I think the choice as to which shared library to
link should parallel which jars are compiled against.  If the
compilation classpath options causes the standard sax/dom jars
(in the standard extension directory) to be searched, then the
linker should link against the standard sax/dom shared library(ies),
and only then.

Command line flags are evil, and unnecessary in this case.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: Java Patches: -fno-org-xml-sax and -fno-org-w3c-dom

[Anthony Green]

On Sun, 2002-12-01 at 09:55, Jeff Sturm wrote:
> Alternatively, if -l-org-xml-sax and -l-org-w3c-dom aren't linked
> automatically, existing binaries are unaffected and no front-end changes
> are required.  Those who need the libraries can just add the linker flags
> (or use xerces)

This goes against one of our unwritten rules, which is that JDK-like
behaviour should not require extra flags.  Is it time to revisit this?
And then what would be the next libraries we'd want to pull out?  AWT? 
Where would we stop?   We don't want to make this difficult to use.

> In any case I think breaking org.xml and org.w3c out of libgcj.so is a
> great idea.
> 
> > + org/xml/sax/helpers/NewInstance.java \
> 
> BTW this class doesn't appear to be in the tree.

Sorry! This patch builds onto my org.xml.sax refresher patch, which is
awaiting approval...

	http://gcc.gnu.org/ml/java-patches/2002-q4/msg00323.html

AG

Re: Java Patches: -fno-org-xml-sax and -fno-org-w3c-dom

[Anthony Green]

On Sun, 2002-12-01 at 10:07, Per Bothner wrote:
> That makes sense, though it might make sense to put them in
> a single shared library.

I like these two libraries, because if you don't add them at link time
libgcj will still be able to find them at runtime via Class.forName().

> This is not OK, IMO.  It's a bad precedent.  We can't keep
> adding random flags for specific packages.

Oh - I thought you had recently agreed to something like this on the
java list.

> First, note it's not just linking, but also compiling - i.e.
> controlling which jar(s) that the compiler searches.  By
> default the compiler should search the jars in the extension
> directory.

gcj does search the extension directory.

> Secondly, I think the choice as to which shared library to
> link should parallel which jars are compiled against.  If the
> compilation classpath options causes the standard sax/dom jars
> (in the standard extension directory) to be searched, then the
> linker should link against the standard sax/dom shared library(ies),
> and only then.

Well, what would you propose then?  Newer versions of Xerces (and
Tomcat, Xalan, etc) are unbuildable right now, so I would like to fix
this quickly.  Perhaps the simplest thing is to do what Jeff suggests
and never link these by default.

AG

Re: Java Patches: -fno-org-xml-sax and -fno-org-w3c-dom

[Per Bothner]

Anthony Green wrote:

> I like these two libraries, because if you don't add them at link time
> libgcj will still be able to find them at runtime via Class.forName().

That's a good reason.

> >This is not OK, IMO.  It's a bad precedent.  We can't keep
> >adding random flags for specific packages.
>
> Oh - I thought you had recently agreed to something like this on the
> java list.

Then I must have been unclear.  I've had and expressed the "vision"
below for quite a while.

> Well, what would you propose then?  Newer versions of Xerces (and
> Tomcat, Xalan, etc) are unbuildable right now, so I would like to fix
> this quickly.  Perhaps the simplest thing is to do what Jeff suggests
> and never link these by default.

I think that is an acceptable short-term solution.

The "correct" solution (assuming we come to consensus that this is
a good idea):

* When the compiler emits a reference to a class that it found in a
jar in an extension directory, it remembers the name of the jar.
(If "emits a reference" is difficult to implement, then alternatively
"resolves a classname to a class in the jar" is ok.)  This should
not be difficult to implement.

* At the end of the compilation, it mangles the jar file name
(without the directory) to a linker library name.  So
"org-xml-sax.jar" becomes "-lorg-xml-sax" or whatever.  This
gets emitted in a special ELF section.  (I don't care about
non-ELF targets for this feature.)  This is also easy to
implement.

* The linker reads the special ELF sections of the linked files,
and addes the linker library names as implicit libraries to search.
(When building a shared library, it combines the lists.)

The last part is the hard part.  However, I have a feeling that
ELF linkers may already support this feature - it is certainly a
very nice feature, not just for Java.  (I know there are hooks to
remember -R flags in executables, which is a related concept.)
Could you discuss this with some linker/ELF experts either at
Red Hat or on the binutils mailing list?

I have two goals, which this satisfies:
(1) Don't have to specify any flags or paths for classes found in
the default locations.
(2) If an explicit path is used to override the default extension
jars, that should also override the searched shared libraries.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: Java Patches: -fno-org-xml-sax and -fno-org-w3c-dom

[Jeff Sturm]

On 1 Dec 2002, Anthony Green wrote:
> On Sun, 2002-12-01 at 09:55, Jeff Sturm wrote:
> > Alternatively, if -l-org-xml-sax and -l-org-w3c-dom aren't linked
> > automatically, existing binaries are unaffected and no front-end changes
> > are required.  Those who need the libraries can just add the linker flags
> > (or use xerces)
>
> This goes against one of our unwritten rules, which is that JDK-like
> behaviour should not require extra flags.  Is it time to revisit this?

Yeah, that's a hard problem.

I'll re-read Per's ideas.  I also like runtime linking via libltdl, *if*
we can avoid the class symbol references that cause undefined symbols at
link time.  Ideally instead of a link failure you'd have a
ClassNotFoundException at runtime, just like the JDK.

Perhaps I'll investigate why -fno-assume-compiled doesn't work.

Jeff

Re: Java Patches: -fno-org-xml-sax and -fno-org-w3c-dom

[Tom Tromey]

>>>>> "Anthony" == Anthony Green <green@redhat.com> writes:

Anthony> There are two sets of patches below.  Ok?

I won't have time to deal with this patch before the holidays.

If you want to, feel free to check in the libgcj part.  If you do
that, please update the manual to reflect the need for the new `-l'
options.

Tom

Re: Java Patches: -fno-org-xml-sax and -fno-org-w3c-dom

[Anthony Green]

On Fri, 2002-12-20 at 14:08, Tom Tromey wrote:
> If you want to, feel free to check in the libgcj part.  If you do
> that, please update the manual to reflect the need for the new `-l'
> options.

Done.. to both branch and trunk.  Thanks.


2002-12-22  Anthony Green  <green@redhat.com>

	* gcj.texi (Limitations): Add note about org.xml.sax and
	org.w3c.dom.

Index: gcj.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/gcj.texi,v
retrieving revision 1.43
diff -2 -c -p -r1.43 gcj.texi
*** gcj.texi	16 Dec 2002 21:59:43 -0000	1.43
--- gcj.texi	22 Dec 2002 16:43:39 -0000
*************** from the JDK implementation.  This is no
*** 516,519 ****
--- 516,530 ----
  affects you, it probably makes sense to report it so that we can discuss
  the appropriate response.
+ 
+ @item
+ @command{gcj} does not currently allow for piecemeal replacement of
+ components within @code{libgcj}. Unfortunately, programmers often want
+ to use newer versions of certain packages, such as those provided by
+ the Apache Software Foundation's Jakarta project.  This has forced us
+ to place the @code{org.w3c.dom} and @code{org.xml.sax} packages into
+ their own libraries, separate from @code{libgcj}.  If you intend to
+ use these classes, you must link them explicitly with
+ @code{-l-org-w3c-dom} and @code{-l-org-xml-sax}.  Future versions of
+ @command{gcj} may not have this restriction.
  @end itemize