gmane.comp.java.classpath.patches

FYI: Add generics to gnu.xml.transform.Bindings

Andrew John Hughes — 2008-11-16T20:29:49

Adding generics to Bindings in preparation for fixing PR classpath/38147. ChangeLog: 2008-11-16 Andrew John Hughes member.fsf.org> * gnu/xml/transform/Bindings.java: Add generics to collections.

FYI: Improve exception output from crypto key selection

Andrew John Hughes — 2008-11-16T02:56:17

The exception for key selection reports an invalid key sizes, but doesn't report what key sizes are valid. ChangeLog: 2008-11-16 Andrew John Hughes member.fsf.org> * gnu/javax/crypto/jce/key/SecretKeyGeneratorImpl.java: (init(int,SecureRandom)): Improve exception message.

Patch: FYI: AIX fixlet in fdlibm.h

Tom Tromey — 2008-10-24T15:25:10

I'm checking this in. This comes from a GCC maintainer. fdlibm fails to build on AIX because 'hz' is defined in some system header there. This patch works around the problem by undeffing hz. Tom ChangeLog: 2008-10-23 David Edelsohn gnu.org> * native/fdlibm/fdlibm.h: Undef hz. Index: native/fdlibm/fdlibm.h =================================================================== RCS file: /cvsroot/classpath/classpath/native/fdlibm/fdlibm.h,v retrieving revision 1.15 diff -u -r1.15 fdlibm.h --- native/fdlibm/fdlibm.h13 Sep 2007 19:39:42 -00001.15 +++ native/fdlibm/fdlibm.h24 Oct 2008 15:23:55 -0000 < at >< at > -24,6 +24,14 < at >< at > #include #include +/* + * AIX includes a header that defines hz, + * which conflicts with an fdlibm variable in some functions. + */ +#ifdef _AIX +#undef hz +#endif + /* GCJ LOCAL: Include files. */ #include "ieeefp.h" /* CLASSPATH LOCAL: */

FYI: More ANTLR fixes

Andrew John Hughes — 2008-10-20T22:06:46

This patch fixes two issues: it removes some redundant broken checks from m4/ac_prog_antlr.m4 and ensures that gjdoc_gendir is used when executing antlr to generate the parser. ChangeLog: 2008-10-20 Andrew John Hughes member.fsf.org> * m4/ac_prog_antlr.m4: Remove redundant checks. * tools/Makefile.am: Use gjdoc_gendir when calling antlr.

FYI: make jar use foreach

Tom Tromey — 2008-10-16T17:17:36

I'm checking this in. While looking at a jar oddity I found that it was still explicitly using iterators. IMO it is cleaner to use the 1.5 foreach feature. This patch implements this. Tom ChangeLog: 2008-10-16 Tom Tromey redhat.com> * tools/gnu/classpath/tools/jar/WorkSet.java (initSet): Use foreach. Change argument type. (WorkSet): Change argument type. * tools/gnu/classpath/tools/jar/Indexer.java (indexJarFile): Use foreach. * tools/gnu/classpath/tools/jar/Creator.java (writeCommandLineEntries): Use foreach. (getAllEntries): Likewise. Index: tools/gnu/classpath/tools/jar/Creator.java =================================================================== RCS file: /cvsroot/classpath/classpath/tools/gnu/classpath/tools/jar/Creator.java,v retrieving revision 1.8 diff -u -r1.8 Creator.java --- tools/gnu/classpath/tools/jar/Creator.java26 May 2008 19:03:41 -00001.8 +++ tools/gnu/classpath/tools/jar/Creator.java16 Oct 2008 17:12:45 -0000 < at >< at > -1,5 +1,5 < at >< at > /* Creator.java - create a new ja

Re: Missing ReleaseArrayElements

Robert Lougher — 2008-10-10T14:35:09

Hi, I forgot to say that somebody needs to commit this, as I can't :) Thanks, Rob. On Fri, Oct 10, 2008 at 7:55 AM, Robert Lougher gmail.com> wrote:

Missing ReleaseArrayElements

Robert Lougher — 2008-10-10T06:55:15

Hi, This fixes a missing ReleaseArrayElements in the GTK peer code (fixing a noticeable memory leak). Rob.

FYI: More ANTLR fixes

Andrew John Hughes — 2008-10-09T21:05:12

This adds a check for cantlr (some Debian specific binary suggested by doko) and ensures that the parser is only generated when both GJDoc and GJDoc parser building are turned on. ChangeLog: 2008-10-06 Andrew John Hughes member.fsf.org> * m4/ac_prog_antlr: Check for cantlr as well. * tools/Makefile.am: Only build GJDoc parser when both CREATE_GJDOC and CREATE_GJDOC_PARSER are on.

FYI: Make building the GJDoc parser optional

Andrew John Hughes — 2008-10-05T21:18:29

This patch makes generating the GJDoc parser with antlr optional in the same way as regenerating the headers (i.e. regeneration is turned on automatically, if they are not found during the configure run). ChangeLog: 2008-10-02 Andrew John Hughes member.fsf.org> * configure.ac: Add regen-gjdoc-parser option, and separate antlr tests. * m4/ac_prog_antlr.m4: Turn single test into AC_LIB_ANTLR and AC_PROG_ANTLR. * m4/ac_prog_java.m4: Quote tests. * tools/Makefile.am: Support CREATE_GJDOC_PARSER option.

FYI: GCJ Merge Backports #02

Andrew John Hughes — 2008-09-30T01:09:21

Backporting this from doko: 2008-09-29 Matthias Klose ubuntu.com> * m4/ac_prog_antlr.m4: Check for antlr binary as well.

FYI: GCJ Merge Backports #01

Andrew John Hughes — 2008-09-29T20:45:10

