[cp-patches] [generics] FYI: Moved getEnumConstants implementation from VMClass to Class

Hi, Since I'm shortly going to commit my change to trunk, I've committed this to the generics branch to make the VM interfaces the same. Regards, Jeroen 2006-04-23 Jeroen Frijters [EMAIL PROTECTED] * java/lang/Class.java (getEnumConstants): Implemented without delegating

[cp-patches] FYI: Class annotation and getEnumConstant support

Hi, I committed my patch as previously announced. Regards, Jeroen 2006-04-23 Jeroen Frijters [EMAIL PROTECTED] * NEWS: Added information about annotation support. * java/lang/Class.java: Implement AnnotatedElement. (equals): Reformatted to match generics branch

RE: [cp-patches] FYI: Merged Package annotation support fromgenerics branch

Mark Wielaard wrote: On Sun, 2006-04-23 at 11:57 +0200, Jeroen Frijters wrote: Note again that if you're a VM maintainer and you use a custom version of VMClassLoader, this is a breaking change and your version of VMClassLoader will have to be updated as well (simply add an extra null

[cp-patches] FYI: Added back Package constructor

Hi, As per Mark's suggestion, I've added back the Package constructor that doesn't take the ClassLoader. It's marked deprecated and will go away in the future, so please migrate to the new constructor. Regards, Jeroen 2006-04-23 Jeroen Frijters [EMAIL PROTECTED] * NEWS: Added entry

RE: [cp-patches] FYI: Merged Package annotation supportfromgenerics branch

Mark Wielaard wrote: I believe that with your and Andrew's work we are now synced for the VM Classes between generics and trunk. Yeah, I think so too. There is one change to Class.newInstance() from you that never went in. I didn't see any objections to it, but also no strong support

RE: [cp-patches] RFC: Class/VMClass merge from generics branch

Andrew John Hughes wrote: On Fri, 2006-04-21 at 15:23 +0200, Jeroen Frijters wrote: Since we can now support annotations on the trunk I'd like to merge Class/VMClass with the versions from the generics branch (modulo any 1.5 language feature, of course). I thought we agreed

[cp-patches] RFC: v2 of the Class/VMClass merge from generics branch

Hi, I moved getEnumConstant from VMClass to Class in this version of the patch. Again, unless anyone complains this will go in sometime next week. Regards, Jeroen Index: java/lang/Class.java === RCS file:

RE: [cp-patches] RFC: Class/VMClass merge from generics branch

Andrew John Hughes wrote: Ah, so IKVM already has some of this implemented? Great. I guess it depends on other VM implementors and how much control they want over this. I think the implementation of the signature parser was a good idea, and the annotation support should have a similar

RE: [cp-patches] [generics] FYI updated AccessibleObject to 1.5

Andrew John Hughes wrote: Please document new methods as you add them. There are already plenty of new undocumented methods on the generics branch, and I'd appreciate it if we didn't add more. These methods are very similar to those in java.lang.Class, so they could be more or less

[cp-patches] [generics] FYI updated AccessibleObject to 1.5

Hi, I updated java.lang.reflect.AccessibleObject to 1.5. I wrote some throwaway code to figure out the JDK 1.5 behavior for these methods and duplicated that. Regards, Jeroen 2006-04-21 Jeroen Frijters [EMAIL PROTECTED] * java/lang/reflect/AccessibleObject.java: Implemented

[cp-patches] FYI: Updated java.lang.reflect.AccessibleObject to 1.5

Hi, Merged from the generics branch. Regards, Jeroen 2006-04-21 Jeroen Frijters [EMAIL PROTECTED] * java/lang/reflect/AccessibleObject.java: Implemented AnnotatedElement. (getAnnotation, getAnnotations, getDeclaredAnnotations, isAnnotationPresent): New methods

[cp-patches] RFC: Class/VMClass merge from generics branch

Hi, Since we can now support annotations on the trunk I'd like to merge Class/VMClass with the versions from the generics branch (modulo any 1.5 language feature, of course). If your VM already supports the generics branch, no changes should be needed. If you don't yet support it, you need to

[cp-patches] FYI: Merged a few java.lang.* changes from generics branch

Hi, I merged a few things from the generics branch to the trunk. Regards, Jeroen 2006-04-17 Jeroen Frijters [EMAIL PROTECTED] * java/lang/Boolean.java: Implemented Comparable. * java/lang/ClassLoader.java (getResources): Not final anymore in 1.5. * java/lang

