Re: [patch] fix to JLayeredPane
graydon == graydon hoare [EMAIL PROTECTED] writes: graydon this patch adapts JLayeredPane to the changes [EMAIL PROTECTED] graydon recently made to Container graydon ok to apply? Yes, thanks. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Serialization compatibility testing
All, I've been working a little lately on some tools I once added to japi for serialization compatibility testing. I'm pretty close to having something useful, just wondering if anyone is interested in using these for checking compatibility? Here's the list of the files that are the same when compared to Sun's JDK 1.4.1 for Kaffe 1.1.3. These .ser files are object serializations. I've omitted the things that are missing in Kaffe or exist in Kaffe but not the JDK. The list of classes the tool attempted to serialize is based on Java 1.4 documented serializable classes. I'm looking forward to adding a tool to attempt to read objects written by Sun's JDK, from version 1.1 through 1.4 into the appropriate object type. Eventually I'll be able to combine these building block type tools to comprehensively state serialization compatibility for a JVM to Sun's JDK. I'll also have fun checking Sun. :) I've thought about trying to add this to Mauve. Thoughts? New module? kaffe113/java/security/Permission.ser identical kaffe113/java/security/Provider.ser identical kaffe113/java/security/BasicPermission.ser identical kaffe113/java/security/PermissionCollection.ser identical kaffe113/java/security/IdentityScope.ser identical kaffe113/java/security/Signer.ser identical kaffe113/java/security/SecureRandomSpi.ser identical kaffe113/java/security/cert/CertPath.ser identical kaffe113/java/security/cert/X509Certificate.ser identical kaffe113/java/security/cert/CertPath$CertPathRep.ser identical kaffe113/java/security/cert/Certificate.ser identical kaffe113/java/security/cert/Certificate$CertificateRep.ser identical kaffe113/java/security/Identity.ser identical kaffe113/java/net/SocketAddress.ser identical kaffe113/java/util/TreeSet.ser identical kaffe113/java/util/LinkedList.ser identical kaffe113/java/util/Stack.ser identical kaffe113/java/util/TimeZone.ser identical kaffe113/java/util/Hashtable.ser identical kaffe113/java/util/TreeMap.ser identical kaffe113/java/util/BitSet.ser identical kaffe113/java/util/IdentityHashMap.ser identical kaffe113/java/util/Calendar.ser identical kaffe113/java/util/EventObject.ser identical kaffe113/java/util/Vector.ser identical kaffe113/java/text/DateFormat.ser identical kaffe113/java/text/Format.ser identical kaffe113/java/text/NumberFormat.ser identical kaffe113/java/awt/Insets.ser identical kaffe113/java/awt/dnd/MouseDragGestureRecognizer.ser identical kaffe113/java/awt/dnd/DragGestureRecognizer.ser identical kaffe113/java/awt/CheckboxGroup.ser identical kaffe113/java/awt/GraphicsConfigTemplate.ser identical kaffe113/java/awt/Dimension.ser identical kaffe113/java/awt/Rectangle.ser identical kaffe113/java/awt/GridLayout.ser identical kaffe113/java/awt/Point.ser identical kaffe113/java/awt/ComponentOrientation.ser identical kaffe113/java/awt/image/renderable/ParameterBlock.ser identical kaffe113/java/awt/color/ColorSpace.ser identical kaffe113/java/awt/Component.ser identical kaffe113/java/awt/MenuComponent.ser identical kaffe113/java/lang/Integer.ser identical kaffe113/java/lang/VirtualMachineError.ser identical kaffe113/java/lang/Byte.ser identical kaffe113/java/lang/Short.ser identical kaffe113/java/lang/Character.ser identical kaffe113/java/lang/Float.ser identical kaffe113/java/lang/Double.ser identical kaffe113/java/lang/String.ser identical kaffe113/java/lang/Number.ser identical kaffe113/java/lang/Long.ser identical kaffe113/java/lang/StringBuffer.ser identical kaffe113/java/beans/PropertyChangeSupport.ser identical kaffe113/java/beans/PropertyChangeEvent.ser identical kaffe113/java/beans/beancontext/BeanContextEvent.ser identical kaffe113/java/beans/beancontext/BeanContextServicesSupport$BCSSServiceProvider.ser identical kaffe113/java/beans/beancontext/BeanContextSupport$BCSChild.ser identical kaffe113/java/beans/beancontext/BeanContextServicesSupport$BCSSChild.ser identical kaffe113/java/beans/VetoableChangeSupport.ser identical kaffe113/java/rmi/server/RemoteStub.ser identical kaffe113/java/rmi/server/RemoteObject.ser identical kaffe113/java/rmi/server/RemoteServer.ser identical kaffe113/java/rmi/activation/Activatable.ser identical kaffe113/java/rmi/activation/ActivationGroup.ser identical kaffe113/java/io/ObjectStreamException.ser identical kaffe113/javax/rmi/CORBA/ClassDesc.ser identical kaffe113/javax/rmi/CORBA/Stub.ser identical kaffe113/javax/naming/ldap/LdapReferralException.ser identical kaffe113/javax/naming/StringRefAddr.ser identical kaffe113/javax/naming/NamingSecurityException.ser identical kaffe113/javax/naming/NameClassPair.ser identical kaffe113/javax/naming/RefAddr.ser identical kaffe113/javax/naming/ReferralException.ser identical Brian -- Brian Jones [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Serialization compatibility testing
On Saturday 10 January 2004 06:00, C. Brian Jones wrote: All, I've been working a little lately on some tools I once added to japi for serialization compatibility testing. I'm pretty close to having something useful, just wondering if anyone is interested in using these for checking compatibility? Yes. :) Here's the list of the files that are the same when compared to Sun's JDK 1.4.1 for Kaffe 1.1.3. These .ser files are object serializations. I've omitted the things that are missing in Kaffe or exist in Kaffe but not the JDK. The list of classes the tool attempted to serialize is based on Java 1.4 documented serializable classes. I'm looking forward to adding a tool to attempt to read objects written by Sun's JDK, from version 1.1 through 1.4 into the appropriate object type. Eventually I'll be able to combine these building block type tools to comprehensively state serialization compatibility for a JVM to Sun's JDK. I'll also have fun checking Sun. :) I've thought about trying to add this to Mauve. Thoughts? New module? This would be a Good Thing. Wonka's test suite contains some tests which were originally written for JUnit - you can find them in Wonka CVS under too/mauve/somewhere, or I could parcel them up and mail them to you; you might find some ideas you can use. [...] -- Chris Gray /k/ Embedded Java Solutions Embedded Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 477 599 703 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: JIT pluggability
On Friday 09 January 2004 09:45, Sascha Brawer wrote: Tom Tromey [EMAIL PROTECTED] wrote on Thu, 8 Jan 2004 17:48:59 -0700: [standard pluggable JIT interface] This would indeed be quite nice, IMHO. IMHO2 (that should probably be 3 or 4 by now). I suspect that the interface to GC will be hard to define, though. There are several possible models, including: 1. The mutator (JITted code) tells GC, hey! I just mutated something!, whereupon GC either (a) aborts the current attempt to mark the heap or (b) makes a note to re-mark the affected objects before doing a sweep. 2. No one is allowed to mutate anything during the marking process, so a protocol is devised which ensures this without deadlock. And that's only counting mark-and-sweep collectors ... Language choice for API. The obvious choices being: C lowest common denominator C++ next-to-lowest common denominator :-) provides some abstraction benefit, maybe Java using our own tools... There are some users of Classpath who cannot execute any C code, such as Jaos and JNodeOS. If the pluggable JIT interface was in Java, these systems would be able to use it (assuming that someone writes a JITter in Java, like IBM did with their Jalapeño/Jikes RVM). Also, I'd assume that the interface would be rather narrow in the sense that it wouldn't get invoked very often in the direction VM -- JIT; probably once for each class or method to be compiled. But the JIT would presumably have to call a lot into the VM (for retrieving field offsets etc.). ABI Issues According to IBM's publications and web pages, Jikes RVM seems to nicely cope with different ABIs (such as the slightly different calling conventions for AIX and MacOS X). Maybe, their code could serve as an example for how to structure the JIT interface so it can cope with different ABIs. Jaos works on top of an abstraction called object kernel, which basically is an API to garbage collection, synchronization, etc. Patrik Reali might be able to tell the list more about this. General API - Verifier interface? Does the verifier do all checking or does it impose some requirements on the JIT/interpreter? (Some verifiers choose to delay some checking until interpretation.) Does the JIT want/need information already computed by the verifier? For instance basic blocks or the type map at a given statement. I think it would be very wasteful to compute this information twice, but it might be very difficult to define common data structures that are suitable for everyone. Might it be sufficient if a verifier could store some opaque reference for later use by the JIT? AegisVM writes that they have developed a modular bytecode verification architecture, but I didn't look at this yet. Another thing that might be interesting to share is parts of a compiler backend, such as assemblers. -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath -- Chris Gray /k/ Embedded Java Solutions Embedded Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 477 599 703 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: File.list()
On Mon, Nov 24, 2003 at 08:44:56PM -0500, David Bélanger wrote:
Hi,
This may be some trace left from a old bug.
File: java/io/File.java.
A long time ago, there was a bug with listInternals as it was
not returning an empty array for no files. This has been
fixed since then and listInternals returns only NULL on error.
If there are no files, it correctly returns a String array
of length 0.
The current implementation of Filelists is as follows:
-
public String[] list (FilenameFilter filter)
{
checkRead ();
// Get the list of files
String list_path = PlatformHelper.removeTailSeparator(path);
File dir = new File(list_path);
if (! dir.exists() || ! dir.isDirectory() ) return null;
String files[] = listInternal(list_path);
-- if (files == null)
-- return new String[0];
if (filter == null)
return files;
Note: From the current implementation of listInternal, it will return NULL
only on error, and it will correctly return new String[0] if
the directory is empty. (I checked with gdb to make sure).
So, I suggest something like:
if (files == null) {
throw new IOException(Unknown IO Exception);
}
I am assuming some JCL_* functions set exceptions on errors (did not study
them) but this may get other exceptional cases.
Let me know if it makes sense.
Sorry for answering so late.
According to SUNs JDK 1.4.2 online api documentation this method doesnt
throw any exception except SecurityException. Throwing an IOException
would be wrong.
I think the code you marked above is wrong because it hides an error in
listInternal with an empty file list. list(FilenameFilter filter) should
return null.
Just my 2 cents.
Michael
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
FYI: Patch: file stuff
Hi list, I wanna start a new trend on this mailing list now. I wanna ask for approving the attached patch. This patch fixes two bugs with files. 1) java.io.File.list() uses an internal method called listInternal(). This methods returns null in the error case. list() now converts this to a String[0] array which is similar to an empty directory. This behaviour is incorrect. We should return the null in the error case. 2) Java_java_io_File_listInternal doest release local references to a newly created string. This patch fixes this. Please review and comment. mjw: Okay to commit ? Michael 2004-01-10 Michael Koch [EMAIL PROTECTED] * java/io/File.java (list): Return null in error case. * native/jni/java-io/java_io_File.c (Java_java_io_File_listInternal): release local reference. Index: java/io/File.java === RCS file: /cvsroot/classpath/classpath/java/io/File.java,v retrieving revision 1.37 diff -u -b -B -r1.37 File.java --- java/io/File.java 21 Oct 2003 14:53:54 - 1.37 +++ java/io/File.java 10 Jan 2004 22:39:01 - @@ -670,8 +670,10 @@ String files[] = listInternal(list_path); +// Check if an error occured in listInternal(). if (files == null) - return new String[0]; + return null; + if (filter == null) return files; Index: native/jni/java-io/java_io_File.c === RCS file: /cvsroot/classpath/classpath/native/jni/java-io/java_io_File.c,v retrieving revision 1.9 diff -u -b -B -r1.9 java_io_File.c --- native/jni/java-io/java_io_File.c 19 Aug 2003 08:59:56 - 1.9 +++ native/jni/java-io/java_io_File.c 10 Jan 2004 22:39:01 - @@ -682,6 +682,9 @@ /* save into array */ (*env)-SetObjectArrayElement(env, filearray, i, str); + + /* delete local reference */ + (*env)-DeleteLocalRef(env, str); } /* free resources */ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
