0.95 branch created
Hi, A release branch has been created 'classpath-0_95-branch' I'll try to pick up any fixes made on the trunk, but if you feel some patch is release critical please do CC me. Mauve results and smoke tests (examples, eclipse, swingset & 2d demo, jboss, jfreechart) look pretty good. There are some docs generated with sinjdoc at http://developer.classpath.org/sinjdoc/ (it doesn't look as good as the old gjdoc ones and it is missing support for -linksource, -licensetext, -validhtml, and @Link support in comments, but has to do for now). Build has been cleaned up to better detect various browser plugin environments and automake 1.10 systems (although Dalibor has some cleanups and documentation pending). It looks pretty good to me, but if there are still bugs you want to get fixed then now would be the time to do it! If cleanups and testing go well over the weekend/easter we will hopefully have a release by Tuesday. And if you did something cool for this release make sure you have updated the NEWS file! Mauve regressions that should be fixed/investigated: FAIL: gnu.java.security.jce.TestOfHttps FAIL: java.net.URLConnection.getHeaderFields (Seems to have to do something with how we handle the cacerts file) FAIL: javax.swing.TransferHandler.createTransferable (I thought this was fixed with Francis latest patch, but builder still has trouble with it for some reason) FAIL: javax.swing.table.JTableHeader.AccessibleJTableHeader.AccessibleJTableHeaderEntry.getFont (Not investigated yet) Also I am seeing some out of memory issues with images in some applications that needs looking into. Cheers, Mark signature.asc Description: This is a digitally signed message part
RE: 0.95 branch created
Mark Wielaard wrote: > A release branch has been created 'classpath-0_95-branch' Shouldn't that have been 0.94? > I'll try to pick up any fixes made on the trunk, but if you feel some > patch is release critical please do CC me. I'd really like to see the removal of the META-INF/services/*xml* go in. The inclusion of these resources breaks a lot of code (e.g. virtually everything that relies on Xalan or Xerces). Regards, Jeroen
Re: 0.95 branch created
On Apr 6, 2007, at 3:51 PM, Mark Wielaard wrote: Mauve regressions that should be fixed/investigated: FAIL: gnu.java.security.jce.TestOfHttps FAIL: java.net.URLConnection.getHeaderFields (Seems to have to do something with how we handle the cacerts file) Undoubtedly, yes. The best way to fix this is likely going to be just creating a TrustManager for Mauve that only returns whatever cert the test server it connects to is using, instead of trying to mess around with a real cacerts file. Thanks.
RE: 0.95 branch created
On Sat, 2007-04-07 at 08:03 +0200, Jeroen Frijters wrote: > Mark Wielaard wrote: > > A release branch has been created 'classpath-0_95-branch' > > Shouldn't that have been 0.94? Yeah, the branch was created, then I realized my mistake. But the revisionist history is that 0.95 is such a huge step forward (and so late) that it deserves a 0.02 version bumb. And it ends in a 5 which shows our commitment to 1.5+ from here on. :) > > I'll try to pick up any fixes made on the trunk, but if you feel some > > patch is release critical please do CC me. > > I'd really like to see the removal of the META-INF/services/*xml* go in. Yes, that seems like a good idea. libgcj also did I believe that and the fallbacks are in place. Besides the four service files you mention they also remove the following 2 though: META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory META-INF/services/org.w3c.dom.DOMImplementationSourceList The first has always (more than a year been there when Chris added relaxng support, second was added a few weeks ago by Gary. Should these also not be there? The rule being if it is a service in the core classes we default to in in code not through service files? Then what about the prefs and sound ones? Cheers, Mark signature.asc Description: This is a digitally signed message part
RE: 0.95 branch created
Il giorno sab, 07/04/2007 alle 12.39 +0200, Mark Wielaard ha scritto: > Should these also not be there? The rule being if it is a service in the > core classes we default to in in code not through service files? > > Then what about the prefs and sound ones? I think that the preference is safe to be there (but I'm not so lazy, if we really want to change it...), as for the sound providers, my idea is to use the same sequence I used in the Desktop API (this may not be always applicable): 1. Check for a system property 2. If no system property is defined, check in the user (or system?) preferences 3. If nothing is found, revert to a default. This can be hardcoded, or we can use the service file, or do whatever we like :). > Cheers, > > Mark Ciao! Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Jabber: [EMAIL PROTECTED] - Profile: http://www.gtalkprofile.com/profile/9661.html pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ signature.asc Description: Questa รจ una parte del messaggio firmata digitalmente
RE: 0.95 branch created
Mark Wielaard wrote: > On Sat, 2007-04-07 at 08:03 +0200, Jeroen Frijters wrote: > > I'd really like to see the removal of the META-INF/services/*xml* go > in. > > Yes, that seems like a good idea. libgcj also did I believe that and > the fallbacks are in place. Besides the four service files you mention > they also remove the following 2 though: > > META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory > META-INF/services/org.w3c.dom.DOMImplementationSourceList > > The first has always (more than a year been there when Chris added > relaxng support, second was added a few weeks ago by Gary. Yeah, I wasn't sure about these two (I don't know very much about all the xml apis, so I was being conservative and requesting to at least remove the ones that I have personally seen cause problems), but if libgcj removed them we probably should too. > Should these also not be there? The rule being if it is a service in > the core classes we default to in in code not through service files? Unfortunately it's not that simple. For example, the sound ones *are* in the JDK (at least the "javax.sound.midi.spi.MidiDeviceProvider" one I tried). I don't know if that means they are required to be there, but I assume it makes the code easier because I also assume that the service api support reading multiple services files. It's just that this method isn't always applicable (like with the xml stuff), because there isn't always a way to determine which implementation is "best" or to merge them. Regards, Jeroen
RE: 0.95 branch created
Hi, On Sat, 2007-04-07 at 17:48 +0200, Jeroen Frijters wrote: > Yeah, I wasn't sure about these two (I don't know very much about all > the xml apis, so I was being conservative and requesting to at least > remove the ones that I have personally seen cause problems), but if > libgcj removed them we probably should too. OK, I did some quick test runs with this patch and will commit it to trunk and the release branch: 2007-04-07 Mark Wielaard <[EMAIL PROTECTED]> * resource/META-INF/services/javax.xml.parsers.DocumentBuilderFactor, resource/META-INF/services/javax.xml.parsers.SAXParserFactory, resource/META-INF/services/javax.xml.parsers.TransformerFactory, resource/META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory, resource/META-INF/services/org.w3c.dom.DOMImplementationSourceList, resource/META-INF/services/org.xml.sax.driver: Removed. Cheers, Mark Index: resource/META-INF/services/javax.xml.parsers.DocumentBuilderFactory === RCS file: resource/META-INF/services/javax.xml.parsers.DocumentBuilderFactory diff -N resource/META-INF/services/javax.xml.parsers.DocumentBuilderFactory --- resource/META-INF/services/javax.xml.parsers.DocumentBuilderFactory 25 May 2005 22:26:30 - 1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1 +0,0 @@ -gnu.xml.dom.DomDocumentBuilderFactory Index: resource/META-INF/services/javax.xml.parsers.SAXParserFactory === RCS file: resource/META-INF/services/javax.xml.parsers.SAXParserFactory diff -N resource/META-INF/services/javax.xml.parsers.SAXParserFactory --- resource/META-INF/services/javax.xml.parsers.SAXParserFactory 27 Dec 2005 19:56:16 - 1.4 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1 +0,0 @@ -gnu.xml.stream.SAXParserFactory Index: resource/META-INF/services/javax.xml.parsers.TransformerFactory === RCS file: resource/META-INF/services/javax.xml.parsers.TransformerFactory diff -N resource/META-INF/services/javax.xml.parsers.TransformerFactory --- resource/META-INF/services/javax.xml.parsers.TransformerFactory 25 May 2005 22:26:30 - 1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1 +0,0 @@ -gnu.xml.transform.TransformerFactoryImpl Index: resource/META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory === RCS file: resource/META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory diff -N resource/META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory --- resource/META-INF/services/org.relaxng.datatype.DatatypeLibraryFactory 13 Feb 2006 19:27:24 - 1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1 +0,0 @@ -gnu.xml.validation.datatype.TypeLibraryFactory Index: resource/META-INF/services/org.w3c.dom.DOMImplementationSourceList === RCS file: resource/META-INF/services/org.w3c.dom.DOMImplementationSourceList diff -N resource/META-INF/services/org.w3c.dom.DOMImplementationSourceList --- resource/META-INF/services/org.w3c.dom.DOMImplementationSourceList 7 Mar 2007 13:30:26 - 1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1 +0,0 @@ -gnu.xml.dom.ImplementationSource Index: resource/META-INF/services/org.xml.sax.driver === RCS file: resource/META-INF/services/org.xml.sax.driver diff -N resource/META-INF/services/org.xml.sax.driver --- resource/META-INF/services/org.xml.sax.driver 29 Dec 2005 09:14:20 - 1.2 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1 +0,0 @@ -gnu.xml.stream.SAXParser
Re: 0.95 branch created
On Sat, 2007-04-07 at 00:51 +0200, Mark Wielaard wrote: > FAIL: javax.swing.TransferHandler.createTransferable > (I thought this was fixed with Francis latest patch, but builder still > has trouble with it for some reason) This has nothing to do with the issue that Francis fixed (that is properly fixed). This is because of a bug introduced in cacao that doesn't do a proper access check and lets the test (indirectly) invoke a method that it shouldn't be able to access. It was introduced in cacao by: r7418 | twisti | 2007-02-28 21:07:06 +0100 (Wed, 28 Feb 2007) Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: 0.95 branch created
Hi, > FAIL: javax.swing.TransferHandler.createTransferable > (I thought this was fixed with Francis latest patch, but builder still > has trouble with it for some reason) > > FAIL: > javax.swing.table.JTableHeader.AccessibleJTableHeader.AccessibleJTableHeaderEntry.getFont > (Not investigated yet) I'll take care of those Swing issues ASAP. /Roman -- http://kennke.org/blog/
Re: 0.95 branch created
On Sat, 2007-04-07 at 23:49 +0200, Mark Wielaard wrote: > On Sat, 2007-04-07 at 00:51 +0200, Mark Wielaard wrote: > > FAIL: javax.swing.TransferHandler.createTransferable > > (I thought this was fixed with Francis latest patch, but builder still > > has trouble with it for some reason) > > This has nothing to do with the issue that Francis fixed (that is > properly fixed). This is because of a bug introduced in cacao that > doesn't do a proper access check and lets the test (indirectly) invoke a > method that it shouldn't be able to access. It was introduced in cacao > by: r7418 | twisti | 2007-02-28 21:07:06 +0100 (Wed, 28 Feb 2007) Grrr, I hate this access checks. I'll try to fix that _again_. - twisti
Re: 0.95 branch created
Hi Mark. On Sat, 2007-04-07 at 00:51 +0200, Mark Wielaard wrote: > A release branch has been created 'classpath-0_95-branch' Can the latest build of the release candidate be made available for download on builder.classpath.org as it was for the previous releases? I think it would help those who want to test but don't stay up to date with CVS. Thanks, Paul -- Paul Jenner <[EMAIL PROTECTED]>
Re: 0.95 branch created
Hi Paul, On Tue, 2007-04-10 at 13:57 +0100, Paul Jenner wrote: > On Sat, 2007-04-07 at 00:51 +0200, Mark Wielaard wrote: > > A release branch has been created 'classpath-0_95-branch' > > Can the latest build of the release candidate be made available for > download on builder.classpath.org as it was for the previous releases? > > I think it would help those who want to test but don't stay up to date > with CVS. Good point. I activated the ClasspathRelease script on builder that should produce a tar.gz for the release candidate (classpath-0.95-rc.tar.gz) at http://builder.classpath.org/dist/ Also checked the normal script and re-enabled to creation of classpath-latest.tar.gz. Don't know why that was disabled. But it is fixed now (I hope, please yell and scream if it isn't refreshed in the next 24 hours). Thanks, Mark signature.asc Description: This is a digitally signed message part
Re: 0.95 branch created
On Sat, 2007-04-07 at 00:51 +0200, Mark Wielaard wrote: > Hi, > > A release branch has been created 'classpath-0_95-branch' > I'll try to pick up any fixes made on the trunk, but if you feel some > patch is release critical please do CC me. As with any release, I have a build failure on IRIX: $ uname -a IRIX64 fp98 6.5 07141529 IP27 mips cc -64 -D__MIPSEB__ -DHAVE_CONFIG_H -I. -I. -I../../../include -I../../../include -I../../../native/jni/classpath -I../../../native/jni/native-lib -g -c cpnet.c -Wp,-MDupdate,.deps/cpnet.TPlo -DPIC -o .libs/cpnet.o cc-1164 cc: WARNING File = cpnet.c, Line = 640 Argument of type "struct hostent **" is incompatible with parameter of type "int *". ret = gethostbyname_r (hostname, &hret, buf, buflen, &result, &herr); ^ cc-1136 cc: ERROR File = cpnet.c, Line = 640 Too many arguments in function call. ret = gethostbyname_r (hostname, &hret, buf, buflen, &result, &herr); ^ cc-1515 cc: ERROR File = cpnet.c, Line = 640 A value of type "struct hostent *" cannot be assigned to an entity of type "int". ret = gethostbyname_r (hostname, &hret, buf, buflen, &result, &herr); ^ 2 errors detected in the compilation of "cpnet.c". >From IRIX's manpage: struct hostent *gethostbyname_r(const char *name, struct hostent *hent, char *buffer, int bufsize, int *h_errnop); How should we handle that? - twisti
Re: 0.95 branch created
Il giorno mar, 10/04/2007 alle 23.47 +0200, Christian Thalinger ha
scritto:
> >From IRIX's manpage:
>
> struct hostent *gethostbyname_r(const char *name, struct hostent *hent, char
> *buffer, int bufsize, int *h_errnop);
>
> How should we handle that?
>
> - twisti
Ciao twisti!
I don't know if it help, but could you try the attached patch?
notte! :)
Mario
--
Lima Software - http://www.limasoftware.net/
GNU Classpath Developer - http://www.classpath.org/
Jabber: [EMAIL PROTECTED] - Profile:
http://www.gtalkprofile.com/profile/9661.html
pgp key: http://subkeys.pgp.net/
PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/
### Eclipse Workspace Patch 1.0
#P classpath
Index: native/jni/native-lib/cpnet.c
===
RCS file: /cvsroot/classpath/classpath/native/jni/native-lib/cpnet.c,v
retrieving revision 1.6
diff -u -r1.6 cpnet.c
--- native/jni/native-lib/cpnet.c 20 Jan 2007 03:24:19 - 1.6
+++ native/jni/native-lib/cpnet.c 10 Apr 2007 22:37:00 -
@@ -636,7 +636,15 @@
{
buf = (char *)JCL_malloc(env, buflen);
#ifdef HAVE_GETHOSTBYNAME_R
+
+# if defined(__sgi)
+ gethostbyname_r (hostname, &hret, buf, buflen, &result, &herr);
+ if (hret == NULL)
+ret = -1;
+# else
ret = gethostbyname_r (hostname, &hret, buf, buflen, &result, &herr);
+# endif /* defined(__sgi) */
+
#else
hret.h_addr_list = NULL;
hret.h_addrtype = 0;
Re: 0.95 branch created
On Wed, 2007-04-11 at 00:43 +0200, Mario Torre wrote: > Il giorno mar, 10/04/2007 alle 23.47 +0200, Christian Thalinger ha > scritto: > > > >From IRIX's manpage: > > > > struct hostent *gethostbyname_r(const char *name, struct hostent *hent, > > char *buffer, int bufsize, int *h_errnop); > > > > How should we handle that? > > > > - twisti > > Ciao twisti! > > I don't know if it help, but could you try the attached patch? Thanks for that! Dalibor told me there is a autoconf macro: http://autoconf-archive.cryp.to/ax_func_which_gethostbyname_r.html I think we should use that one. - twisti
Re: 0.95 branch created
Il giorno mer, 11/04/2007 alle 00.43 +0200, Mario Torre ha scritto:
> I don't know if it help, but could you try the attached patch?
Ehm... this patch, I mean [1]...
> notte! :)
Right... needed...!
Mario
[1] I got this from the Solaris 10 manpage, so I don't know if it apply
to IRIX too: "The gethostent() and gethostent_r() functions each return
a pointer to a struct hostent if they successfully enumerate an entry;
otherwise they return NULL, indicating the end of the enumeration...
When the pointer returned by the reentrant functions gethostbyname_r(),
gethostbyaddr_r(), and gethostent_r() is not NULL, it is always equal to
the result pointer that was supplied by the caller." See why I like to
work on Classpath?
--
Lima Software - http://www.limasoftware.net/
GNU Classpath Developer - http://www.classpath.org/
Jabber: [EMAIL PROTECTED] - Profile:
http://www.gtalkprofile.com/profile/9661.html
pgp key: http://subkeys.pgp.net/
PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/
### Eclipse Workspace Patch 1.0
#P classpath
Index: native/jni/native-lib/cpnet.c
===
RCS file: /cvsroot/classpath/classpath/native/jni/native-lib/cpnet.c,v
retrieving revision 1.6
diff -u -r1.6 cpnet.c
--- native/jni/native-lib/cpnet.c 20 Jan 2007 03:24:19 - 1.6
+++ native/jni/native-lib/cpnet.c 10 Apr 2007 22:54:38 -
@@ -636,7 +636,14 @@
{
buf = (char *)JCL_malloc(env, buflen);
#ifdef HAVE_GETHOSTBYNAME_R
+
+# if defined(__sgi)
+ if (gethostbyname_r(hostname, &hret, buf, buflen, &result, &herr) == NULL)
+ret = -1;
+# else
ret = gethostbyname_r (hostname, &hret, buf, buflen, &result, &herr);
+# endif /* defined(__sgi) */
+
#else
hret.h_addr_list = NULL;
hret.h_addrtype = 0;
Re: 0.95 branch created
Il giorno mer, 11/04/2007 alle 00.50 +0200, Christian Thalinger ha scritto: > http://autoconf-archive.cryp.to/ax_func_which_gethostbyname_r.html > > I think we should use that one. Cool! Ok so, I'll leave it for you then ;) > - twisti Night! Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Jabber: [EMAIL PROTECTED] - Profile: http://www.gtalkprofile.com/profile/9661.html pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/
Re: 0.95 branch created
Hi list. On Sat, 2007-04-07 at 00:51 +0200, Mark Wielaard wrote: > Mauve regressions that should be fixed/investigated: > > FAIL: gnu.java.security.jce.TestOfHttps > FAIL: java.net.URLConnection.getHeaderFields > (Seems to have to do something with how we handle the cacerts file) > > FAIL: javax.swing.TransferHandler.createTransferable > (I thought this was fixed with Francis latest patch, but builder still > has trouble with it for some reason) > > FAIL: > javax.swing.table.JTableHeader.AccessibleJTableHeader.AccessibleJTableHeaderEntry.getFont > (Not investigated yet) Comparing mauve results for 0.95-rc against 0.93, I also see: +FAIL: java.util.prefs.PreferenceTest +FAIL: org.omg.CORBA.ORB.parallelRunTest +FAIL: java.awt.Choice.PaintTest +FAIL: java.awt.Graphics.TestPaintGraphics +FAIL: java.awt.Canvas.PaintTest +FAIL: java.awt.TextField.PaintTest +FAIL: java.awt.Container.LightweightContainer +FAIL: java.awt.Checkbox.PaintTest +FAIL: java.awt.Robot.getPixelColor +FAIL: java.awt.Robot.mouseWheel +FAIL: java.awt.Robot.mouseMove +FAIL: java.awt.Robot.createScreenCapture +FAIL: java.awt.Robot.keyRelease Guess they could be local issues - is anyone else seeing those? Paul -- Paul Jenner <[EMAIL PROTECTED]>
Re: 0.95 branch created
Il giorno mer, 18/04/2007 alle 23.27 +0100, Paul Jenner ha scritto: > Hi list. > > On Sat, 2007-04-07 at 00:51 +0200, Mark Wielaard wrote: > > Mauve regressions that should be fixed/investigated: > > > Comparing mauve results for 0.95-rc against 0.93, I also see: > > +FAIL: java.util.prefs.PreferenceTest This one passes for me, and I think we have changed nothing on this code from 0.92. What configuration you have? Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Jabber: [EMAIL PROTECTED] - Profile: http://www.gtalkprofile.com/profile/9661.html pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/
Re: 0.95 branch created
+FAIL: java.util.prefs.PreferenceTest +FAIL: org.omg.CORBA.ORB.parallelRunTest +FAIL: java.awt.Choice.PaintTest +FAIL: java.awt.Graphics.TestPaintGraphics +FAIL: java.awt.Canvas.PaintTest +FAIL: java.awt.TextField.PaintTest +FAIL: java.awt.Container.LightweightContainer +FAIL: java.awt.Checkbox.PaintTest +FAIL: java.awt.Robot.getPixelColor +FAIL: java.awt.Robot.mouseMove +FAIL: java.awt.Robot.createScreenCapture +FAIL: java.awt.Robot.keyRelease All of these pass for me as well, with one exception. In general I've found robot / visual tests (as many of these are) are very finicky, and require that you not be using your computer at all while they are running. The one exception is: > +FAIL: java.awt.Robot.mouseWheel It seems that when I run this test the first time, it fails; then if I run it again without touching the mouse it passes... but if I move the mouse and then run it, again it fails. Francis
Re: 0.95 branch created
Hi, On Thu, 2007-04-19 at 12:58 -0400, Francis Kung wrote: > All of these pass for me as well, with one exception. In general I've > found robot / visual tests (as many of these are) are very finicky, and > require that you not be using your computer at all while they are running. Here too, but indeed they are a little fragile. Thanks for the extra testing! Cheers, Mark signature.asc Description: This is a digitally signed message part
RE: RE: 0.95 branch created
Jeroen Frijters wrote: > Mark Wielaard wrote: > > I'll try to pick up any fixes made on the trunk, but if you feel some > > patch is release critical please do CC me. > > I'd really like to see the removal of the META-INF/services/*xml* go > in. The inclusion of these resources breaks a lot of code (e.g. > virtually everything that relies on Xalan or Xerces). The ones in particular I'd like to remove (for now) are: META-INF/services/javax.xml.parsers.DocumentBuilderFactory META-INF/services/javax.xml.parsers.SAXParserFactory META-INF/services/javax.xml.parsers.TransformerFactory META-INF/services/org.xml.sax.driver I've confirmed that JDK 1.6 includes none of these and the corresponding factory methods[1] in GNU Classpath still work without these. Regards, Jeroen [1] The ones I tried are: javax.xml.parsers.DocumentBuilderFactory.newInstance() javax.xml.parsers.SAXParserFactory.newInstance() javax.xml.transform.TransformerFactory.newInstance() org.xml.sax.helpers.XMLReaderFactory.createXMLReader()
