[cp-patches] FYI: Matcher.usePattern(Pattern) implemented and missing gcj patches pushed
As discussed on the gcj mailing list recently: http://gcc.gnu.org/ml/java/2012-03/msg00048.html I've added an implementation of java.util.regex.Matcher.usePattern(Pattern). It was pretty simple, not more than a five minute job. ChangeLog: 2012-03-22 Andrew John Hughes ahug...@redhat.com * java/util/regex/Matcher.java: (usePattern(Pattern)): Implemented. I've also synced in a number of fixes which were only committed to gcj and not GNU Classpath that I found during the merge: http://gcc.gnu.org/ml/java-patches/2012-q1/msg00063.html 2012-01-01 Jakub Jelinek ja...@redhat.com * gnu/java/rmi/registry/RegistryImpl.java (version): Update copyright notice dates. * tools/gnu/classpath/tools/orbd/Main.java (run): Likewise. 2007-02-26 Jakub Jelinek ja...@redhat.com * java/util/TimeZone.java (getDefaultDisplayName): Don't check if TimeZone is instanceof SimpleTimeZone. 2006-09-13 Andrew Haley a...@redhat.com * java/util/PriorityQueue.java: Throw IllegalArgumentException for capacity 1. (Iterator.remove()): Decrement index after removing element. 2007-02-14 Jakub Jelinek ja...@redhat.com Andrew Haley a...@redhat.com * java/util/TimeZone.java (getDateParams): Negate dayOfWeek. All patches are attached and have been committed. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 commit 8d06dfcad3d15670c0b14a447ff93821a8f6e369 Author: Andrew Haley a...@redhat.com Date: Tue Apr 3 12:25:59 2012 +0100 Negate dayOfWeek in java.util.TimeZone.getDateParams. 2007-02-14 Jakub Jelinek ja...@redhat.com Andrew Haley a...@redhat.com * java/util/TimeZone.java (getDateParams): Negate dayOfWeek. Signed-off-by: Andrew John Hughes ahug...@redhat.com diff --git a/ChangeLog b/ChangeLog index 1711490..f8bfb96 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2007-02-14 Jakub Jelinek ja...@redhat.com + Andrew Haley a...@redhat.com + + * java/util/TimeZone.java (getDateParams): Negate dayOfWeek. + 2012-03-22 Andrew John Hughes ahug...@redhat.com * java/util/regex/Matcher.java: diff --git a/java/util/TimeZone.java b/java/util/TimeZone.java index ce59c20..276602e 100644 --- a/java/util/TimeZone.java +++ b/java/util/TimeZone.java @@ -1151,18 +1151,30 @@ public abstract class TimeZone implements java.io.Serializable, Cloneable int day; // Month, week of month, day of week + + // Mm.w.d. d is between 0 (Sunday) and 6. Week w is + // between 1 and 5; Week 1 is the first week in which day d + // occurs and Week 5 specifies the last d day in the month. + // Month m is between 1 and 12. + month = Integer.parseInt(date.substring(1, date.indexOf('.'))); int week = Integer.parseInt(date.substring(date.indexOf('.') + 1, date.lastIndexOf('.'))); int dayOfWeek = Integer.parseInt(date.substring(date.lastIndexOf('.') + 1)); -if (week == 5) - day = -1; // last day of month is -1 in java, 5 in TZ -else - // first day of week starting on or after. - day = (week - 1) * 7 + 1; + dayOfWeek++; // Java day of week is one-based, Sunday is first day. + + if (week == 5) + day = -1; // last day of month is -1 in java, 5 in TZ + else + { + // First day of week starting on or after. For example, + // to specify the second Sunday of April, set month to + // APRIL, day-of-month to 8, and day-of-week to -SUNDAY. + day = (week - 1) * 7 + 1; + dayOfWeek = -dayOfWeek; + } -dayOfWeek++; // Java day of week is one-based, Sunday is first day. month--; // Java month is zero-based. return new int[] { month, day, dayOfWeek }; } commit 7dbf9fc8c6b98137c4db3d8a6c63e5344746fefd Author: Andrew Haley a...@redhat.com Date: Tue Apr 3 12:31:42 2012 +0100 Decrement index when removing elements from PriorityQueue. Catch capacity 1. 2006-09-13 Andrew Haley a...@redhat.com * java/util/PriorityQueue.java: Throw IllegalArgumentException for capacity 1. (Iterator.remove()): Decrement index after removing element. Signed-off-by: Andrew John Hughes ahug...@redhat.com diff --git a/ChangeLog b/ChangeLog index f8bfb96..f935a45 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2006-09-13 Andrew Haley a...@redhat.com + + * java/util/PriorityQueue.java: Throw IllegalArgumentException for + capacity 1. + (Iterator.remove()): Decrement index after removing element. + 2007-02-14 Jakub Jelinek ja...@redhat.com Andrew Haley
GNU Classpath 0.99 Released!
We are proud to announce the release of GNU Classpath 0.99. GNU Classpath, essential libraries for java, is a project to create free core class libraries for use with runtimes, compilers and tools for the java programming language. The GNU Classpath developer snapshot releases are not directly aimed at the end user but are meant to be integrated into larger development platforms. For example JamVM, CACAO and Kaffe can make use of an installed copy of GNU Classpath 0.99, while GCC (gcj) will use the developer snapshots as a base for future versions. For more projects based on GNU Classpath, http://www.gnu.org/software/classpath/stories.html This release brings with it a number of interesting new features: * Addition of java.util.regex.Pattern.quote. * Addition of java.io.IOError. * Addition of java.io.Console. There have also been many bugfixes over the past year. Those relevant to 0.99 can be found at http://gcc.gnu.org/bugzilla/buglist.cgi?product=classpathtarget_milestone=0.99 With the 0.95 release, we switched fully towards the 1.5 generics work that we previously released separately as classpath-generics. All this work is now fully integrated in the main release and various runtimes (gcj, cacao, jamvm, ikvm, etc) have been extended to take advantage of the new generics, annotations and enumeration support in the core library. As a consequence, only 1.5 capable compilers (currently the Eclipse Compiler for Java (ecj) and Sun's javac) may be used to build Classpath. The GNU Classpath developers site http://developer.classpath.org/ provides detailed information on how to start with helping the GNU Classpath project and gives an overview of the core class library packages currently provided. For each snapshot release generated documentation is provided through the gjdoc tool, which is part of GNU Classpath 0.99. Full documentation on the currently implementated packages and classes can be found at: http://developer.classpath.org/doc/ We are looking into how to extend the documentation experience in the future. Please contact the mailinglist if you would like to help with this effort. For more information about the project see also: GNU Classpath home page: http://www.gnu.org/software/classpath/ Developer information (wiki): http://developer.classpath.org/ Full class documentation: http://developer.classpath.org/doc/ GNU Classpath hackers: http://planet.classpath.org/ Autobuilder, current build status, build snapshots: http://builder.classpath.org/ Application test pages (wiki) http://developer.classpath.org/mediation/Applets http://developer.classpath.org/mediation/FreeAWTTestApps http://developer.classpath.org/mediation/FreeSwingTestApps http://developer.classpath.org/mediation/FreeSWTTestApps GNU Classpath hacking with Eclipse (wiki) http://developer.classpath.org/mediation/ClasspathHackingWithEclipse GNU Classpath promotion banners: http://developer.classpath.org/mediation/ClasspathBanners GNU Classpath 0.99 can be downloaded from ftp://ftp.gnu.org/pub/gnu/classpath/ or one of the ftp.gnu.org mirrors http://www.gnu.org/order/ftp.html File: classpath-0.99.tar.gz SHA256sum: f929297f8ae9b613a1a167e231566861893260651d913ad9b6c11933895fecc8 New in release 0.99 (Mar 07, 2012) * Addition of java.util.regex.Pattern.quote. * Addition of java.io.IOError. * Addition of java.io.Console. * Bug fixes: - PR39408: gjavah doesn't generate constants in header files where they occur in a superclass - PR40590: namespace namespace broken in CNI - PR40630: java.util.Scanner fails when used for charset generation by the OpenJDK build - PR40653: Issue with XML stream writer and namespaces - PR40663: Support Stax API 1.0.1 - PR39177: trunk revision 144128 - jar: internal error: java.lang.NullPointerException - PR41696: java.util.zip.Inflater:finished () returns false when it should return true - PR43536: CopyOnWriteArrayList bug in delete() when empty - PR36560: java.util.zip: Error parsing zip file with larger files in it - Restrict access to VM classes. - Cleanup use of message resources. - Throw exception when encrypted zip file entries are encountered. - Fix infinite recursion in javax.print.attribute.standard.JobStateReasons.add. - Native code cleanups in GtkToolkit.c and jcl.c. - Only log when debugging is on. - PR44411: System.nanoTime() is not independent of wall-clock time - PR46775: Calling Policy.setPolicy with a new Policy object has no effect on the DefaultSecurityManager - Use implementation of VMClass.getSimpleName from gcj. - Simplify security determination in ProtectionDomain in situations where all permissions are available. - PR42390: Missing Security Manager checks in classpath apis - Throw NullPointerExceptions appropriately for compatibility with OpenJDK. - Use Integer.parseInt in preference to Integer.decode in java.util.Formatter. - Use same default
[cp-patches] FYI: GStreamer -Werror build fix
I've applied the attached simple fix to the GStreamer sources to remove an unused variable so that it will build with -Werror. 2012-02-15 Andrew John Hughes ahug...@redhat.com * native/jni/gstreamer-peer/gst_classpath_src.c, (gst_classpath_src_class_init(GstClasspathSrcClass)): Remove unused gstelement_class. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 Index: native/jni/gstreamer-peer/gst_classpath_src.c === RCS file: /sources/classpath/classpath/native/jni/gstreamer-peer/gst_classpath_src.c,v retrieving revision 1.1 diff -u -u -r1.1 gst_classpath_src.c --- native/jni/gstreamer-peer/gst_classpath_src.c 18 Aug 2007 15:23:14 - 1.1 +++ native/jni/gstreamer-peer/gst_classpath_src.c 21 Feb 2012 00:14:09 - @@ -163,14 +163,12 @@ gst_classpath_src_class_init (GstClasspathSrcClass *klass) { GObjectClass *gobject_class; - GstElementClass *gstelement_class; GstBaseSrcClass *gstbasesrc_class; GstPushSrcClass *gstpushsrc_class; GParamSpec *pspec; gobject_class = G_OBJECT_CLASS (klass); - gstelement_class = GST_ELEMENT_CLASS (klass); gstbasesrc_class = GST_BASE_SRC_CLASS (klass); gstpushsrc_class = GST_PUSH_SRC_CLASS (klass); signature.asc Description: Digital signature
[cp-patches] FYI: RH712013: pdftk crashes with java.lang.ArrayIndexOutOfBoundsException
I've just committed what is the first part of a larger fix for: https://bugzilla.redhat.com/show_bug.cgi?id=712013 As explained in the bug report, this massively reduces the amount of incorrect locale data (and avoids the exception), but there are still some errors. Fixing this requires changing the locale data, which I'll do in a series of separate patches. 2011-12-12 Andrew John Hughes ahug...@redhat.com RH712013: pdftk crashes with java.lang.ArrayIndexOutOfBoundsException * java/text/DateFormatSymbols.java: (getStringArray(ListResourceBundle, String, int)): Calls getStringArray(list,string,int,null). (getStringArray(ListResourceBundle, String, int, String[])): Populate a String array with locale data. The data used is the first non-null non-empty element found as we traverse the locale hierarchy. May be supplemented by fallback data. (DateFormatSymbols(Locale)): Get a list of all bundles up the locale hierarchy, rather than just using the one specific locale. Use the improved getStringArray method to populate the arrays, supplying existing data where sideways inheritance takes place. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 signature.asc Description: Digital signature
Re: [cp-patches] [RFC/PATCH] Add java.io.IOError class
On 19:25 Thu 05 Jan , Pekka Enberg wrote: This patch adds a missing IOError class to GNU Classpath that was introduced in Java 1.6. 2012-01-05 Pekka Enberg penb...@kernel.org * java/io/IOError: Add new class. Looks good. Would be nice to have Javadoc on the constructor. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 signature.asc Description: Digital signature
Re: classpath configure update?
On 17:45 Mon 28 Nov , Andreas Tobler wrote: Hi Mark, On 28.11.11 17:39, Mark Wielaard wrote: On Mon, 2011-11-28 at 09:50 +0100, Andreas Tobler wrote: I recently pushed a commit to gcc head and gcc-4.6 to fix the detection of FreeBSD-10. http://gcc.gnu.org/ml/gcc-cvs/2011-11/msg00886.html Now I see that I need to do that for libjava/classpath/configure too. My question, how do I do that? Means, can I simply commit the fix to the gcc/libjava/classpath and don't care about upstream classpath? Or how do I proceed? Upstream classpath doesn't check in generated files like configure, so if it is just the generated files, then nothing has to be done. If you have a patch against configure.ac then please just post it to java-patc...@gcc.gnu.org and/or classpath-patc...@gnu.org and we take it from there. For changes that only apply to libjava/gcj there is a libjava/classpath/ChangeLog.gcj to track those. Well, it is a regenerated configure (which pulls in gcc toplevel libtool.m4 changes) and the config.rpath. For the former I need to dive into cp sources to see how it works. For the latter I guess it is a normal patch. configure is only present in gcj's copy of GNU Classpath. config.rpath will need patching in GNU Classpath, so please post a patch to classpath-patc...@gnu.org. How does the change to configure persist if you don't change the source configure.ac? Thanks, Andreas -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 signature.asc Description: Digital signature
Re: [cp-patches] [PATCH] Fix raw type references in AnnotationInvocationHandler
On 12:07 Wed 12 Oct , Ian Rogers wrote: On 12 October 2011 03:52, Mark Wielaard m...@klomp.org wrote: On Wed, 2011-10-12 at 10:29 +0300, Pekka Enberg wrote: On Wed, Oct 12, 2011 at 1:28 AM, Dr Andrew John Hughes ahug...@redhat.com wrote: If we're going to change that, it should happen after the next release and with plenty of discussion / heads up for VMs. Right. I guess I could send patches for JamVM, CACAO, and Jato as well. Are there other VMs we care about? JikesRVM and GCJ of course! Although they only use part of the VM interface at this time. There is a somewhat full list at: https://www.gnu.org/software/classpath/stories.html#jvm Some of those are somewhat in hibernation though. Heay, and JATO is missing... If we're going to do this, it needs to wait until after the next release. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
Re: [cp-patches] [PATCH] Fix raw type references in AnnotationInvocationHandler
On 16:26 Wed 12 Oct , Brian Jones wrote: On Wed, Oct 12, 2011 at 3:16 PM, Dr Andrew John Hughes ahug...@redhat.com wrote: On 12:07 Wed 12 Oct , Ian Rogers wrote: On 12 October 2011 03:52, Mark Wielaard m...@klomp.org wrote: On Wed, 2011-10-12 at 10:29 +0300, Pekka Enberg wrote: On Wed, Oct 12, 2011 at 1:28 AM, Dr Andrew John Hughes ahug...@redhat.com wrote: If we're going to change that, it should happen after the next release and with plenty of discussion / heads up for VMs. Right. I guess I could send patches for JamVM, CACAO, and Jato as well. Are there other VMs we care about? JikesRVM and GCJ of course! Although they only use part of the VM interface at this time. There is a somewhat full list at: https://www.gnu.org/software/classpath/stories.html#jvm Some of those are somewhat in hibernation though. Heay, and JATO is missing... If we're going to do this, it needs to wait until after the next release. When is that? I need to finish the fix for: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42390 and fix: https://bugzilla.redhat.com/show_bug.cgi?id=712013 Then we'll have a release, if there are no objections. Is anyone against moving the VM interfaces to 1.5 constructs post 0.99? Or adding 1.7 classes for that matter (which was discussed earlier)? Brian -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
Re: [cp-patches] [PATCH] Fix raw type references in AnnotationInvocationHandler
On 00:00 Wed 12 Oct , Pekka Enberg wrote: This patch converts AnnotationInvoncationHandler to use parametrized types for Class, Map, and Iterator which kills few compilation warnings during build. Signed-off-by: Pekka Enberg penb...@kernel.org --- ChangeLog | 10 ++ .../annotation/AnnotationInvocationHandler.java| 31 +++ 2 files changed, 28 insertions(+), 13 deletions(-) diff --git a/ChangeLog b/ChangeLog index 7f57a9e..cf728f4 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,13 @@ +2011-10-11 Pekka Enberg penb...@kernel.org + + * sun/reflect/annotation/AnnotationInvocationHandler.java: + (AnnotationInvocationHandler): Parametrize raw types. + (create): Parametrize raw types. + (equals): Parametrize raw types. + (hashCode): Parametrize raw types. + (toString): Parametrize raw types. + (getBoxedReturnType): Parametrize raw types. + 2011-09-09 Andrew John Hughes ahug...@redhat.com PR classpath/45526: Produce header files for diff --git a/sun/reflect/annotation/AnnotationInvocationHandler.java b/sun/reflect/annotation/AnnotationInvocationHandler.java index 909e7ae..7d585a9 100644 --- a/sun/reflect/annotation/AnnotationInvocationHandler.java +++ b/sun/reflect/annotation/AnnotationInvocationHandler.java @@ -62,21 +62,23 @@ public final class AnnotationInvocationHandler implements InvocationHandler, Serializable { private static final long serialVersionUID = 6182022883658399397L; -private final Class type; -private final Map memberValues; +private final Class? extends Annotation type; +private final MapString, Object memberValues; /** * Construct a new invocation handler for an annotation proxy. * Note that the VM is responsible for filling the memberValues map * with the default values of all the annotation members. */ -public AnnotationInvocationHandler(Class type, Map memberValues) +public AnnotationInvocationHandler(Class? extends Annotation type, + MapString, Object memberValues) { this.type = type; this.memberValues = memberValues; } -public static Annotation create(Class type, Map memberValues) +public static Annotation create(Class? extends Annotation type, +MapString, Object memberValues) { for (Method m : type.getDeclaredMethods()) { @@ -106,7 +108,8 @@ public final class AnnotationInvocationHandler * (can) use different representations of annotations that reuse this * method. */ -public static boolean equals(Class type, Map memberValues, Object other) +public static boolean equals(Class? extends Annotation type, + MapString, Object memberValues, Object other) { if (type.isInstance(other)) { @@ -217,13 +220,14 @@ public final class AnnotationInvocationHandler * (can) use different representations of annotations that reuse this * method. */ -public static int hashCode(Class type, Map memberValues) +public static int hashCode(Class? extends Annotation type, + MapString, Object memberValues) { int h = 0; -Iterator iter = memberValues.keySet().iterator(); +IteratorString iter = memberValues.keySet().iterator(); while (iter.hasNext()) { -Object key = iter.next(); +String key = iter.next(); Object val = memberValues.get(key); h += deepHashCode(val) ^ 127 * key.hashCode(); } @@ -267,15 +271,16 @@ public final class AnnotationInvocationHandler * (can) use different representations of annotations that reuse this * method. */ -public static String toString(Class type, Map memberValues) +public static String toString(Class? extends Annotation type, + MapString, Object memberValues) { StringBuffer sb = new StringBuffer(); sb.append('@').append(type.getName()).append('('); String sep = ; -Iterator iter = memberValues.keySet().iterator(); +IteratorString iter = memberValues.keySet().iterator(); while (iter.hasNext()) { -Object key = iter.next(); +String key = iter.next(); Object val = memberValues.get(key); sb.append(sep).append(key).append('=').append(deepToString(val)); sep = , ; @@ -284,9 +289,9 @@ public final class AnnotationInvocationHandler return sb.toString(); } -private static Class getBoxedReturnType(Method method) +private static Class? getBoxedReturnType(Method method) { -Class returnType = method.getReturnType();
Re: Using ASM for invokedynamic bytecode generation
On 08:38 Thu 08 Sep , Pekka Enberg wrote: Hi all, I started hacking on invokedynamic again: https://github.com/penberg/classpath/commit/21c457f4928678bb5709dfc5a992b80f0d02c4b8 https://github.com/penberg/jato/commits/indy I'm planning to use ASM for generating bytecode for method handle chains. Does that sound like a reasonable thing to do? We already carry the ASM code under tools/external/asm/. Can I just move that under external/ and rename the package so that it doesn't clash with the upstream project? Pekka I'd rather we just depended on it. The current version is outdated as it is. As to the code, a number of comments: * Can we keep fields near the top of the class? I don't know about others, but personally I find it hard to track things if fields are hiding at the bottom of a class. * The unimplemented ones should declare and throw gnu.classpath.NotImplementedException so JAPI picks it up, not UnsupportedOperationException which has different semantics. * Why are you redefining toString() as a stub? The default from Object would do. * Indenting is out in VMMethodHandles.java and you need some line breaks on those long definitions. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
[cp-patches] FYI: PR45526: Produce header files for inner classes
This patch makes gjavah have the same behaviour as OpenJDK's javah in producing header files for any inner classes found in the classes being parsed. ChangeLog: 2011-09-09 Andrew John Hughes ahug...@redhat.com PR classpath/45526: Produce header files for any inner classes found. * tools/gnu/classpath/tools/javah/Main.java: (parsed): Set of class names that have been parsed. (writeHeader(Map,Printer)): Take a general Map rather than a specific HashMap. (parseClasses(IteratorObject)): Factor out the parsing of class files into a separate method so it can be called recursively for inner classes. (getClass(String)): Remove redundant cast. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 Index: tools/gnu/classpath/tools/javah/Main.java === RCS file: /sources/classpath/classpath/tools/gnu/classpath/tools/javah/Main.java,v retrieving revision 1.13 diff -u -u -r1.13 Main.java --- tools/gnu/classpath/tools/javah/Main.java 3 Jun 2010 19:14:37 - 1.13 +++ tools/gnu/classpath/tools/javah/Main.java 9 Sep 2011 04:59:31 - @@ -58,9 +58,11 @@ import java.util.HashMap; import java.util.HashSet; import java.util.Iterator; +import java.util.Set; import java.util.Map; import org.objectweb.asm.ClassReader; +import org.objectweb.asm.tree.InnerClassNode; public class Main { @@ -101,6 +103,9 @@ // Map class names to lists of Text objects. HashMapString,ArrayListText textMap = new HashMapString,ArrayListText(); + // Set of classes which have been parsed + SetString parsed = new HashSetString(); + void readCommandFile(String textFileName) throws OptionException { FileInputStream fis; @@ -317,7 +322,7 @@ return result; } - private void writeHeaders(HashMapFile,ClassWrapper klasses, Printer printer) + private void writeHeaders(MapFile,ClassWrapper klasses, Printer printer) throws IOException { IteratorMap.EntryFile,ClassWrapper i = klasses.entrySet().iterator(); @@ -332,6 +337,53 @@ } } + private MapFile,ClassWrapper parseClasses(IteratorObject inputs) +throws IOException + { +MapFile,ClassWrapper results = new HashMapFile,ClassWrapper(); +while (inputs.hasNext()) + { +// Let user specify either kind of class name or a +// file name. +Object item = inputs.next(); +ClassWrapper klass; +File filename; +if (item instanceof File) + { +// Load class from file. +if (verbose) + System.err.println([reading file + item + ]); +klass = getClass((File) item); +filename = new File(klass.name); + } +else + { +// Load class given the class name. +String className = ((String) item).replace('.', '/'); +if (verbose) + System.err.println([reading class + className + ]); +// Use the name the user specified, even if it is +// different from the ultimate class name. +filename = new File(className); +klass = getClass(className); + } +results.put(filename, klass); +parsed.add(item.toString()); + +// Check to see if there are inner classes to also parse +Iterator? innerClasses = klass.innerClasses.iterator(); +HashSetObject innerNames = new HashSetObject(); +while (innerClasses.hasNext()) + { +String innerName = ((InnerClassNode) innerClasses.next()).name; +if (!parsed.contains(innerName)) + innerNames.add(innerName); + } +results.putAll(parseClasses(innerNames.iterator())); + } +return results; + } + protected void postParse(String[] names) { // Nothing here. @@ -385,40 +437,12 @@ } } -IteratorObject i = klasses.iterator(); -HashMapFile,ClassWrapper results = new HashMapFile,ClassWrapper(); -while (i.hasNext()) - { -// Let user specify either kind of class name or a -// file name. -Object item = i.next(); -ClassWrapper klass; -File filename; -if (item instanceof File) - { -// Load class from file. -if (verbose) - System.err.println([reading file + item + ]); -klass = getClass((File) item); -filename = new File(klass.name); - } -else - { -// Load class given the class name. -String className = ((String) item).replace('.', '/'); -if
[cp-patches] FYI: Fix javah issues
I've applied a couple of patches (attached) to fix some long standing javah issues: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40188 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45527 These fixes allow gjavah to generate header files during the OpenJDK build in the same way as the OpenJDK javah. ChangeLog: 2011-07-07 Andrew John Hughes ahug...@redhat.com PR classpath/45527 * tools/gnu/classpath/tools/javah/JniHelper.java: (mangle(String)): Replace '$' with '_' rather than encoding it as hex. 2011-07-07 Andrew John Hughes ahug...@redhat.com PR classpath/40188 * tools/gnu/classpath/tools/javah/JniIncludePrinter.java: (writeFields(ClassWrapper,JniPrintStream)): Retain a reference to the original class and use it in naming fields, as opposed to the class in which it occurs. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 Index: tools/gnu/classpath/tools/javah/JniIncludePrinter.java === RCS file: /sources/classpath/classpath/tools/gnu/classpath/tools/javah/JniIncludePrinter.java,v retrieving revision 1.11 diff -u -u -r1.11 JniIncludePrinter.java --- tools/gnu/classpath/tools/javah/JniIncludePrinter.java 3 Jun 2010 19:14:37 - 1.11 +++ tools/gnu/classpath/tools/javah/JniIncludePrinter.java 7 Jul 2011 10:13:22 - @@ -63,6 +63,7 @@ { klass.linkSupers(); boolean wroteAny = false; +ClassWrapper headerClass = klass; for (; klass != null; klass = klass.superClass) { Iterator? i = klass.fields.iterator(); @@ -77,7 +78,7 @@ continue; // Note that we don't want to mangle the field name. -String name = (JniHelper.mangle(klass.name) + _ + field.name); +String name = (JniHelper.mangle(headerClass.name) + _ + field.name); out.print(#undef ); out.println(name); out.print(#define ); Index: tools/gnu/classpath/tools/javah/JniHelper.java === RCS file: /sources/classpath/classpath/tools/gnu/classpath/tools/javah/JniHelper.java,v retrieving revision 1.4 diff -u -u -r1.4 JniHelper.java --- tools/gnu/classpath/tools/javah/JniHelper.java 3 Jun 2010 19:14:37 - 1.4 +++ tools/gnu/classpath/tools/javah/JniHelper.java 7 Jul 2011 11:27:22 - @@ -104,6 +104,8 @@ result.append(_3); else if (c == '/') result.append(_); +else if (c == '$') + result.append(_); else if ((c = '0' c = '9') || (c = 'a' c = 'z') || (c = 'A' c = 'Z')) result.append(c);
[cp-patches] FYI: Fix warnings with gcc 4.6 which cause build failure with -Werror
The attached patch fixes a number of issues (mostly unused variables and ignored return variables) which raise warnings with gcc 4.6 and cause a build failure if -Werror is also enabled. ChangeLog: 2011-06-27 Andrew John Hughes ahug...@redhat.com Fix issues with building with -Werror and gcc 4.6. * native/jni/gtk-peer/GtkDragSourceContextPeer.c: (Java_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer_nativeSetCursor): Remove unused ptr variable and mark env as unused. (connect_signals_for_widget(GtkWidget*)): Mark w unused and don't set it. (Java_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer_nativeStartDrag): Remove unused ptr variable. * native/jni/gtk-peer/gnu_java_awt_peer_gtk_ComponentGraphics.c: (Java_gnu_java_awt_peer_gtk_ComponentGraphics_initState): Remove unused width and height variables. * native/jni/gtk-peer/gnu_java_awt_peer_gtk_GdkRobotPeer.c: (Java_gnu_java_awt_peer_gtk_GdkRobotPeer_mouseMove): Check result of XTestFakeMotionEvent call. (Java_gnu_java_awt_peer_gtk_GdkRobotPeer_mousePress): Likewise for XTestFakeButtonEvent call. (Java_gnu_java_awt_peer_gtk_GdkRobotPeer_mouseRelease): Likewise. (Java_gnu_java_awt_peer_gtk_GdkRobotPeer_keyPress): Use g_message instead of deprecated g_printerr. Check result of XTestFakeKeyEvent. (Java_gnu_java_awt_peer_gtk_GdkRobotPeer_keyRelease): Likewise. * native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkPopupMenuPeer.c: (Java_gnu_java_awt_peer_gtk_GtkPopupMenuPeer_setupAccelGroup): Completely disable code to attach parent, including use of ptr2 and parent argument, and reinstate original FIXME to explain why. * native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkVolatileImage.c: (Java_gnu_java_awt_peer_gtk_GtkVolatileImage_nativeGetPixels): Remove unused depth variable. * native/jni/midi-alsa/gnu_javax_sound_midi_alsa_AlsaPortDevice.c, (Java_gnu_javax_sound_midi_alsa_AlsaPortDevice_run_1receiver_1thread_1): Check return values and throw an InternalError if a problem occurs. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 Index: native/jni/gtk-peer/GtkDragSourceContextPeer.c === RCS file: /sources/classpath/classpath/native/jni/gtk-peer/GtkDragSourceContextPeer.c,v retrieving revision 1.7 diff -u -u -r1.7 GtkDragSourceContextPeer.c --- native/jni/gtk-peer/GtkDragSourceContextPeer.c 25 Apr 2007 14:53:03 - 1.7 +++ native/jni/gtk-peer/GtkDragSourceContextPeer.c 26 Jun 2011 14:34:07 - @@ -99,9 +99,8 @@ JNIEXPORT void JNICALL Java_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer_nativeSetCursor - (JNIEnv *env, jobject obj, jint type) + (JNIEnv *env __attribute__((unused)), jobject obj, jint type) { - void *ptr; GdkWindow *win; GdkCursorType gdk_cursor_type; GdkCursor *gdk_cursor; @@ -109,7 +108,6 @@ gdk_threads_enter (); javaObj = obj; - ptr = gtkpeer_get_global_ref (env, obj); switch (type) { @@ -230,10 +228,9 @@ } static void -connect_signals_for_widget (GtkWidget *w) +connect_signals_for_widget (GtkWidget *w __attribute__((unused))) { /* FIXME: Not implemented. */ - w = NULL; } JNIEXPORT void JNICALL @@ -257,7 +254,6 @@ (JNIEnv *env, jobject obj, jobject img, jint x, jint y, jint act, jstring target) { - void *ptr; const gchar *data; GtkTargetEntry tar[1]; GdkEvent *event; @@ -268,7 +264,6 @@ gdk_threads_enter (); javaObj = obj; - ptr = gtkpeer_get_global_ref (env, obj); data = (*env)-GetStringUTFChars (env, target, NULL); tar[0].target = (gchar *) data; Index: native/jni/gtk-peer/gnu_java_awt_peer_gtk_ComponentGraphics.c === RCS file: /sources/classpath/classpath/native/jni/gtk-peer/gnu_java_awt_peer_gtk_ComponentGraphics.c,v retrieving revision 1.22 diff -u -u -r1.22 gnu_java_awt_peer_gtk_ComponentGraphics.c --- native/jni/gtk-peer/gnu_java_awt_peer_gtk_ComponentGraphics.c 11 Sep 2007 09:48:50 - 1.22 +++ native/jni/gtk-peer/gnu_java_awt_peer_gtk_ComponentGraphics.c 26 Jun 2011 14:34:07 - @@ -121,7 +121,6 @@ { GdkDrawable *drawable; GtkWidget *widget; - int width, height; cairo_t *cr; void *ptr; @@ -136,9 +135,6 @@ drawable = widget-window; g_assert (drawable != NULL); - width = widget-allocation.width; - height = widget-allocation.height; - cr = gdk_cairo_create(drawable); g_assert(cr != NULL); Index:
Re: [cp-patches] [RFC/PATCH] Generate META-INF/INDEX.LIST file for glibj.zip
On 13:51 Mon 30 May , Andrew Haley wrote: On 05/27/2011 04:45 AM, Dr Andrew John Hughes wrote: On 15:39 Thu 26 May , Pekka Enberg wrote: This patch changes the glibj.zip packaging so that META-INF/INDEX.LIST is generated to the file. This is needed for VMClassLoader.getBootPackages() to work correctly: private static String[] getBootPackages() { URL indexList = getResource(META-INF/INDEX.LIST); if (indexList != null) { NOTE! This problem is only seen with Jato currently as it's the only VM I'm aware of that doesn't override any of the classes in vm/reference. CACAO and JamVM override the whole classloading parts themselves. I asked about this on IRC and Mark Wielaard explained background on the issue: mjw 2006-04-19 Olivier Jolly olivier.jo...@pcedev.com mjw* vm/reference/java/lang/VMClassLoader.java (getBootPackages): Loads mjwboot packages list from the META-INF/INDEX.LIST file if it exists. mjw http://developer.classpath.org/pipermail/classpath-patches/2006-April/001704.html mjw the patch to support the -i option should be incorporated soon and we'll be able to add the creation of the index to the glibj.zip by default. mjw soon just happens the be 5 years... Signed-off-by: Pekka Enberg penb...@kernel.org --- lib/Makefile.am |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/Makefile.am b/lib/Makefile.am index 8104ee7..50d1baa 100644 --- a/lib/Makefile.am +++ b/lib/Makefile.am @@ -71,7 +71,7 @@ glibj.zip: else if WITH_JAR -CREATE_GLIBJ_ZIP=$(JAR) cf glibj.zip gnu java javax org sun META-INF +CREATE_GLIBJ_ZIP=$(JAR) cf glibj.zip gnu java javax org sun META-INF $(JAR) i glibj.zip else CREATE_GLIBJ_ZIP=$(ZIP) -r -D glibj.zip gnu java javax org sun META-INF /dev/null endif -- 1.7.4.1 My only concern with the patch (as I think Mark also raised on IRC) is that it means the index is only generated if WITH_JAR is set and not if $(ZIP) is used. Should we just drop the $(ZIP) option and require jar to be available? I suspect the reason we haven't done this is a bootstrapping issue. That's right. Is there some reason that zip can't generate the index? I thought it was just another file. Well, zip can't but I guess we could. Andrew. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [cp-patches] [RFC/PATCH] Generate META-INF/INDEX.LIST file for glibj.zip
On 08:51 Fri 27 May , Pekka Enberg wrote: Hi Andrew, On Fri, May 27, 2011 at 6:45 AM, Dr Andrew John Hughes ahug...@redhat.com wrote: if WITH_JAR -CREATE_GLIBJ_ZIP=$(JAR) cf glibj.zip gnu java javax org sun META-INF +CREATE_GLIBJ_ZIP=$(JAR) cf glibj.zip gnu java javax org sun META-INF $(JAR) i glibj.zip else CREATE_GLIBJ_ZIP=$(ZIP) -r -D glibj.zip gnu java javax org sun META-INF /dev/null endif My only concern with the patch (as I think Mark also raised on IRC) is that it means the index is only generated if WITH_JAR is set and not if $(ZIP) is used. Should we just drop the $(ZIP) option and require jar to be available? I suspect the reason we haven't done this is a bootstrapping issue. Does anyone have any thoughts? I think requiring jar is reasonable in 2011 and we should drop zip support. ;-) Pekka Somehow I knew you were going to say that... ;-) I think now that ecj is required to build, it's not the sort of blocker it once was. Plus there is fastjar. I'm happy for the current patch to go in, then we can make jar a requirement in a separate patch. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [cp-patches] [RFC/PATCH] Generate META-INF/INDEX.LIST file for glibj.zip
On 15:39 Thu 26 May , Pekka Enberg wrote: This patch changes the glibj.zip packaging so that META-INF/INDEX.LIST is generated to the file. This is needed for VMClassLoader.getBootPackages() to work correctly: private static String[] getBootPackages() { URL indexList = getResource(META-INF/INDEX.LIST); if (indexList != null) { NOTE! This problem is only seen with Jato currently as it's the only VM I'm aware of that doesn't override any of the classes in vm/reference. CACAO and JamVM override the whole classloading parts themselves. I asked about this on IRC and Mark Wielaard explained background on the issue: mjw 2006-04-19 Olivier Jolly olivier.jo...@pcedev.com mjw* vm/reference/java/lang/VMClassLoader.java (getBootPackages): Loads mjwboot packages list from the META-INF/INDEX.LIST file if it exists. mjw http://developer.classpath.org/pipermail/classpath-patches/2006-April/001704.html mjw the patch to support the -i option should be incorporated soon and we'll be able to add the creation of the index to the glibj.zip by default. mjw soon just happens the be 5 years... Signed-off-by: Pekka Enberg penb...@kernel.org --- lib/Makefile.am |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/Makefile.am b/lib/Makefile.am index 8104ee7..50d1baa 100644 --- a/lib/Makefile.am +++ b/lib/Makefile.am @@ -71,7 +71,7 @@ glibj.zip: else if WITH_JAR -CREATE_GLIBJ_ZIP=$(JAR) cf glibj.zip gnu java javax org sun META-INF +CREATE_GLIBJ_ZIP=$(JAR) cf glibj.zip gnu java javax org sun META-INF $(JAR) i glibj.zip else CREATE_GLIBJ_ZIP=$(ZIP) -r -D glibj.zip gnu java javax org sun META-INF /dev/null endif -- 1.7.4.1 My only concern with the patch (as I think Mark also raised on IRC) is that it means the index is only generated if WITH_JAR is set and not if $(ZIP) is used. Should we just drop the $(ZIP) option and require jar to be available? I suspect the reason we haven't done this is a bootstrapping issue. Does anyone have any thoughts? Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
FOSDEM 2011 Free Java Movies
They're finally appearing online. Keep an eye on: http://fuseyism.com/#movies -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: disabling jawt
On 16:57 Fri 15 Apr , Paul Blacquiere wrote: Attempting to build classpath for arm, am using the following config: CC=arm-fusion-linux-uclibcgnueabi-gcc ./configure --host=arm-linux --build=i686-linux --target=arm-linux --prefix=/var/g6/java --without-x --disable-jawt --disable-plugin --disable-gmp --disable-jni --with-glibj-zip=/path/to/glibj.zip But I get the following when building: arm-fusion-linux-uclibcgnueabi-gcc -DHAVE_CONFIG_H -I. -I../../include -I../../include -I../../native/jni/classpath -I../../native/jni/native-lib -g -O2 -MT jawt.lo -MD -MP -MF .deps/jawt.Tpo -c jawt.c -fPIC -DPIC -o .libs/jawt.o In file included from jawt.c:41: ../../include/jawt_md.h:44:22: error: X11/Xlib.h: No such file or directory Which is no surprise as the target does not have X support, and if it did not build jawt then I suspect it would not need X... What is the option to disable building jawt? Thanks for help in advance. Blacq.. --disable-gtk-peer. I'm surprised configure passed if you don't have X support. Can you attach your config.log? May be a bug. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
[cp-patches] FYI: PR42823: TCP/IP read/write sockets cause memory leak
I've committed the attached patch which was posted by Gert Brettlecker on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42823 This is short enough (two lines added) to count as a trivial patch without copyright assignment. ChangeLog: 2011-03-30 Gert Brettlecker gert.brettlec...@ergon.ch PR classpath/42823 * native/jni/java-net/java_net_VMInetAddress.c, (Java_VMInetAddress_getHostByAddr(JNIEnv*,jclass,jarray)): Free address structure after use. (Java_java_net_VMInetAddress_aton(JNIEnv*,jclass,jstring)): Release UTF string after use. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 Index: native/jni/java-net/java_net_VMInetAddress.c === RCS file: /sources/classpath/classpath/native/jni/java-net/java_net_VMInetAddress.c,v retrieving revision 1.11 diff -u -u -r1.11 java_net_VMInetAddress.c --- native/jni/java-net/java_net_VMInetAddress.c11 Jan 2008 22:14:31 - 1.11 +++ native/jni/java-net/java_net_VMInetAddress.c30 Mar 2011 23:14:13 - @@ -180,6 +180,7 @@ /* Resolve the address and return the name */ result = cpnet_getHostByAddr (env, addr, hostname, sizeof (hostname)); + cpnet_freeAddress (env, addr); if (result != CPNATIVE_OK) { JCL_ThrowException (env, UNKNOWN_HOST_EXCEPTION, @@ -330,6 +331,7 @@ } result = cpnet_aton (env, hostname, address); + (*env)-ReleaseStringUTFChars (env, host, hostname); if (result != CPNATIVE_OK) { JCL_ThrowException (env, UNKNOWN_HOST_EXCEPTION, Internal Error);
Re: [cp-patches] FYI: [PATCH] Fix Java_java_nio_VMDirectByteBuffer_allocate() for negative capacity
On 17 March 2011 19:52, Pekka Enberg penb...@kernel.org wrote: JavaDocs clearly state that ByteBuffer.allocateDirect() must throw IllegalArgumentException if capacity is negative. 2011-03-17 Pekka Enberg penb...@kernel.org * native/jni/java-nio/java_nio_VMDirectByteBuffer.c: (Java_java_nio_VMDirectByteBuffer_allocate): Check for negative capacity. --- native/jni/java-nio/java_nio_VMDirectByteBuffer.c | 7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/native/jni/java-nio/java_nio_VMDirectByteBuffer.c b/native/jni/java-nio/java_nio_VMDirectByteBuffer.c index bfee7e9..7325c5b 100644 --- a/native/jni/java-nio/java_nio_VMDirectByteBuffer.c +++ b/native/jni/java-nio/java_nio_VMDirectByteBuffer.c @@ -51,6 +51,13 @@ Java_java_nio_VMDirectByteBuffer_allocate { void *buffer; + if (capacity 0) + { + JCL_ThrowException (env, java/lang/IllegalArgumentException, + negative capacity); + return 0; + } + buffer = malloc (capacity); if (buffer == NULL) -- 1.7.1 Maybe it would be better to do this in DirectByteBufferImpl.java ? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [cp-patches] [PATCH] Fix Use ArrayList.add() in StyleSheet.resolveStyle
On 14 March 2011 21:56, Pekka Enberg penb...@kernel.org wrote: Hi Andrew! On Mon, Mar 14, 2011 at 11:46 PM, Dr Andrew John Hughes ahug...@redhat.com wrote: Thanks for catching this bug. I was going to approve it but you seem to have already committed it -- why??? I thought that'd be OK since the fix was pretty simple and I was able to work out why the regression was there. Would you prefer that I wait for an explicit ACKs in the future? Please just make it clear what you're asking for. If it's a fix you're sure about, then just post to the patches list with the FYI: subject prefix and commit straight away. If not, prefix the subject with RFC: and wait for feedback. With this one, it was unclear whether you wanted feedback or not and the commit wasn't immediate, but delayed by two days. http://www.gnu.org/software/classpath/docs/cp-hacking.html#SEC11 might be helpful. Pekka -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] [PATCH] Fix Use ArrayList.add() in StyleSheet.resolveStyle
On 12:55 Tue 15 Mar , Pekka Enberg wrote: Hi Andrew, On Tue, Mar 15, 2011 at 12:47 PM, Dr Andrew John Hughes ahug...@redhat.com wrote: Please just make it clear what you're asking for. If it's a fix you're sure about, then just post to the patches list with the FYI: subject prefix and commit straight away. If not, prefix the subject with RFC: and wait for feedback. With this one, it was unclear whether you wanted feedback or not and the commit wasn't immediate, but delayed by two days. Oh, sorry about that - I'm still in my 'other project' mindset. I was thought the fix was obvious enough but delayed the commit by few days so people could take a look at the patch to see if you wanted me to fix it in some other way. Yeah it's just a bit confusing for anyone (probably just me...) watching that process as you didn't reply to say why you were committing... /me goes to re-read the GNU Classpath Hacker's Guide... Pekka -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [cp-patches] [PATCH] Fix Use ArrayList.add() in StyleSheet.resolveStyle
On 22:07 Thu 10 Mar , Pekka Enberg wrote: The following cleanup patch: More warning fixes. 2009-03-09 Andrew John Hughes ahug...@redhat.com [snip] * javax/swing/text/html/StyleSheet.java: Add generic typing. changed the code to do ArrayList.set() on an instance thats allocated like this: ListMapString,String attributes = new ArrayListMapString,String(count); This is, however, broken as ArrayList constructor only ensures capacity but doesn't allow you to set() elements outside of ArrayList.size(). This causes the following exception to happen upon JPC start-up: penberg@jaguar:~/testing/jato$ /usr/local/jamvm/bin/jamvm -jar JPCApplication.jar Exception in thread main java.lang.ExceptionInInitializerError at java.lang.VMClass.forName(Native Method) at java.lang.Class.forName(Class.java:233) at jamvm.java.lang.JarLauncher.main(JarLauncher.java:46) Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.raiseBoundsError(ArrayList.java:504) at java.util.ArrayList.checkBoundExclusive(ArrayList.java:490) at java.util.ArrayList.set(ArrayList.java:323) at javax.swing.text.html.StyleSheet.resolveStyle(StyleSheet.java:417) at javax.swing.text.html.StyleSheet.getResolvedStyle(StyleSheet.java:376) at javax.swing.text.html.StyleSheet.getRule(StyleSheet.java:358) at javax.swing.text.html.ViewAttributeSet.init(ViewAttributeSet.java:112) at javax.swing.text.html.StyleSheet.getViewAttributes(StyleSheet.java:562) at javax.swing.text.html.ParagraphView.getAttributes(ParagraphView.java:117) at javax.swing.text.html.ParagraphView.setPropertiesFromAttributes(ParagraphView.java:131) at javax.swing.text.html.ParagraphView.setParent(ParagraphView.java:106) at javax.swing.text.CompositeView.replace(CompositeView.java:214) at javax.swing.text.BoxView.replace(BoxView.java:232) at javax.swing.text.html.BlockView.replace(BlockView.java:665) at javax.swing.text.CompositeView.loadChildren(CompositeView.java:123) at javax.swing.text.CompositeView.setParent(CompositeView.java:138) at javax.swing.text.html.BlockView.setParent(BlockView.java:187) at javax.swing.text.CompositeView.replace(CompositeView.java:214) at javax.swing.text.BoxView.replace(BoxView.java:232) at javax.swing.text.html.BlockView.replace(BlockView.java:665) at javax.swing.text.CompositeView.loadChildren(CompositeView.java:123) at javax.swing.text.CompositeView.setParent(CompositeView.java:138) at javax.swing.text.html.BlockView.setParent(BlockView.java:187) at javax.swing.plaf.basic.BasicTextUI$RootView.setView(BasicTextUI.java:322) at javax.swing.plaf.basic.BasicTextUI.setView(BasicTextUI.java:1499) at javax.swing.plaf.basic.BasicTextUI.modelChanged(BasicTextUI.java:1522) at javax.swing.plaf.basic.BasicTextUI$Handler.propertyChange(BasicTextUI.java:210) at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:388) at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:332) at java.awt.Component.firePropertyChange(Component.java:5236) at javax.swing.text.JTextComponent.setDocument(JTextComponent.java:1343) at javax.swing.JEditorPane.setEditorKit(JEditorPane.java:1081) at javax.swing.JEditorPane.init(JEditorPane.java:715) at org.jpc.j2se.JPCApplication.clinit(JPCApplication.java:55) at java.lang.VMClass.forName(Native Method) ...2 more Signed-off-by: Pekka Enberg penb...@kernel.org --- javax/swing/text/html/StyleSheet.java |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/javax/swing/text/html/StyleSheet.java b/javax/swing/text/html/StyleSheet.java index 5cf015b..31879b2 100644 --- a/javax/swing/text/html/StyleSheet.java +++ b/javax/swing/text/html/StyleSheet.java @@ -414,11 +414,12 @@ public class StyleSheet extends StyleContext tags[i] = t.toString(); else tags[i] = null; -attributes.set(i, attributeSetToMap(atts)); +attributes.add(attributeSetToMap(atts)); } else { tags[i] = null; +attributes.add(null); } } tags[0] = tag.toString(); -- 1.7.1 Thanks for catching this bug. I was going to approve it but you seem to have already committed it -- why??? -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
[cp-patches] PR42390: Don't include Policy permissions in toString output
The permissions from the current policy are included in the toString() output of java.security.ProtectionDomain. However, as a test case I added to Mauve (gnu.testlet.java.security.Policy.Security) shows when run against OpenJDK, these permissions shouldn't be revealed when the SecurityManager prohibts calls to getPolicy. I've committed the attached patch fixes this issue so that the permissions are excluded if the SecurityManager doesn't allow the policy to be read. 2011-02-22 Andrew John Hughes ahug...@redhat.com PR classpath/42390 * java/security/ProtectionDomain.java: (toString()): Don't include permissions from the policy if we don't have permission to read it. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 Index: java/security/ProtectionDomain.java === RCS file: /sources/classpath/classpath/java/security/ProtectionDomain.java,v retrieving revision 1.18 diff -u -u -r1.18 ProtectionDomain.java --- java/security/ProtectionDomain.java 25 Dec 2010 01:23:50 - 1.18 +++ java/security/ProtectionDomain.java 6 Mar 2011 17:17:58 - @@ -255,7 +255,15 @@ sb.append(linesep); if (!staticBinding) // include all but dont force loading Policy.currentPolicy if (Policy.isLoaded()) -sb.append(Policy.getCurrentPolicy().getPermissions(this)); +try + { +sb.append(Policy.getPolicy().getPermissions(this)); + } +catch (SecurityException e) + { +// We are not allowed access to the policy. +sb.append(perms); + } else // fallback on this one's permissions sb.append(perms); else
Re: [cp-patches] Fix pointer aliasing errors
On 11:18 Thu 03 Mar , Damjan Jovanovic wrote: Hi Classpath 0.98 doesn't even compile nowdays, giving various pointer aliasing errors on GCC 4.4.3 and later. It will with --disable-werror. There's not really a way we can change the existing release. I'm aiming for a new release soon but myself and Pekka Enberg seem to be the only ones committing to Classpath at present. I guess the rest shackled themselves to Oracle's OpenJDK. One of the affected files, native/jni/native-lib/cpnet.c, has already been patched in CVS (so why hasn't it been released yet?), and I am attaching a patch for the other. Thanks. I'll give it a test. I note you haven't contributed before, but I think this is trivial enough to just apply without copyright assignment. I'm puzzled why I haven't hit this failure myself with GCC 4.5.2. Regards Damjan Jovanovic diff -ur classpath-0.98/native/jni/java-nio/gnu_java_nio_VMChannel.c classpath-0.98-patched/native/jni/java-nio/gnu_java_nio_VMChannel.c --- classpath-0.98/native/jni/java-nio/gnu_java_nio_VMChannel.c 2007-12-28 19:49:56.0 +0200 +++ classpath-0.98-patched/native/jni/java-nio/gnu_java_nio_VMChannel.c 2011-03-03 11:06:15.0 +0200 @@ -761,9 +761,11 @@ struct sockaddr_in6 sock_storage; struct sockaddr_in6 *sock6; socklen_t slen = sizeof (struct sockaddr_in6); +#define SIN_FAMILY sin6_family #else struct sockaddr_in sock_storage; socklen_t slen = sizeof (struct sockaddr_in); +#define SIN_FAMILY sin_family #endif /* HAVE_INET6 */ struct sockaddr *sockaddr = (struct sockaddr *) sock_storage; struct sockaddr_in *sock4; @@ -801,7 +803,7 @@ return 0; } - if (sockaddr-sa_family == AF_INET) + if (sock_storage.SIN_FAMILY == AF_INET) { sock4 = (struct sockaddr_in *) sockaddr; memcpy (addrPortPtr, (sock4-sin_addr.s_addr), 4); @@ -809,7 +811,7 @@ result = 4; } #ifdef HAVE_INET6 - else if (sockaddr-sa_family == AF_INET6) + else if (sock_storage.SIN_FAMILY == AF_INET6) { sock6 = (struct sockaddr_in6 *) sockaddr; memcpy (addrPortPtr, (sock6-sin6_addr.s6_addr), 16); @@ -829,6 +831,7 @@ buf.count += ret; JCL_release_buffer (env, buf, dst, 0); +#undef SIN_FAMILY return result; #else (void) fd; @@ -1362,9 +1365,11 @@ struct sockaddr_in6 *addr6; struct sockaddr_in6 sock_storage; socklen_t socklen = sizeof (struct sockaddr_in6); +#define SIN_FAMILY sin6_family #else struct sockaddr_in sock_storage; socklen_t socklen = sizeof (struct sockaddr_in); +#define SIN_FAMILY sin_family #endif /* HAVE_INET6 */ struct sockaddr *sockaddr = (struct sockaddr *) sock_storage; @@ -1379,7 +1384,7 @@ return 0; } - if (sockaddr-sa_family == AF_INET) + if (sock_storage.SIN_FAMILY == AF_INET) { addr4 = (struct sockaddr_in *) sockaddr; memcpy (nameptr, (addr4-sin_addr.s_addr), 4); @@ -1389,7 +1394,7 @@ #ifdef HAVE_INET6 /* IPv6 */ - if (sockaddr-sa_family == AF_INET6) + if (sock_storage.SIN_FAMILY == AF_INET6) { addr6 = (struct sockaddr_in6 *) sockaddr; memcpy (nameptr, (addr6-sin6_addr.s6_addr), 16); @@ -1404,6 +1409,7 @@ (void) name; JCL_ThrowException (env, IO_EXCEPTION, getsockname not supported); return -1; +#undef SIN_FAMILY #endif /* HAVE_GETSOCKNAME */ } @@ -1422,9 +1428,11 @@ struct sockaddr_in6 *addr6; struct sockaddr_in6 sock_storage; socklen_t socklen = sizeof (struct sockaddr_in6); +#define SIN_FAMILY sin6_family #else struct sockaddr_in sock_storage; socklen_t socklen = sizeof (struct sockaddr_in); +#define SIN_FAMILY sin_family #endif /* HAVE_INET6 */ struct sockaddr *sockaddr = (struct sockaddr *) sock_storage; @@ -1440,7 +1448,7 @@ return 0; } - if (sockaddr-sa_family == AF_INET) + if (sock_storage.SIN_FAMILY == AF_INET) { addr4 = (struct sockaddr_in *) sockaddr; memcpy (nameptr, (addr4-sin_addr.s_addr), 4); @@ -1448,7 +1456,7 @@ return 4; } #ifdef HAVE_INET6 - else if (sockaddr-sa_family == AF_INET6) + else if (sock_storage.SIN_FAMILY == AF_INET6) { addr6 = (struct sockaddr_in6 *) sockaddr; memcpy (nameptr, (addr6-sin6_addr.s6_addr), 16); -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [cp-patches] [PATCH] Fix Matcher.find() infinite loop bug
On 16:22 Wed 02 Mar , Pekka Enberg wrote: This patch fixes a problem in Match.find() where the following piece of code would enter an infinite loop: Pattern p = Pattern.compile(\u); Matcher m = p.matcher(hello, world); System.out.println(m.find()); Seems a sensible fix. Could you provide a testcase for Mauve for this too? Signed-off-by: Pekka Enberg penb...@kernel.org --- ChangeLog|5 + java/util/regex/Matcher.java |6 ++ 2 files changed, 11 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 05aa794..2b9cb5c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2011-03-02 Pekka Enberg penb...@kernel.org + + * java/util/regex/Matcher: + (find): Make sure match is within input data limits. + 2011-02-22 Pekka Enberg penb...@kernel.org * java/util/HashMap: diff --git a/java/util/regex/Matcher.java b/java/util/regex/Matcher.java index be57471..86c4873 100644 --- a/java/util/regex/Matcher.java +++ b/java/util/regex/Matcher.java @@ -169,6 +169,12 @@ public final class Matcher implements MatchResult if (match != null) { int endIndex = match.getEndIndex(); +// Is the match within input limits? +if (endIndex = input.length()) + { +match = null; +return false; + } // Are we stuck at the same position? if (!first endIndex == position) { -- 1.7.1 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [cp-patches] [PATCH] Bump up HashMap default initial capacity
On 16:07 Tue 22 Feb , Mark Wielaard wrote: On Tue, 2011-02-22 at 16:58 +0200, Pekka Enberg wrote: While debugging Jython bootstrap issues with GNU Classpath, I noticed that HashMap.DEFAULT_CAPACITY is set to 11 although 1.4 Javadocs, for example, define it to be 16. Signed-off-by: Pekka Enberg penb...@kernel.org /** - * Default number of buckets. This is the value the JDK 1.3 uses. Some - * early documentation specified this value as 101. That is incorrect. + * Default number of buckets; this is explicitly specified by the spec. * Package visible for use by HashSet. */ - static final int DEFAULT_CAPACITY = 11; + static final int DEFAULT_CAPACITY = 16; Just say this is currently set to 16. Since obviously the spec changed a bit over time. I agree with this. Not only does the spec. change, but then the user has to work out what 'the spec' refers to and go check it. Much easier to just say 'currently set to 16'. The actual change seems OK. Thanks, Mark -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [cp-patches] [PATCH] Fix Formatter.parseInt() wrt. leading zeroes
On 18:57 Wed 16 Feb , Pekka Enberg wrote: The following test case: public class StringTest { public static void main(String[] args) { System.out.println(String.format(%08x, 1234)); } } produces the following error: Exception in thread main java.lang.NumberFormatException: invalid character at position 2 in 08 at java.lang.Integer.parseInt(Integer.java:837) at java.lang.Integer.decode(Integer.java:568) at java.util.Formatter.parseInt(Formatter.java:1191) at java.util.Formatter.parseArgumentIndex(Formatter.java:1212) at java.util.Formatter.format(Formatter.java:1326) at java.util.Formatter.format(Formatter.java:1442) at java.lang.String.format(String.java:1984) at java.lang.String.format(String.java:1990) at StringTest.main(StringTest.java:3) This patch fixes the issue by switching to Integer.parseInt() in java.util.Formatter.parseInt(). Signed-off-by: Pekka Enberg penb...@kernel.org --- ChangeLog|7 +++ java/util/Formatter.java |2 +- 2 files changed, 8 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index a575fb9..f1c7c31 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2010-02-16 Pekka Enberg penb...@kernel.org + + * java/util/Formatter.java: + (parseInt): Use Integer.parseInt() insted of Integer.decode() + because the latter doesn't work with leading zeros which are + used in String.format() formatting, for example. + 2010-07-02 Ivan Maidanski iv...@mail.ru * java/util/regex/Pattern.java: diff --git a/java/util/Formatter.java b/java/util/Formatter.java index 04ae805..62f6845 100644 --- a/java/util/Formatter.java +++ b/java/util/Formatter.java @@ -1188,7 +1188,7 @@ public final class Formatter advance(); if (start == index) return -1; -return Integer.decode(format.substring(start, index)); +return Integer.parseInt(format.substring(start, index)); } /** -- 1.7.1 The difference between the two methods is that parseInt only handles decimal numbers (the issue with decode is that it treats 08 as octal). As all the possible values after % should be decimal integers (decimal integer for the argument index, and non-negative decimal integers for width and precision), this change seems ok. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [RFC/PATCH] Invokedynamic API stubs
On 9 February 2011 14:24, Mark Wielaard m...@klomp.org wrote: On Tue, 2011-02-08 at 21:52 +, Dr Andrew John Hughes wrote: I assume by Mercurial 'branching', you mean what we do with IcedTea6 HEAD and the releases at present, not the in-tree support? Because that's worse than CVS IME. I don't know yet. The in-tree support was bad pre-1.0. But that was years ago. Are you sure it is still not workable? I'll try and figure out what savannah supports soon. No, but I don't really have time to look into it either. Let's just keep with what we know for now. This patch implements the work-in-progress invokedynamic API stubs described here: http://download.oracle.com/javase/7/docs/api/java/dyn/package-summary.html The classes don't do anything useful yet and don't even contain all the specified methods. Might be better to find some other reference to point people at. This screams it isn't finished yet, might move. I don't have a good suggestion though. The java doc in OpenJDK is distributed under the GPL though, but doesn't seem to be online yet. Is there anything stopping us having the docs generated by IcedTea online? Maybe the builder could produce them? The builder does already produce them, it just doesn't publish them anywhere yet :) I'll look into pushing them public somewhere. Probably to the main icedtea server. And as Robert just pointed out John Rose has been keeping a GPL derived version of the spec/javadoc here: http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/ I think we need public ones from both IcedTea 6 7 so we know what they are based on. Cheers, Mark -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [RFC/PATCH] Invokedynamic API stubs
On 13:28 Tue 08 Feb , Mark Wielaard wrote: On Mon, 2011-02-07 at 22:01 +0200, Pekka Enberg wrote: On Mon, 2011-02-07 at 15:24 +0100, Dr Andrew John Hughes wrote: I guess I could keep it on my Github mirror until I have something concrete enough to be merged to trunk. I'd prefer to have it in HEAD as long as it's clearly marked as stubs (the NotImplementedException I mentioned) and there is work actively taking place. Then there's always the (slim) possibility someone else can work on it :-) That was my original thinking as well. Does the included patch look better to you? Mark, what do you think about this? I admit to still just not like stubs, however they are setup. If creating branches wasn't such a pain with CVS I would really recommend doing all this on a branch and only merge when ready and it can actually be used with some VM. I guess it is just time to bite the bullet and create some time to move to mercurial and setup some rules about how to create working branches. I won't veto getting this in right now if that is really what you and Andrew want, but I am not particularly excited either. I assume by Mercurial 'branching', you mean what we do with IcedTea6 HEAD and the releases at present, not the in-tree support? Because that's worse than CVS IME. This patch implements the work-in-progress invokedynamic API stubs described here: http://download.oracle.com/javase/7/docs/api/java/dyn/package-summary.html The classes don't do anything useful yet and don't even contain all the specified methods. Might be better to find some other reference to point people at. This screams it isn't finished yet, might move. I don't have a good suggestion though. The java doc in OpenJDK is distributed under the GPL though, but doesn't seem to be online yet. Is there anything stopping us having the docs generated by IcedTea online? Maybe the builder could produce them? Cheers, Mark -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [RFC/PATCH] Invokedynamic API stubs
On 7 February 2011 11:30, Pekka Enberg penb...@kernel.org wrote: Hi! On Thu, 2011-02-03 at 16:47 +0200, Pekka Enberg wrote: I'd like to check in these simple invokedynamic API stubs into CVS HEAD. The APIs are not final but I think now is as good time as any to start working on them especially as it needs work on the VM side. Furthermore, there's already open source projects such as JRuby out there that use invokedynamic so I think GNU Classpath probably needs to support it at some point anyway. The classes don't do anything useful yet and don't even contain all the specified methods. On Fri, Feb 4, 2011 at 10:11 AM, Mark Wielaard m...@klomp.org wrote: I have to admit that I don't like putting in stubs. In the past we have decided to just leave things really unimplemented if we don't support it. And as you say it needs a bit more design thinking. So I would suggest you do this on a branch first (grmbl CVS...) and/or first try to spec it out against a jato VM implementation. Sure, I want to start looking at implementing invokedynamic for Jato which is why I implemented these stubs in the first place. I expect that to take some time so the question is where to put the work-in-progress implementation. I don't see any reason to keep it stashed on my local hard disk but I have to admit I'm not entirely happy with the idea of using CVS branches for it either... I guess I could keep it on my Github mirror until I have something concrete enough to be merged to trunk. I'd prefer to have it in HEAD as long as it's clearly marked as stubs (the NotImplementedException I mentioned) and there is work actively taking place. Then there's always the (slim) possibility someone else can work on it :-) On Fri, Feb 4, 2011 at 10:11 AM, Mark Wielaard m...@klomp.org wrote: BTW. John Rose has lots of background material online: http://cr.openjdk.java.net/~jrose/pres/ Thanks! Pekka -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [cp-patches] [PATCH] Implement Pattern.quote() API method
On 01:13 Fri 28 Jan , Ivan Maidanski wrote: Hi, Ok, since even if OpenJDK quote() is buggy, nonetheless we should reproduce its behavior in the Classpath. ;) Sadly, this is usually true, though obviously the specification should also be checked for agreement. Regards. Thu, 27 Jan 2011 23:58:18 +0200 Pekka Enberg penb...@cs.helsinki.fi: On Thu, 2011-01-27 at 23:28 +0300, Ivan Maidanski wrote: 2. I hope (when you were composing this test case) that you produced the result value for abc\\E123\E manually by reading the spec, not by executing quote() and copy-pasting its result to this test case code ;) I copy-pasted the result of OpenJDK's Pattern.quote() output, not your implementation. That should be OK, no? Pekka -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] [PATCH] Implement Pattern.quote() API method
On 22:41 Wed 26 Jan , Ivan Maidanski wrote: Hi, It's ok but: 1. I'd better rewrote check for null (IMHO looks better): try { Pattern.quote(null); harness.check(true); } catch (NullPointerException e) { harness.check(false); } Yeah I like this version better too. The current one reads rather oddly. However, you seem to have inverted the logic; harness.check(true) should be called when the NPE is given. If an NPE should be thrown for null values, that should be documented in the Classpath patch too. 2. Add a test for a string which already contains \Q Regards. Tue, 25 Jan 2011 23:30:41 +0200 Pekka Enberg penb...@cs.helsinki.fi: On Mon, 2011-01-24 at 23:36 +, Dr Andrew John Hughes wrote: Oh this is one of Ivan's? I didn't spot that. Which number is it? (so I don't review it all over again ;-) ) A test case would be great. I can't really review this patch well without knowing what it's supposed to be doing. Here's a test case I came up with. Ivan, anything else I should test for? Pekka // Tags: JDK1.5 // Copyright (C) 2011 Pekka Enberg // This file is part of Mauve. // Mauve is free software; you can redistribute it and/or modify // it under the terms of the GNU General Public License as published by // the Free Software Foundation; either version 2, or (at your option) // any later version. // Mauve is distributed in the hope that it will be useful, // but WITHOUT ANY WARRANTY; without even the implied warranty of // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the // GNU General Public License for more details. // You should have received a copy of the GNU General Public License // along with Mauve; see the file COPYING. If not, write to // the Free Software Foundation, 59 Temple Place - Suite 330, // Boston, MA 02111-1307, USA. package gnu.testlet.java.util.regex.Pattern; import gnu.testlet.*; import java.util.regex.*; public class quote implements Testlet { private TestHarness harness; public void test (TestHarness harness) { harness.check(Pattern.quote(hello), \\Qhello\\E); boolean pass = false; pass = false; try { Pattern.quote(null); } catch (NullPointerException e) { pass = true; } harness.check(pass); } } -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] [PATCH] Implement Pattern.quote() API method
On 22:15 Wed 26 Jan , Pekka Enberg wrote: On Wed, 2011-01-26 at 20:10 +, Dr Andrew John Hughes wrote: On 22:41 Wed 26 Jan , Ivan Maidanski wrote: Hi, It's ok but: 1. I'd better rewrote check for null (IMHO looks better): try { Pattern.quote(null); harness.check(true); } catch (NullPointerException e) { harness.check(false); } Yeah I like this version better too. The current one reads rather oddly. However, you seem to have inverted the logic; harness.check(true) should be called when the NPE is given. If an NPE should be thrown for null values, that should be documented in the Classpath patch too. Here's a new version. Is \\Q\\Q\\E really the right behaviour? Presumably they don't nest and \E closes all open \Qs? I'll update the Javadoc in the patch. Andrew, if your OK with the Mauve test case, feel free to commit it to CVS. I'm still waiting for my Mauve CVS account. Oh, thought you had access. I'll glad commit the test for you and also see if I can find who sorts out access to this. Pekka // Tags: JDK1.5 // Copyright (C) 2011 Pekka Enberg // This file is part of Mauve. // Mauve is free software; you can redistribute it and/or modify // it under the terms of the GNU General Public License as published by // the Free Software Foundation; either version 2, or (at your option) // any later version. // Mauve is distributed in the hope that it will be useful, // but WITHOUT ANY WARRANTY; without even the implied warranty of // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the // GNU General Public License for more details. // You should have received a copy of the GNU General Public License // along with Mauve; see the file COPYING. If not, write to // the Free Software Foundation, 59 Temple Place - Suite 330, // Boston, MA 02111-1307, USA. package gnu.testlet.java.util.regex.Pattern; import gnu.testlet.*; import java.util.regex.*; public class quote implements Testlet { private TestHarness harness; public void test (TestHarness harness) { harness.check(Pattern.quote(hello), \\Qhello\\E); harness.check(Pattern.quote(\\Q), \\Q\\Q\\E); try { Pattern.quote(null); harness.check(false); } catch (NullPointerException e) { harness.check(true); } } } -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] [PATCH] Implement Pattern.quote() API method
On 22:29 Wed 26 Jan , Pekka Enberg wrote: On Wed, Jan 26, 2011 at 10:25 PM, Dr Andrew John Hughes ahug...@redhat.com wrote: On 22:15 Wed 26 Jan , Pekka Enberg wrote: On Wed, 2011-01-26 at 20:10 +, Dr Andrew John Hughes wrote: On 22:41 Wed 26 Jan , Ivan Maidanski wrote: Hi, It's ok but: 1. I'd better rewrote check for null (IMHO looks better): try { Pattern.quote(null); harness.check(true); } catch (NullPointerException e) { harness.check(false); } Yeah I like this version better too. The current one reads rather oddly. However, you seem to have inverted the logic; harness.check(true) should be called when the NPE is given. If an NPE should be thrown for null values, that should be documented in the Classpath patch too. Here's a new version. Is \\Q\\Q\\E really the right behaviour? Presumably they don't nest and \E closes all open \Qs? It should be the right behavior. I run the tests always with OpenJDK and with JamVM and Jato with GNU Classpath CVS head and make sure they pass with all three of them. Ok, cool. I wasn't saying it was wrong (haven't tested this method at all yet) but just seemed odd from a naive perspective. I'll update the Javadoc in the patch. Andrew, if your OK with the Mauve test case, feel free to commit it to CVS. I'm still waiting for my Mauve CVS account. Oh, thought you had access. I'll glad commit the test for you and also see if I can find who sorts out access to this. I did fill out some form as suggested by Mark and now I'm just waiting... :-) -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] [PATCH] Implement Pattern.quote() API method
On 11:26 Tue 25 Jan , Pekka Enberg wrote: On Tue, Jan 25, 2011 at 1:36 AM, Dr Andrew John Hughes ahug...@redhat.com wrote: On 23:22 Mon 24 Jan , Pekka Enberg wrote: On 22 January 2011 19:38, Pekka Enberg penb...@kernel.org wrote: From: Ivan Maidanski iv...@mail.ru 2010-07-02 Ivan Maidanski iv...@mail.ru * java/util/regex/Pattern.java: (quote): Implement new 1.5 Java API method. --- ChangeLog | 5 + java/util/regex/Pattern.java | 37 - 2 files changed, 41 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 4d0bf6d..52b4760 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2010-07-02 Ivan Maidanski iv...@mail.ru + + * java/util/regex/Pattern.java: + (quote): Implement new 1.5 Java API method. + 2011-01-21 Pekka Enberg penb...@kernel.org * java/lang/Class.java: diff --git a/java/util/regex/Pattern.java b/java/util/regex/Pattern.java index 7d1fc84..2aae9bb 100644 --- a/java/util/regex/Pattern.java +++ b/java/util/regex/Pattern.java @@ -1,5 +1,6 @@ /* Pattern.java -- Compiled regular expression ready to be applied. - Copyright (C) 2002, 2004, 2005, 2007 Free Software Foundation, Inc. + Copyright (C) 2002, 2004, 2005, 2007, 2010 + Free Software Foundation, Inc. This file is part of GNU Classpath. @@ -37,6 +38,8 @@ exception statement from your version. */ package java.util.regex; +import gnu.java.lang.CPStringBuilder; + import gnu.java.util.regex.RE; import gnu.java.util.regex.REException; import gnu.java.util.regex.RESyntax; @@ -260,6 +263,38 @@ public final class Pattern implements Serializable } /** + * Returns a literal pattern for the specified String. + * + * @since 1.5 + */ + public static String quote(String str) + { + int eInd = str.indexOf(\\E); + if (eInd 0) + { + // No need to handle backslashes. + return \\Q + str + \\E; + } + + CPStringBuilder sb = new CPStringBuilder(str.length() + 16); + sb.append(\\Q); // start quote + + int pos = 0; + do + { + // A backslash is quoted by another backslash; + // 'E' is not needed to be quoted. + sb.append(str.substring(pos, eInd)) + .append(\\E + + E + \\Q); + pos = eInd + 2; + } while ((eInd = str.indexOf(\\E, pos)) = 0); + + sb.append(str.substring(pos, str.length())) + .append(\\E); // end quote + return sb.toString(); + } + + /** * Return the regular expression used to construct this object. * @specnote Prior to JDK 1.5 this method had a different behavior * @since 1.5 On Sun, Jan 23, 2011 at 2:38 AM, Dr Andrew John Hughes gnu_and...@member.fsf.org wrote: The javadoc is incomplete; the parameter and return value are not documented. Do you have some test cases for this? No, I don't. Ivan, do you have test cases for this? If not, I can write one for Mauve. Oh this is one of Ivan's? I didn't spot that. Which number is it? (so I don't review it all over again ;-) ) It's this one here: - http://article.gmane.org/gmane.comp.java.classpath.patches/13009 (classpath-ivmai-26.diff); Thanks! A test case would be great. I can't really review this patch well without knowing what it's supposed to be doing. Can I add a new one in Mauve that simply test that the return value makes sense or should I try to embed it into gnu/testlet/java/util/regex/Pattern/matches.java? I'd prefer a separate test e.g. gnu/testlet/java/util/regex/Pattern/quote.java -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] [PATCH] Implement Pattern.quote() API method
On 23:22 Mon 24 Jan , Pekka Enberg wrote: On 22 January 2011 19:38, Pekka Enberg penb...@kernel.org wrote: From: Ivan Maidanski iv...@mail.ru 2010-07-02 Ivan Maidanski iv...@mail.ru * java/util/regex/Pattern.java: (quote): Implement new 1.5 Java API method. --- ChangeLog | 5 + java/util/regex/Pattern.java | 37 - 2 files changed, 41 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 4d0bf6d..52b4760 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2010-07-02 Ivan Maidanski iv...@mail.ru + + * java/util/regex/Pattern.java: + (quote): Implement new 1.5 Java API method. + 2011-01-21 Pekka Enberg penb...@kernel.org * java/lang/Class.java: diff --git a/java/util/regex/Pattern.java b/java/util/regex/Pattern.java index 7d1fc84..2aae9bb 100644 --- a/java/util/regex/Pattern.java +++ b/java/util/regex/Pattern.java @@ -1,5 +1,6 @@ /* Pattern.java -- Compiled regular expression ready to be applied. - Copyright (C) 2002, 2004, 2005, 2007 Free Software Foundation, Inc. + Copyright (C) 2002, 2004, 2005, 2007, 2010 + Free Software Foundation, Inc. This file is part of GNU Classpath. @@ -37,6 +38,8 @@ exception statement from your version. */ package java.util.regex; +import gnu.java.lang.CPStringBuilder; + import gnu.java.util.regex.RE; import gnu.java.util.regex.REException; import gnu.java.util.regex.RESyntax; @@ -260,6 +263,38 @@ public final class Pattern implements Serializable } /** + * Returns a literal pattern for the specified String. + * + * @since 1.5 + */ + public static String quote(String str) + { + int eInd = str.indexOf(\\E); + if (eInd 0) + { + // No need to handle backslashes. + return \\Q + str + \\E; + } + + CPStringBuilder sb = new CPStringBuilder(str.length() + 16); + sb.append(\\Q); // start quote + + int pos = 0; + do + { + // A backslash is quoted by another backslash; + // 'E' is not needed to be quoted. + sb.append(str.substring(pos, eInd)) + .append(\\E + + E + \\Q); + pos = eInd + 2; + } while ((eInd = str.indexOf(\\E, pos)) = 0); + + sb.append(str.substring(pos, str.length())) + .append(\\E); // end quote + return sb.toString(); + } + + /** * Return the regular expression used to construct this object. * @specnote Prior to JDK 1.5 this method had a different behavior * @since 1.5 On Sun, Jan 23, 2011 at 2:38 AM, Dr Andrew John Hughes gnu_and...@member.fsf.org wrote: The javadoc is incomplete; the parameter and return value are not documented. Do you have some test cases for this? No, I don't. Ivan, do you have test cases for this? If not, I can write one for Mauve. Oh this is one of Ivan's? I didn't spot that. Which number is it? (so I don't review it all over again ;-) ) A test case would be great. I can't really review this patch well without knowing what it's supposed to be doing. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] [PATCH] Fix PrintStream constructor API differences for null
On 23 January 2011 12:41, Pekka Enberg penb...@kernel.org wrote: On Sun, 2011-01-23 at 00:36 +, Dr Andrew John Hughes wrote: What is the current behaviour? Does it eventually throw an NPE but just performs a lot of additional computation first? Or does it throw some other error? Or return a bad value? The NPEs should have some message as to what went wrong e.g. The specified output stream was null.. I've included an updated patch below. Pekka From 264f44315ba45e1ecd95b5d6aee0ec8b7ce22db0 Mon Sep 17 00:00:00 2001 From: Pekka Enberg penb...@kernel.org Date: Sat, 22 Jan 2011 18:19:08 +0200 Subject: [PATCH] Fix PrintStream constructor API differences for null 2011-01-22 Pekka Enberg penb...@kernel.org * java/io/PrintStream.java (PrintStream): Throw NullPointerException if out or encoding is null to be compatible with OpenJDK. --- java/io/PrintStream.java | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/java/io/PrintStream.java b/java/io/PrintStream.java index eaab7c3..caa6035 100644 --- a/java/io/PrintStream.java +++ b/java/io/PrintStream.java @@ -181,10 +181,15 @@ public class PrintStream extends FilterOutputStream implements Appendable * @param out The codeOutputStream/code to write to. * @param auto_flush codetrue/code to flush the stream after every * line, codefalse/code otherwise + * @exception NullPointerException If out is null. */ public PrintStream (OutputStream out, boolean auto_flush) { super (out); + + if (out == null) + throw new NullPointerException(out is null); + String encoding; try { encoding = SystemProperties.getProperty(file.encoding); @@ -213,12 +218,19 @@ public class PrintStream extends FilterOutputStream implements Appendable * line, codefalse/code otherwise * @param encoding The name of the character encoding to use for this * object. + * @exception NullPointerException If out or encoding is null. */ public PrintStream (OutputStream out, boolean auto_flush, String encoding) throws UnsupportedEncodingException { super (out); + if (out == null) + throw new NullPointerException(out is null); + + if (encoding == null) + throw new NullPointerException(encoding is null); + new String(new byte[]{0}, encoding); // check if encoding is supported this.encoding = encoding; this.auto_flush = auto_flush; -- 1.7.1 Ok to commit. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] [PATCH] Fix PrintStream constructor API differences for null
On 22 January 2011 19:13, Pekka Enberg penb...@kernel.org wrote: 2011-01-22 Pekka Enberg penb...@kernel.org * java/io/PrintStream.java (PrintStream): Throw NullPointerException if out or encoding is null to be compatible with OpenJDK. --- java/io/PrintStream.java | 9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/java/io/PrintStream.java b/java/io/PrintStream.java index eaab7c3..72286bf 100644 --- a/java/io/PrintStream.java +++ b/java/io/PrintStream.java @@ -181,10 +181,15 @@ public class PrintStream extends FilterOutputStream implements Appendable * @param out The codeOutputStream/code to write to. * @param auto_flush codetrue/code to flush the stream after every * line, codefalse/code otherwise + * @exception NullPointerException If out is null. */ public PrintStream (OutputStream out, boolean auto_flush) { super (out); + + if (out == null) + throw new NullPointerException(); + String encoding; try { encoding = SystemProperties.getProperty(file.encoding); @@ -213,12 +218,16 @@ public class PrintStream extends FilterOutputStream implements Appendable * line, codefalse/code otherwise * @param encoding The name of the character encoding to use for this * object. + * @exception NullPointerException If out or encoding is null. */ public PrintStream (OutputStream out, boolean auto_flush, String encoding) throws UnsupportedEncodingException { super (out); + if (out == null || encoding == null) + throw new NullPointerException(); + new String(new byte[]{0}, encoding); // check if encoding is supported this.encoding = encoding; this.auto_flush = auto_flush; -- 1.7.1 What is the current behaviour? Does it eventually throw an NPE but just performs a lot of additional computation first? Or does it throw some other error? Or return a bad value? The NPEs should have some message as to what went wrong e.g. The specified output stream was null.. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] [PATCH] Implement Pattern.quote() API method
On 22 January 2011 19:38, Pekka Enberg penb...@kernel.org wrote: From: Ivan Maidanski iv...@mail.ru 2010-07-02 Ivan Maidanski iv...@mail.ru * java/util/regex/Pattern.java: (quote): Implement new 1.5 Java API method. --- ChangeLog | 5 + java/util/regex/Pattern.java | 37 - 2 files changed, 41 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 4d0bf6d..52b4760 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2010-07-02 Ivan Maidanski iv...@mail.ru + + * java/util/regex/Pattern.java: + (quote): Implement new 1.5 Java API method. + 2011-01-21 Pekka Enberg penb...@kernel.org * java/lang/Class.java: diff --git a/java/util/regex/Pattern.java b/java/util/regex/Pattern.java index 7d1fc84..2aae9bb 100644 --- a/java/util/regex/Pattern.java +++ b/java/util/regex/Pattern.java @@ -1,5 +1,6 @@ /* Pattern.java -- Compiled regular expression ready to be applied. - Copyright (C) 2002, 2004, 2005, 2007 Free Software Foundation, Inc. + Copyright (C) 2002, 2004, 2005, 2007, 2010 + Free Software Foundation, Inc. This file is part of GNU Classpath. @@ -37,6 +38,8 @@ exception statement from your version. */ package java.util.regex; +import gnu.java.lang.CPStringBuilder; + import gnu.java.util.regex.RE; import gnu.java.util.regex.REException; import gnu.java.util.regex.RESyntax; @@ -260,6 +263,38 @@ public final class Pattern implements Serializable } /** + * Returns a literal pattern for the specified String. + * + * @since 1.5 + */ + public static String quote(String str) + { + int eInd = str.indexOf(\\E); + if (eInd 0) + { + // No need to handle backslashes. + return \\Q + str + \\E; + } + + CPStringBuilder sb = new CPStringBuilder(str.length() + 16); + sb.append(\\Q); // start quote + + int pos = 0; + do + { + // A backslash is quoted by another backslash; + // 'E' is not needed to be quoted. + sb.append(str.substring(pos, eInd)) + .append(\\E + + E + \\Q); + pos = eInd + 2; + } while ((eInd = str.indexOf(\\E, pos)) = 0); + + sb.append(str.substring(pos, str.length())) + .append(\\E); // end quote + return sb.toString(); + } + + /** * Return the regular expression used to construct this object. * @specnote Prior to JDK 1.5 this method had a different behavior * @since 1.5 -- 1.7.1 The javadoc is incomplete; the parameter and return value are not documented. Do you have some test cases for this? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] [PATCH] Fix java.lang.Class field and method API for null names
On 13:33 Fri 21 Jan , Pekka Enberg wrote: On Mon, Dec 13, 2010 at 5:41 PM, Pekka Enberg penb...@kernel.org wrote: On Mon, Dec 13, 2010 at 2:53 PM, Dr Andrew John Hughes ahug...@redhat.com wrote: OK, I'm sorry I'm having some difficulties adjusting to GNU style of working. I'll update the patch and resend. Please just post a ChangeLog in the mail. Don't include it in the patch as it makes it hard to apply. 2010-12-13 Pekka Enberg penb...@kernel.org * java/lang/Class.java: (getDeclaredField): Throw NullPointerException instead of NoSuchFieldException if name is null. (getField): Likewise. (getDeclaredMethod): Throw NullPointerException instead of NoSuchMethodException if name is null. (getMethod): Likewise. Also, as stated before, we can't yet apply these until the copyright assignment is sorted. I've signed the papers and sent them back to FSF so hopefully that'll be cleared soon. Ping? What do I need to do to get this patch merged? My paperwork has been approved now. The patch looks ok to me. You need to apply to join the Classpath group on Savannah (https://savannah.gnu.org/projects/classpath) to get commit access. Once approved, you can commit. Alternatively, one of us can commit for you but it might be more expedient to sort commit access out for yourself. Please be aware that non-trivial patches still need to be reviewed before commit. Oh, and always make sure Classpath still builds before committing :-) -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
[cp-patches] FYI: PR42390: Add security check to ObjectOutputStream(OutputStream constructor)
This patch adds a missing security check to the ObjectOutputStream(OutputStream) constructor as reported in PR42390. 2010-12-25 Andrew John Hughes ahug...@redhat.com PR classpath/42390 * java/io/ObjectOutputStream.java: (ObjectOutputStream(OutputStream)): Add required security check. (overridesMethods(Class?)): Check whether the subclass overrides one of the methods which requires a security check. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 Index: java/io/ObjectOutputStream.java === RCS file: /sources/classpath/classpath/java/io/ObjectOutputStream.java,v retrieving revision 1.74 diff -u -u -r1.74 ObjectOutputStream.java --- java/io/ObjectOutputStream.java 3 Jun 2010 19:12:56 - 1.74 +++ java/io/ObjectOutputStream.java 25 Dec 2010 16:10:07 - @@ -48,6 +48,8 @@ import java.lang.reflect.InvocationTargetException; import java.lang.reflect.Method; +import java.security.AccessController; +import java.security.PrivilegedAction; /** * An codeObjectOutputStream/code can be used to write objects @@ -136,6 +138,10 @@ */ public ObjectOutputStream (OutputStream out) throws IOException { +SecurityManager secMan = System.getSecurityManager(); +if (secMan != null overridesMethods(getClass())) + secMan.checkPermission(SUBCLASS_IMPLEMENTATION_PERMISSION); + realOutput = new DataOutputStream(out); blockData = new byte[ BUFFER_SIZE ]; blockDataCount = 0; @@ -1481,4 +1487,44 @@ private boolean dump = false; private static final boolean DEBUG = false; + + /** + * Returns true if the given class overrides either of the + * methods codeputFields/code or codewriteUnshared/code. + * + * @param clazz the class to check. + * @return true if the class overrides one of the methods. + */ + private static boolean overridesMethods(final Class? clazz) + { +if (clazz == ObjectOutputStream.class) + return false; + +return AccessController.doPrivileged(new PrivilegedActionBoolean() { +public Boolean run() +{ + Method[] methods = clazz.getDeclaredMethods(); + for (int a = 0; a methods.length; ++a) +{ + String name = methods[a].getName(); + if (name.equals(writeUnshared)) +{ + Class?[] paramTypes = methods[a].getParameterTypes(); + if (paramTypes.length == 1 + paramTypes[0] == Object.class + methods[a].getReturnType() == Void.class) +return true; +} + else if (name.equals(putFields)) +{ + if (methods[a].getParameterTypes().length == 0 + methods[a].getReturnType() == PutField.class) +return true; +} +} + return false; +} + }); + } + }
[cp-patches] FYI: PR42390: Add security check to LogManager.{add, remove}PropertyChangeListener
Another missing security check reported in PR42390: 2010-12-25 Andrew John Hughes ahug...@redhat.com PR classpath/42390 * java/util/logging/LogManager.java: (addPropertyChangeListener(PropertyChangeListener)): Document fully. Throw NPE in a clearer way. Add SecurityException. (removePropertyChangeListener(PropertyChangeListener)): Document fully. Add SecurityException. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 Index: java/util/logging/LogManager.java === RCS file: /sources/classpath/classpath/java/util/logging/LogManager.java,v retrieving revision 1.29 diff -u -u -r1.29 LogManager.java --- java/util/logging/LogManager.java 3 Jun 2010 19:13:14 - 1.29 +++ java/util/logging/LogManager.java 25 Dec 2010 17:29:19 - @@ -211,11 +211,21 @@ /** * Registers a listener which will be notified when the * logging properties are re-read. + * + * @param listener the event listener to register. + * @throws NullPointerException if the listener is {...@code null}. + * @throws SecurityException if a security manager exists and the + * calling code does not have the permission + * {...@code LoggingPermission(control)}. */ public synchronized void addPropertyChangeListener(PropertyChangeListener listener) { -/* do not register null. */ -listener.getClass(); +if (listener == null) + throw new NullPointerException(Attempt to add null property change listener); + +SecurityManager sm = System.getSecurityManager(); +if (sm != null) + sm.checkPermission(new LoggingPermission(control, null)); pcs.addPropertyChangeListener(listener); } @@ -226,11 +236,22 @@ * If codelistener/code has not been registered previously, * nothing happens. Also, no exception is thrown if * codelistener/code is codenull/code. + * + * @param listener the listener to remove. + * @throws SecurityException if a security manager exists and the + * calling code does not have the permission + * {...@code LoggingPermission(control)}. */ public synchronized void removePropertyChangeListener(PropertyChangeListener listener) { if (listener != null) - pcs.removePropertyChangeListener(listener); + { +SecurityManager sm = System.getSecurityManager(); +if (sm != null) + sm.checkPermission(new LoggingPermission(control, null)); + +pcs.removePropertyChangeListener(listener); + } } /**
[cp-patches] FYI: PR42390 Add missing security check in java.io.File#isHidden()
Another one from PR42390: 2010-12-25 Andrew John Hughes ahug...@redhat.com PR classpath/42390 * java/io/File.java: (isHidden()): Add and document missing security check. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 Index: java/io/File.java === RCS file: /sources/classpath/classpath/java/io/File.java,v retrieving revision 1.75 diff -u -u -r1.75 File.java --- java/io/File.java 3 Jun 2010 19:12:55 - 1.75 +++ java/io/File.java 25 Dec 2010 19:07:38 - @@ -700,11 +700,13 @@ * * @return codetrue/code if the file is hidden, codefalse/code * otherwise. - * + * @throws SecurityException if a security manager exists and denies + * read access to this file. * @since 1.2 */ public boolean isHidden() { +checkRead(); return VMFile.isHidden(path); }
[cp-patches] FYI: Provide implies shortcut for ProtectionDomain instances with AllPermission
As mentioned in http://sourceware.org/ml/mauve-patches/2010/msg3.html and checked in the referenced Mauve test, OpenJDK provides a shortcut for ProtectionDomain instances with AllPermission set which results in Policy.implies(Permission) not being called. This patch implements a like shortcut in GNU Classpath. 2010-12-24 Andrew John Hughes ahug...@redhat.com * java/security/ProtectionDomain.java, (hasAllPermissions): Add new field. (ProtectionDomain(CodeSource,PermissionCollection, ClassLoader,Principal,boolean)): Check if permission collection includes AllPermission and, if so, set hasAllPermissions. (implies(Permission)): Immediately return true if hasAllPermissions is set. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 Index: java/security/ProtectionDomain.java === RCS file: /sources/classpath/classpath/java/security/ProtectionDomain.java,v retrieving revision 1.17 diff -u -u -r1.17 ProtectionDomain.java --- java/security/ProtectionDomain.java 3 Jun 2010 19:13:07 - 1.17 +++ java/security/ProtectionDomain.java 25 Dec 2010 01:15:32 - @@ -41,6 +41,8 @@ import gnu.java.lang.CPStringBuilder; +import java.util.Enumeration; + /** * This class represents a group of classes, along with their granted * permissions. The classes are identified by a {...@link CodeSource}. Thus, any @@ -71,6 +73,9 @@ /** Post 1.4 the policy may be refreshed! use false for pre 1.4. */ private boolean staticBinding; + /** True if this protection domain has all permissions */ + private boolean hasAllPermissions; + /** * Initializes a new instance of codeProtectionDomain/code representing * the specified {...@link CodeSource} and set of permissions. No permissions @@ -128,6 +133,13 @@ { perms = permissions; perms.setReadOnly(); +/* Check if this protection domain has all permissions */ +EnumerationPermission e = permissions.elements(); +while (e.hasMoreElements()) + { +if (e.nextElement() instanceof AllPermission) + hasAllPermissions = true; + } } this.classloader = classloader; @@ -190,6 +202,8 @@ */ public boolean implies(Permission permission) { +if (hasAllPermissions) + return true; if (staticBinding) return (perms == null ? false : perms.implies(permission)); // Else dynamically bound. Do we have it?
Re: [cp-patches] [PATCH] Fix java.lang.Class field and method API for null names
On 14:41 Mon 13 Dec , Pekka Enberg wrote: On Mon, Dec 13, 2010 at 12:08 PM, Andrew Haley a...@redhat.com wrote: On 12/12/2010 11:46 AM, Pekka Enberg wrote: This patch fixes Class getDeclaredField, getDeclaredMethod, getField, and getMethod API to throw NullPointerException if given name is null. Thanks, but two things: a. What happens with the current code base? We throw NoSuchFieldException or NoSuchMethodException. I saw that because of a test case we had written in Malva which has very strict API checks. b. We need a change log entry. OK, I'm sorry I'm having some difficulties adjusting to GNU style of working. I'll update the patch and resend. Please just post a ChangeLog in the mail. Don't include it in the patch as it makes it hard to apply. Also, as stated before, we can't yet apply these until the copyright assignment is sorted. Pekka -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] [PATCH v2] Fix VMClass#getSimpleName() implementation
On 22:52 Wed 08 Dec , Pekka Enberg wrote: This patch replaces VMClass#getSimpleName() implementation with JamVM's version that supposedly comes from GCJ. This fixes a compatibility problem found by Malva. Signed-off-by: Pekka Enberg penb...@kernel.org --- vm/reference/java/lang/VMClass.java | 29 +++-- 1 files changed, 15 insertions(+), 14 deletions(-) diff --git a/vm/reference/java/lang/VMClass.java b/vm/reference/java/lang/VMClass.java index a0091c0..d80eecd 100644 --- a/vm/reference/java/lang/VMClass.java +++ b/vm/reference/java/lang/VMClass.java @@ -303,20 +303,21 @@ final class VMClass return getComponentType(klass).getSimpleName() + []; } String fullName = getName(klass); -int pos = fullName.lastIndexOf($); -if (pos == -1) - pos = 0; -else - { -++pos; -while (Character.isDigit(fullName.charAt(pos))) - ++pos; - } -int packagePos = fullName.lastIndexOf(., pos); -if (packagePos == -1) - return fullName.substring(pos); -else - return fullName.substring(packagePos + 1); +Class enclosingClass = getEnclosingClass(klass); +if (enclosingClass == null) + // It's a top level class. + return fullName.substring(fullName.lastIndexOf(.) + 1); + +fullName = fullName.substring(enclosingClass.getName().length()); + +// We've carved off the enclosing class name; now we must have '$' +// followed optionally by digits, followed by the class name. +int pos = 1; +while (Character.isDigit(fullName.charAt(pos))) + ++pos; +fullName = fullName.substring(pos); + +return fullName; } /** -- 1.7.0.4 I've fixed the Classpath version using the gcj version as above. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Future blog
On 10:54 Sun 12 Dec , Pekka Enberg wrote: On Thu, 2010-12-09 at 12:45 +, Dr Andrew John Hughes wrote: I disagree. Just because the version in gcj is different doesn't mean it's correct. As far as I'm aware, Pekka already has a testcase for this so it would be good to have it in Mauve. Sorry for the delay, here's a test case for getSimpleName(). Pekka From 3637ab8ec4f866da6fadc092eab1f99ce4adb417 Mon Sep 17 00:00:00 2001 From: Pekka Enberg penb...@kernel.org Date: Sun, 12 Dec 2010 10:52:27 +0200 Subject: [PATCH] mauve: Add test case for Class.getSimpleName() Signed-off-by: Pekka Enberg penb...@kernel.org --- gnu/testlet/java/lang/Class/ClassTest.java | 13 + 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/gnu/testlet/java/lang/Class/ClassTest.java b/gnu/testlet/java/lang/Class/ClassTest.java index 71b144c..c5927e8 100644 --- a/gnu/testlet/java/lang/Class/ClassTest.java +++ b/gnu/testlet/java/lang/Class/ClassTest.java @@ -577,6 +577,18 @@ public class ClassTest implements Cloneable, java.io.Serializable, Testlet harness.check(in == null); } + public void test_getSimpleName() + { +harness.checkPoint(test_getSimpleName); +harness.check(int.class.getSimpleName().equals(int)); +harness.check(int[].class.getSimpleName().equals(int[])); +harness.check(int[][].class.getSimpleName().equals(int[][])); +harness.check(Object[].class.getSimpleName().equals(Object[])); +harness.check(Object.class.getSimpleName().equals(Object)); +harness.check(InnerClass.class.getSimpleName().equals(InnerClass)); + } + public static class InnerClass { }; + public void testall() { test_toString(); @@ -594,6 +606,7 @@ public class ClassTest implements Cloneable, java.io.Serializable, Testlet // This one doesn't work so well in Mauve. // test_getResource(); test_getResourceAsStream(); +test_getSimpleName(); } -- 1.7.0.4 I've committed this to Mauve as a new test case (rather than extending ClassTest) as this should make it easier to run. I also added cases to check anonymous classes which should return . This test also unearthed another bug in CACAO which seems to think that the class of an array of an anonymous class is anonymous, while gcj, jamvm and OpenJDK all disagree. This causes it to still fail one of the test cases as it returns instead of [] for an array class with a component type that is an anonymous class. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Future blog
On 11:03 Thu 09 Dec , Andrew Haley wrote: On 12/08/2010 08:02 PM, Ivan Maidanski wrote: I remember you (or someone else) had pointed me about of inconvenience of reading my patches in the form they were attached and I had promised to use .diff.txt file extension but forgot about it after a long delay. (there is such problem in, say, hpl.com mailing list where I frequently send my patches to; besides, I have no problem in opening the attachment in the link below in Firefox which I use). I apologies for the inconvenience and I'll try to keep in my mind that it's better to use .txt extension when posting to this ML. This turns out to be a known Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=327323 The bugzilla shows a way around this problem. I appended the following line to my .mailcap: application/octet-stream;/usr/bin/emacs %u So, at least it is now possible to see the patches without first saving them and then opening in an editor as a separate action. Note that I am not recommending that anyone use incorrect MIME-types in future, just that there is at least a workaround. It also only solves part of the problem. AFAICS, you still have to open the patch in an external application instead of reading it in the mail itself. Andrew. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Future blog
On 09:42 Thu 09 Dec , Andrew Haley wrote: On 12/08/2010 05:17 PM, Dr Andrew John Hughes wrote: On 11:13 Wed 08 Dec , Andrew Haley wrote: On 12/08/2010 10:58 AM, Pekka Enberg wrote: On Wed, Dec 8, 2010 at 12:32 PM, Andrew Haley a...@redhat.com wrote: I hereby offer to review some patches. Please send pointers to the list. http://developer.classpath.org/pipermail/classpath-patches/2010-November/006511.html This needs a ChangeLog, otherwise OK. http://developer.classpath.org/pipermail/classpath-patches/2010-November/006513.html This needs a ChangeLog, otherwise OK. I've already seen these and I agree both seem fine. But Pekka needs a copyright assignment before any more work can be committed. http://developer.classpath.org/pipermail/classpath-patches/2010-November/006512.html What compatibility problem does this fix? I'd like to see a test case in Mauve for this before we change this. That's not a good reason not to commit: the fix is in other versions, including gcj. I disagree. Just because the version in gcj is different doesn't mean it's correct. As far as I'm aware, Pekka already has a testcase for this so it would be good to have it in Mauve. Andrew. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Future blog
On 09:20 Wed 08 Dec , Pekka Enberg wrote: On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes There are several inaccuracies in the points themselves. I'm not too surprised, given that Pekka is still new to the project, but I am surprised that you'd agree wholeheartedly with such little hesitation. I hope my inaccuracies didn't get into the way of the overall point. No, and as I said, they were understandable from someone new to the project. On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes gnu_and...@member.fsf.org wrote: 1.6 work has already been done on GNU Classpath, though that is now some time back; it's all there in the mailing list archives though. Last time I tested Jato with GNU Classpath, there were some obvious missing 1.6 APIs in java.lang.Math, for example. I need to check if that's changed now. The overall feel I get from GNU Classpath is that it's quite firmly stuck at 1.5 level, though. I wasn't saying it was by any means complete, just that there was already some progress in that area and we hadn't decided to do 1.5 only. For example, I updated most of the JMX implementation to the 1.6 level. Live comparisons are here: http://builder.classpath.org/japi/ I don't think the OpenJDK snapshots used have been updated in a while, so the comparison for 7 will be quite dated. On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes gnu_and...@member.fsf.org wrote: There is no 1.7 API to implement yet, so that's a pointless statement. I also tend to still believe in the general Classpath spirit that we implement primarily to match the requirements of applications, not specific applications. We have no hope of ever TCKing the thing anyway, and to my knowledge it's never been used with a JDK that's not Oracle-based so I have no trust in its reliability. There's APIs that are likely to make it into 1.7 (e.g. NIO2). I don't see much to be gained from not implementing them now. You might have a different view on what should be implemented and what not but that doesn't make my statement pointless. Ok, maybe not pointless, but hardly 'critical' as you claimed in your blog. Applications aren't going to be relying on 1.7 code just yet. I've only recently started to see 1.6 dependencies (and mainly in OpenJDK). Now the cool thing would be if I said lets do them all right now!. But instead I am going on vacation and be offline for about two weeks. Sorry about that. But I didn't want to not respond at all. As soon as I am back I would like us to at least start moving to mercurial on savannah if people don't mind. Yes, I do mind. We already discussed this some time back: http://developer.classpath.org/pipermail/classpath/2008-June/002629.html and nothing happened. I don't particularly see any huge benefit to moving the repository to a different version control system. It would make more sense if there were lots of contributors but there aren't. As is, if you're going to put some time in, I'd rather it was spent reviewing patches than messing about with the VCS. Hey, it's not as if I'm making this up! This is a genuine experience from someone who wanted to contribute a simple thing to GNU Classpath. While *you* don't see the benefit from transitioning to Mercurial or git, I certainly do, and I claim other people who are used to modern tooling see that as well. I didn't say there wasn't a benefit, I said there wasn't a 'huge benefit'. If you read the link I posted, you will see it was me who proposed a shift to Mercurial over two years ago, so I clearly think it is beneficial. I agree CVS isn't ideal by a long shot. However, in the general scheme of things, I don't think it's as important as getting patches reviewed. Moving to Mercurial is not going to make all the patches get reviewed and committed. The real advantages of DVCS show up when you have lots of active developers, and are especially useful in remote situations as they allow you to commit without having to push at the same time. But not having Mercurial hardly stops people writing patches. On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes gnu_and...@member.fsf.org wrote: One of Pekka's motivations is also flawed: 'how much problems it causes for developers that don't have commit rights to the centralized repository!' Moving it all to Mercurial just so it's easier for someone else to create a forked lower-quality copy that accepts unreviewed patches is not a good motivation IMHO. I hope you don't mean this: https://github.com/penberg/classpath because it's (a) not a fork (it's queue of patches I want to feed to mainline) and (b) I don't merge unreviewed patches (I reviewed them myself). No, I didn't mean that specifically, but your blog gave the impression that an advantage to Mercurial was that you could avoid the main repository. Sure, you can commit locally in Mercurial where you can't
Re: Future blog
On 11:05 Wed 08 Dec , Mark Wielaard wrote: Hi, On Tue, 2010-12-07 at 23:53 +, Dr Andrew John Hughes wrote: I'll apologise in advance if some of what I've written below sounds harsh, but I'm not that happy with the state of Free Java generally right now. And I apologize for not stating the obvious. You are the only active maintainer of GNU Classpath at the moment. It is unfair we aren't helping you out more. Especially because there are new hackers wanting to see their contributions integrated. Just like Mario I do feel somewhat guilty for not making the time necessary. GNU Classpath is the project that shaped me and that created a community of friends. Please don't feel discouraged by some of the details Pekka is wrong about. It is the fact that he is so positive and forward looking that made me agree so much with what he said. We need a wakeup call. People like what GNU Classpath stands for. It is an important project to move forward. It is needed to bootstrap the free java world. People want to contribute. Lets see what we can/should do to help you more. I understand some of your hesitation because we let you down. You are currently the maintainer that carries the whole load. Thanks. There is no 1.7 API to implement yet, so that's a pointless statement. 1.7 will be what OpenJDK implements. We can run japi against it to get comparisons. We already do: http://builder.classpath.org/japi/openjdk7-classpath.html though as I said in my reply to Pekka, I don't know how up-to-date the OpenJDK snapshot is. Now you have a better builder, maybe it could be done from the test builds instead. I also tend to still believe in the general Classpath spirit that we implement primarily to match the requirements of applications, not specific applications. Yes, I do agree with that. But one of the applications is making sure IcedTea can be bootstrapped. That will require more 1.6 and eventually 1.7 work. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39410 Feel free to get hacking. Every time I update IcedTea7, I usually find some new bug to workaround. We have no hope of ever TCKing the thing anyway, and to my knowledge it's never been used with a JDK that's not Oracle-based so I have no trust in its reliability. Cacao got access to the TCK. http://openjdk.java.net/groups/conformance/JckAccess/jck-access.html I agree the terms of the TCK are erroneous though. I wouldn't be happy to have to accept them. It makes open collaboration impossible. But if someone is really motivated to they could do like cacao did, mix and match GNU Classpath with Hotspot and make that work. Maybe 'ever' was a bit far, but I don't think it's the be-all-and-end-all by any means. And yes GNU Classpath + HotSpot may be possible; depends on how the decision making has changed with the transition from Sun to Oracle. The CACAO license, AFAIK, was for CACAO+OpenJDK, not CACAO+GNU Classpath. The latter seems to be forbidden by the license terms (unless you could count JAXWS as a substantial part of OpenJDK?) As soon as I am back I would like us to at least start moving to mercurial on savannah if people don't mind. Yes, I do mind. We already discussed this some time back: http://developer.classpath.org/pipermail/classpath/2008-June/002629.html and nothing happened. I don't particularly see any huge benefit to moving the repository to a different version control system. That surprises me. CVS really, really is a pain. I will be offline for two weeks, having a modern dvcs would be so nice. This entire discussion mimics the previous one fairly well, with many people outlining benefits and others not seeing the point. I do see _a_ benefit. I just don't think it's the most important thing when there are patches to be reviewed and low output. The biggest problem with CVS is the inability to work remotely, which, while nice, is hardly the biggest reason to change the version control system, when there are other more important things to do that would have a bigger impact IMHO. As is, if you're going to put some time in, I'd rather it was spent reviewing patches than messing about with the VCS. Point taken. In my defense, I like tinkering with services around the code base. Having autobuilders, a good dvcs integrated with a bug database, etc. help me get motivated that the code base is useful and in a good shape. Well if you really want to spend the time doing it, feel free from my point of view. Just make sure all that history is preserved. Thanks, Mark Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Future blog
On 10:32 Wed 08 Dec , Andrew Haley wrote: On 12/08/2010 10:05 AM, Mark Wielaard wrote: As is, if you're going to put some time in, I'd rather it was spent reviewing patches than messing about with the VCS. Point taken. In my defense, I like tinkering with services around the code base. Having autobuilders, a good dvcs integrated with a bug database, etc. help me get motivated that the code base is useful and in a good shape. Moving it all to Mercurial just so it's easier for someone else to create a forked lower-quality copy that accepts unreviewed patches is not a good motivation IMHO. That would not be the motivation. Getting rid of the pain that is CVS would be. Replaced with the pain of Mercurial. :-) Anyway, I don't mind that as long as someone else does it. (Clearly, the issue of developers without commit access is a red herring, as every developer should have commit access.) Indeed. The problem is not the VCS. It's that the people with commit access are inactive, and new developers are not at the stage where commit access can be given. Pekka has produced a number of patches that are of good quality and I'd be happy for him to have commit access. However, he first has to complete the copyright assignment process required by the FSF. In Ivan's case, I've reviewed a number of the patches and I've had to do work on most of them to get them in a state where they can be committed. This is why I've been hesitant on giving commit access if the result is that it will break things that may be hard to trace later. I'm not saying every patch has to be perfect. But I do think that they should generally be reviewed, especially when the developer is new to Classpath development. Besides, commit access is not the blocker. Most of my time is spent reviewing the patch, not committing it. It takes a couple of minutes to apply and commit a patch if it's in a state where it can be committed. On a related subject, we should give more people access to Mauve too. I have no idea who's in charge of this any more (it's on sourceware.org). I'd be happier with some of these patches if there were test cases being added to Mauve that showed the benefit. Andrew. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Future blog
On 11:13 Wed 08 Dec , Andrew Haley wrote: On 12/08/2010 10:58 AM, Pekka Enberg wrote: On Wed, Dec 8, 2010 at 12:32 PM, Andrew Haley a...@redhat.com wrote: I hereby offer to review some patches. Please send pointers to the list. http://developer.classpath.org/pipermail/classpath-patches/2010-November/006511.html This needs a ChangeLog, otherwise OK. http://developer.classpath.org/pipermail/classpath-patches/2010-November/006513.html This needs a ChangeLog, otherwise OK. I've already seen these and I agree both seem fine. But Pekka needs a copyright assignment before any more work can be committed. http://developer.classpath.org/pipermail/classpath-patches/2010-November/006512.html What compatibility problem does this fix? I'd like to see a test case in Mauve for this before we change this. It is something I've been meaning to look at for a while, but haven't got around to. There's also 10-15 patches from Ivan sitting in the archives Hmm, I had seen some discussion around those and thought they were being addressed. Bring them on! Andrew. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Future blog
On 08:16 Wed 08 Dec , Pekka Enberg wrote: On Wed, Dec 8, 2010 at 1:53 AM, Dr Andrew John Hughes gnu_and...@member.fsf.org wrote: As soon as I am back I would like us to at least start moving to mercurial on savannah if people don't mind. Yes, I do mind. We already discussed this some time back: http://developer.classpath.org/pipermail/classpath/2008-June/002629.html and nothing happened. I don't particularly see any huge benefit to moving the repository to a different version control system. It would make more sense if there were lots of contributors but there aren't. As is, if you're going to put some time in, I'd rather it was spent reviewing patches than messing about with the VCS. One of Pekka's motivations is also flawed: 'how much problems it causes for developers that don't have commit rights to the centralized repository!' Moving it all to Mercurial just so it's easier for someone else to create a forked lower-quality copy that accepts unreviewed patches is not a good motivation IMHO. The discussion earlier today: http://developer.classpath.org/pipermail/classpath-patches/2010-December/006528.html shows exactly why we do need patch review and discussion. No, no, that's not my motivation at all. Have you used Mercurial or git? CVS make local *development* unnecessary hard. I'm not trying to bypass the review process (which is a great thing!) with a tool. I just find it utterly silly that I need to manually create a git mirror of your CVS repository to make development experience sane. I've used a number of DVCS including Mercurial and git. In fact, I use Mercurial on a daily basis for OpenJDK IcedTea. I agree CVS is not ideal, but it's hardly the biggest problem here. On a side note, if you think Classpath CVS is bad, you should try working with GCC SVN. And no, using the git mirror doesn't really help, GCC's repo is just huge. Pekka -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Re[2]: Future blog
2010/12/8 Ivan Maidanski iv...@mail.ru: Hi Andrew and Pekka, Thank you Pekka but there are also some more ones (in June 2010): - http://article.gmane.org/gmane.comp.java.classpath.patches/12989 (follow the link in body to get classpath-ivmai-05.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/12988 (classpath-ivmai-06.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/12982 (classpath-ivmai-07.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/12983 (classpath-ivmai-08.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/12984 (classpath-ivmai-09.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/12985 (classpath-ivmai-10.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/12986 (classpath-ivmai-11.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/12991 (classpath-ivmai-12-v3.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/12972 (classpath-ivmai-14.diff, discussed in http://article.gmane.org/gmane.comp.java.classpath.patches/12975). classpath-ivmai-13.diff has just been reviewed by Andrew. And, here is the unprocessed ones listed by Pekka: - http://developer.classpath.org/pipermail/classpath-patches/2010-June/006438.html (classpath-ivmai-15.diff); - http://developer.classpath.org/pipermail/classpath-patches/2010-June/006439.html (classpath-ivmai-16.diff); - http://developer.classpath.org/pipermail/classpath-patches/2010-June/006440.html (classpath-ivmai-17.diff); - http://developer.classpath.org/pipermail/classpath-patches/2010-June/006441.html (classpath-ivmai-18.diff); - http://developer.classpath.org/pipermail/classpath-patches/2010-June/006442.html (classpath-ivmai-19.diff); - http://developer.classpath.org/pipermail/classpath-patches/2010-June/006443.html (classpath-ivmai-20.diff); - http://developer.classpath.org/pipermail/classpath-patches/2010-June/006444.html (classpath-ivmai-21.diff); - http://developer.classpath.org/pipermail/classpath-patches/2010-June/006445.html (classpath-ivmai-22.diff); - http://developer.classpath.org/pipermail/classpath-patches/2010-June/006446.html (classpath-ivmai-23.diff); - http://developer.classpath.org/pipermail/classpath-patches/2010-June/006447.html (classpath-ivmai-24.diff); - http://developer.classpath.org/pipermail/classpath-patches/2010-June/006448.html (classpath-ivmai-25.diff); And, some more unprocessed ones posted in July: - http://article.gmane.org/gmane.comp.java.classpath.patches/13009 (classpath-ivmai-26.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/13010 (classpath-ivmai-27.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/13011 (classpath-ivmai-28.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/13012 (classpath-ivmai-29.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/13013 (classpath-ivmai-30.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/13015 (classpath-ivmai-31.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/13016 (classpath-ivmai-32.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/13018 (classpath-ivmai-33.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/13020 (classpath-ivmai-34.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/13021 (classpath-ivmai-35.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/13022 (classpath-ivmai-36.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/13023 (classpath-ivmai-37.diff). and, the recently published ones (and discussed with Pekka): - http://article.gmane.org/gmane.comp.java.classpath.patches/13052 (classpath-ivmai-38.diff); - http://article.gmane.org/gmane.comp.java.classpath.patches/13056 (classpath-ivmai-39.diff, the test case provided turned out to be irrelevant to the patch provided as discussed in the thread http://thread.gmane.org/gmane.comp.java.classpath.patches/13078); - http://article.gmane.org/gmane.comp.java.classpath.patches/13058 (classpath-ivmai-40.diff, just adds the test case for classpath-ivmai-33.diff). I really apologies for such huge amount of patches posted :( Don't! We should be the ones apologising for not reviewing them sooner. Regards. Wed, 8 Dec 2010 13:32:20 +0200 Pekka Enberg penb...@kernel.org: On Wed, Dec 8, 2010 at 1:13 PM, Andrew Haley a...@redhat.com wrote: There's also 10-15 patches from Ivan sitting in the archives Hmm, I had seen some discussion around those and thought they were being addressed. Bring them on! I'm not sure if this is all of it but it's a start anyway: ... -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath
Re: [cp-patches] Fwd: Patch for parse() of DecimalFormat and SimpleDateFormat
On 00:19 Tue 07 Dec , Pekka Enberg wrote: 2010/12/6 Ivan Maidanski iv...@mail.ru: Googling around doesn't seem to bring anything on the topic which makes me think this is an old bug that nobody really cares about but there can be applications out there that rely on the current behavior that would be broken under GNU Classpath. Not would - is broken now. The patch would make it less broken. (returning 4 digits for the test case is definitely wrong here) Why not to fix this first (a long with the other bugs fixed by the proposed patch) and then think (discuss with the community) should we remove stop position calculation or not (if yes then prepare a separate small patch for it). I meant applications relying on the current behavior of OpenJDK so it's probably not worth it to make the behavior correct in either of the projects. But sure, I do think your patch is an improvement as-is so I'm for merging your patch even with the stop position calculation (that I think needs to go at some point). Is there some GNU Classpath maintainer around who agrees or disagrees with the patch? What can we do to make the patch more palatable for merging? I haven't looked at the patch yet. This thread is rather hard to follow and doesn't seem to connect to the original patch post. However, I think the OpenJDK behaviour is correct and the expected result of the test case wrong. The NumberFormat class is designed for both formatting and parsing. The documentation is rather unclear, but does state: 'NumberFormat and DecimalFormat are designed such that some controls work for formatting and others work for parsing' and 'You can also control the display of numbers with such methods as setMinimumFractionDigits.' (note the word 'display') so I believe these setMin, setMax, etc. methods are only meant to affect the display of the numbers. Indeed, if you change the last line of the test case to: System.out.println(numberFormat.format(numberFormat.parse(1234567890))); OpenJDK will print 90 while Classpath prints 34 (because of the earlier broken parsing). So max/min is interpreted right to left. Thus, Classpath should be fixed to give the same results as OpenJDK. One thing Classpath could do is document this much better... Pekka -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Future blog
On 23:06 Tue 07 Dec , Mark Wielaard wrote: Hi all, Hi Mark, I'll apologise in advance if some of what I've written below sounds harsh, but I'm not that happy with the state of Free Java generally right now. For those who didn't see Pekka's blog on planet.classpath.org you can find it here: http://penberg.posterous.com/whats-the-future-of-gnu-classpath He makes some very good points. I agree with all of them. I agree on the general overtone. Indeed, I already blogged about it: http://blog.fuseyism.com/index.php/2010/11/03/the-homogenisation-of-the-java-platform/ There are several inaccuracies in the points themselves. I'm not too surprised, given that Pekka is still new to the project, but I am surprised that you'd agree wholeheartedly with such little hesitation. Mauve has not been abandoned (as you acknowledge below). You merely need to look at the logs to see that tests have been added e.g. http://sources.redhat.com/cgi-bin/cvsweb.cgi/mauve/gnu/testlet/java/security/Policy/setPolicy.java?cvsroot=mauve I posted to the Mauve mailing list about this last week. It is in the same state as GNU Classpath, in that there are very few contributors, but it has not been abandoned. 1.6 work has already been done on GNU Classpath, though that is now some time back; it's all there in the mailing list archives though. There is no 1.7 API to implement yet, so that's a pointless statement. I also tend to still believe in the general Classpath spirit that we implement primarily to match the requirements of applications, not specific applications. We have no hope of ever TCKing the thing anyway, and to my knowledge it's never been used with a JDK that's not Oracle-based so I have no trust in its reliability. Now the cool thing would be if I said lets do them all right now!. But instead I am going on vacation and be offline for about two weeks. Sorry about that. But I didn't want to not respond at all. As soon as I am back I would like us to at least start moving to mercurial on savannah if people don't mind. Yes, I do mind. We already discussed this some time back: http://developer.classpath.org/pipermail/classpath/2008-June/002629.html and nothing happened. I don't particularly see any huge benefit to moving the repository to a different version control system. It would make more sense if there were lots of contributors but there aren't. As is, if you're going to put some time in, I'd rather it was spent reviewing patches than messing about with the VCS. One of Pekka's motivations is also flawed: 'how much problems it causes for developers that don't have commit rights to the centralized repository!' Moving it all to Mercurial just so it's easier for someone else to create a forked lower-quality copy that accepts unreviewed patches is not a good motivation IMHO. The discussion earlier today: http://developer.classpath.org/pipermail/classpath-patches/2010-December/006528.html shows exactly why we do need patch review and discussion. This is just because other projects around free java (hi openjdk) are also using mercurial and it seems convenient to use something similar, but other suggestions appreciated. Hopefully we can do something similar for Mauve (it isn't abandoned, more in the same state as GNU Classpath). And somehow integrate/extend it with Malva and the jtreg testsuite from OpenJDK. (They probably should stay separate projects, but at least the autobuilder should run them. The autobuilder is in a really bad shape, but there is a new host already that can pick up the load.) jtreg would have to be a project to begin with. It doesn't seem to be one at present, and I'd barely call OpenJDK one either. Why else are we all working on IcedTea? The discussion on the patches mailinglist does show a real problem though. We have very little active hackers, and so aren't doing very well helping new hackers like Pekka and Ivan to get their work integrated. I agree this is a problem. But whining about it won't help. Getting involved would. I'm doing my best but I can't do everything. There are only so many hours in the day. I'd prefer to spend more of those hours on GNU Classpath rather than the intense boredom of IcedTea/OpenJDK work, but unfortunately that's not how the cards are stacked. Opinions? Suggestions? Flames? Thanks, Mark -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
[cp-patches] FYI: PR46775: Ensure setPolicy calls are reflected by the default SecurityManager
I've just pushed the attached fix for a bug in the reference VMAccessController implementation (PR46775). When Policy.setPolicy was used to set a new Policy object, the default SecurityManager should reflect this change. This wasn't the case prior to this patch as VMAccessController creates ProtectionDomain objects with the two argument constructor which enforces static permissions. This fix replaces these calls with the four argument constructor so the Policy is consulted. 2010-12-02 Andrew John Hughes ahug...@redhat.com PR classpath/46775 * vm/reference/java/security/VMAccessController.java: (DEFAULT_CONTEXT): Create ProtectionDomain with four argument constructor (arguments are the same as those implied by the two argument constructor). (getContext()): Create ProtectionDomain instances with four argument constructor using a null Principal array (as before) but including the classloader, which was always null before. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 Index: vm/reference/java/security/VMAccessController.java === RCS file: /sources/classpath/classpath/vm/reference/java/security/VMAccessController.java,v retrieving revision 1.8 diff -u -u -r1.8 VMAccessController.java --- vm/reference/java/security/VMAccessController.java 3 Jun 2010 19:14:41 - 1.8 +++ vm/reference/java/security/VMAccessController.java 3 Dec 2010 00:45:15 - @@ -71,7 +71,7 @@ Permissions permissions = new Permissions(); permissions.add(new AllPermission()); ProtectionDomain[] domain = new ProtectionDomain[] { - new ProtectionDomain(source, permissions) + new ProtectionDomain(source, permissions, null, null) }; DEFAULT_CONTEXT = new AccessControlContext(domain); } @@ -188,12 +188,13 @@ { Class clazz = classes[i]; String method = methods[i]; +ClassLoader loader = clazz.getClassLoader(); if (DEBUG) { debug(checking + clazz + . + method); // subject to getClassLoader RuntimePermission -debug(loader = + clazz.getClassLoader()); +debug(loader = + loader); } // If the previous frame was a call to doPrivileged, then this is @@ -225,7 +226,8 @@ // Create a static snapshot of this domain, which may change over time // if the current policy changes. domains.add(new ProtectionDomain(domain.getCodeSource(), - domain.getPermissions())); + domain.getPermissions(), + loader, null)); } if (DEBUG)
Re: Savannah accident
On 30 November 2010 21:23, Mark Wielaard m...@klomp.org wrote: On Tue, 2010-11-30 at 19:35 +, Dr Andrew John Hughes wrote: That explains why I couldn't cvs update yesterday. I wonder why I didn't get this message too? Maybe I just missed it. The message is up on http://savannah.gnu.org/ you might have missed it if you didn't look there after your CVS update failed. No I didn't look there. I just assumed it was a temporary glitch. I thought you'd got that in e-mail, didn't realise it was a copy and paste job :-) -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
[cp-patches] FYI: Fix issues with recent autotools
The attached patch adds the missing config.rpath now required by the use of AM_ICONV (presumably due to changes in libtool which seems to have supplied it previously) and fixes some warnings arising with autoconf 2.68. 2010-11-04 Andrew John Hughes ahug...@redhat.com * config.rpath: Add file required by autogen.sh due to use of AM_ICONV. * m4/ax_func_which_gethostbyname_r.m4: Use AC_LANG_SOURCE as suggested by warnings from autoconf 2.68. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 Index: config.rpath === RCS file: config.rpath diff -N config.rpath --- /dev/null 1 Jan 1970 00:00:00 - +++ config.rpath5 Nov 2010 00:44:50 - @@ -0,0 +1,672 @@ +#! /bin/sh +# Output a system dependent set of variables, describing how to set the +# run time search path of shared libraries in an executable. +# +# Copyright 1996-2010 Free Software Foundation, Inc. +# Taken from GNU libtool, 2001 +# Originally by Gordon Matzigkeit g...@gnu.ai.mit.edu, 1996 +# +# This file is free software; the Free Software Foundation gives +# unlimited permission to copy and/or distribute it, with or without +# modifications, as long as this notice is preserved. +# +# The first argument passed to this file is the canonical host specification, +#CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM +# or +#CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM +# The environment variables CC, GCC, LDFLAGS, LD, with_gnu_ld +# should be set by the caller. +# +# The set of defined variables is at the end of this script. + +# Known limitations: +# - On IRIX 6.5 with CC=cc, the run time search patch must not be longer +# than 256 bytes, otherwise the compiler driver will dump core. The only +# known workaround is to choose shorter directory names for the build +# directory and/or the installation directory. + +# All known linkers require a `.a' archive for static linking (except MSVC, +# which needs '.lib'). +libext=a +shrext=.so + +host=$1 +host_cpu=`echo $host | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\1/'` +host_vendor=`echo $host | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\2/'` +host_os=`echo $host | sed 's/^\([^-]*\)-\([^-]*\)-\(.*\)$/\3/'` + +# Code taken from libtool.m4's _LT_CC_BASENAME. + +for cc_temp in $CC; do + case $cc_temp in +compile | *[\\/]compile | ccache | *[\\/]ccache ) ;; +distcc | *[\\/]distcc | purify | *[\\/]purify ) ;; +\-*) ;; +*) break;; + esac +done +cc_basename=`echo $cc_temp | sed -e 's%^.*/%%'` + +# Code taken from libtool.m4's _LT_COMPILER_PIC. + +wl= +if test $GCC = yes; then + wl='-Wl,' +else + case $host_os in +aix*) + wl='-Wl,' + ;; +darwin*) + case $cc_basename in +xlc*) + wl='-Wl,' + ;; + esac + ;; +mingw* | cygwin* | pw32* | os2* | cegcc*) + ;; +hpux9* | hpux10* | hpux11*) + wl='-Wl,' + ;; +irix5* | irix6* | nonstopux*) + wl='-Wl,' + ;; +newsos6) + ;; +linux* | k*bsd*-gnu) + case $cc_basename in +ecc*) + wl='-Wl,' + ;; +icc* | ifort*) + wl='-Wl,' + ;; +lf95*) + wl='-Wl,' + ;; +pgcc | pgf77 | pgf90) + wl='-Wl,' + ;; +ccc*) + wl='-Wl,' + ;; +como) + wl='-lopt=' + ;; +*) + case `$CC -V 21 | sed 5q` in +*Sun\ C*) + wl='-Wl,' + ;; + esac + ;; + esac + ;; +osf3* | osf4* | osf5*) + wl='-Wl,' + ;; +rdos*) + ;; +solaris*) + wl='-Wl,' + ;; +sunos4*) + wl='-Qoption ld ' + ;; +sysv4 | sysv4.2uw2* | sysv4.3*) + wl='-Wl,' + ;; +sysv4*MP*) + ;; +sysv5* | unixware* | sco3.2v5* | sco5v6* | OpenUNIX*) + wl='-Wl,' + ;; +unicos*) + wl='-Wl,' + ;; +uts4*) + ;; + esac +fi + +# Code taken from libtool.m4's _LT_LINKER_SHLIBS. + +hardcode_libdir_flag_spec= +hardcode_libdir_separator= +hardcode_direct=no +hardcode_minus_L=no + +case $host_os in + cygwin* | mingw* | pw32* | cegcc*) +# FIXME: the MSVC++ port hasn't been tested in a lng time +# When not using gcc, we currently assume that we are using +# Microsoft Visual C++. +if test $GCC != yes; then + with_gnu_ld=no +fi +;; + interix*) +# we just hope/assume this is gcc and not c89 (= MSVC++) +with_gnu_ld=yes +;; + openbsd*) +with_gnu_ld=no +;; +esac + +ld_shlibs=yes +if test $with_gnu_ld = yes; then + # Set some defaults for GNU ld with shared library support. These +
Re: [cp-patches] [PATCH v2] Use CLOCK_MONOTONIC for System.nanoTime
On 26 October 2010 21:00, Pekka Enberg penb...@kernel.org wrote: Hi everyone, I'm now carrying this and one other patch in my github branch: http://github.com/penberg/classpath/tree/maint/penberg It's frustrating that CVS trunk doesn't build out of the box and that reviewed patches are not getting merged. :( Pekka Sorry for the delay on this, but I'm unsure about the copyright situation. From reading http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44411, it seems to be the work of Roland Brand, it's his first patch and both myself and Mark agree it's trivial enough to go in with an assignment from Roland. However, any further patches from Roland would need an assignment. If you can confirm this is the correct origin of the patch, I'll commit it. I'm not aware of the CVS build being broken. It certainly builds here. Can you provide more information? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] Membership request for group classpath
2010/10/25 Ivan Maidanski iv...@mail.ru: Hi, Andrew! Is it possible to finally get commit access? It seems nobody else is willing to review and commit to. The patches were published at least 3 months ago and there is no pending questions or negative comments (from the interested parties) regarding them. I'm afraid you don't get to commit patches just because some arbitrary amount of time has passed. This is especially true of Classpath at the moment as it's more likely that no-one has had the time to look at them than that they can be assumed fine. I'm wary about giving commit access, as your previous patches have required further work to apply to current CVS HEAD and in some cases, have caused build breakage. Also, from your previous e-mails, I believe you stated that you weren't working on CVS HEAD or doing normal builds of the code, and I wouldn't feel happy allowing commits in this situation. I'm also planning to create new patches (fixing bugs in Number/DateFormatter parsers) but if the patches are unlikely to be committed then there is little sense in submitting them. We are grateful for these patch submissions. And they will get reviewed. Sadly, there are only a certain number of hours in the day so I'm afraid you'll just have to be patient. I don't see any reason why you need to wait for the existing ones to be committed before posting more. My main concern is that they are out there and available for review/commit as time allows. Regards. Tue, 01 Jun 2010 14:56:07 +0400 Ivan Maidanski iv...@mail.ru: Hi! Tue, 1 Jun 2010 11:32:25 +0100 Andrew John Hughes ahug...@redhat.com: On 21:22 Sat 29 May , Ivan Maidanski wrote: Hello, Andrew! I've signed the copyright paper and also recently received it (with the both signatures) via e-mail. What's the next step? Hi Ivan. Yes, I saw the assignment come through as I finished work on Friday. I need to finish looking through the remaining patches you posted. Once those are ok to go back, I'll give you commit access to push them. Ok. Thanks. This is NOT urgent. (Currently I've sent roughly 1/2 of patches I've intended to submit, and the unsent party is a bit more complicated.) Please understand that with such power comes responsibility so please use it wisely :-) Ok. I've got experience in BoehmGC. Thanks. Sun, 11 Apr 2010 23:56:53 +0100 Andrew John Hughes ahug...@redhat.com: On 11:04 Sat 10 Apr , Ivan Maidanski wrote: Fri, 09 Apr 2010 18:13:42 +0200 Mark Wielaard m...@klomp.org: On Thu, 2010-04-08 at 21:34 +0100, Andrew John Hughes wrote: I need to speak to Mark about this process when he returns from paternity leave. Still somewhat sleep deprived from handling the new family addition, but I am reading email again. Sorry for any delays. On 8 April 2010 14:01, Ivan Maidanski iv...@mail.ru wrote: I'd like to contribute patches for Classpath. I have a lot of small bug fixes and minor code speed improvements (which I've collected over 5 year), as well as some java generics has been added, and now I'd like to push them all to the community - I've grouped the changes and prepared the patch files (10 files, 450K overall) against the latest SVN. Wow, cool. The best course of action would be to send them, if at all possible as separate patches to the classpath-patches@gnu.org mailinglist, so others can help get them reviewed and merged. Well, I could send them to the entitled email but AICS there is no others getting them reviewed and merged (probably, because of JDK which turned into OpenJDK). They still need to be posted. CC me and I'll make sure they get reviewed. I already did so for one patch. But I can't make every patch less than 15 lines. (So, if I understood correctly, they hardly be merged to the trunk.) This is 15 lines over all patches, not per patch i.e. anything more than a trivial fix needs an assignment. On the other hand, I could just send them to and forget about it, because I can have a legal copy of Classpath on my side and patch it in any way I like. True. Though nice to contribute back if you can. As Andrew said the FSF would like to keep a record of all contributions. Would you be willing to assign the copyright to the Free Software Foundation, so that we could add your patches to GNU Classpath? It seems to me (w/o yet looking into the real papers), I won't loose anything if I assign. Great. The FSF still a bit old fashioned and deals in real paper records. They will send you a copy if you complete the attached request form and send it, with as subject your full name to ass...@gnu.org (please CC me and Andrew so we can keep
Re: [cp-patches] [PATCH v2] Use CLOCK_MONOTONIC for System.nanoTime
On 4 November 2010 13:27, Pekka Enberg penb...@kernel.org wrote: On 11/4/10 3:18 PM, Dr Andrew John Hughes wrote: Sorry for the delay on this, but I'm unsure about the copyright situation. From reading http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44411, it seems to be the work of Roland Brand, it's his first patch and both myself and Mark agree it's trivial enough to go in with an assignment from Roland. However, any further patches from Roland would need an assignment. If you can confirm this is the correct origin of the patch, I'll commit it. Yes, the patch I sent is taken from that bugzilla issue. I cleaned it up bit myself as per review comments. I've committed the change as attached. This additionally reverts back to the old behaviour if CLOCK_MONOTONIC is unavailable as suggested on the bug report. I'm not aware of the CVS build being broken. It certainly builds here. Can you provide more information? It's this commit here: https://github.com/penberg/classpath/commit/6201f571b267f47f2b51797da6bdcb8048131672 AFAIK, it's known breakage and the fix was suggested by mjw. Ok, I'll look at adding config.rpath to the repository though I have no idea why this problem has suddenly arisen. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] [PATCH v2] Use CLOCK_MONOTONIC for System.nanoTime
On 5 November 2010 00:16, Dr Andrew John Hughes gnu_and...@member.fsf.org wrote: On 4 November 2010 13:27, Pekka Enberg penb...@kernel.org wrote: On 11/4/10 3:18 PM, Dr Andrew John Hughes wrote: Sorry for the delay on this, but I'm unsure about the copyright situation. From reading http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44411, it seems to be the work of Roland Brand, it's his first patch and both myself and Mark agree it's trivial enough to go in with an assignment from Roland. However, any further patches from Roland would need an assignment. If you can confirm this is the correct origin of the patch, I'll commit it. Yes, the patch I sent is taken from that bugzilla issue. I cleaned it up bit myself as per review comments. I've committed the change as attached. This additionally reverts back to the old behaviour if CLOCK_MONOTONIC is unavailable as suggested on the bug report. I'm not aware of the CVS build being broken. It certainly builds here. Can you provide more information? It's this commit here: https://github.com/penberg/classpath/commit/6201f571b267f47f2b51797da6bdcb8048131672 AFAIK, it's known breakage and the fix was suggested by mjw. Ok, I'll look at adding config.rpath to the repository though I have no idea why this problem has suddenly arisen. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 And here's the patch. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 pr44411.patch Description: Binary data
Re: [cp-patches] [PATCH] native: Use CLOCK_MONOTONIC for System.nanoTime
On 23 September 2010 17:20, Pekka Enberg penb...@kernel.org wrote: From: Roland Brand roland.br...@ergon.ch As explained by AdamB: On Linux, Classpath appears to implement the System.nanoTime() function using the gettimeofday function (see java_lang_VMSystem.c). Since gettimeofday returns a wall-clock time this makes it unreliable for measuring elapsed time, (because the system clock could be changed by another process at any moment. According to the Sun javadocs: ... This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. The value returned represents nanoseconds since some fixed but arbitrary time ... In short, gettimeofday is not appropriate for measuring elapsed time. This patch fixes System.nanoTime() to use CLOCK_MONOTONIC which is what OpenJDK does as well. Cc: AdamB ad...@videx.com Cc: Mark Wielaard m...@klomp.org Cc: Roland Brand roland.br...@ergon.ch Bugzilla-URL: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44411 Signed-off-by: Pekka Enberg penb...@kernel.org --- native/jni/java-lang/java_lang_VMSystem.c | 26 +- vm/reference/java/lang/VMSystem.java | 5 + 2 files changed, 26 insertions(+), 5 deletions(-) diff --git a/native/jni/java-lang/java_lang_VMSystem.c b/native/jni/java-lang/java_lang_VMSystem.c index d203227..80315a5 100644 --- a/native/jni/java-lang/java_lang_VMSystem.c +++ b/native/jni/java-lang/java_lang_VMSystem.c @@ -39,6 +39,7 @@ exception statement from your version. */ #include jcl.h +#include time.h #include sys/time.h #include stdlib.h @@ -121,6 +122,29 @@ Java_java_lang_VMSystem_nanoTime (JNIEnv * env __attribute__ ((__unused__)), jclass thisClass __attribute__ ((__unused__))) { + jlong result; + struct timespec tp; + + if (clock_gettime (CLOCK_MONOTONIC, tp) == -1) + (*env)-FatalError (env, clock_gettime call failed.); + + result = (jlong) tp.tv_sec; + result *= (jlong)10L; + result += (jlong)tp.tv_nsec; + + return result; +} + +/* + * Class: java_lang_VMSystem + * Method: currentTimeMillis + * Signature: ()J + */ +JNIEXPORT jlong JNICALL +Java_java_lang_VMSystem_currentTimeMillis + (JNIEnv * env __attribute__ ((__unused__)), + jclass thisClass __attribute__ ((__unused__))) +{ /* Note: this implementation copied directly from Japhar's, by Chris Toshok. */ jlong result; struct timeval tp; @@ -131,7 +155,7 @@ Java_java_lang_VMSystem_nanoTime result = (jlong) tp.tv_sec; result *= (jlong)100L; result += (jlong)tp.tv_usec; - result *= (jlong)1000; + result /= (jlong)1000L; return result; } diff --git a/vm/reference/java/lang/VMSystem.java b/vm/reference/java/lang/VMSystem.java index a194663..0b3d692 100644 --- a/vm/reference/java/lang/VMSystem.java +++ b/vm/reference/java/lang/VMSystem.java @@ -129,10 +129,7 @@ final class VMSystem * @return the current time * @see java.util.Date */ - static long currentTimeMillis() - { - return nanoTime() / 100L; - } + static native long currentTimeMillis(); /** * p -- 1.7.0.4 I'd suggest including the error text in the message returned by FatalError (sys_errlist[errno]). Otherwise, looks good. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] [PATCH v2] Use CLOCK_MONOTONIC for System.nanoTime
On 23 September 2010 18:43, Pekka Enberg penb...@kernel.org wrote: From: Roland Brand roland.br...@ergon.ch As explained by AdamB: On Linux, Classpath appears to implement the System.nanoTime() function using the gettimeofday function (see java_lang_VMSystem.c). Since gettimeofday returns a wall-clock time this makes it unreliable for measuring elapsed time, (because the system clock could be changed by another process at any moment. According to the Sun javadocs: ... This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. The value returned represents nanoseconds since some fixed but arbitrary time ... In short, gettimeofday is not appropriate for measuring elapsed time. This patch fixes System.nanoTime() to use CLOCK_MONOTONIC which is what OpenJDK does as well. Cc: Andrew Hughes gnu_and...@members.fsf.org Cc: AdamB ad...@videx.com Cc: Mark Wielaard m...@klomp.org Cc: Roland Brand roland.br...@ergon.ch Bugzilla-URL: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44411 Signed-off-by: Pekka Enberg penb...@kernel.org --- v1 - v2: Use strerror() to pass human readable error message to FatalError() as suggested by Andrew Hughes native/jni/java-lang/java_lang_VMSystem.c | 30 - vm/reference/java/lang/VMSystem.java | 5 +--- 2 files changed, 30 insertions(+), 5 deletions(-) diff --git a/native/jni/java-lang/java_lang_VMSystem.c b/native/jni/java-lang/java_lang_VMSystem.c index d203227..4ff7355 100644 --- a/native/jni/java-lang/java_lang_VMSystem.c +++ b/native/jni/java-lang/java_lang_VMSystem.c @@ -39,8 +39,10 @@ exception statement from your version. */ #include jcl.h +#include time.h #include sys/time.h #include stdlib.h +#include errno.h /* * Class: java_lang_VMSystem @@ -121,6 +123,32 @@ Java_java_lang_VMSystem_nanoTime (JNIEnv * env __attribute__ ((__unused__)), jclass thisClass __attribute__ ((__unused__))) { + jlong result; + struct timespec tp; + + if (clock_gettime (CLOCK_MONOTONIC, tp) == -1) { + char error[64]; + snprintf(error, 64, clock_gettime call failed: %s., strerror(errno)); + (*env)-FatalError (env, error); + } + + result = (jlong) tp.tv_sec; + result *= (jlong)10L; + result += (jlong)tp.tv_nsec; + + return result; +} + +/* + * Class: java_lang_VMSystem + * Method: currentTimeMillis + * Signature: ()J + */ +JNIEXPORT jlong JNICALL +Java_java_lang_VMSystem_currentTimeMillis + (JNIEnv * env __attribute__ ((__unused__)), + jclass thisClass __attribute__ ((__unused__))) +{ /* Note: this implementation copied directly from Japhar's, by Chris Toshok. */ jlong result; struct timeval tp; @@ -131,7 +159,7 @@ Java_java_lang_VMSystem_nanoTime result = (jlong) tp.tv_sec; result *= (jlong)100L; result += (jlong)tp.tv_usec; - result *= (jlong)1000; + result /= (jlong)1000L; return result; } diff --git a/vm/reference/java/lang/VMSystem.java b/vm/reference/java/lang/VMSystem.java index a194663..0b3d692 100644 --- a/vm/reference/java/lang/VMSystem.java +++ b/vm/reference/java/lang/VMSystem.java @@ -129,10 +129,7 @@ final class VMSystem * @return the current time * @see java.util.Date */ - static long currentTimeMillis() - { - return nanoTime() / 100L; - } + static native long currentTimeMillis(); /** * p -- 1.7.0.4 Thanks! strerror was the function I wanted but I couldn't think of it at the time, and the perror manpage listed sys_errlist. I'll check out the copyright situation on the patch and commit it as soon as I can. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] Minor debugging-related code refinements in gnu.java.security and gnu.javax.crypto
On 14:30 Sun 09 May , Ivan Maidanski wrote: Hi! This is a very minor code refinement - I just guarded the code initializing log variables (which are used only for debugging in the classes of the entitled packages) with if (Configuration.DEBUG), so the Logger stuff is no longer compiled in and called at the class initialization (unless the debugging mode in on). Among other minor fixes - an added class type check of the object returned by newInstance() in CSPRNG.getSystemInstance(). Committed, without the merging of the catch blocks in CSPRNG as this would hide additional exceptions. ChangeLog entries: * gnu/java/security/Properties.java: Initialize log private static variable to null (don't unnecessarily call Logger.getLogger) in case of Configuration.DEBUG is false (the variable is unused when the debugging mode is off). * gnu/java/security/hash/Whirlpool.java: Likewise. * gnu/java/security/jce/sig/EncodedKeyFactory.java: Likewise. * gnu/java/security/jce/sig/SignatureAdapter.java: Likewise. * gnu/java/security/key/dss/DSSKeyPairGenerator.java: Likewise. * gnu/java/security/key/dss/DSSKeyPairPKCS8Codec.java: Likewise. * gnu/java/security/key/rsa/RSAKeyPairGenerator.java: Likewise. * gnu/java/security/key/rsa/RSAKeyPairPKCS8Codec.java: Likewise. * gnu/java/security/key/rsa/RSAKeyPairX509Codec.java: Likewise. * gnu/java/security/pkcs/PKCS7SignedData.java: Likewise. * gnu/java/security/pkcs/SignerInfo.java: Likewise. * gnu/java/security/provider/PKIXCertPathValidatorImpl.java: Likewise. * gnu/java/security/sig/rsa/EMSA_PSS.java: Likewise. * gnu/java/security/sig/rsa/RSAPSSSignature.java: Likewise. * gnu/java/security/x509/X509CRL.java: Likewise. * gnu/java/security/x509/X509CRLEntry.java: Likewise. * gnu/java/security/x509/ext/Extension.java: Likewise. * gnu/javax/crypto/cipher/Anubis.java: Likewise. * gnu/javax/crypto/cipher/BaseCipher.java: Likewise. * gnu/javax/crypto/cipher/Khazad.java: Likewise. * gnu/javax/crypto/cipher/Rijndael.java: Likewise. * gnu/javax/crypto/cipher/Twofish.java: Likewise. * gnu/javax/crypto/jce/cipher/KeyWrappingAlgorithmAdapter.java: Likewise. * gnu/javax/crypto/jce/keyring/GnuKeyring.java: Likewise. * gnu/javax/crypto/jce/params/BlockCipherParameters.java: Likewise. * gnu/javax/crypto/jce/prng/ICMRandomSpi.java: Likewise. * gnu/javax/crypto/jce/prng/UMacRandomSpi.java: Likewise. * gnu/javax/crypto/key/dh/GnuDHKeyPairGenerator.java: Likewise. * gnu/javax/crypto/key/srp6/SRPKeyPairGenerator.java: Likewise. * gnu/javax/crypto/keyring/Entry.java: Likewise. * gnu/javax/crypto/keyring/EnvelopeEntry.java: Likewise. * gnu/javax/crypto/keyring/GnuPublicKeyring.java: Likewise. * gnu/javax/crypto/mac/OMAC.java: Likewise. * gnu/javax/crypto/pad/BasePad.java: Likewise. * gnu/javax/crypto/pad/PKCS1_V1_5.java: Likewise. * gnu/javax/crypto/pad/PKCS7.java: Likewise. * gnu/javax/crypto/pad/TBC.java: Likewise. * gnu/javax/crypto/prng/CSPRNG.java: Likewise. * gnu/javax/crypto/sasl/SaslInputStream.java: Likewise. * gnu/javax/crypto/sasl/SaslOutputStream.java: Likewise. * gnu/javax/crypto/sasl/srp/SRPClient.java: Likewise. * gnu/javax/crypto/sasl/srp/SRPServer.java: Likewise. * gnu/javax/security/auth/login/ConfigFileParser.java: Likewise. * gnu/javax/security/auth/login/ConfigFileTokenizer.java: Likewise. * gnu/javax/security/auth/login/GnuConfiguration.java: Likewise. * java/math/BigInteger.java: Likewise. * gnu/java/security/der/DERWriter.java (toUtf8): Don't unnecessarily use FP arithmetic. * gnu/java/security/pkcs/SignerInfo.java (SignerInfo): Log version string only if Configuration.DEBUG. * gnu/javax/crypto/key/dh/GnuDHKeyPairGenerator.java (sha): Remove unused private variable. * gnu/javax/crypto/prng/CSPRNG.java (getSystemInstance): Collapse all catches for forName/newInstance() into a single one; add a cast to EntropySource to ignore instances of wrong type (before adding newly-created instance to l. * gnu/javax/security/auth/login/ConfigFileParser.java (map): Make the private variable final. * gnu/javax/security/auth/login/ConfigFileTokenizer.java (br): Likewise. * gnu/javax/security/auth/login/ConfigFileTokenizer.java (ConfigFileTokenizer): Remove redundant super() call and initialised initialization to false. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK
Re: SSL communication problem Classpath 0.97.2
On 13 January 2009 14:09, mohammad jouni mohammad.jo...@gmail.com wrote: Hello Everyone , I am attempting to run an application that uses SSL communication using JamVM and GNU Classpath 0.97.2 . Every time I attempt to run the application I am presented with the following error : java.io.IOException at javax.net.ssl.SSLSocketFactory$ErrorSocketFactory.createSocket(SSLSocketFactory.java:178) at EchoClient.main(EchoClient.java:18) Caused by: java.lang.RuntimeException: error instantiating default socket factory: java.security.KeyManagementException: java.security.KeyStoreException: gnu.javax.crypto.keyring.MalformedKeyringException: MAC verification failed at javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:147) at EchoClient.main(EchoClient.java:17) Caused by: java.security.KeyManagementException: java.security.KeyStoreException: gnu.javax.crypto.keyring.MalformedKeyringException: MAC verification failed at gnu.javax.net.ssl.provider.SSLContextImpl.defaultTrustManager(SSLContextImpl.java:283) at gnu.javax.net.ssl.provider.SSLContextImpl.engineInit(SSLContextImpl.java:202) at javax.net.ssl.SSLContext.init(SSLContext.java:291) at javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:141) ...1 more Caused by: java.security.KeyStoreException: gnu.javax.crypto.keyring.MalformedKeyringException: MAC verification failed at gnu.javax.net.ssl.provider.X509TrustManagerFactory.engineInit(X509TrustManagerFactory.java:173) at javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:285) at gnu.javax.net.ssl.provider.SSLContextImpl.defaultTrustManager(SSLContextImpl.java:270) ...4 more Caused by: gnu.javax.crypto.keyring.MalformedKeyringException: MAC verification failed at gnu.javax.crypto.keyring.PasswordAuthenticatedEntry.decode(PasswordAuthenticatedEntry.java:108) at gnu.javax.crypto.keyring.GnuPrivateKeyring.load(GnuPrivateKeyring.java:354) at gnu.javax.crypto.keyring.BaseKeyring.load(BaseKeyring.java:77) at gnu.javax.crypto.jce.keyring.GnuKeyring.loadPrivateKeyring(GnuKeyring.java:429) at gnu.javax.crypto.jce.keyring.GnuKeyring.engineLoad(GnuKeyring.java:350) at java.security.KeyStore.load(KeyStore.java:500) at gnu.javax.net.ssl.provider.X509TrustManagerFactory.engineInit(X509TrustManagerFactory.java:169) ...6 more I attempted to add the certificate using each of these commands , but on both instances i encountered the same error sh /usr/lib/classpath/gkeytool -import -alias dm -keystore /usr/lib/security/cacerts -file /root/Cert.crt sh /usr/lib/classpath/gkeytool -import -keystore /usr/lib/security/cacerts -trustcacerts -file /root/Cert.crt Thank you It would be helpful if you could provide a simple reproducer e.g. applying the attached certificate X and running attached program Y cause the failure. From what you've written here, it's unclear how anyone would be able to reproduce this reliably, let alone fix it. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [commit-cp] classpath ChangeLog javax/print/attribute/stand...
On 30 July 2010 11:58, Andrew Haley a...@redhat.com wrote: CVSROOT: /sources/classpath Module name: classpath Changes by: Andrew Haley aph 10/07/30 10:58:20 Modified files: . : ChangeLog javax/print/attribute/standard: JobStateReasons.java Log message: 2010-07-30 Andrew Haley a...@redhat.com * javax/print/attribute/standard/JobStateReasons.java (add): Fix infinite recursion with call to super. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9798r2=1.9799 http://cvs.savannah.gnu.org/viewcvs/classpath/javax/print/attribute/standard/JobStateReasons.java?cvsroot=classpathr1=1.9r2=1.10 I didn't see a post to classpath-patches for this, not even an FYI :-( -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] [commit-cp] classpath ChangeLog javax/print/attribute/stand...
On 30 July 2010 11:58, Andrew Haley a...@redhat.com wrote: CVSROOT: /sources/classpath Module name: classpath Changes by: Andrew Haley aph 10/07/30 10:58:20 Modified files: . : ChangeLog javax/print/attribute/standard: JobStateReasons.java Log message: 2010-07-30 Andrew Haley a...@redhat.com * javax/print/attribute/standard/JobStateReasons.java (add): Fix infinite recursion with call to super. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9798r2=1.9799 http://cvs.savannah.gnu.org/viewcvs/classpath/javax/print/attribute/standard/JobStateReasons.java?cvsroot=classpathr1=1.9r2=1.10 I didn't see a post to classpath-patches for this, not even an FYI :-( -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] [commit-cp] classpath ChangeLog javax/print/attribute/stand...
On 30 July 2010 12:05, Dr Andrew John Hughes ahug...@redhat.com wrote: On 30 July 2010 11:58, Andrew Haley a...@redhat.com wrote: CVSROOT: /sources/classpath Module name: classpath Changes by: Andrew Haley aph 10/07/30 10:58:20 Modified files: . : ChangeLog javax/print/attribute/standard: JobStateReasons.java Log message: 2010-07-30 Andrew Haley a...@redhat.com * javax/print/attribute/standard/JobStateReasons.java (add): Fix infinite recursion with call to super. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9798r2=1.9799 http://cvs.savannah.gnu.org/viewcvs/classpath/javax/print/attribute/standard/JobStateReasons.java?cvsroot=classpathr1=1.9r2=1.10 I didn't see a post to classpath-patches for this, not even an FYI :-( -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 Ah, just saw it. My bad. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8