According to JDK1.2RC1 java.io.ObjectOutputStream/ObjectInputStream...
"The method does not need to concern itself with the state belonging
to the object's superclasses or subclasses."
Method here refers to readObject and writeObject. Hence I've written
ExceptionInInitializerError like this (te
Hi !
I am trying to import object serialization classes from Classpath to
kaffe. I managed
to make them work together but I found some behaviour inconsistencies.
For example,
I do not understand the method
java.io.ObjectStreamClass.getSerialPersistentFields:
apparently the official
Hi,
I nearly managed to get Classpath's serialization up to kaffe's level
and at the
same time keeping the advantage of it. However, it is "nearly". As I said to
Mark Wielaard, kaffe's regression tests TestSerialVersions.Test0007,
Test0009,
Test0010, Test0011,
Perhaps everyone already knew this; perhaps it's already been
discussed; but Stuart let me know that our Objects have to be serialized in
the Sun format to be compatible (this is fairly obvious in retrospect, but
an annoying pill to swallow). Just a reminder: anyone who writes a
serialized O
I'd like to remind everyone to download the JDK 1.2beta4 documentation and
ensure your classes are compatible with the JDK's for serialization
purposes. Every serializable class has a link on the doc page called
"Serializable Form" which includes the fields that must be
Apparently my thinking has at least something in common with Sun's.
(Whether that is a good thing or bad thing is debateable). The
"@serialized" tag I proposed for commenting serializable fields is actually
already part of the latest Javadoc spec. You might want to read up on it as
a few tags h
Does anyone know if there is a way to load a serialized Object using an
explicit ClassLoader? I need it for Beans.instantiate().
--John Keiser
Hi,
On Wed, 2003-08-06 at 18:38, Guilhem Lavaux wrote:
> I am trying to import object serialization classes from Classpath to
> kaffe.
Cool. If there is anything to make the use of these classes with Kaffe
easier, please let us know.
The ObjectIn/OutputStream implementations from GNU Cla
g a
getDeclaredField, but this time with the correct spelling).
I agree that the code is not that clean.
Once I have the agreement I will submit the necessary modifications to
make the serialization a little
stronger (well at least it will make kaffe's regression test pass).
There are sti
Guilhem Lavaux <[EMAIL PROTECTED]> writes:
> Hi,
>
> I nearly managed to get Classpath's serialization up to kaffe's
> level and at the same time keeping the advantage of it. However, it
> is "nearly".
>
> However I cam across an RMI's docu
> From: Stuart Ballard [mailto:[EMAIL PROTECTED]]
>
>
>
> For a spec that is supposed to be stable and implementable, beta4 has
a
> long way to go - I found another significant spec bug in the latest
> changes to java.util.List also, which will make some common methods in
> spec-conforming class
Stuart Ballard <[EMAIL PROTECTED]> writes:
> I've actually realised since posting this spec bug a better way to
> address it than the one I set out in the original bug report, but
> I'm still waiting for a bug number before I can submit this solution
> to Sun.
Don't wait for a bug report. None
John Keiser wrote:
>
> > From: Stuart Ballard [mailto:[EMAIL PROTECTED]]
> >
> > For a spec that is supposed to be stable and implementable, beta4 has
> a
> > long way to go - I found another significant spec bug in the latest
> > changes to java.util.List also, which will make some common method
A question about serialization. Do we have to make any instance variables
that aren't supposed to be serialized in the spec as transiet or something?
If we don't have to do that, we need to document which variables are
serialized in our code. This keeps people from changing thei
"John Keiser" <[EMAIL PROTECTED]> writes:
> Does anyone know if there is a way to load a serialized Object using an
> explicit ClassLoader? I need it for Beans.instantiate().
> --John Keiser
Subclass ObjectInputStream and override resolveClass() to use the
given ClassLoader:
public stati
We are going to run into a major problem with Serialization. Our
Objects are different from Sun's. Thus serialized Beans and objects coming
to us over RMI will very possibly not be in our format (anything that
contains a java.lang.String object, for example).
I have an idea of h
Hi,
The current ObjectInputStream/ObjectOutputStream implementation doesn't
support multiple private fields with the same name.
Example:
import java.io.*;
class sertestbase implements Serializable {
private int a = 1;
public String toString() { return "" + a; }
}
class sertest extends serte
I recently added some security checking code to libgcj. In particular
we now do access checking for reflection: Method calls and Field reads
and writes.
This breaks serialization quite dramatically. Now uses of
serialization cause crashes, as we get into infinite recursion
catching and writing
Hi,
Finally, I have followed kaffe's regression tests. Classpath's
serialization passes all kaffe's tests, although one is wrong
according to JDK 1.4.2 (TestSerialVersions.Test0007 should give "null,
105"). serialPersistentFields is now also used
by the reading pr
Guilhem Lavaux <[EMAIL PROTECTED]> writes:
> Hi,
>
> Finally, I have followed kaffe's regression tests. Classpath's
> serialization passes all kaffe's tests, although one is wrong
> according to JDK 1.4.2 (TestSerialVersions.Test0007 should give "null,
&g
Hi,
On Tue, 2003-08-12 at 01:13, Brian Jones wrote:
>
> Sweet, when could this go into Classpath?
Guilhem already send me a patch and as soon as the paperwork is done it
will almost certainly go immediately (I will review it, but it looks
pretty good). And Guilhem already checked in this new code
1 Guilhem Lavaux <[EMAIL PROTECTED]>
* java/io/ObjectStreamField.java: A few methods were added in prevision of the
upcoming upgrade of the serialization code.
(ObjectStreamField): We should throw a NullPointerException when 'name'
Hi,
Here is a new part of the patch for serialization. It is mainly about
restructuring the class lookup logic. It appeared that you need to build
a class lookup table and a class hierarchy for a given input stream.
Without that, if you write something with ObjectOutputStream and then
read
Hi,
This is the patch #5 (the last will be the #6) about serialization.
It fixes the following problems:
* getField handles transient and non persistent field,
* readClassDescriptor uses the right class loader to decode fields,
it also verifies that the available fields (and required by the input
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 ar
I found some serialization bugs when debugging JOnAS. The fixes are
on gcj-abi-2-dev-branch for some while, but I've kept them to myself
for too long.
The current implementation doesn't handle nested objects very well,
and doesn't use the correct class loader. I fixed that,
Hi,
I cooked up the attached serialization patch to fix a failure on Mauve's
gnu.testlet.java.io.ObjectInputOutput.InputTest.
Specifically, the test that deserializes a non-public Externalizable
class.
Please review.
Regards,
Jeroen
objectinput.patch
Description: objectinput.
John Keiser wrote:
>
> We are going to run into a major problem with Serialization. Our
> Objects are different from Sun's. Thus serialized Beans and objects coming
> to us over RMI will very possibly not be in our format (anything that
> contains a java.lang.String
; To: [EMAIL PROTECTED]
> Subject: Re: Serialization and Sun
>
>
> John Keiser wrote:
> >
> > We are going to run into a major problem with Serialization. Our
> > Objects are different from Sun's. Thus serialized Beans and
> objects coming
> > to
"John Keiser" <[EMAIL PROTECTED]> writes:
> Aye, I saw that. It's a good thing. Still, it begs the question:
> are we going to use Sun's serialized format for all our core
> objects?
Yes.
--
Paul Fisher * [EMAIL PROTECTED]
"Aaron M. Renn" <[EMAIL PROTECTED]> writes:
> A question about serialization. Do we have to make any instance variables
> that aren't supposed to be serialized in the spec as transiet or something?
> If we don't have to do that, we need to document which var
d some element of clarity to it.
- Godmar
>
> A question about serialization. Do we have to make any instance variables
> that aren't supposed to be serialized in the spec as transiet or something?
> If we don't have to do that, we need to document which vari
> "David" == David P Grove <[EMAIL PROTECTED]> writes:
David> If you come up with a finer-grained fix for libgcj, let me know
David> -- I'm not that happy with what we are currently doing in Jikes
David> RVM.
I checked in a couple patches last night that fix this problem.
Basically we now cal
Hi Tom,
We've
had security manager checks in the reflection code in Jikes RVM for a while.
Our current workaround for serialization is that classes loaded by
the system classloader are always allowed access. This is probably
too big of a hole, but it does work in practice. Th
On Saturday, Aug 2, 2003, at 01:46 Pacific/Auckland, David P Grove wrote:
Hi Tom,
We've had security manager checks in the reflection code in Jikes RVM for a while. Our current workaround for serialization is that classes loaded by the system classloader are always allowed a
On Monday 04 August 2003 01:53, Bryce McKinlay wrote:
> On Saturday, Aug 2, 2003, at 01:46 Pacific/Auckland, David P Grove
>
> wrote:
> > Hi Tom,
> >
> > We've had security manager checks in the reflection code in
> > Jikes RVM for a while. Our c
Chris Gray wrote:
> Granting AllPermission to everything loaded by the system
> class loader is IMHO acceptable, *iff* by system class
> loader you mean the class loader which
> loads java.* classes from a trusted location.
This is the "bootstrap class loader" aka "null class loader" (because
Ob
ystem
classloader, it doesn't need a PrivilegedAction. ie: regardless of the
code that calls it, the ObjectOutputStream class itself always has full
privileges (assuming the default security policies). Note that the
serialization classes have their own security checks to prevent them
always be loaded by the system
> classloader, it doesn't need a PrivilegedAction. ie: regardless of the
> code that calls it, the ObjectOutputStream class itself always has full
> privileges (assuming the default security policies). Note that the
> serialization classes have their own se
On Monday 04 August 2003 11:57, Jeroen Frijters wrote:
> Chris Gray wrote:
> > Granting AllPermission to everything loaded by the system
> > class loader is IMHO acceptable, *iff* by system class
> > loader you mean the class loader which
> > loads java.* classes from a trusted location.
>
> This i
On Monday, Aug 4, 2003, at 21:33 Pacific/Auckland, Chris Gray wrote:
No. The security context of a given method invocation is the set of
classes
"on the stack" at the time of the invocation, and the resulting set of
privileges is the intersection of the privileges of all those classes.
So if
co
On Tuesday 05 August 2003 01:43, Bryce McKinlay wrote:
> The performance implications of all this are also rather concerning -
> walking up the stack is going to be fairly slow. But I presume that for
> normal applications where security is not required (ie
> System.getSecurityManager()), such che
indow where other unprivileged code could access that
> Method. This can only happen in the serialization code if Class
> returns the same Method or Field object to other callers.
It is not valid, but the vm reference classes of GNU Classpath do
suggest this wrong optimization. I just added a coup
> "Bryce" == Bryce McKinlay <[EMAIL PROTECTED]> writes:
Bryce> But I presume that for normal applications where security is
Bryce> not required (ie System.getSecurityManager()), such checks are
Bryce> avoided?
Yes, the security manager itself walks the stack in this case, so if
there is no se
eged code could access that
Method. This can only happen in the serialization code if Class
returns the same Method or Field object to other callers.
Tom
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Hi,
would like to propose a modification to Toms fix. It looks to me as if
all fields of a deserialized object are accessible as well as the
private readObject-Method. Or does the VM reset the Accessible flag?
I think we need to reset the accessible flag after we are done with the
field or met
Hi,
it seems there is a misunderstanding problem between kaffe's class loader
mechanism and classpath's serialization. Here is the current state:
* ObjectInputStream builds class decriptors from input stream, or if it
is not described build them from classes directly. To do so it resolv
Guilhem Lavaux wrote:
Hi,
Here is a new part of the patch for serialization. It is mainly about
restructuring the class lookup logic. It appeared that you need to build
a class lookup table and a class hierarchy for a given input stream.
Without that, if you write something with
Salut Guilhem,
Guilhem Lavaux wrote:
Hi,
This is the patch #5 (the last will be the #6) about serialization.
It fixes the following problems:
* getField handles transient and non persistent field,
* readClassDescriptor uses the right class loader to decode fields,
it also verifies that the
Dalibor Topic wrote:
Salut Guilhem,
@@ -442,18 +443,46 @@
String field_name = this.realInputStream.readUTF ();
dumpElementln (field_name);
String class_name;
- +
+// There're many cases you can't get java.lang.Class from
+// typename if your context class loader
Guilhem Lavaux <[EMAIL PROTECTED]> writes:
> Dalibor Topic wrote:
>
> > Salut Guilhem,
> >
> >> @@ -442,18 +443,46 @@
> >> String field_name = this.realInputStream.readUTF ();
> >> dumpElementln (field_name);
> >> String class_name;
> >> - + +// There're many cases y
Brian Jones wrote:
Guilhem Lavaux <[EMAIL PROTECTED]> writes:
Dalibor Topic wrote:
Salut Guilhem,
@@ -442,18 +443,46 @@
String field_name = this.realInputStream.readUTF ();
dumpElementln (field_name);
String class_name;
- + +// There're many cases you c
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 u
>>>>> "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 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
Regards,
Jeroen
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/ma
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
d
g.reflect.TypeSignature;
+import java.security.AccessController;
+import 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
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,
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
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 g
24 Feb 2004 17:15:57 -
@@ -41,6 +41,8 @@
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;
import gnu.java.lang.reflect.TypeSignature;
+import java.security.AccessController;
+import java.security.PrivilegedAction;
/**
* This class intends to describe the field of a class for the serializ
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
Sun seems to still be plugging away at this, new comment on 12-14.
> Robert wants to look at this to see how difficult it would be to fix
> for 1.2.2 Atul, perhaps you could look at this first, then present it
> to Robert. x@x 1998-12-14
Looked at a review of the South Park game today.
Hi,
On Thu, 2003-08-14 at 16:04, Guilhem Lavaux wrote:
> Thanks to Mark I have found a compatible way to do what I want with the
> SecurityManager.
> I am going to see if it works in real world now.
For an example of what I suggested see the way java.util.ResourceBundle
creates a SecurityManager
Hi,
Thanks to Mark I have found a compatible way to do what I want with the
SecurityManager.
I am going to see if it works in real world now.
Thanks Mark ! ;)
Cheers,
Guilhem.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/
Hi,
I think I will have to begin the split of the serialization patch at a
time or another. I'm beginning with this really simple patch for
TypeSignature.
It is needed so class can resolved by name using a specific class loader
and not using a default class loader as it was the case wit
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
each serialized fields
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 in
--- 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
e stream.
Reverse engineering of this nature is not allowed. Serialization of
classes is to be written according to the javadocs. If the javadocs
are incomplete, file a bug report with Sun.
We had this discussion a long time ago. If we do find a case where we
need to reverse engineer a serialized objec
Hi,
This patch adds extra checking required by JDK's behaviour. If someone
tries to assign a field which has not the required type then an
InvalidClassException should be thrown.
Please review it.
Cheers,
Guilhem.
P.S.: Should I really write a documentation for each of the methods in
this pat
Salut Guilhem,
Guilhem Lavaux wrote:
Hi,
I think I will have to begin the split of the serialization patch at a
time or another. I'm beginning with this really simple patch for
TypeSignature.
It is needed so class can resolved by name using a specific class loader
and not using a de
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
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
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 on
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.
Chan
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,
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
___
; to handle these specially.
>
> http://developer.java.sun.com/developer/bugParade/bugs/4174797.html
> Synopsis: Serialization should not use reflection to set final fields
> State: Closed, fixed
> Evaluation: [...] Serialization needs to use JNI SetField Routines
> to set fields, instead
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 excep
engineering of this nature is not allowed. Serialization of
> classes is to be written according to the javadocs. If the javadocs
> are incomplete, file a bug report with Sun.
>
> We had this discussion a long time ago. If we do find a case where we
> need to reverse engineer a seria
Scott Miller <[EMAIL PROTECTED]> writes:
> Am I right in assuming this is a moot point because serialization
> does this anyway and he doesn't need to have read/writeObject
> serialize those fields (As they are listed in the docs)?
Sun documents (as of 1.2b4) how cl
On Wed, Nov 26, 2003 at 09:07:24PM +0100, Guilhem Lavaux wrote:
> P.S.: Should I really write a documentation for each of the methods in
> this patch ? I would think they are straightforward to understand... In
> the other case I'll try to write something.
The way you do it here seems okay, but
Sorry. Here is the patch.
Guilhem.
Index: java/io/ObjectInputStream.java
===
RCS file: /cvsroot/classpath/classpath/java/io/ObjectInputStream.java,v
retrieving revision 1.32
diff -u -r1.32 ObjectInputStream.java
--- java/io/ObjectInpu
Hi Guilhem,
Guilhem Lavaux wrote:
Hi,
This patch adds extra checking required by JDK's behaviour. If someone
tries to assign a field which has not the required type then an
InvalidClassException should be thrown.
Please review it.
The patch looks good to me. If we don't have mauve tests for th
We have tested some Classpath serialization mechanisms with ORP providing complementary
native implementations. We found some problems in ObjectInputStream/ObjectOutputStream/
ObjectStreamClass/Throwable classes.
Here is the first of the series.
1. About ObjectOutputStream
Considered the
About the serialization of Throwable:
Consider the snippet from Throwable.java:
private void writeObject(java.io.ObjectOutputStream s)
throws IOException
{
ObjectOutputStream.PutField oFields;
oFields = s.putFields();
oFields.put("detailMessage"
Object serialization problems about ObjectInputStream, part 1:
Consider read (...) here:
public int read (byte data[], int offset, int length) throws IOException
{
if (this.readDataFromBlock)
{
- if (this.blockDataPosition + length >= this.blockDataBytes){
+
On Wed, 26 Jul 2000, Jochen Hoenicke wrote:
> Nonfinal static fields that are initialized and "static {...}" blocks
> in the java code are compiled to a "" constructor in bytecode.
> To calculate the serialVersionUID, classpath has to know the presence
> of this constructor. IIRC it uses a nativ
> try
> {
> ...
> }
> catch (IOException e)
> {
> + if(e instanceof NotSerializableException ){ <- Comment 2
> + throw e;
> + }
>...
> }
>
The following should be more elegant:
try {
...
}
catch (NotSeri
>>>>> "Bryce" == Bryce McKinlay <[EMAIL PROTECTED]> writes:
Bryce> Yes, In this case I dont see why it shouldn't be done in Java
Bryce> unless there is a compelling performance advantage in doing
Bryce> otherwise. In fact I suspect that all of Seriali
Hi, Bryce,
I heard of a pure-java implementation of java.util.zip.* named jazzlib, but I
never tried it. Would you like
to try it?
> It should be trivial to merge the BigInteger stuff into classpath. For
>java.util.zip as you know it is more
> difficult for us due to the native code
ct I suspect that all of Serialization can be
implemented in pure Java, it
is probably just for legacy reasons that we have native methods in there at all. This
would require some
significant reworking of the code but I think it would be worthwhile.
> BTW, because of legacy problems, w
"Wu, Gansha" <[EMAIL PROTECTED]> writes:
> About the serialization of Throwable:
>
> Consider the snippet from Throwable.java:
>
> private void writeObject(java.io.ObjectOutputStream s)
> throws IOException
> {
> ObjectOutput
Hi, Brian,
You're right. Exception will be thrown if field is null, I mean to put a mapping
between local field name and serialized field name, e.g, in writeObject():
... ...
oFields.put("message", "detailMessage", message);
That means that a local field mes
On Wed, 26 Jul 2000, Warren Levy wrote:
> Classpath calls a private static method in ObjectStreamClass
> (hasClassInitializer) to check this; which in turn calls a Class method:
>
> Class classArgs[] = {};
> Method m = clazz.getMethod ("", classArgs);
Ah, the above call should be g
--- Comment #2 from audriusa at bluewin dot ch 2006-01-27 16:33 ---
Created an attachment (id=10742)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10742&action=view)
Proposed fix
This patch fixes the RMI bug 25520 (the user class is not found by the RMI
server). The user class is
Hi there!
Does anybody know a java-1.1 compatible serialization framework which
is not integrated into a jre's classpath, so that it can be used just
as any other external library.
I would need such a library for also supporting older jvms like msjvms
or netscape jvms :(
It would be gre
98 matches
Mail list logo
