Andrew Haley writes:
Looking at the Classpath sources for ObjectInputStream, it seems that
the area where I had so much trouble has been reworked. I'll
investigate importing those classes into libgcj.
I've thought about this some more, and come to the conclusion that the
best thing is to
in gcj's serialization code mean that we have interoperability between
Sun's RMI and gcj's, in both client-server directions.
I haven't tried anything more elaborate than this simple test, though.
Andrew.
bug, please do, but IMO the only cure
for our serialization code is to replace it altogether.
Andrew.
2007-04-25 Andrew Haley [EMAIL PROTECTED]
* java/io/ObjectStreamClass.java (ensureFieldsSet): New method.
(setFields): call ensureFieldsSet.
(fieldsSet): New field
Looking at the Classpath sources for ObjectInputStream, it seems that
the area where I had so much trouble has been reworked. I'll
investigate importing those classes into libgcj.
Andrew.
I'm applying Andrew Haley's recent patch to HEAD,
along with the addition of a new ObjectName constant.
Changelog:
2007-04-06 Andrew John Hughes [EMAIL PROTECTED]
* javax/management/ObjectName.java:
(WILDCARD): Added.
2007-04-04 Andrew Haley [EMAIL PROTECTED]
This patch makes the Notification and MBeanFeature/AttributeInfo
classes serialization compatible with Sun's JDK.
Changelog:
2007-04-06 Andrew John Hughes [EMAIL PROTECTED]
* javax/management/MBeanAttributeInfo.java:
(serialVersionUID): Added.
* javax/management
This patch adds the missing java.io methods for 1.4,
which handle unshared object serialization.
Changelog:
2006-12-24 Andrew John Hughes [EMAIL PROTECTED]
* gnu/classpath/Pair.java: New class.
* java/io/ObjectInputStream.java:
(readUnshared()): Implemented
Andrew == Andrew John Hughes [EMAIL PROTECTED] writes:
Andrew * gnu/classpath/Pair.java: New class.
I think this would probably be better in gnu.java.util.
Usually we're reserving gnu.classpath for stuff that should never be
accessed by user code for security reasons; we've got other
This patch adds serialization support to BeanContextSupport.
Tests to follow.
Changelog:
2006-11-27 Andrew John Hughes [EMAIL PROTECTED]
* java/beans/beancontext/BeanContextSupport.java:
(readObject(ObjectInputStream)): Implemented.
(writeObject(ObjectOutputStream
Tom == Tom Tromey [EMAIL PROTECTED] writes:
Tom I checked something like this into libgcj. I'd like some comments on
Tom it.
Tom This is a different serialization fix for Locale. See the earlier
Tom thread for background:
I checked this in today.
Tom
I checked something like this into libgcj. I'd like some comments on
it.
This is a different serialization fix for Locale. See the earlier
thread for background:
http://developer.classpath.org/pipermail/classpath-patches/2006-August/003818.html
I prefer this fix because it uses one less field
Hi there,
Jeroen Frijters schrieb:
Roman Kennke wrote:
What about
|| (l == VMClassLoader.getSystemClassLoader())
instead ?
You shouldn't call VMClassLoader.getSystemClassLoader() (it creates a
new instance of the system class loader), but apart from that comparing
against the system class
Roman Kennke wrote:
Jeroen Frijters schrieb:
Roman Kennke wrote:
What about
|| (l == VMClassLoader.getSystemClassLoader())
instead ?
You shouldn't call VMClassLoader.getSystemClassLoader() (it
creates a
new instance of the system class loader), but apart from
that comparing
Roman Kennke wrote:
Friedjof hacked up the Object de-/serialization code for improved
performance. It is now an order of magnitude faster.
Thanks. Most of it looks good. A few comments:
This looks funny:
+ {System.err.println(1);
I think this is bad style:
+catch
Roman Kennke wrote:
This test is wrong:
+ || (l.getClass().getClassLoader() == null /*
application loader
*/);
If an application instantiates URLClassLoader, it should still be
garbage collectable.
I think that he should consider using a cache that uses
weak references
Roman Kennke wrote:
What about
|| (l == VMClassLoader.getSystemClassLoader())
instead ?
You shouldn't call VMClassLoader.getSystemClassLoader() (it creates a
new instance of the system class loader), but apart from that comparing
against the system class loader would work, but I'd much
This is a major embarassment.
2006-08-13 Sven de Marothy [EMAIL PROTECTED]
* java/util/Locale.java
(hashcode): Is a serialized field, not transient.
(equals): Should NOT compare strings by reference.
(readObject/writeObject): Use the default methods and handle
On Sun, 2006-08-13 at 02:21 +0200, Sven de Marothy wrote:
2006-08-13 Sven de Marothy [EMAIL PROTECTED]
* java/util/Locale.java
(hashcode): Is a serialized field, not transient.
(equals): Should NOT compare strings by reference.
(readObject/writeObject): Use the
+ * for serialization purposes. The actual cache is hashcodeCache
*
* @serial should be -1 in serial streams
*/
- private int hashcode;
+ private int hashcode = -1;
+
+ /**
+ * This is the cached hashcode.
+ */
+ private transient int hashcodeCache;
/**
* Array storing all
java.io.Serializable;
import java.util.EventListener;
@@ -440,4 +443,33 @@
{
return (ChangeListener[]) getListeners(ChangeListener.class);
}
+
+ /**
+ * Provides serialization support.
+ *
+ * @param stream the output stream (codenull/code not permitted).
+ *
+ * @throws
I'm committing the attached patch to merge enum
serialization support from the generics branch to HEAD.
Changelog:
2006-04-02 Andrew John Hughes [EMAIL PROTECTED]
* java/io/ObjectOutputStream.java:
(writeObject(Object)): Added enum support.
(writeClassDescriptor
Hi,
this fixes the serialization issues reported. I will go later through
the remaining stuff of javax.naming.* to fix some more serialization stuff.
2006-04-06 Wolfgang Baer [EMAIL PROTECTED]
Fixes bug #26995
* javax/naming/directory/BasicAttribute.java,
* javax
Hi,
I have checked all the classes of the javax.naming subpackages and
found one more serialization problem which is fixed by this patch.
2006-04-06 Wolfgang Baer [EMAIL PROTECTED]
* javax/naming/CompositeName.java:
(readObject): New deserialization method
I'm committing the attached patch which adds enum serialization support
to ObjectOutputStream.
Changelog:
2006-04-02 Andrew John Hughes [EMAIL PROTECTED]
* java/io/ObjectOutputStream.java:
(writeObject(Object)): Added enum support.
(writeClassDescriptor
Hi Andrew,
On Mon, 2006-03-27 at 22:45 +0100, Andrew John Hughes wrote:
2006-03-27 Andrew John Hughes [EMAIL PROTECTED]
* java/math/RoundingMode.java:
Fixed serialization UID.
* java/net/Proxy.java:
(Type): Likewise.
This breaks the generics branch autobuilder
Andrew == Andrew John Hughes [EMAIL PROTECTED] writes:
Andrew I'm committing the attached patch which fixes the
Andrew serialization UIDs for two new enumerations.
I was wondering about this patch, in particular, whether we really
need to specify serialVersionUID for an enum. Enums
Mark == Mark Wielaard [EMAIL PROTECTED] writes:
Mark This breaks the generics branch autobuilder:
Fixed as appended.
Tom
2006-03-28 Tom Tromey [EMAIL PROTECTED]
* java/net/Proxy.java (TYPE): Added missing ;.
Index: java/net/Proxy.java
I'm committing the attached patch which fixes the serialization UIDs for two
new enumerations.
Changelog:
2006-03-27 Andrew John Hughes [EMAIL PROTECTED]
* java/math/RoundingMode.java:
Fixed serialization UID.
* java/net/Proxy.java:
(Type): Likewise
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-07 16:05 ---
Fix was checked in before 0.90.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
I submitted the patch written by Rafael Teixeira:
http://developer.classpath.org/pipermail/classpath-patches/2006-February/000473.html
that fixes BigInteger serialization.
2006-02-28 Anthony Balkissoon [EMAIL PROTECTED]
* java/math/BigInteger.java:
Committed patch by Rafael
Tony == Anthony Balkissoon [EMAIL PROTECTED] writes:
Tony I submitted the patch written by Rafael Teixeira:
Tony
http://developer.classpath.org/pipermail/classpath-patches/2006-February/000473.html
Tony that fixes BigInteger serialization.
You have to be careful with patches like
thing to do (hard
to express this idea very differently in code - although you did clean
it up to be in GNU style - thanks). To make that more clear you could
comment the code/method to explain the serialization representation for
the end-user.
Cheers,
Mark
(*) See also
http://www.gnu.org/prep
Hi,
this patch fixes all incompatibilities with serialization in the javax.print
namespace. If I haven't forgot something all is now conformant to the JDK
classes serialized form.
2006-02-23 Wolfgang Baer [EMAIL PROTECTED]
* javax/print/attribute/standard/MediaSize.java
When reading GNU Classpath a serialized BigInteger with Sun's
VM/rt.jar, I was getting a StreamCorruptedException: signum-magnitude
mismatch.
Comparing serialized blobs I've found that for ZERO-valued
BigIntegers, Sun expect that magnitude comes out as a zero-element
byte array.
Below is a patch
Hi,
here is another individual fix proposition in the serialization area,
but in the serialization process itself this time. I propose to commit
it with the following changelog :
2006-02-15 Olivier Jolly [EMAIL PROTECTED]
* java/io/ObjectOutputStream.java (writeClassDescriptor):
Call
Hi Olivier,
On Wed, 2006-02-15 at 19:23 +0100, Olivier Jolly wrote:
2006-02-15 Olivier Jolly [EMAIL PROTECTED]
* java/io/ObjectOutputStream.java (writeClassDescriptor):
Call assignNewHandle() after writing Proxy class.
Look great. Please commit.
Thanks,
Mark
signature.asc
The first
constructor of the first concrete non serializable super class was
selected instead of the first non serializable super class, either
concrete or abstract. It is reported in bugzilla as bug 14144 (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14144 )
Strange. I cannot see why we
Hi,
this is my first patch proposition to classpath. I just have my
paperwork done with FSF and I have created an account on savannah as ojolly.
Those patches are both dealing with serialization. One deals with the
generation of back reference handle in the output stream which was
forgotten
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
Hi Gary,
On Tue, 2006-01-24 at 14:14 +, Gary Benson wrote:
I just committed a patch that implements serialization in
java.net.SocketPermission. I had to add a dummy field,
actions, in order for the serialized representation to
match that from a proprietary JVM. This seems sucky, but
I
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
Hi all,
I just committed a patch that implements serialization in
java.net.SocketPermission. I had to add a dummy field,
actions, in order for the serialized representation to
match that from a proprietary JVM. This seems sucky, but
I think it's the only way.
Cheers,
Gary
k
Index: ChangeLog
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
I'm committing the attached patch which fixes a regression in
object serialization, namely:
+FAIL: gnu.testlet.java.text.DecimalFormatSymbols.serial (number 1)
+FAIL: gnu.testlet.java.text.DecimalFormatSymbols.serial:
uncaught exception: java.lang.NullPointerException
I couldn't work out why
Tom Tromey wrote:
This updates QName to be Serializable as required by 1.5.
As part of this, I changed the qName field to be computed lazily, so
that it would work properly with serialization without requiring a
readObject method.
Any comments? Is this ok? This isn't really my area so I
I'm checking this in.
This fixes some serialization buglets in javax.xml that were pointed
out by japi (against 1.5). Normally I would ask for comment on a
patch well outside my area like this, but this one seems pretty
obvious.
For some of these classes, our javadoc says '@since 1.3
I'm checking this in.
This is a small serialization fix in java.text.
Tom
Index: ChangeLog
from Tom Tromey [EMAIL PROTECTED]
* java/text/DateFormat.java (serialVersionUID): New field.
Index: java/text/DateFormat.java
I'm checking this in.
I saw a bunch of AWT accessibility serialization reports in japi, so
I went through and fixed them all. There was only one case where a
change other than simply adding serialVersionUID was needed.
BTW I noticed this in List.java:
// FIXME: Need read/writeObject
IMO
I'm committing the attached patch, which fixes the problem described in:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310520
(for JamVM at least, the Kaffe problem seems to be something else)
Changelog:
2005-09-12 Andrew John Hughes [EMAIL PROTECTED]
*
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
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
Hi,
I fixed serialization/deseriazation of Proxy instances. Together with my
previous patch (javax.naming.CompoundName serialization) this allows a
JNDI lookup against JBoss to work now. I don't know anything about JNDI,
RMI or JBoss, so I don't know whether you can do anything useful now
Mark == Mark Wielaard [EMAIL PROTECTED] writes:
You compile all of these.
Then you go back and add 'private ... readResolve()' to B.
Mark How precisely would you go back?
Yeah, ignore that example. I was thinking about binary compatibility,
but that is too complicated.
Should C now really
Of Daniel Bonniot
Sent: Monday, June 27, 2005 19:32
To: classpath-patches@gnu.org
Subject: [cp-patches] Re: Serialization: readResolve and
writeReplace inparent class
This seems like it must be duplicated somewhere, but I couldn't find
it quickly.
I also looked but could not find code
: Friday, July 08, 2005 11:03
To: 'Daniel Bonniot'; classpath-patches@gnu.org
Subject: 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
Hi Jeroen Frijters,
Your patch broke the Mauve gnu.testlet.java.io.Serializable.readResolve
test.
What VM do you get this failure with? I tried again with jamvm and classpath
with my patch (and without yours) and all java.io.Serializable tests pass (0/5
failures).
If the readResolve
Daniel Bonniot wrote:
Your patch broke the Mauve
gnu.testlet.java.io.Serializable.readResolve
test.
What VM do you get this failure with? I tried again with
jamvm and classpath with my patch (and without yours) and all
java.io.Serializable tests pass (0/5 failures).
I used my own VM
Daniel Bonniot wrote:
I'm fairly confident that IKVM.NET does the right thing. My guess is
that JamVM incorrectly allows calls to private methods.
Is this a known missing feature in jamvm? Are there mauve
tests to check it?
I think that gnu.testlet.java.lang.reflect.Method.invoke is
Daniel Actually, this is a VM concern rather than a class library one, so I'm
Daniel not sure where such tests belong. Is there a common VM testsuite at
Daniel all? (other things that could be tested: integer and floating point
Daniel arithmetics, synchronization, ...)
There isn't one, but I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
Daniel Bonniot wrote:
I used my own VM (IKVM.NET).
:-)
I'm fairly confident that IKVM.NET does the right thing. My guess is
that JamVM incorrectly allows calls to private methods.
Is this a known missing feature in jamvm? Are there
Mark == Mark Wielaard [EMAIL PROTECTED] writes:
I wonder if there is a strange case here where someone adds a private
method to the class hierarchy later (after all the other classes are
compiled). Should the private method hide the superclass methods of
the same signature? Perhaps
On Tue, 2005-07-05 at 10:41 -0600, Tom Tromey wrote:
Mark == Mark Wielaard [EMAIL PROTECTED] writes:
Suppose you have a hierarchy like:
class A { blah blah readResolve() }
class B extends A { }
class C extends B { }
You compile all of these.
Then you go back and add 'private ...
Hi,
On Mon, 2005-06-27 at 19:32 +0200, Daniel Bonniot wrote:
I wonder if there is a strange case here where someone adds a private
method to the class hierarchy later (after all the other classes are
compiled). Should the private method hide the superclass methods of
the same signature?
Mark Wielaard wrote:
Hi Guilhem,
On Fri, 2004-04-02 at 21:52, Guilhem Lavaux wrote:
Here is the real patch for object serialization. I've added new static
methods to VMObjectStreamClass and changed the methods called in
ObjectStreamField accordingly. Note that we need to check all exceptions
Hi Guilhem,
On Fri, 2004-04-02 at 21:52, Guilhem Lavaux wrote:
Here is the real patch for object serialization. I've added new static
methods to VMObjectStreamClass and changed the methods called in
ObjectStreamField accordingly. Note that we need to check all exceptions
now as the native
Hi,
On Sun, 2004-04-04 at 20:01, Mark Wielaard wrote:
This looks very nice. Thanks.
Some nitpicks:
[...]
Last nitpick. I promise!
- Do you have a test case that can be added to Mauve?
Thanks,
Mark
signature.asc
Description: This is a digitally signed message part
, will not be fixed
Evaluation: These are the only thing which should ever behave this way,
so there's no need for a special interface for this. The JIT just needs
to handle these specially.
http://developer.java.sun.com/developer/bugParade/bugs/4174797.html
Synopsis: Serialization should not use reflection
Hi,
Here is the real patch for object serialization. I've added new static
methods to VMObjectStreamClass and changed the methods called in
ObjectStreamField accordingly. Note that we need to check all exceptions
now as the native functions may fail for some other obscure reasons.
ChangeLog
Mark Wielaard wrote:
Hi,
Hi Mark !
On Thu, 2004-03-25 at 21:19, Guilhem Lavaux wrote:
Some people has reported failures in kaffe with applications trying to
deserialize objects containing final fields. Apparently it is authorized
in the serialization spec but we cannot rely
Hi,
On Thu, 2004-03-25 at 21:19, Guilhem Lavaux wrote:
Some people has reported failures in kaffe with applications trying to
deserialize objects containing final fields. Apparently it is authorized
in the serialization spec but we cannot rely on
java.lang.reflect.Field to set them. So
Hi,
Some people has reported failures in kaffe with applications trying to
deserialize objects containing final fields. Apparently it is authorized
in the serialization spec but we cannot rely on
java.lang.reflect.Field to set them. So our only solution is to bypass
the protection
Guilhem Lavaux wrote:
In that case I'm proposing this patch. I have replaced the
type checks in setXXXField by a type check in
ObjectStreamClass.setClass by invoking a new method
ObjectStreamField.checkFieldType. Here I'm only checking
that the field is really assignable with a value
Guilhem Lavaux wrote:
The problem if you sort fields using
ObjectStreamField.compareTo is that you separate names which
are alphabetically sorted. I will explain this on the
following example.
[...explanation deleted...]
Thanks for explaining it! Now it makes sense and the patch looks good
java.security.PrivilegedAction;
/**
* This class intends to describe the field of a class for the serialization
@@ -99,7 +101,7 @@
/**
* There are many cases you can not get java.lang.Class from typename
- * if your context class loader cann not load it, then use typename to
+ * if your context
are written before reference
fields, it's not simply sorted by name. See
http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/class.doc3.ht
ml
Regards,
Jeroen
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
fields are written before reference
fields, it's not simply sorted by name. See
http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/class.doc3.ht
ml
Right. I've forgotten this problem. This was introduced to fix a
specific problem when you have inconsistencies between the field
descriptors
for the serialization
@@ -99,7 +101,7 @@
/**
* There are many cases you can not get java.lang.Class from typename
- * if your context class loader cann not load it, then use typename to
+ * if your context class loader cannot load it, then use typename to
* construct the field
Hi,
Here is a new patch I propose. I've taken the suggestion
into account and fix another small error reporting problem.
I don't understand checkTypeConsistency, it looks odd and I'm having a
hard time believing that it is correct. BTW, Shouldn't nonPrimitive be
named primitive?
Also, I
Jeroen Frijters wrote:
Hi,
Here is a new patch I propose. I've taken the suggestion
into account and fix another small error reporting problem.
I don't understand checkTypeConsistency, it looks odd and I'm having a
hard time believing that it is correct. BTW, Shouldn't nonPrimitive be
named
Brian == C Brian Jones [EMAIL PROTECTED] writes:
Brian I've been working a little lately on some tools I once added to
Brian japi for serialization compatibility testing.
Awesome! We've needed this for a long time.
Brian I've thought about trying to add this to Mauve. Thoughts? New
Brian
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
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
Guilhem Lavaux wrote:
Hi,
Here is the last patch on serialization.
This patch fixes the behaviour of readFields() in ObjectInputStream:
* if called multiple times read fields and build field decoder only once.
* more documentation
* GetField methods should take into account the flags concerning
1 - 100 of 152 matches
Mail list logo