[cp-patches] FYI: Implement java.lang.Iterable in java.util.Collection

Hi, Committed. Regards, Jeroen 2006-04-17 Jeroen Frijters [EMAIL PROTECTED] * java/util/Collection.java: Implemented java.lang.Iterable. Index: java/util/Collection.java === RCS file: /cvsroot/classpath/classpath/java

RE: [cp-patches] FYI: Merging reflection stuff from generics branch

Tom Tromey wrote: Twisti == Christian Thalinger [EMAIL PROTECTED] writes: Twisti Sorry. Completely the wrong methods. I meant: Twisti isSynthetic Twisti isAnnotation Twisti isEnum Actually I've been curious to know why these don't simply use getModifiers (or whatever the equivalent

RE: [cp-patches] Patch: FYI: mime.types parsing

Tom Tromey wrote: This updates our internal mime type database in two ways. First, we now parse /etc/mime.types, if it exists. IMO that needs to be factored into a VM interface. On Windows it doesn't make sense to try to read /etc/ (and it may in fact represent a security issue to do so).

[cp-patches] FYI: Added Class.cast() method

Hi, Committed. Regards, Jeroen 2006-04-05 Jeroen Frijters [EMAIL PROTECTED] * java/lang/Class.java (cast): New method. Index: java/lang/Class.java === RCS file: /cvsroot/classpath/classpath/java/lang/Class.java,v

[cp-patches] [generics] FYI: Method Constructor fix

Hi, Committed. Regards, Jeroen 2006-03-27 Jeroen Frijters [EMAIL PROTECTED] * vm/reference/java/lang/reflect/Constructor.java (getTypeParameters): Check return value of getSignature for null. * vm/reference/java/lang/reflect/Method.java (getTypeParameters

RE: [cp-patches] [generics] FYI: Getting ready for concurrency

Andrew John Hughes wrote: I'm committing the attached patch which adds some features required by the new concurrency tree prepared by Tom Tromey and documented by myself. +public class Unsafe Unsafe should be final, otherwise you can create an instance by subclassing and capturing the this in

RE: [cp-patches] Patch: RFC: changing parts of VM reflection API

Tom Tromey wrote: I'm posting this for comment. This is the patch to change Method/Field/Constructor to have a 'getModifiersInternal' method, which returns the un-masked modifiers as read from the .class file. This lets us implement the new 1.5 reflection predicates such as isSynthetic.

RE: [cp-patches] RFC: Robustness fixes

Roman Kennke wrote: my collegue Fridjof has been playing around with data flow analysis and spotted some interesting points where we could improve robustness a little. For the most part this creates local variables for fields in some places (see ChangeLog entry below) and operates on these

RE: [cp-patches] NIO Scatter/Gather patch

Michael Barker wrote: Attached is a patch to add non-blocking i/o and scatter/gather for nio SocketChannels. I have signed the necessary legal forms for contribution. I have been off for on vaction so its been a little late in coming. Thanks. Please review. private int native_fd; +

[cp-patches] FYI: ResourceBundle fix

Hi, Committed. Dacapo Xalan now runs successfully. Regards, Jeroen 2006-03-01 Jeroen Frijters [EMAIL PROTECTED] * java/util/ResourceBundle.java (tryBundle): Catch and ignore all Exceptions. Index: java/util/ResourceBundle.java

[cp-patches] FYI: ZipConstants patch

Hi, I committed Stuart's patch. Regards, Jeroen 2006-02-20 Stuart Ballard [EMAIL PROTECTED] * java/util/zip/ZipConstants.java (LOCSIG): Change type to long. (EXTSIG): Likewise. (CENSIG): Likewise. (ENDSIG): Likewise. *

[cp-patches] FYI: Small gnu/java/net/protocol/ftp/ActiveModeDTP.java fix

Hi, Committed patch below to mark the thread that gets spun by active ftp as a daemon thread. Regards, Jeroen 2006-02-17 Jeroen Frijters [EMAIL PROTECTED] * gnu/java/net/protocol/ftp/ActiveModeDTP.java (ActiveModeDTP): Mark accept thread as daemon. Index: gnu/java/net

[cp-patches] FYI: Fix for 25752 (gnu/java/net/protocol/ftp/FTPURLConnection.java)

Hi, Committed. Regards, Jeroen 2006-02-17 Jeroen Frijters [EMAIL PROTECTED] Fixes PR 25752 * gnu/java/net/protocol/ftp/FTPURLConnection.java (connect): Changed to use SystemProperties. (getInputStream): Try changeWorkingDirectory to figure out if url

RE: [cp-patches] RFC: ZipFile optimizations

[EMAIL PROTECTED] wrote: Jeroen == Jeroen Frijters [EMAIL PROTECTED] writes: Jeroen I noticed that ZipFile currently doesn't use any buffering Jeroen when reading the zip file directory, so I would like to Jeroen propose the attached patch to fix this. For me this Jeroen significantly

[cp-patches] FYI: ZipFile optimizations

Hi, Committed. Regards, Jeroen 2006-02-15 Jeroen Frijters [EMAIL PROTECTED] * java/util/zip/ZipFile.java (checkZipFile): Inlined readLeInt and rewritten for robustness. (readLeShort(DataInput,byte[]), readLeInt(DataInput,byte[], readLeShort(byte[],int

[cp-patches] RFC: ZipFile optimizations

Hi, I noticed that ZipFile currently doesn't use any buffering when reading the zip file directory, so I would like to propose the attached patch to fix this. For me this significantly increases performance of reading the zip directory. In addition to the buffering tweaks, this patch also fixes

[cp-patches] FYI: InputStreamReader fix (PR 26220)

Hi, Committed. Regards, Jeroen 2006-02-12 Jeroen Frijters [EMAIL PROTECTED] Fixes PR 26220 * java/io/InputStreamReader.java (InputStreamReader(InputStream)): Use SystemProperties. (InputStreamReader(InputStream,Charset)): Corrected @since tag. Throw

[cp-patches] FYI: Small InputStream fix

Hi, Committed. Regards, Jeroen 2006-02-12 Jeroen Frijters [EMAIL PROTECTED] * java/io/InputStream.java (read(byte[],int,int)): Changed argument validation to prevent integer overflow. Remove redundant check. Index: java/io/InputStream.java

RE: [cp-patches] RFC: Introduction of VMMath

Robert Schuster wrote: Nice work. I think the JNode guys will appreciate this. :) As do I! Regards, Jeroen

[cp-patches] FYI: ObjectInputStream fix

Hi, Committed. Regards, Jeroen 2006-02-06 Jeroen Frijters [EMAIL PROTECTED] Fixes PR 26121 * java/io/ObjectInputStream.java (readNextBlock()): Handle TC_RESET. ObjectInputStream.java.patch Description: ObjectInputStream.java.patch

[cp-patches] FYI: InetAddress deserialization fix

Hi, Committed. Regards, Jeroen 2006-02-06 Jeroen Frijters [EMAIL PROTECTED] Fixes PR 25313 * java/net/InetAddress.java (readResolve): Implemented. InetAddress.java.patch Description: InetAddress.java.patch

[cp-patches] FYI: java/net/URL.java fix

Hi, Committed. Regards, Jeroen 2006-01-12 Jeroen Frijters [EMAIL PROTECTED] * java/net/URL.java (static, getURLStreamHandler): Use SystemProperties. Index: java/net/URL.java === RCS file: /cvsroot/classpath

[cp-patches] FYI: Patch to fix the incorrect RuntimePermission(charsetProvider) check

Hi, I've checked in the attached patch to fix the fact that we're incorrectly checking for the charsetProvider runtime permission when instantiating the built in providers. Regards, Jeroen 2005-01-13 Jeroen Frijters [EMAIL PROTECTED] * gnu/java/nio/charset/Provider.java: Added

[cp-patches] FYI: java/io/PrintStream fix

Hi, I checked in the attached patch to fix PrintStream to use SystemProperties (to make sure we don't request unneeded security permissions). Regards, Jeroen 2005-01-13 Jeroen Frijters [EMAIL PROTECTED] * java/io/PrintStream.java (line_separator, PrintStream(OutputStream

[cp-patches] FYI: Hashtable fix for PR 25727

Hi, Committed. Regards, Jeroen 2006-01-09 Jeroen Frijters [EMAIL PROTECTED] PR classpath/25727 * java/util/Hashtable.java (contains): Call equals on existing value. (containsKey, get, put, remove): Call equals on existing key. (getEntry): Call equals

RE: [cp-patches] RFC: Hashtable cleanup

Roman Kennke wrote: I would like to propose the following patch that was written by my collegue Fridjof. Basically, it replaces the parameterized Iterator and Enumerator classes with normal classes for values/entries/keys. Thank you! This is much better than before. Regards, Jeroen

[cp-patches] FYI: Changed HashMap/WeakHashMap to fix PR 24618

Hi, Committed. Regards, Jeroen 2006-01-06 Jeroen Frijters [EMAIL PROTECTED] PR classpath/24618 * java/util/AbstractMap.java (equals(Object,Object)): Test for identity first. * java/util/WeakHashMap.java (WeakBucket.WeakEntry.equals): Use helper method

RE: [cp-patches] RFC: patch for Unicode scalar value to UTF-16conversion

Chris Burdess wrote: Tom Tromey wrote: Chris Please comment. Chris -dst[dstIndex + 1] = (char) ((codePoint 0x3ff) Chris -+ (int) MIN_LOW_SURROGATE ); Chris -dst[dstIndex] = (char) ((codePoint 10) + (int) MIN_HIGH_SURROGATE);

RE: [cp-patches] RFC: patch for Unicode scalar value to UTF-16conversion

Chris Burdess wrote: I also have a mild preference for the bit-shifting and masking computation, but this is more minor. The problem is that the bit-shifting method produces the wrong result. In this case they both produce the same result. I think the problem was that the

[cp-patches] FYI: Using a WeakIdentityHashMap for thread locals

[EMAIL PROTECTED] wrote: Jeroen == Jeroen Frijters [EMAIL PROTECTED] writes: Jeroen I propose the attached change to the handling of thread locals. This Jeroen fixes bug #24858 and makes the code slightly more obvious (at the cost Jeroen of introducing the new class WeakIdentityHashMap

[cp-patches] FYI: java/util/Collections.java compatibility fix

Hi, Committed. Regards, Jeroen 2005-12-25 Jeroen Frijters [EMAIL PROTECTED] * java/util/Collections.java (binarySearch(List,Object,Comparator)): Changed comparison order for improved compatibility. Collections.java.patch Description: Collections.java.patch

RE: [cp-patches] RFC : modifiers in java/lang/Class

Hi Nicolas, Yes it makes sense to filter the relevant bits here instead of at the VM level, please commit. Thanks, Jeroen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nicolas Geoffray Sent: Saturday, December 17, 2005 00:05 To:

RE: [cp-patches] Re: RFC: Patchfor duplicate entries in serialPersistentFields

Archie Cobbs wrote: Stuart Ballard wrote: Jeroen pointed out to me a while back that you can use generics to throw an unchecked exception: There's also a way to do this without using JDK 1.5 stuff, but it's even uglier :-) Construct a class (dynamically) that has a default

RE: [cp-patches] FYI: Opening RandomAccessFilesrequiresexcessivepermission

@gnu.org Subject: Re: [cp-patches] FYI: Opening RandomAccessFilesrequiresexcessivepermission Hi Jeroen, Oh, in that case I'll use your patch, assuming nobody objects. The mauve test ought to spot anything that slips through. Cheers, Gary Jeroen Frijters wrote: Hi Gary, I used

FW: [cp-patches] FYI: OpeningRandomAccessFilesrequiresexcessivepermission

To: classpath-patches@gnu.org Subject: Re: [cp-patches] FYI: OpeningRandomAccessFilesrequiresexcessivepermission Hi Jeroen, David, What was the point? Cheers, Gary Jeroen Frijters wrote: Hi Gary, David Daney made a good point that reminded me that it probably wasn't as clever as I

RE: [cp-patches] RFC: new VM interface for Socket impls

Mark Wielaard wrote: On Wed, 2005-11-09 at 21:16 +, Roman Kennke wrote: Ingo has abstracted out the native code from gnu.java.net.PlainSocketImpl and gnu.java.net.PlainDatagramSocketImpl into a new VM interface. This allows VM implementors to provide a different implementation for

RE: [cp-patches] RFC: StringIndexOutOfBoundsException fixes inString contructors

Christian Thalinger wrote: +if (offset + count 0 || offset + count ascii.length) You can write this more efficiently as: if (ascii.length - offset count) (This assumes that offset and count have previously been checked to be non-negative.) Regards, Jeroen

[cp-patches] FYI: Bug fix java/io/ObjectOutputStream.java

Hi, Committed. Regards, Jeroen 2005-11-01 Jeroen Frijters [EMAIL PROTECTED] * java/io/ObjectOutputStream.java (writeObject): Fixed NPE. Index: java/io/ObjectOutputStream.java === RCS file: /cvsroot/classpath

RE: [cp-patches] RFC: Remove lowercasing of Windows paths

Roman Kennke wrote: Ingo found a bug in the Windows path handling. In the PlatformHelper class we lowercase all Windows paths. This is kind of naive and shortsighted, because paths are not only file system paths, but can also be paths inside JAR files etc, which actually ARE case-sensitive.

RE: [cp-patches] RFC: implementation of getPackage for the vmreference

Nicolas Geoffray wrote: Mark are you OK with the changes? I would like to see this go in before 0.19. After 0.19 (based on feedback from other VM implementers) we should consider making getBootPackages native so that they will be able to use the reference VMClassLoader as is. Regards, Jeroen

RE: [cp-patches] RFC: implementation of getPackage for the vmreference

Nicolas Geoffray wrote: Why should it be native? It might be the same work for all VMs. Maybe we could add a static initializer to VMClassLoader that would look for java.boot.class.path property and fill the packages (eg the directories) it finds in the definedPackages hashmap. I just

RE: [cp-patches] RFC: implementation of getPackage for the vm reference

Nicolas Geoffray wrote: This patch was written when we wanted to test our vm and gnu classpath with jonas. Jonas complained (crashed) because it got a null package for a system class. This patch corrects the issue, and should be adequate for all vms. Looks good, but you should use

RE: [cp-patches] RFC: implementation of getPackage for the vm reference

Jeroen Frijters wrote: Nicolas Geoffray wrote: This patch was written when we wanted to test our vm and gnu classpath with jonas. Jonas complained (crashed) because it got a null package for a system class. This patch corrects the issue, and should be adequate for all vms. Looks

[cp-patches] FYI: java/lang/reflect/Proxy.java fix

Hi, There was a bootstrap / system class loader confusion bug in Proxy. I committed the attached patch to fix it. Regards, Jeroen 2005-10-21 Jeroen Frijters [EMAIL PROTECTED] * java/lang/reflect/Proxy.java (ProxyType.ProxyType): Don't replace null with system class loader

[cp-patches] FYI: java/io/ObjectInputStream.java

Hi, I committed the attached patch to fix proxy deserialization (bug 24422). Regards, Jeroen 2005-10-18 Jeroen Frijters [EMAIL PROTECTED] * java/io/ObjectInputStream.java (parseContent): Removed bogus println and fixed bug #24422. Index: java/io/ObjectInputStream.java

RE: [cp-patches] [PATCH] Fix PR classpath/24086, PR classpath/24091, PR classpath/24104 et al. ...

David Daney wrote: A finalizer is simple and gets the job done. Finalizers are anything but simple. They really should only be used to free native resources (as a last resort), not for any type of Java clean up. Blocking and locking should be avoided in a finalizer. Typically there is only one

RE: [cp-patches] [PATCH] Fix PR classpath/24086, PR classpath/24091, PR classpath/24104 et al. ...

Boehm, Hans wrote: Blocking on IO indeed seems dubious. But finalizers almost always need to acquire at least one lock. Agreed, but outside of the lock needed to protect the finalizable resource it's probably best to avoid taking other locks, because it is very easy to introduce potential

RE: [cp-patches] RFC: prevent URL degeneration - v3

Robert Schuster wrote: However I consider these tests wrong because they violate the URL spec. Some people (like me) believe it is more important, in some cases, to be compatible with the reference implementation than to the spec. proto:p1/p2 is not the same as proto://p1/p2

RE: [cp-patches] [PATCH] Fix PR classpath/24086, PR classpath/24091, PR classpath/24104 et al. ...

David Daney wrote: This is the new version of my HTTP patch. It keeps promoting (near) silence from the approvers, and I keep finding and fixing new bugs. Also it has been about a week and I fixed another bug, so I thought I would post the current version. Thanks for this rewrite. I

RE: [cp-patches] Stupid spec constant values

Stuart Ballard wrote: On 10/5/05, Jeroen Frijters [EMAIL PROTECTED] wrote: They never change. They only exist because of an historical accident, way back. I don't have a strong opinion on whether we should copy them or not, but I certainly have no objection against it (and I'd like

[cp-patches] FYI: Fixed URLClassLoader regression (on Windows)

Hi, I committed the attached patch to fix a regression introduced in the previous URLClassLoader change. Regards, Jeroen 2005-10-01 Jeroen Frijters [EMAIL PROTECTED] * java/net/URLClassLoader.java (Resource.name): Removed field. (JarURLResource.name): Added field

[cp-patches] [generics] Finished generics signature parsing

Hi, I finished the generics signature parsing support code. Next up, changing the vm\reference reflection classes to make use of it. Regards, Jeroen 2005-09-30 Jeroen Frijters [EMAIL PROTECTED] * gnu/java/lang/reflect/FieldSignatureParser.java: New file. * gnu/java/lang

[cp-patches] [generics] Removed generics from VMSystem interface

Hi, As previously discussed, I've applied the attached patch to remove the generic type from the VMSystem.environ() call, to make it easier to have a common VMSystem for the trunk and the generics branch. Regards, Jeroen 2005-09-25 Jeroen Frijters [EMAIL PROTECTED] * java/lang

[cp-patches] [generics] Copied org/omg/PortableServer/portable/Delegate.java

Hi, org/omg/PortableServer/portable/Delegate.java was missing on the generics branch, so I copied it over. Regards, Jeroen ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches

[cp-patches] FYI: Small Proxy fix

Hi, I committed the attached patch to fix the class name of proxies that implement only public interfaces (the name was null$Proxy0, but it should be $Proxy0). Regards, Jeroen 2005-09-09 Jeroen Frijters [EMAIL PROTECTED] * java/lang/reflect/Proxy.java (pack): Initialize field

[cp-patches] FYI: Moved System.loadLibrary() calls from ObjectInputStream/ObjectOutputStream to VM classes

Hi, I committed the attached patch to move the System.loadLibrary calls to the VM classes. Regards, Jeroen 2005-09-09 Jeroen Frijters [EMAIL PROTECTED] * java/io/ObjectInputStream.java: Removed static initializer. * java/io/ObjectOutputStream.java: Removed static initializer

[cp-patches] FYI: Fix to javax/security/auth/login/Configuration.java

Hi, I committed the attached patch to fix a NPE in LoginContext (it calls the package private getConfig() method, but if the config field hadn't previously been initialized that would return null). Regards, Jeroen 2005-09-09 Jeroen Frijters [EMAIL PROTECTED] * javax/security/auth

[cp-patches] FYI: Serialization implementation for javax/naming/CompoundName.java

Hi, I implemented serialization support for javax.naming.CompoundName. Regards, Jeroen 2005-09-08 Jeroen Frijters [EMAIL PROTECTED] * javax/naming/CompoundName.java (readObject, writeObject): New methods. ___ Classpath-patches

[cp-patches] RE: FYI: Serialization implementation for javax/naming/CompoundName.java

Again, with the patch this time. -Original Message- From: Jeroen Frijters Sent: Thursday, September 08, 2005 10:33 To: Classpath-Patches Subject: FYI: Serialization implementation for javax/naming/CompoundName.java Hi, I implemented serialization support

[cp-patches] FYI: Proxy serialization fixes

, but it's a first step. Regards, Jeroen 2005-09-08 Jeroen Frijters [EMAIL PROTECTED] * java/io/ObjectInputStream.java (readObject): Removed println and fixed Proxy class descriptor deserialization. (resolveProxyClass): Use Class.forName() instead of calling

[cp-patches] FYI: java/awt/Container.java fix.

Hi, A small fix to Container. Regards, Jeroen 2005-08-16 Jeroen Frijters [EMAIL PROTECTED] * java/awt/Container.java (addImpl, remove): Only repaint if the container is showing. Index: java/awt/Container.java

RE: [cp-patches] RFC: AWT painting broken?

Roman Kennke wrote: Oh sorry, the diff has confused me. It is ok then. Please check it in. Thanks. I've checked it in. Regards, Jeroen 2005-08-16 Jeroen Frijters [EMAIL PROTECTED] * java/awt/Component.java (dispatchEventImpl): Always call peer.handleEvent

RE: [cp-patches] [generics] Patch: FYI: update Timer

Hi Tom, Why are you checking this into the generics branch? I was under the impression that 1.5 functionality could also be applied to the main branch, as long as it doesn't require any 1.5 language features. Regards, Jeroen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL

RE: [cp-patches] [RFC/JDWP] ClassLoaderReferenceCommandSet

Archie Cobbs wrote: Aaron Luchko wrote: There's only a single command which asks for a list of every class the ClassLoader has been requested to load. The first way to do this is just use a hook in the vm. I don't know enough with how ClassLoaders are handled within the vm to know how

RE: [cp-patches] [RFC/JDWP] ClassLoaderReferenceCommandSet

Archie Cobbs wrote: Jeroen Frijters wrote: I strongly agree with Archie. Also, approach #2 is incorrect, because the classes that should be returned are the classes for which this class loader has been recorded as the initiating loader. The class loader doesn't know whether

[cp-patches] FYI: java/io/ObjectInputStream.java clean up

-pattern return from finally.) Regards, Jeroen 2005-08-06 Jeroen Frijters [EMAIL PROTECTED] * java/io/ObjectInputStream.java (readClassDescriptor): Removed bogus handling of primitive types. (readFields.GetField.defaulted): Pass cause to exception

[cp-patches] FYI: Some 1.5 Exception constructors merged back from generics branch

Hi, I merged some new 1.5 exception constructors from the generics branch to HEAD. Regards, Jeroen 2005-08-06 Jeroen Frijters [EMAIL PROTECTED] * java/lang/IllegalArgumentException.java, java/lang/IllegalStateException.java, java/lang/SecurityException.java

RE: [cp-patches] [generics] Enum#valueOf implementation

Andrew John Hughes wrote: Currently, what appears to be a bug in ecj (https://bugs.eclipse.org/bugs/show_bug.cgi?id=105531) is preventing me from doing a full compile, but no other errors cropped up from this patch. I've seen this ecj bug as well, but it never seems to happen if you do a

[cp-patches] FYI: Class class loader VM interface simplification applied

Hi, As previously discussed, I've committed the attached patch to simplify the VM interface for Class and ClassLoader. Regards, Jeroen 2005-08-01 Jeroen Frijters [EMAIL PROTECTED] * NEWS: Added info about VM interfaces changes. * java/lang/Class.java (forName(String

[cp-patches] FYI: ClassLoader security patch

Hi, I committed the attached patch to fix some potential security holes in ClassLoader. I also created a Mauve testcase (gnu/testlet/java/lang/ClassLoader/initialize.java) that tests for this. Regards, Jeroen 2005-08-01 Jeroen Frijters [EMAIL PROTECTED] * java/lang/ClassLoader.java

[cp-patches] RE: RFC: New class loader patch proposal

Robert Lougher wrote: On 7/28/05, Jeroen Frijters [EMAIL PROTECTED] wrote: Hi, Here's an alternative patch that rips out most of the complexity and leaves everything to the VM. It took me about three minutes to implement this new interface for IKVM, so I know I'm happy

RE: [cp-patches] RFC: Class Loader patch to record class withinitiating class loader

Archie Cobbs wrote: For what it's worth, JCVM maintains its own intiated types and defined types tables internally, so this patch does not make life better (or worse). I would have to disable this code. This raises the question, how many VMs are actually using the loadedClasses hashtable in

RE: [cp-patches] RFC: Class Loader patch to record classwithinitiating class loader

Mark Wielaard wrote: It looks like that is also what gcj and jamvm do already. That is why I am surprised that we really need the double callbacks everywhere. Does that make the interface really more flexible? In the case of Class.forName() you mean that when we need to delegate to

RE: [cp-patches] RFC: Class Loader patch to record class withinitiating class loader

David Gilbert wrote: I hope when I mentioned that JamVM was broken, it didn't sound like a complaint, because that wasn't what I intended. Not at all. I was just a bit surprised that it is possible to live on the bleeding edge of development and still maintain the notion: how VMs work...as

[cp-patches] RFC: Class Loader patch to record class with initiating class loader

) 2005-07-27 Jeroen Frijters [EMAIL PROTECTED] * java/lang/Class.java (forName(String), forName(String,boolean,ClassLoader)): Added call to VMClassLoader.registerInitiatingLoader. * java/lang/ClassLoader.java (defineClass(String,byte[],int,int

RE: [cp-patches] FYI: ClassLoader caching Part 2

Mark Wielaard wrote: On Mon, 2005-07-25 at 18:17 +0200, Jeroen Frijters wrote: Is this an important scenario? I thought you long haired types didn't like binary distributions ;-) He he. Sure we don't. But if you follow the harmony effort of the cleanly shaved apache types you will have

RE: [cp-patches] FYI: Small additional ClassLoader VMextensibility point

Mark Wielaard wrote: On Mon, 2005-07-25 at 11:43 +0200, Jeroen Frijters wrote: I committed the attached patch, that allows a VM implementer to hook Classloader.findLoadedClass. When adding new VM hooks could you please add a little note to the NEWS file. That makes it much easier for VM

[cp-patches] FYI: Proxy - VMProxy patch

Hi, I moved to native methods in Proxy to VMProxy and moved the configuration flags that control whether the native methods are used from gnu.classpath.Configuration to VMProxy as well. Regards, Jeroen 2005-07-26 Jeroen Frijters [EMAIL PROTECTED] * NEWS: Added comment about new

RE: [cp-patches] RFC: RMI Class loader fix

Andrew Haley wrote: Tom Tromey writes: Jeroen == Jeroen Frijters [EMAIL PROTECTED] writes: Jeroen* java/rmi/server/RMIClassLoader.java Jeroen(loadClass(String, String)): Use Class.forName() instead of Jeroendirectly calling ClassLoader.loadClass(), to handle array

RE: [cp-patches] RFC: RMI Class loader fix

Andrew Haley wrote: All of this is fairly ill-specified. As usual :-( I just re-read the relevant part of the 1.5 API spec and JLS (which it refers to) and I think you can actually interpret it to prohibit loading array classes via ClassLoader.loadClass (indirectly based on the definition of

[cp-patches] FYI: Small additional ClassLoader VM extensibility point

Hi, I committed the attached patch, that allows a VM implementer to hook Classloader.findLoadedClass. Regards, Jeroen 2005-07-25 Jeroen Frijters [EMAIL PROTECTED] * java/lang/ClassLoader.java (findLoadedClass): Call VMClassLoader.findLoadedClass. * vm/reference/java

[cp-patches] RFC: RMI Class loader fix

Hi, I'm not an RMI person, but an IKVM user ran into an RMI problem that I think is caused by a problem in the RMI class loader that the attached patch should fix. Please comment. Regards, Jeroen * java/rmi/server/RMIClassLoader.java (loadClass(String, String)): Use

RE: [cp-patches] FYI: ClassLoader caching Part 2

Mark Wielaard wrote: Yes, but unfortunately that doesn't change the byte-code of the ClassLoader class. static final primitive (and String) field values are actually inlined into other classes. So you can replace VMClassLoader all you want with a version the has VM_USE_CACHE set to another

RE: [cp-patches] RFC: RMI Class loader fix

Mark Wielaard wrote: On Mon, 2005-07-25 at 14:52 +0200, Jeroen Frijters wrote: I'm not an RMI person, but an IKVM user ran into an RMI problem that I think is caused by a problem in the RMI class loader that the attached patch should fix. Please comment. I assume this is because

RE: [cp-patches] FYI: ClassLoader caching Part 2

Jeroen Frijters wrote: Mark Wielaard wrote: On Mon, 2005-07-25 at 16:29 +0200, Jeroen Frijters wrote: I committed the attached patch to complete to ability of the VM to bypass the class caching in ClassLoader. 2005-07-25 Jeroen Frijters [EMAIL PROTECTED] * java/lang

[cp-patches] FYI: RMI Class loader fix

Hi, I applied the attached fix. Regards, Jeroen * java/rmi/server/RMIClassLoader.java (loadClass(String, String)): Use Class.forName() instead of directly calling ClassLoader.loadClass(), to handle array types correctly. Index: java/rmi/server/RMIClassLoader.java

RE: [cp-patches] Re: Serialization: readResolve and writeReplace inparent class

Hi Daniel, Your patch broke the Mauve gnu.testlet.java.io.Serializable.readResolve test. If the readResolve method is in the current class and it is private it is no longer found. Regards, Jeroen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of

<    1   2   3   >