This patch backports a number of (largely formatting) cleanups I did on recent Classpath patches in the GCJ merge tree. ChangeLog: 2008-09-28 Andrew John Hughes member.fsf.org> * configure.ac: Always check for JAVA prior to ANTLR check. * java/lang/ThreadLocal.java, * java/lang/ThreadLocalMap.java: Rename notFound back to sentinel to avoid potential issues with use of the old name. Cleanup formatting. * java/nio/Buffer.java, * java/nio/ByteBuffer.java, * java/nio/ByteBufferImpl.java, * java/nio/CharBuffer.java, * java/nio/CharViewBufferImpl.java, * java/nio/DirectByteBufferImpl.java, * java/nio/DoubleBuffer.java, * java/nio/DoubleBufferImpl.java, * java/nio/FloatBuffer.java, * java/nio/FloatBufferImpl.java, * java/nio/IntBuffer.java, * java/nio/LongBuffer.java, * java/nio/LongBufferImpl.java, * java/nio/MappedByteBuffer.java, * java/nio/ShortBuffer.java, * java/nio/ShortBufferImpl.java, * java/nio/ShortViewBufferImpl.java: Cleanup formatting.

Re: FYI: System.getenv

Mario Torre — 2008-09-19T16:16:08

Il giorno gio, 18/09/2008 alle 01.00 +0100, Andrew John Hughes ha scritto: Sorry, this one was a cut and paste typo, thanks for spotting it. Cheers, Mario

Re: FYI: System.getenv

Andrew John Hughes — 2008-09-18T00:00:51

Please be more careful when applying such fixes. This patch alters code which is nothing to do with the bug: and thus breaks the implementation by replacing the EnvironmentMap (necessary to ensure the contract of the returned collection) with a raw HashMap. Fixed in CVS with this patch: 2008-09-16 Andrew John Hughes member.fsf.org> * java/lang/System.java (getenv): Reinstate use of EnvironmentMap as opposed to raw HashMap.

FYI: System.getenv

Mario Torre — 2008-09-16T19:42:22

Hi all! I just submitted this patch that fixes a problem in our System.getenv() method. It's possible to have variable in the form of: key=value=value=value like (from my env list): XDM_MANAGED=method=classic cheers, Mario 2008-09-16 Mario Torre aicas.com> * java/lang/System.java (getenv): Fix env entries of the form key=value=value=value not parsed correctly.

FYI: Simplify addition of ANTLR JAR file to theclasspath

Andrew John Hughes — 2008-09-15T00:32:22

Matthias pointed out that we end up with two classpath arguments when building with antlr. This simplifies tools/Makefile.am accordingly. ChangeLog: 2008-09-15 Andrew John Hughes member.fsf.org> Reported by: Matthias Klose * tools/Makefile.am: Simplify the addition of the ANTLR JAR file to the classpath.

FYI: Use 'runantlr' where available

Andrew John Hughes — 2008-09-14T23:38:43

I'm committing this build enhancement from Matthias (doko): 2008-09-14 Matthias Klose ubuntu.com> * m4/ac_prog_antlr.m4: Allow use of runantlr on systems which have it (Debian/Ubuntu).

FYI: Simplify building of tools and examples

Andrew John Hughes — 2008-09-14T16:49:23

This patch makes it possible to build the tools and/or examples even if the class library is only built and not installed, as is the case for gcj. ChangeLog: 2008-09-14 Andrew John Hughes member.fsf.org> * examples/Makefile.am: Check lib directly as well as glibj.zip for boot classes. * m4/acinclude.m4: Only require the class files to be built to allow the tools and examples to be built, not the installation of glibj.zip. * tools/Makefile.am: Check lib directly as well as glibj.zip for boot classes.

Re: FYI: ThreadLocal optimisation

Andrew Haley — 2008-09-13T15:06:40

OK, that makes sense. On such OSes you might as well do it in Java. (Sigh. I just did a web search to find out which OSes had such small PTHREAD_KEYS_MAX, and, to no surprise, found Darwin.) No, it's not like that. For the sake of the GC you have to maintain some sort of table of the values in the Java heap. However, if you have a very fast OS-provided mechanism for thread locals -- and on GNU/Linux you do -- you might as well use that mechanism as a fast way to bypass the table. OK. It might be that the most useful optimization for some VMs would be to use a real thread-local variable (rather than POSIX TLS) for currentThread(). We don't do that in libgcj because when that part of the library was written real thread-local variables didn't exist. Andrew.

Re: FYI: ThreadLocal optimisation

Andrew Haley — 2008-09-13T14:49:56

Thinking about it some more, I suppose there may be one interesting case where a Java implementation has some kind of super-fast optimization of VMThread.currentThread() in the VM itself but very slow JNI. In this case the all-Java implementation might be faster than using OS-supplied thread locals. Andrew.

Re: FYI: ThreadLocal optimisation

Jeroen Frijters — 2008-09-13T14:45:57

PTHREAD_KEYS_MAX is very low on some OSes compared with the needs of some Java apps. Non-conservative GC means that an extra indirection layer is needed, you might as well add another one and hang everything off the Thread object. Maybe, but for IKVM that wouldn't have been an option due to the peculiarities of the underlying platform (note that IKVM doesn't support GNU Classpath anymore, so it's just an example, I don't care either way.), but optimizing a thread local static was easy. Regards, Jeroen

Re: FYI: ThreadLocal optimisation

Andrew Haley — 2008-09-13T14:24:53

Why? If you're going to call pthread_getspecific() to get the current thread, you might as well call it to get the thread-local variable. That remains true regardless of GC, TL inheritance, or anything else. Sure, but they might as well optimize ThreadLocals while they're at it. Andrew.