Damm!!!! I hate to bother people on stupid things. You are right, I
did change my classpath on the window I was using to run the class
but not on the one that was doing the compiling :(
Now it works great. BTW you might be interested to know that JSX
creates smaller object footprints (for objects bigger than 100bytes)
which is very good for doing XML based network comunnication. On the
other hand XSJ is 3 times slower than Java's native serialization
routines.
Thanks for your help
Matias
--- In JSX-ideas@y..., bren@m... wrote:
> Hi again Matias,
>
> > Messenger.java:261: JSX.Config is not public in JSX; cannot be
> > accessed from outside package
>
> > It seems that somebody forgot to export it.
>
> Got it!
>
> "Config" has actually been in the package for a while now, but not
> used, and not public. It only does anything in the very latest
> release (JSX0.9.3.0) - somehow, you must be invoking a previous
> version of JSX. Assuming you downloaded the latest one ;-),
> perhaps the old jar is still in your classpath?
>
> I'm so sure this guess is right - please let me know if it was!
>
> > Thanks and keep up with the good work
> Thanks very much! Such encouragement is very much appreciated.
>
>
> Cheers,
> Brendan
Hi Matias,
--- In JSX-ideas@y..., mcuenca2@m... wrote:
> Damm!!!! I hate to bother people on stupid things. You are right,
> I did change my classpath on the window I was using to run the
> class but not on the one that was doing the compiling :(
Don't worry, just glad to get it working for you, and problems that
are easily solved have their own special charm. ;-)
Also, it seems that "outside the frame" problems like this with
classpath one are very common, and the more of them I see, the
easier it is to diagnose them.
> Now it works great. BTW you might be interested to know that JSX
> creates smaller object footprints (for objects bigger than
> 100bytes) which is very good for doing XML based network
> comunnication.
That is interesting! You mean smaller than binary serialization, or
smaller than it was before?
> On the other hand XSJ is 3 times slower than Java's native
> serialization routines.
JSX has a lot of inefficiency in it, and soon I plan to re-architect
it, and integrate it more closely with native serialization, which
should make it much faster (though probably not quite as fast as
the binary format).
Have a great day!
Cheers,
Brendan
PS: if you would like to, I'd be very keen to hear how you are
using JSX, and if you have any other problems with it, or suggestions.
> Thanks for your help
> Matias
>
> --- In JSX-ideas@y..., bren@m... wrote:
> > Hi again Matias,
> >
> > > Messenger.java:261: JSX.Config is not public in JSX; cannot be
> > > accessed from outside package
> >
> > > It seems that somebody forgot to export it.
> >
> > Got it!
> >
> > "Config" has actually been in the package for a while now, but not
> > used, and not public. It only does anything in the very latest
> > release (JSX0.9.3.0) - somehow, you must be invoking a previous
> > version of JSX. Assuming you downloaded the latest one ;-),
> > perhaps the old jar is still in your classpath?
> >
> > I'm so sure this guess is right - please let me know if it was!
> >
> > > Thanks and keep up with the good work
> > Thanks very much! Such encouragement is very much appreciated.
> >
> >
> > Cheers,
> > Brendan
Here are the experiments I did for some clases (includes lists and
hashes).
1-Java serial size:107bytes XML serial size:106bytes / 94bytes
2-Java serial size:368bytes XML serial size:408bytes / 361bytes
3-Java serial size:702bytes XML serial size:906bytes / 656bytes
The first number is the amount used by the standar java approach,
and the second on is JSX. The third one is JSX with no spaces. It's
interesting to note that java requires 32bytes to serialize an EMPTY
class!!! All the overhead I think come from their fingerprinting and
versioning mechanisms.
I'm using JSX to do XML based comunication between nodes on an
overlay P2P network. XML makes it easy to debug my comunications and
it doesn't add a big space overhead. It would be nice to be able to
define formaters that allow me to used a more compact XML notation
like for example reducing closing tag to the minimun needed to
deambiguate them i.e
<MyFirstTag>
<MySecondTag>
</MyS
</M
this was the reason why I looked into the config class, to see if
something like this was feasible.
Ok, back to work :)
Matias
--- In JSX-ideas@y..., bren@m... wrote:
> Hi Matias,
>
> --- In JSX-ideas@y..., mcuenca2@m... wrote:
> > Damm!!!! I hate to bother people on stupid things. You are
right,
> > I did change my classpath on the window I was using to run the
> > class but not on the one that was doing the compiling :(
>
> Don't worry, just glad to get it working for you, and problems that
> are easily solved have their own special charm. ;-)
>
> Also, it seems that "outside the frame" problems like this with
> classpath one are very common, and the more of them I see, the
> easier it is to diagnose them.
>
> > Now it works great. BTW you might be interested to know that
JSX
> > creates smaller object footprints (for objects bigger than
> > 100bytes) which is very good for doing XML based network
> > comunnication.
> That is interesting! You mean smaller than binary serialization, or
> smaller than it was before?
>
> > On the other hand XSJ is 3 times slower than Java's native
> > serialization routines.
> JSX has a lot of inefficiency in it, and soon I plan to re-
architect
> it, and integrate it more closely with native serialization, which
> should make it much faster (though probably not quite as fast as
> the binary format).
>
> Have a great day!
>
> Cheers,
> Brendan
> PS: if you would like to, I'd be very keen to hear how you are
> using JSX, and if you have any other problems with it, or
suggestions.
>
> > Thanks for your help
> > Matias
> >
> > --- In JSX-ideas@y..., bren@m... wrote:
> > > Hi again Matias,
> > >
> > > > Messenger.java:261: JSX.Config is not public in JSX; cannot
be
> > > > accessed from outside package
> > >
> > > > It seems that somebody forgot to export it.
> > >
> > > Got it!
> > >
> > > "Config" has actually been in the package for a while now, but
not
> > > used, and not public. It only does anything in the very latest
> > > release (JSX0.9.3.0) - somehow, you must be invoking a previous
> > > version of JSX. Assuming you downloaded the latest one ;-),
> > > perhaps the old jar is still in your classpath?
> > >
> > > I'm so sure this guess is right - please let me know if it was!
> > >
> > > > Thanks and keep up with the good work
> > > Thanks very much! Such encouragement is very much appreciated.
> > >
> > >
> > > Cheers,
> > > Brendan
Hi again Matias,
It's really good to see that the more compact version is already
being useful!
> 1-Java serial size:107bytes XML serial size:106bytes / 94bytes
> 2-Java serial size:368bytes XML serial size:408bytes / 361bytes
> 3-Java serial size:702bytes XML serial size:906bytes / 656bytes
>
> The first number is the amount used by the standar java approach,
> and the second on is JSX. The third one is JSX with no spaces. It's
> interesting to note that java requires 32bytes to serialize an
> EMPTY class!!!
> All the overhead I think come from their fingerprinting and
> versioning mechanisms.
Yes, I think so...
> I'm using JSX to do XML based comunication between nodes on an
> overlay P2P network. XML makes it easy to debug my comunications
and
> it doesn't add a big space overhead. It would be nice to be able to
> define formaters that allow me to used a more compact XML notation
> like for example reducing closing tag to the minimun needed to
> deambiguate them i.e
> <MyFirstTag>
> <MySecondTag>
> </MyS
> </M
> this was the reason why I looked into the config class, to see if
> something like this was feasible.
This is an appealing idea - not standard XML, of course. I think
the savings in length wouldn't be worth the reduction in readability
(the above example is readable, but would get much harder with
greater complexity.)
The above example relies on new-line characters for the end of the
tag - it would probably be better to do this:
> <MyFirstTag>
> <MySecondTag>
> </MyS>
> </M>
But actually, even this is not necessary, for we could do this:
> <MyFirstTag>
> <MySecondTag>
> </>
> </>
But if you wanted to go this route:
like nested parentheses, the close tag is always completely
determined. At any point in the XML, a close tag can only close
a particular element, for well-formed XML. This is because well-
formed XML is a tree. Thus, we don't need to disambiguate them, but
just have a "</>". You would just assume that the close tag is
always the right one. You could do this by altering the
XMLDeserialize source, so that the test on the close tag name is
ignored. In XMLSerialize, you would just replace all close tags
with "</>".
I wouldn't support this in the JSX releases, because it would not be
standard XML - which is a primary goal of JSX. Another reason is
that I think it really would be less readable. However, arguably,
a good XML-aware editor would add-in the required close tags, thus
making it human readable again...
I think you could probably acheive the above effects by
subclassing XMLSerialize and XMLDeserialize, and also subclassing
ObjIn and ObjOut to use your versions of XMLSerialize and
XMLDeserialize. That way, your changes would automatically be
applied to new releases of JSX as they came out - a bit like
swapping in different foundations!
Cheers,
Brendan
This email is to inform you of release '0.9.4.0' of 'Java Serialization to
XML' through freshmeat.net. All URLs and other useful information can be
found at http://freshmeat.net/projects/jsx/
The changes in this release are as follows:
Evolution of fieldnames can now be handled centrally. A
"NoSuchFieldHandler" is invoked for fieldnames in XML that are not present
in the class. You can specify what is done in that situation by
subclassing
NoSuchFieldHandler and setting it in the Config object.
If you would like to cancel subscription to releases of this project, login
to freshmeat.net and choose 'home' from the personal menubar at the top of
the page. You'll be presented with a list of projects you're subscribed to
in the right column, which you may cancel by highlighting the project in
question and clicking the 'delete' button.
Sincerely,
freshmeat.net
Externalizable is practically ready for release - I thought this
would be really useful; but looking closer, I see some limitations.
But first, let me cover what Externalizable is:
Externalizable is an interface, with readExternal() and
writeExternal() methods, which allows a class to control how it *and*
its superclasses are serialized - this differs from readObject()
and writeObject(), which only control the class itself is
serialized.
An example: if class Sub extends Super, both of them can have
a readObject() object, which writes out the fields that come from
each of the two classes. But if Sub implements Externalizable, then
only its readExternal is called - and any readObject() from Super
is ignored. In other words, if a subclass is Externalizable, it
trumps all of its superclasses, and it is up to that subclass to
take care of reading and writing all the fields of all the
superclasses.
Here's what I had thought we'd be able to do with it:
> >Firstly, what you really need is Externalizable together with
> >PutField and GetField - it's the only way for a class to take
> >control over the serialization of its superclasses
Now, the limitation: we can't use Externalizable together with
PutField and GetField, due to the interface definition:
void readExternal(ObjectInput in)
The problem is that ObjectInput does not have GetField and PutField,
and so they are not available within the method. Although we could
cast them to ObjectInputStream, but there is no guarantee that
this would work in general, as all we are promised is that "in"
implements the ObjectInput interface...
Any thoughts on this?
Cheers,
Brendan
bren@... wrote:
>Externalizable is practically ready for release - I thought this
>would be really useful; but looking closer, I see some limitations.
>But first, let me cover what Externalizable is:
>
>Externalizable is an interface, with readExternal() and
>writeExternal() methods, which allows a class to control how it *and*
>its superclasses are serialized - this differs from readObject()
>and writeObject(), which only control the class itself is
>serialized.
>
>An example: if class Sub extends Super, both of them can have
>a readObject() object, which writes out the fields that come from
>each of the two classes. But if Sub implements Externalizable, then
>only its readExternal is called - and any readObject() from Super
>is ignored. In other words, if a subclass is Externalizable, it
>trumps all of its superclasses, and it is up to that subclass to
>take care of reading and writing all the fields of all the
>superclasses.
>
>Here's what I had thought we'd be able to do with it:
>
>>>Firstly, what you really need is Externalizable together with
>>>PutField and GetField - it's the only way for a class to take
>>>control over the serialization of its superclasses
>>>
>
>Now, the limitation: we can't use Externalizable together with
>PutField and GetField, due to the interface definition:
> void readExternal(ObjectInput in)
>
>The problem is that ObjectInput does not have GetField and PutField,
>and so they are not available within the method. Although we could
>cast them to ObjectInputStream, but there is no guarantee that
>this would work in general, as all we are promised is that "in"
>implements the ObjectInput interface...
>
>Any thoughts on this?
>
>
>Cheers,
>Brendan
>
>
>
>To unsubscribe from this group, send an email to:
>JSX-ideas-unsubscribe@egroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
All I can say, is I'm going to jump on it as soon as I can. For my
application, I don't expect to have to deal with class evolution with
the very simple classes that I am going to extend instead of wrap. My
goal is to improve the readability the XML output.
JSX is already to the point where it works like JOS, but does allow the
developer to configure how to works such as circular references. As
long as functionality is compatible with JOS, it's up to the develper if
they wish to use features that are not compatible.
Can you fix the limitation in JSX and JOS and submit the JOS
enchancement to the java community process as an enhancement?
Anyway, I'll be glad to see Externalizable
Craig
I'm so frustrated! Can someone help me with this?
//This is how I write an object to a file (successfully, no
exception) :
FileOutputStream ostream = new FileOutputStream(file);
ObjOut out = new ObjOut(ostream, true);
out.writeObject(myObject);
ostream.close();
out.close();
//This is how I read an object from a file (sucessfully, no
exception):
FileReader fileReader = new FileReader(file);
BufferedReader bufferedReader = new BufferedReade(fileReader);
ObjIn in = new ObjIn(bufferedReader);
MyClass obj = (MyClass) in.readObject();
fileReader.close();
bufferedReader.close();
in.close();
//After reading object successfully, I try to write the object (just
read) back to a file call text.xml
File file2 = new File("C:\\data\\test.xml");
FileOutputStream ostream = new FileOutputStream(file2);
ObjOut out = new ObjOut(ostream, true);
out.writeObject(obj);
ostream.close();
out.close();
//Here is the exception I got:
java.lang.reflect.InvocationTargetException:
java.awt.color.CMMException: Invalid profile data
at sun.awt.color.CMM.checkStatus(CMM.java:121)
at java.awt.color.ICC_Profile.getData(ICC_Profile.java:1127)
at java.awt.color.ICC_Profile.writeObject(ICC_Profile.java:1739)
at java.lang.reflect.Method.invoke(Native Method)
at JSX.XMLSerialize.internalSer(XMLSerialize.java:950)
at JSX.XMLSerialize.getAllFields(XMLSerialize.java:862)
at JSX.XMLSerialize.serializeFields(XMLSerialize.java:712)
at JSX.XMLSerialize.serializeObject(XMLSerialize.java:523)
at JSX.XMLSerialize.serializeReferences(XMLSerialize.java:817)
at JSX.XMLSerialize.serializeObject(XMLSerialize.java:555)
at JSX.XMLSerialize.serializeReferences(XMLSerialize.java:817)
at JSX.XMLSerialize.serializeObject(XMLSerialize.java:555)
........................
//The object that I try to read and write has one transient variable
(a JFrame with many JInternalFrames and layers). I have to make that
variable transient because JSX does not handle that variable very
well and it prints out many exceptions. When I make that variable
transient, I face with the above problem. Please help!
Hi Kelly,
Don't worry! It's not your fault - you are using JSX correctly.
It looks like there is a bug in JSX.
If you can post more information about the problem, I will be able
to fix it for you - and by doing this you are making a great
contribution to an open source project, and will get your name up
on the homepage (but mainly, your code will start working!)
Could you please post:
- the exceptions you got before making that variable transient
- the source code for the object that is causing all the problems
- and the XML that JSX produces (the first time, when it runs
correctly).
Meanwhile, I will have a look at the java.awt.ICC_Profile class
which *might* be provoking the bug - but it's not really enough
information to go on, to diagnose the problem correctly.
> //Here is the exception I got:
> java.lang.reflect.InvocationTargetException:
> java.awt.color.CMMException: Invalid profile data
> at sun.awt.color.CMM.checkStatus(CMM.java:121)
> at java.awt.color.ICC_Profile.getData(ICC_Profile.java:1127)
> at java.awt.color.ICC_Profile.writeObject
(ICC_Profile.java:1739)
> //The object that I try to read and write has one transient
> variable (a JFrame with many JInternalFrames and layers). I have
> to make that variable transient because JSX does not handle that
> variable very well and it prints out many exceptions. When I make
> that variable transient, I face with the above problem. Please
> help!
The more information you post, the easier it is to help you! ;-)
Don't worry, we'll get it working soon! Relax, and have a great day!
Cheers,
Brendan
Hi again Kelly,
> Meanwhile, I will have a look at the java.awt.ICC_Profile class[...]
> > //Here is the exception I got:
> > java.lang.reflect.InvocationTargetException:
> > java.awt.color.CMMException: Invalid profile data
> > at sun.awt.color.CMM.checkStatus(CMM.java:121)
> > at java.awt.color.ICC_Profile.getData(ICC_Profile.java:1127)
> > at java.awt.color.ICC_Profile.writeObject
> (ICC_Profile.java:1739)
I found a bug in ICC_Profile handling. It's fixed now (yay!)
Hopefully, that was the sole cause of the problems you
encountered, and so the next release of JSX should end your
frustration!
You need the release with the version number: JSX0.9.5.0 (this also
includes Externalizable). It is up on the web site right now
(just put it there), and the freshmeat announcement should follow
in a few hours.
For those interested:
This bug was to do with readResolve(), and Serialization's hybrid
treatment of it:
In some ways it is like readObject(), which must be private, and is
only ever used for the class that declares it (ie it is not
inherited). It is still called by Serialization, even if private...
But in other ways, it is like readExternal(), which can have any
access modifier, and so can be inherited.
The result is that JSX has to simulate the accessibility rules for
readResolve() - which it now does.
If you ask me, this is pretty confusing. And certainly, I couldn't
see anything in the specs which suggested this behaviour! But
maybe I missed something:
http://java.sun.com/products//jdk/1.2/docs/guide/serialization/spec/in
put.doc6.html#5903
Even though the logic does make a kind of sense, I wonder if
there might be a better way to achieve the same effect?
Note that the inheritance of readResolve is very important for the
singleton enumeration pattern, where a different subclass represents
a different value. Their common superclass ensures that they are
all "readResolved" to the same single instance. It is more
convenient to do this in a single inherited readResolve(), than
repeat the logic in each of them individually (though this is
arguable). Consider the code in question from ICC_Profile:
It checks for the identifying string (in csName), and then looks up
the appropriate instance with getInstance():
int cspace = 0; // ColorSpace.CS_* constant if known
boolean isKnownPredefinedCS = false;
if (csName != null) {
isKnownPredefinedCS = true;
if (csName.equals("CS_sRGB")) {
cspace = ColorSpace.CS_sRGB;
} else if (csName.equals("CS_CIEXYZ")) {
cspace = ColorSpace.CS_CIEXYZ;
} else if (csName.equals("CS_PYCC")) {
cspace = ColorSpace.CS_PYCC;
} else if (csName.equals("CS_GRAY")) {
cspace = ColorSpace.CS_GRAY;
} else if (csName.equals("CS_LINEAR_RGB")) {
cspace = ColorSpace.CS_LINEAR_RGB;
} else {
isKnownPredefinedCS = false;
}
}
if (isKnownPredefinedCS) {
resolvedDeserializedProfile = getInstance(cspace);
} else {
resolvedDeserializedProfile = getInstance(data);
}
All this code is actually in readResolve(), not in readResolve() -
it is "passed" (globally) to readResolve via the
resolvedDeserializedProfile field:
protected Object readResolve() throws ObjectStreamException {
return resolvedDeserializedProfile;
}
private transient ICC_Profile resolvedDeserializedProfile;
Cheers,
Brendan
This email is to inform you of release '0.9.5.0' of 'Java Serialization to
XML' through freshmeat.net. All URLs and other useful information can be
found at http://freshmeat.net/projects/jsx/
The changes in this release are as follows:
The Serialization API is now completely re-implemented. A bug for
inherited
readResolve() methods was also fixed (affecting
java.awt.color.ICC_Profile).
If you would like to cancel subscription to releases of this project, login
to freshmeat.net and choose 'home' from the personal menubar at the top of
the page. You'll be presented with a list of projects you're subscribed to
in the right column, which you may cancel by highlighting the project in
question and clicking the 'delete' button.
Sincerely,
freshmeat.net
Hey Craig,
Externalizable is RELEASED! And that completes the JOS API!!
(Sorry about the delay, got tied up with some licensing issues.)
> All I can say, is I'm going to jump on it as soon as I can.
Great!
> JSX is already to the point where it works like JOS, but does
> allow the developer to configure how to works such as circular
> references.
Yes - but the only enhancements provided are those that are
accessible through constructors... just construct a JOS object, and
it still works the same.
I suppose with circular references, we could write code that
*depended* on that behaviour... so I see your point. But I want
to minimise incompatibility, so people are *guaranteed* to be able
to switch back to binary JOS, if they need to. It's like a safety
escape hatch.
But by this argument, I should require Serializable, and SUIDs, too...
> As long as functionality is compatible with JOS, it's up to the
> develper if they wish to use features that are not compatible.
This sounds fair, but look what Microsoft's IE did to HTML - by
adding lots of extra bits, many web-pages would only work properly
in IE. This "pollution" of the HTML "API" was a temptation...
> Can you fix the limitation in JSX and JOS and submit the JOS
> enchancement to the java community process as an enhancement?
It's hard to fix APIs, without messing everthing up. I had a think
about this, but couldn't see a way to do it...
Anyway, here's an example of how to do what you want with JSX -
but I can't get it to work with JOS. I wanted to fix this up before
releasing it, but maybe you will have better luck than I...
Please note to everyone else:
- PutField and GetField work in both JSX and in JOS (Java Object
Serialization - the standard binary format)
- Externalizable works in both JSX and JOS.
- BUT: JSX allows you to use PutField/GetField *together* with
Externalizable, but JOS does not. The reason is the Externalizable
interface - it takes ObjectInput/ObjectOutput arguments, which don't
contain the methods for handling PutField/GetField.
- the *danger* is that objects that rely on this won't work with
JOS anymore... and this is bad.
(Maybe it wouldn't break compatibility that much, if Sun added
those methods into the interface...?)
import java.io.*;
public class Subclass extends Superclass implements Externalizable {
public Subclass() {} //needed by Java's Externalize
String sDate = "sub class field";
int i = 20;
static public void main(String[] args) throws Exception {
ObjectInputStream in = null;
ObjectOutputStream out = null;
if (args.length==0) {
out = new JSX.ObjOut();
//out = new ObjectOutputStream(System.out); //PutField not work
out.writeObject(new Subclass());
}
else {
in = new JSX.ObjIn();
//in = new ObjectInputStream(System.in); //GetField not work
Object o = in.readObject();
new JSX.ObjOut().writeObject(o); //so we can see (alt: java
JSX.ObjIn)
}
}
static final long serialVersionUID = 30593813711490L;
private static final ObjectStreamField[] serialPersistentFields = {
new ObjectStreamField("date", String.class)
};
public void writeExternal(ObjectOutput out) throws IOException {
ObjectOutputStream s = (ObjectOutputStream)out;
ObjectOutputStream.PutField fields = s.putFields();
fields.put("date", sDate);
s.writeFields();
}
public void readExternal(ObjectInput in) throws IOException,
ClassNotFoundExce
ption {
ObjectInputStream s = (ObjectInputStream)in;
ObjectInputStream.GetField fields = s.readFields();
sDate = (String)fields.get("date", null)+" (this bit added by
readExternal)"
;
}
class Superclass {
String a = "this is a superclass field";
}
And here's the XML:
<?jsx version="1"?>
<Subclass>
<java.lang.String obj-name="date" valueOf="sub class field"/>
</Subclass>
Note that the Superclass field ("a") is not written out... that's
what Externalizable does.
Have a great day!
Cheers,
Brendan
Brendan - I suggest some announcements on Sun-soaked lists, though I suspect
this stuff'll already be on radar (anyone on list to confirm that?)
Way cool work, by the way dude(s)!
Now get exporting the HOWTOs...
Cheers,
Danny.
---
Danny Ayers
http://www.isacat.net
Alternate email (2001) :
danny666@...
danny_ayers@...
>-----Original Message-----
>From: bren@... [mailto:bren@...]
>Sent: 26 October 2001 13:11
>To: JSX-ideas@yahoogroups.com
>Subject: [JSX-ideas] Re: Externalizable is practically ready for release
>
>
>Hey Craig,
>
>Externalizable is RELEASED! And that completes the JOS API!!
>
>(Sorry about the delay, got tied up with some licensing issues.)
>
>> All I can say, is I'm going to jump on it as soon as I can.
>Great!
>
>> JSX is already to the point where it works like JOS, but does
>> allow the developer to configure how to works such as circular
>> references.
>Yes - but the only enhancements provided are those that are
>accessible through constructors... just construct a JOS object, and
>it still works the same.
>
>I suppose with circular references, we could write code that
>*depended* on that behaviour... so I see your point. But I want
>to minimise incompatibility, so people are *guaranteed* to be able
>to switch back to binary JOS, if they need to. It's like a safety
>escape hatch.
>
>But by this argument, I should require Serializable, and SUIDs, too...
>
>> As long as functionality is compatible with JOS, it's up to the
>> develper if they wish to use features that are not compatible.
>This sounds fair, but look what Microsoft's IE did to HTML - by
>adding lots of extra bits, many web-pages would only work properly
>in IE. This "pollution" of the HTML "API" was a temptation...
>
>> Can you fix the limitation in JSX and JOS and submit the JOS
>> enchancement to the java community process as an enhancement?
>It's hard to fix APIs, without messing everthing up. I had a think
>about this, but couldn't see a way to do it...
>
>Anyway, here's an example of how to do what you want with JSX -
>but I can't get it to work with JOS. I wanted to fix this up before
>releasing it, but maybe you will have better luck than I...
>
>Please note to everyone else:
> - PutField and GetField work in both JSX and in JOS (Java Object
>Serialization - the standard binary format)
> - Externalizable works in both JSX and JOS.
> - BUT: JSX allows you to use PutField/GetField *together* with
>Externalizable, but JOS does not. The reason is the Externalizable
>interface - it takes ObjectInput/ObjectOutput arguments, which don't
>contain the methods for handling PutField/GetField.
> - the *danger* is that objects that rely on this won't work with
>JOS anymore... and this is bad.
>
>(Maybe it wouldn't break compatibility that much, if Sun added
>those methods into the interface...?)
>
>
>import java.io.*;
>
>public class Subclass extends Superclass implements Externalizable {
> public Subclass() {} //needed by Java's Externalize
> String sDate = "sub class field";
> int i = 20;
> static public void main(String[] args) throws Exception {
> ObjectInputStream in = null;
> ObjectOutputStream out = null;
> if (args.length==0) {
> out = new JSX.ObjOut();
> //out = new ObjectOutputStream(System.out); //PutField not work
> out.writeObject(new Subclass());
> }
> else {
> in = new JSX.ObjIn();
> //in = new ObjectInputStream(System.in); //GetField not work
> Object o = in.readObject();
> new JSX.ObjOut().writeObject(o); //so we can see (alt: java
>JSX.ObjIn)
> }
> }
>
> static final long serialVersionUID = 30593813711490L;
> private static final ObjectStreamField[] serialPersistentFields = {
> new ObjectStreamField("date", String.class)
> };
>
> public void writeExternal(ObjectOutput out) throws IOException {
> ObjectOutputStream s = (ObjectOutputStream)out;
> ObjectOutputStream.PutField fields = s.putFields();
> fields.put("date", sDate);
> s.writeFields();
> }
> public void readExternal(ObjectInput in) throws IOException,
>ClassNotFoundExce
>ption {
> ObjectInputStream s = (ObjectInputStream)in;
> ObjectInputStream.GetField fields = s.readFields();
> sDate = (String)fields.get("date", null)+" (this bit added by
>readExternal)"
>;
>}
>
>class Superclass {
> String a = "this is a superclass field";
>}
>
>
>And here's the XML:
><?jsx version="1"?>
><Subclass>
> <java.lang.String obj-name="date" valueOf="sub class field"/>
></Subclass>
>
>Note that the Superclass field ("a") is not written out... that's
>what Externalizable does.
>
>Have a great day!
>
>
>Cheers,
>Brendan
>
>
>
>To unsubscribe from this group, send an email to:
>JSX-ideas-unsubscribe@egroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
Hi all,
I've seen some previous discussion on this problem & maybe the additional
information provided can help you to solve the problem that had me blocked
for some time now:
Using the following IBM java environment
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20001025 (JIT enabled:
jitc))
on a Linux Box running SuSE 7.2 with the following two java sources:
Test.java:
import JSX.ObjIn;
import JSX.ObjOut;
import java.io.*;
public class Test
{
private tt tti;
private int i;
private int j;
public
Test(int i)
{
tti = new tt();
this.i = i;
j = 100;
}
public int i() { return i; }
public int j() { return j; }
public tt tti() { return tti; }
public static void
main(String[] args)
{
try {
// FileOutputStream out = new
FileOutputStream("ttt");
// ObjOut oout = new ObjOut(false, out);
// oout.writeObject(new Test(123));
// oout.close();
FileInputStream in = new FileInputStream("ttt");
ObjIn oin = new ObjIn(in);
Test t = (Test)oin.readObject();
System.out.println(t.i() + " " + t.j());
oin.close();
} catch (Exception ex) {
ex.printStackTrace();
}
}
}
tt.java:
public class tt
{
private int a = 34;
private int b = 35;
public int a() { return a; }
public int b() { return b; }
}
and the JSX 0.9.4/0.9.5 file "ttt":
<?jsx version="1"?>
<Test
j="100"
i="123">
<tt obj-name="tti"
b="35"
a="34"/>
</Test>
results in the following when run (reproducible!):
java.lang.NullPointerException
at JSX.XMLDeserialize.addAttr(XMLDeserialize.java:1939)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1002)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2032)
at JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1413)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1223)
at JSX.XMLDeserialize.deserialize(XMLDeserialize.java:321)
at JSX.ObjIn.readObjectOverride(ObjIn.java:138)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:238)
at Test.main(Test.java:47)
Note that when the commented out code in Test.java (actually used to
generate the JSX file) is included then everything works OK!
The problem seems to be that oin.readObject requires the class tt to be
loaded by the ClassLoader right when the object is read (can see that with
java -verbose:class). The same can also happen when garbage collection
decides to unload a class and this seems to have hit me in my servlet...
I also tried with the SUN jvm - the same code works without problems, so this
seems to be IBM JVM specific.
I also tried to use jdb to further track down the problem, but jdb hangs when
it becomes interesting...
The workaround I'm currently using is to create a new object of the type I'm
trying to read just before the readObject - this requires the loading of the
class and avoids the problem - ugly but workable.
Interesting sideline: If you repeat the code in the try/catch block, you will
get the same execption twice, so the class obviously could not be loaded
when JSX caused the exception.
Cheers,
Wolf
Hi Wolf,
This is a really interesting problem! Is the "previous discussion",
about Jean-Christophe's IBM JVM problems? It sounds like it when
you mention "reproducible", and suggest possible non-determinism
with garbage collection:
> results in the following when run (reproducible!):
...
> The same can also happen when garbage collection
> decides to unload a class and this seems to have hit me in my
> servlet...
Your diagnosis is very helpful - I think you're right, and JSX
simply doesn't explicitly load in the class. It often wouldn't
show up in tests, because the class is already loaded, as you say...
And for some reason, in Sun's implementation, the class *is* loaded.
> I also tried with the SUN jvm - the same code works without
> problems, so this seems to be IBM JVM specific.
Yes - I just checked, and it does work with the Sun jvm.
I'm betting that the problem is to do with the way the class is
loaded... here's a workaround: subclass ObjIn, and override the
method "resolveClass":
protected Class resolveClass(ObjectStreamClass v) throws
IOException, ClassNotFoundException
This is part of the standard Serialization API.
Your method will be called by JSX, with an ObjectStreamClass. You
can get the name of the class to be loaded with "v.getName()", and
then load it with your favourite classloader, and then return the
Class.
However, before trying that, I wonder if you could try out
"JSX0.9.5.1"? It will not fix the problem, but I've added some
diagnostics, which hopefully will demonstrate that my above guesses
are correct...
http://www.csse.monash.edu.au/~bren/JSX/JSX0.9.5.1.jar
OR
http://www.csse.monash.edu.au/~bren/JSX/JSX0.9.5.1.zip
Note: these *only* linked from the top of the page ("0.9.5.1.zip
(Wolf)", as they are mere tests.
Please let me know how this test goes, and also if the resolveClass
is a workable workaround. If all goes well, we should be able to
find a general solution.
And thanks again for the clarity of your bug report! Have a great
day. ;-)
Cheers,
Brendan
Hey Danny ("is-a-cat"),
Great to see you on the list - this is the first time you've posted
I think.
> Brendan - I suggest some announcements on Sun-soaked lists,
> though I suspect this stuff'll already be on radar (anyone on
> list to confirm that?)
I think it is on radar - people on other mailing lists refer to it
without feeling the need to give pointers etc - but a little
promotion like this is a great idea.
> Way cool work, by the way dude(s)!
Thanks!
> Now get exporting the HOWTOs...
As in writing up proper tutorials/examples/manpages/javadocs?
I guess "export" is right, since there are already heaps and heaps
of examples floating about the place - just not collected into one
convenient place... and this would ease the learning curve
enormously... and I suspect would surprise many people with uses
they hadn't thought of (myself very much included!)
But bugs first, like this IBM JDK one... ;-)
Cheers,
Brendan
> >Externalizable is RELEASED! And that completes the JOS API!!
bren@... wrote:
Hi Brendan,
put my comments in your answer - thanks for your speedy reply!
Added some traces at the end of the message
Wolf.
> Hi Wolf,
>
> This is a really interesting problem! Is the "previous discussion",
> about Jean-Christophe's IBM JVM problems? It sounds like it when
> you mention "reproducible", and suggest possible non-determinism
> with garbage collection:
The discussion I was referring to is:
243 Re: Problem with JSX0.8.8[.1] on Linux (Update)
Brendan Macmillan Fri 5/25/2001
and only partly Jean-Christophe's IBM Problem, which may have
a different cause.
What I meant by reproducible is that with the given sources the
problem can be reproduced 100% of the time, whereas in my
application it happens only after the servlet has been running
for some time.
> > results in the following when run (reproducible!):
> ...
> > The same can also happen when garbage collection
> > decides to unload a class and this seems to have hit me in my
> > servlet...
>
> Your diagnosis is very helpful - I think you're right, and JSX
> simply doesn't explicitly load in the class. It often wouldn't
> show up in tests, because the class is already loaded, as you say...
> And for some reason, in Sun's implementation, the class *is* loaded.
Looking at the ouput of java -verbose:class it seems that both
implementations load the class at that point - but only the SUN
implementation does so successfully.
> > I also tried with the SUN jvm - the same code works without
> > problems, so this seems to be IBM JVM specific.
> Yes - I just checked, and it does work with the Sun jvm.
>
> I'm betting that the problem is to do with the way the class is
> loaded... here's a workaround: subclass ObjIn, and override the
> method "resolveClass":
> protected Class resolveClass(ObjectStreamClass v) throws
> IOException, ClassNotFoundException
>
> This is part of the standard Serialization API.
> Your method will be called by JSX, with an ObjectStreamClass. You
> can get the name of the class to be loaded with "v.getName()", and
> then load it with your favourite classloader, and then return the
> Class.
I just added the following code to Test.java (commented out
the "import JSX.ObjIn" at the top):
class ObjIn extends JSX.ObjIn
{
public
ObjIn(InputStream in)
throws IOException
{
super(in);
}
protected Class
resolveClass(ObjectStreamClass v)
throws IOException, ClassNotFoundException
{
System.out.println(v.getName()); //DEBUG
return Class.forName(v.getName());
}
}
and voila - it works!
> However, before trying that, I wonder if you could try out
> "JSX0.9.5.1"? It will not fix the problem, but I've added some
> diagnostics, which hopefully will demonstrate that my above guesses
> are correct...
> http://www.csse.monash.edu.au/~bren/JSX/JSX0.9.5.1.jar
> OR
> http://www.csse.monash.edu.au/~bren/JSX/JSX0.9.5.1.zip
>
> Note: these *only* linked from the top of the page ("0.9.5.1.zip
> (Wolf)", as they are mere tests.
The output of the test is:
java.lang.NullPointerException
at JSX.XMLDeserialize.addAttr(XMLDeserialize.java:1943)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1006)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2036)
at JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1417)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1227)
at JSX.XMLDeserialize.deserialize(XMLDeserialize.java:321)
at JSX.ObjIn.readObjectOverride(ObjIn.java:138)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:238)
at Test.main(Test.java:47)
> Please let me know how this test goes, and also if the resolveClass
> is a workable workaround. If all goes well, we should be able to
> find a general solution.
>
> And thanks again for the clarity of your bug report! Have a great
> day. ;-)
>
> Cheers,
> Brendan
P.S.: Here is the output generated by 'java -verbose:class' for the workaround
case and the failing case - maybe this gives you a clue
Workaround case:
....
[Preparing JSX/MagicClass]
[Initializing JSX/MagicClass]
[Running static initializer for JSX/MagicClass]
[Loaded [J]
[Loading superclasses of [J]
[Preparing [J]
[Loaded [C]
[Loading superclasses of [C]
[Preparing [C]
[Loaded [B]
[Loading superclasses of [B]
[Preparing [B]
[Preparing java/io/DataOutput]
[Preparing java/io/ObjectOutput]
[Preparing java/io/ObjectOutputStream]
[Loaded [Ljava.io.ObjectStreamField;]
[Loading superclasses of [Ljava/io/ObjectStreamField;]
[Preparing [Ljava/io/ObjectStreamField;]
[Loaded java.lang.reflect.Modifier from /usr/lib/java/jre/lib/rt.jar]
[Loading superclasses of java/lang/reflect/Modifier]
[Preparing java/lang/reflect/Modifier]
Test
[Loaded java.io.Externalizable from /usr/lib/java/jre/lib/rt.jar]
[Loading superclasses of java/io/Externalizable]
[Preparing java/io/Externalizable]
[Loaded JSX.XMLSerialize]
[Loading superclasses of JSX/XMLSerialize]
[Loaded java.io.WriteAbortedException from /usr/lib/java/jre/lib/rt.jar]
[Loading superclasses of java/io/WriteAbortedException]
[Loaded java.lang.InternalError from /usr/lib/java/jre/lib/rt.jar]
[Loading superclasses of java/lang/InternalError]
[Preparing JSX/XMLSerialize]
[Signaling in VM: java/lang/NoSuchMethodException, message: readObject]
at java.lang.Class.getMethod0(Native Method)
at java.lang.Class.getDeclaredMethod(Class.java:1188)
at JSX.XMLSerialize.getDeclaredMethod(XMLSerialize.java:1568)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1197)
at JSX.XMLDeserialize.deserialize(XMLDeserialize.java:321)
at JSX.ObjIn.readObjectOverride(ObjIn.java:138)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:238)
at Test.main(Test.java:46)
[Preparing java/lang/NoSuchMethodException]
tt
[Loaded tt]
[Loading superclasses of tt]
[Preparing tt]
[Signaling in VM: java/lang/NoSuchMethodException, message: readObject]
at java.lang.Class.getMethod0(Native Method)
at java.lang.Class.getDeclaredMethod(Class.java:1188)
at JSX.XMLSerialize.getDeclaredMethod(XMLSerialize.java:1568)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1197)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2036)
at JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1417)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1227)
at JSX.XMLDeserialize.deserialize(XMLDeserialize.java:321)
at JSX.ObjIn.readObjectOverride(ObjIn.java:138)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:238)
at Test.main(Test.java:46)
[Signaling in VM: java/lang/NoSuchMethodException, message: readResolve]
at java.lang.Class.getMethod0(Native Method)
at java.lang.Class.getDeclaredMethod(Class.java:1188)
at JSX.XMLDeserialize.readResolve(XMLDeserialize.java:1320)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1239)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2036)
at JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1417)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1227)
at JSX.XMLDeserialize.deserialize(XMLDeserialize.java:321)
at JSX.ObjIn.readObjectOverride(ObjIn.java:138)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:238)
at Test.main(Test.java:46)
[Signaling in VM: java/lang/NoSuchMethodException, message: readResolve]
at java.lang.Class.getMethod0(Native Method)
at java.lang.Class.getDeclaredMethod(Class.java:1188)
at JSX.XMLDeserialize.readResolve(XMLDeserialize.java:1326)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1239)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2036)
at JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1417)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1227)
at JSX.XMLDeserialize.deserialize(XMLDeserialize.java:321)
at JSX.ObjIn.readObjectOverride(ObjIn.java:138)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:238)
at Test.main(Test.java:46)
[Signaling in VM: java/lang/NoSuchMethodException, message: readResolve]
at java.lang.Class.getMethod0(Native Method)
at java.lang.Class.getDeclaredMethod(Class.java:1188)
at JSX.XMLDeserialize.readResolve(XMLDeserialize.java:1320)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1239)
at JSX.XMLDeserialize.deserialize(XMLDeserialize.java:321)
at JSX.ObjIn.readObjectOverride(ObjIn.java:138)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:238)
at Test.main(Test.java:46)
[Signaling in VM: java/lang/NoSuchMethodException, message: readResolve]
at java.lang.Class.getMethod0(Native Method)
at java.lang.Class.getDeclaredMethod(Class.java:1188)
at JSX.XMLDeserialize.readResolve(XMLDeserialize.java:1326)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1239)
at JSX.XMLDeserialize.deserialize(XMLDeserialize.java:321)
at JSX.ObjIn.readObjectOverride(ObjIn.java:138)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:238)
at Test.main(Test.java:46)
123 100
...
and for the non-working case:
...
[Preparing JSX/MagicClass]
[Initializing JSX/MagicClass]
[Running static initializer for JSX/MagicClass]
[Loaded [J]
[Loading superclasses of [J]
[Preparing [J]
[Loaded [C]
[Loading superclasses of [C]
[Preparing [C]
[Loaded [B]
[Loading superclasses of [B]
[Preparing [B]
[Preparing java/io/DataOutput]
[Preparing java/io/ObjectOutput]
[Preparing java/io/ObjectOutputStream]
[Loaded [Ljava.io.ObjectStreamField;]
[Loading superclasses of [Ljava/io/ObjectStreamField;]
[Preparing [Ljava/io/ObjectStreamField;]
[Loaded java.lang.reflect.Modifier from /usr/lib/java/jre/lib/rt.jar]
[Loading superclasses of java/lang/reflect/Modifier]
[Preparing java/lang/reflect/Modifier]
[Loaded java.io.Externalizable from /usr/lib/java/jre/lib/rt.jar]
[Loading superclasses of java/io/Externalizable]
[Preparing java/io/Externalizable]
[Loaded JSX.XMLSerialize]
[Loading superclasses of JSX/XMLSerialize]
[Loaded java.io.WriteAbortedException from /usr/lib/java/jre/lib/rt.jar]
[Loading superclasses of java/io/WriteAbortedException]
[Loaded java.lang.InternalError from /usr/lib/java/jre/lib/rt.jar]
[Loading superclasses of java/lang/InternalError]
[Preparing JSX/XMLSerialize]
[Signaling in VM: java/lang/NoSuchMethodException, message: readObject]
at java.lang.Class.getMethod0(Native Method)
at java.lang.Class.getDeclaredMethod(Class.java:1188)
at JSX.XMLSerialize.getDeclaredMethod(XMLSerialize.java:1568)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1197)
at JSX.XMLDeserialize.deserialize(XMLDeserialize.java:321)
at JSX.ObjIn.readObjectOverride(ObjIn.java:138)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:238)
at Test.main(Test.java:47)
[Preparing java/lang/NoSuchMethodException]
[Loaded tt]
[Loading superclasses of tt]
[Signaling in VM: java/lang/NullPointerException, message: ]
at JSX.XMLDeserialize.addAttr(XMLDeserialize.java:1943)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1006)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2036)
at JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1417)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1227)
at JSX.XMLDeserialize.deserialize(XMLDeserialize.java:321)
at JSX.ObjIn.readObjectOverride(ObjIn.java:138)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:238)
at Test.main(Test.java:47)
java.lang.NullPointerException
at JSX.XMLDeserialize.addAttr(XMLDeserialize.java:1943)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1006)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2036)
at JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1417)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1227)
at JSX.XMLDeserialize.deserialize(XMLDeserialize.java:321)
at JSX.ObjIn.readObjectOverride(ObjIn.java:138)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:238)
at Test.main(Test.java:47)
...
Hi Wolf,
> put my comments in your answer - thanks for your speedy reply!
Cool ;-)
I'll follow up on your points later - so now tho, it looks like
the workaround is adequate for your specific case. More comments
below.
Cheers,
Brendan
> The discussion I was referring to is:
> 243 Re: Problem with JSX0.8.8[.1] on Linux (Update)
> Brendan Macmillan Fri 5/25/2001
> and only partly Jean-Christophe's IBM Problem, which may have
> a different cause.
Thanks - I'll check it out.
> > loaded... here's a workaround: subclass ObjIn, and override the
> > method "resolveClass":
...
> and voila - it works!
Yay!
> > http://www.csse.monash.edu.au/~bren/JSX/JSX0.9.5.1.jar
> The output of the test is:
> java.lang.NullPointerException
> at JSX.XMLDeserialize.addAttr(XMLDeserialize.java:1943)
Man, that is strange - same as before... I'll need to look into this
further...
> P.S.: Here is the output generated by 'java -verbose:class' for the
workaround
> case and the failing case - maybe this gives you a clue
Cool - thanks, I'll also look at this
Hi again Wolf,
Could you try this one too, please?
http://www.csse.monash.edu.au/~bren/JSX/JSX0.9.5.2.jar
I didn't get the result I expected from the previous one...
I checked out the older message - I don't think this one is
related, but it could be...
I'll look over the other stuff you posted later.
Cheers,
Brendan
Hey!
After two weeks of cooking two WD harddrives and very, very poor
warranty service I made the switch to Externalizable instead of a
wrapper and it works great.
There seems to be a debugging message in writeUTF and readUTF...
writePrim() is correct, not writeObject()
getPrimString() is correct, not readObject()
Is this debug code or something I need to be concerned with? I have
commented out the messages for now. Everything appears to be working
correctly and it reduced the size of the code and compiled class
quite a bit instead of using a wrapper.
Good work!
Thanks,
Craig
Hi Brendan, Wolf, (other readers too!)
It seems that others enjoy working with IBM's JDK ...
> The discussion I was referring to is:
> 243 Re: Problem with JSX0.8.8[.1] on Linux (Update)
> Brendan Macmillan Fri 5/25/2001
> and only partly Jean-Christophe's IBM Problem, which may have
> a different cause.
My problems are -linked- with Serialization, which is something we do
quite a lot (recovery system). By -linked-, I mean that JSX is not
responsible, but works as a catalyzer.
Deserialization is done at startup.
Moreover, my app run on AIX. I should have a try at Wolf's Test.
JC.
bren@... wrote:
> Hi again Wolf,
>
> Could you try this one too, please?
> http://www.csse.monash.edu.au/~bren/JSX/JSX0.9.5.2.jar
Same result:
java.lang.NullPointerException
at JSX.XMLDeserialize.addAttr(XMLDeserialize.java:1952)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1009)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2045)
at JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1420)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1230)
at JSX.XMLDeserialize.deserialize(XMLDeserialize.java:321)
at JSX.ObjIn.readObjectOverride(ObjIn.java:138)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:238)
at Test.main(Test.java:47)
>
>
> I didn't get the result I expected from the previous one...
>
> I checked out the older message - I don't think this one is
> related, but it could be...
>
> I'll look over the other stuff you posted later.
>
> Cheers,
> Brendan
>
> To unsubscribe from this group, send an email to:
> JSX-ideas-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
--- In JSX-ideas@y..., jcsalome@y... wrote:
> Hi Brendan, Wolf, (other readers too!)
>
> It seems that others enjoy working with IBM's JDK ...
Just curious, but what's the attraction of IBM's JDK? Is it
better in some way, or is it that it just runs on different
(ie IBM) hardware? Or both? ;-)
> Moreover, my app run on AIX. I should have a try at Wolf's Test.
What's AIX? Aha:
http://www-1.ibm.com/servers/aix/
Top Research Firm Cites IBM UNIX Leadership Over the Competition
Just Released Report Gives High Ratings to AIX 5L on Scalability,
Capacity and Performance, and Names AIX an Operating System for
Emerging e-Infrastructures
IBM to demo Web-based search of human genome database using 64-bit
JAVA.
IBM today announced that it will make 64-bit Java® technology
available on its AIX® UNIX operating system. With this offering, AIX
leaps ahead of both Sun Solaris and Hewlett-Packard HP-UX, which have
yet to make 64-bit Java technology generally available.
IBM crushes Sun in JAVA performance
On tests measuring Java software performance for four, eight, twelve
and twenty-four processor systems, IBM outperformed Sun servers by as
much as 56 percent.
Announcing AIX® 5L Version 5.1
AIX 5L with Linux® affinity and support for POWER architectures.
IBM unveils midrange servers, Linux-friendly AIX
IBM backed up its billion-dollar support of the open-source Linux
operating system Monday when it unveiled AIX 5L, Version 5.1, a new
version of its high-end OS with added Linux support.
Thanks Wolf,
> Same result:
> java.lang.NullPointerException
> at JSX.XMLDeserialize.addAttr(XMLDeserialize.java:1952)
Really strange - I explicitly checked everything that could
be null... so I don't understand how there can be a null pointer
exception... unless it is internal to the JVM somehow (?)
I thought that maybe you were accidentally running the old jar - but
the line numbers are in accordance with the new jars...
One last try:
http://www.csse.monash.edu.au/~bren/JSX/JSX0.9.5.3.jar
PS: I had a look at the "-verbose:class" diagnostics you sent:
I noticed that the workaround case prints "Test" and "tt" - but
the other doesn't. Also, the workaround case does a "[preparing tt]",
but the other doesn't.
This reminds me of the "initialize" option:
public static Class forName(String name,
boolean initialize,
ClassLoader loader)
It may be that Sun's default classloader for Serialization does the
initialization (ie the "[preparing tt]", but IBM's does not. However,
when explicitly loading a class, the initialization is done.
Here is the code from Sun's:
protected Class resolveClass(ObjectStreamClass v)
throws IOException, ClassNotFoundException
{
/* Resolve by looking up the stack for a non-zero class
* loader. If not found use the system class loader.
*/
ClassLoader loader = latestUserDefinedLoader();
return Class.forName(v.getName(), false, loader);
}
Note that initialize is "false"... but perhaps Sun's forName
actually does prepare it anyway? A simple test for this is to
change your subclass of ObjIn, to use the above line ie:
return Class.forName(v.getName(), false, loader);
You'll need to get the default loader from somewhere, too.
The other possible problem is that IBM and Sun's JVM get a different
classloader for some reason. For example, the latestUserDefinedLoader
is a little bit odd, and may have subtly different behaviours in
each....
BTW: does Serialization work OK on the cases you are trying? Is it
only JSX?
Cheers,
Brendan
Hey Craig,
> After two weeks of cooking two WD harddrives and very, very poor
> warranty service I made the switch to Externalizable instead of a
> wrapper and it works great.
Glad something is working!
> There seems to be a debugging message in writeUTF and readUTF...
>
> writePrim() is correct, not writeObject()
> getPrimString() is correct, not readObject()
>
> Is this debug code or something I need to be concerned with? I
> have commented out the messages for now. Everything appears to
> be working correctly
Yes, I'm pretty sure that this is just debug code. As you probably
saw in the comments, the distinction between writeUTF(String str)
and writeObject(String str) is that the former treats the String
as a primitive (and so is fully written out each time), while the
latter treats it as an object - the significance of which is that
the one object may be referred to several times.
If you want to make sure your code is readable, using writeUTF etc
is probably a good idea. Another way to achieve a similar effect is
to turn off aliasing (done through one of the constructors - check
back through the old web-pages, or check ObjOut.java directly.)
I think Danny is right, and we really need some "how to's"!!
> and it reduced the size of the code and compiled class quite a
> bit instead of using a wrapper.
Hey, cool! Please let me know if you find any other bugs - it's
fresh code, and so there are quite likely to be some problems with
it.
> Good work!
Thanks!
Cheers,
Brendan
>Just curious, but what's the attraction of IBM's JDK? Is it
>better in some way, or is it that it just runs on different
>(ie IBM) hardware? Or both? ;-)
AIX is IBM's unix, for IBM's servers.
>What's AIX? Aha:
>IBM to demo Web-based search of human genome database using 64-bit
>JAVA.
>IBM crushes Sun in JAVA performance
>On tests measuring Java software performance for four, eight, twelve
>and twenty-four processor systems, IBM outperformed Sun servers by as
>much as 56 percent.
>[...]
Well, that sounds interesting and ... terrible. Our problems are strongly
bound with SMP.
These are new versions, but I would prefer independant tests (which might
reveal some problems).
For more details about JVMs and OSes, have a look at (benchmarks):
http://www.volano.com/report/index.htmlhttp://www.volano.com/report/network.txt
(unfortunately, nothing on AIX)
Have a good day,
JCS
This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
---------------------------------------------
Ce message et toutes les pieces jointes (ci-apres le
"message") sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
Hi Brendan,
>
> ...
> Thanks Wolf,
>
> > Same result:
> > java.lang.NullPointerException
> > at JSX.XMLDeserialize.addAttr(XMLDeserialize.java:1952)
>
> Really strange - I explicitly checked everything that could
> be null... so I don't understand how there can be a null pointer
> exception... unless it is internal to the JVM somehow (?)
Maybe this helps: when I tried to jdb the problem I could go
something like 2 or 3 layers further down the stack before jdb
would hang, but the exception has always been the same
> I thought that maybe you were accidentally running the old jar - but
> the line numbers are in accordance with the new jars...
>
> One last try:
> http://www.csse.monash.edu.au/~bren/JSX/JSX0.9.5.3.jar
Here is the output:
IBM: me is not null
IBM: currentGetField = GetFieldImpl state: {}
IBM: attr = j="100" , tag nameMissing=false
IBM: o is not null
IBM: currentGetField = GetFieldImpl state: {j=100}
IBM: attr = i="123" , tag nameMissing=false
IBM: o is not null
IBM: me is not null
IBM: currentGetField = GetFieldImpl state: {j=100, i=123}
IBM: attr = b="35" , tag nameMissing=false
IBM: o is not null
java.lang.NullPointerException
at JSX.XMLDeserialize.addAttr(XMLDeserialize.java:1956)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1015)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2052)
at JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1426)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1236)
at JSX.XMLDeserialize.deserialize(XMLDeserialize.java:327)
at JSX.ObjIn.readObjectOverride(ObjIn.java:138)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:238)
at Test.main(Test.java:47)
> PS: I had a look at the "-verbose:class" diagnostics you sent:
>
> I noticed that the workaround case prints "Test" and "tt" - but
> the other doesn't. Also, the workaround case does a "[preparing tt]",
> but the other doesn't.
The "Test" and "tt" are debug output generated by the overloaded
resolveClass in the working case. The missing [preparing tt] is the one that
I thing could be the problem.
> This reminds me of the "initialize" option:
> public static Class forName(String name,
> boolean initialize,
> ClassLoader loader)
>
> It may be that Sun's default classloader for Serialization does the
> initialization (ie the "[preparing tt]", but IBM's does not. However,
> when explicitly loading a class, the initialization is done.
>
> Here is the code from Sun's:
> protected Class resolveClass(ObjectStreamClass v)
> throws IOException, ClassNotFoundException
> {
> /* Resolve by looking up the stack for a non-zero class
> * loader. If not found use the system class loader.
> */
> ClassLoader loader = latestUserDefinedLoader();
> return Class.forName(v.getName(), false, loader);
> }
>
> Note that initialize is "false"... but perhaps Sun's forName
> actually does prepare it anyway? A simple test for this is to
> change your subclass of ObjIn, to use the above line ie:
> return Class.forName(v.getName(), false, loader);
>
> You'll need to get the default loader from somewhere, too.
Will try this when I find the time - too busy right now
> The other possible problem is that IBM and Sun's JVM get a different
> classloader for some reason. For example, the latestUserDefinedLoader
> is a little bit odd, and may have subtly different behaviours in
> each....
>
> BTW: does Serialization work OK on the cases you are trying? Is it
> only JSX?
Yes it does. The reason for me to switch to JSX is that I'm on a Linux box
and want to use the UNIX text tools to analyze masses of data.
> Cheers,
> Brendan
>
Cheers,
Wolf.
Hi Wolf,
> Will try this when I find the time - too busy right now
Thanks a lot for the testing you have put in already!
I've just changed JSX's default implementation of resolveClass to
work the same as the way you subclassed it. This should fix it,
although it is not entirely correct...
Just to summarise:
(1). It's an internal problem - the null is coming from the JVM
internals:
> IBM: currentGetField = GetFieldImpl state: {j=100, i=123}
> IBM: attr = b="35" , tag nameMissing=false
> IBM: o is not null
> java.lang.NullPointerException
(2). It's an internal problem - jdb doesn't usually hang!
> Maybe this helps: when I tried to jdb the problem I could go
> something like 2 or 3 layers further down the stack before jdb
> would hang, but the exception has always been the same
(3). It's an internal problem - "tt" is not prepared.
> The missing [preparing tt] is the one that I thing could be the
> problem.
(4). It's an internal problem - forName(name) fixes it. This
differs in two ways: different classloader, and it initializes it.
> > This reminds me of the "initialize" option:
> > public static Class forName(String name,
> > boolean initialize,
> > ClassLoader loader)
> > return Class.forName(v.getName(), false, loader);
> > BTW: does Serialization work OK on the cases you are trying?
> > Is it only JSX?
> Yes it does.
CURRENT GUESS:
Java's own Serialization (JOS) may initialize the class at some other
point, without relying on the classloader to do it. But JSX doesn't
do this other initialization, which is why JOS works, but JSX
doesn't. The correct solution is simply for JSX to trigger
initialization at some other point - or when it is loaded (which is
what we are doing now). Actually, I feel pretty sure about this
guess, now. It fits well. Let me check the JOS source... oh well,
no I can't see it doing it anywhere; it may be a side effect of
some other call which is not obvious.
> The reason for me to switch to JSX is that I'm on a Linux box and
> want to use the UNIX text tools to analyze masses of data.
I think that diagnosis is the fundamental advantage of XML, and
therefore of JSX.
Cheers,
Brendan
Hi everyone,
Below is the class that I'm having problems with.
There are also attachments (class file and exception
file) in case they are hard to read in this email. In
Frame1 class, I create a JFrame, then add a
JDesktopPane to it (so I can add internal frames),
then I add a JInternalFrame to JDeskTopPane. I could
not even write object "cera" to a file. Did I do
something wrong? Please help!
Kelly
/*********** Here is my class ****************/
import java.awt.*;
import javax.swing.*;
import JSX.*;
import java.io.*;
public class Frame1 extends JFrame {
JDesktopPane desktop;
JInternalFrame jif;
public Frame1() {
this.getContentPane().setLayout(new
BorderLayout());
this.setSize(600,600);
try {
// create the desktop pane for internal windows
desktop = new JDesktopPane();
desktop.setSize(600, 600);
// create the desktop manager
desktop.setDesktopManager(new
DefaultDesktopManager());
this.getContentPane().add("Center", desktop);
// create an internal window
jif = new JInternalFrame("Kelly Frame");
jif.getContentPane().setLayout(new
BorderLayout());
jif.getContentPane().setSize(200, 200);
desktop.add(jif);
}
catch (Exception e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
Frame1 cera = new Frame1();
try {
// write frame
File file = new File
("c:\\data\\CeraFrame.xml");
FileOutputStream ostream = new
FileOutputStream(file);
ObjOut out = new ObjOut(ostream, true);
out.writeObject(cera);
ostream.close();
out.close();
//read frame
FileReader fileReader = new FileReader(file);
BufferedReader bufferedReader = new
BufferedReader(fileReader);
ObjIn in = new ObjIn(bufferedReader);
Frame1 obj = (Frame1) in.readObject();
fileReader.close();
bufferedReader.close();
in.close();
//After reading frame successfully, I try to write
the read frame again
File file2 = new
File("C:\\data\\CeraFrame2.xml");
ostream = new FileOutputStream(file2);
out = new ObjOut(ostream, true);
out.writeObject(obj);
ostream.close();
out.close();
obj.show();
}
catch (java.io.IOException ioe) {
System.out.println("CANNOT READ OR WRITE
OBJECT");
ioe.printStackTrace();
}
catch (java.lang.ClassNotFoundException ne) {
System.out.println("CANNOT CAST");
ne.printStackTrace();
}
}
}
/************Here is the exception****************/
java.lang.reflect.InvocationTargetException
java.lang.reflect.InvocationTargetException:
java.lang.Error: Do not use
javax.swing.JInternalFrame.setLayout() use
javax.swing.JInternalFrame.getContentPane().setLayout()
instead
at
javax.swing.JInternalFrame.setLayout(JInternalFrame.java:463)
at
javax.swing.plaf.basic.BasicInternalFrameUI.uninstallListeners(BasicInternalFram\
eUI.java:216)
at
javax.swing.plaf.basic.BasicInternalFrameUI.uninstallUI(BasicInternalFrameUI.jav\
a:120)
at
javax.swing.plaf.metal.MetalInternalFrameUI.uninstallUI(MetalInternalFrameUI.jav\
a:90)
at
javax.swing.JComponent.compWriteObjectNotify(JComponent.java:4532)
at
javax.swing.JInternalFrame.compWriteObjectNotify(JInternalFrame.java:1559)
at
javax.swing.JComponent$EnableSerializationFocusListener.writeObject(JComponent.j\
ava:4522)
at java.lang.reflect.Method.invoke(Native Method)
at
JSX.XMLSerialize.internalSer(XMLSerialize.java:1360)
at
JSX.XMLSerialize.getAllFields(XMLSerialize.java:1260)
at
JSX.XMLSerialize.serializeFields(XMLSerialize.java:1029)
at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:765)
at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:782)
at
JSX.XMLSerialize.serializeWrapperOrObject(XMLSerialize.java:1451)
at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:885)
at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:942)
at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:699)
at
JSX.XMLSerialize.serializeReferences(XMLSerialize.java:1202)
at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:792)
at
JSX.XMLSerialize.serializeWrapperOrObject(XMLSerialize.java:1451)
at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:885)
at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:942)
at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:699)
at
JSX.XMLSerialize.serializeReferences(XMLSerialize.java:1202)
at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:792)
at
JSX.XMLSerialize.serializeWrapperOrObject(XMLSerialize.java:1451)
at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:885)
at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:942)
at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:699)
at
JSX.XMLSerialize.serializeReferences(XMLSerialize.java:1202)
at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:792)
at
JSX.XMLSerialize.serializeWrapperOrObject(XMLSerialize.java:1451)
at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:885)
at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:942)
at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:699)
at
JSX.XMLSerialize.serializeReferences(XMLSerialize.java:1202)
at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:792)
at
JSX.XMLSerialize.serializeWrapperOrObject(XMLSerialize.java:1451)
at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:885)
at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:942)
at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:699)
at
JSX.XMLSerialize.serializeReferences(XMLSerialize.java:1202)
at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:792)
at JSX.XMLSerialize.commonSer(XMLSerialize.java:289)
at JSX.XMLSerialize.serialize(XMLSerialize.java:266)
at JSX.ObjOut.writeObjectOverride(ObjOut.java:107)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:271)
at
com.sparta.asto.cera.ceraGui.ceraView.Frame1.main(Frame1.java:53)
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
java.lang.reflect.InvocationTargetExceptionjava.lang.reflect.InvocationTargetExc\
eption: java.lang.Error: Do not use javax.swing.JInternalFrame.setLayout() use
javax.swing.JInternalFrame.getContentPane().setLayout() instead at
javax.swing.JInternalFrame.setLayout(JInternalFrame.java:463)
at
javax.swing.plaf.basic.BasicInternalFrameUI.uninstallListeners(BasicInternalFram\
eUI.java:216) at
javax.swing.plaf.basic.BasicInternalFrameUI.uninstallUI(BasicInternalFrameUI.jav\
a:120) at
javax.swing.plaf.metal.MetalInternalFrameUI.uninstallUI(MetalInternalFrameUI.jav\
a:90) at javax.swing.JComponent.compWriteObjectNotify(JComponent.java:4532) at
javax.swing.JInternalFrame.compWriteObjectNotify(JInternalFrame.java:1559) at
javax.swing.JComponent$EnableSerializationFocusListener.writeObject(JComponent.j\
ava:4522) at java.lang.reflect.Method.invoke(Native Method) at
JSX.XMLSerialize.internalSer(XMLSerialize.java:1360) at
JSX.XMLSerialize.getAllFields(XMLSerialize.java:1260) at
JSX.XMLSerialize.serializeFields(XMLSerialize.java:1029) at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:765) at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:782) at
JSX.XMLSerialize.serializeWrapperOrObject(XMLSerialize.java:1451) at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:885) at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:942) at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:699) at
JSX.XMLSerialize.serializeReferences(XMLSerialize.java:1202) at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:792) at
JSX.XMLSerialize.serializeWrapperOrObject(XMLSerialize.java:1451) at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:885) at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:942) at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:699) at
JSX.XMLSerialize.serializeReferences(XMLSerialize.java:1202) at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:792) at
JSX.XMLSerialize.serializeWrapperOrObject(XMLSerialize.java:1451) at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:885) at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:942) at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:699) at
JSX.XMLSerialize.serializeReferences(XMLSerialize.java:1202) at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:792) at
JSX.XMLSerialize.serializeWrapperOrObject(XMLSerialize.java:1451) at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:885) at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:942) at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:699) at
JSX.XMLSerialize.serializeReferences(XMLSerialize.java:1202) at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:792) at
JSX.XMLSerialize.serializeWrapperOrObject(XMLSerialize.java:1451) at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:885) at
JSX.XMLSerialize.serializeArrayReferences(XMLSerialize.java:942) at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:699) at
JSX.XMLSerialize.serializeReferences(XMLSerialize.java:1202) at
JSX.XMLSerialize.serializeObject(XMLSerialize.java:792) at
JSX.XMLSerialize.commonSer(XMLSerialize.java:289) at
JSX.XMLSerialize.serialize(XMLSerialize.java:266) at
JSX.ObjOut.writeObjectOverride(ObjOut.java:107) at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:271) at
com.sparta.asto.cera.ceraGui.ceraView.Frame1.main(Frame1.java:53)
Hi Kelly,
Thanks a lot for following up with more detail. Unfortunately, it
looks like you have now found a bug in Java itself!!
I just tried your code with Java's own Serialization (JOS) - and
got the same exception! Below is the exception, followed by your
code, modified to use JOS.
What does this mean?
(1). check Sun's bug parade, and if not there, to submit it.
(2). upgrade to a later version of the JDK (if possible -
note that JSX will not work with JDK 1.4 until it leaves beta)
(3). If neither solve it, use a different class - one approach is to
subclass it, to avoid the part that throws the exception...
I *might* be able to hack in a special case within JSX, to
overcome this bug, but it might not be possible, and it certainly
would be ugly!
Following is the code that actually throws the exception. Note
that the comments suggest subclassing it for your particular
component.
I've got to run right now, but please let me know how this goes!
Cheers,
Brendan
/**
* By default the layout of this component may not be set,
* the layout of its <code>contentPane</code> should be set
instead.
* For example:
* <pre>
* thisComponent.getContentPane().setLayout(new BorderLayout())
* </pre>
* An attempt to set the layout of this component will cause an
* runtime exception to be thrown. Subclasses can disable this
* behavior.
*
* @param manager the <code>LayoutManager</code>
* @see #setRootPaneCheckingEnabled
* @exception Error if called with
<code>isRootPaneChecking</code> true
*/
public void setLayout(LayoutManager manager) {
if(isRootPaneCheckingEnabled()) {
throw createRootPaneException("setLayout");
}
else {
super.setLayout(manager);
}
}
Writing first
java.lang.Error: Do not use javax.swing.JInternalFrame.setLayout()
use javax.swing.JInternalFrame.getContentPane().setLayout() instead
at javax.swing.JInternalFrame.createRootPaneException
(JInternalFrame.java:400)
at javax.swing.JInternalFrame.setLayout
(JInternalFrame.java:463)
at
javax.swing.plaf.basic.BasicInternalFrameUI.uninstallListeners
(BasicInternalFrameUI.java:224)
at javax.swing.plaf.basic.BasicInternalFrameUI.uninstallUI
(BasicInternalFrameUI.java:123)
at javax.swing.plaf.metal.MetalInternalFrameUI.uninstallUI
(MetalInternalFrameUI.java:90)
at javax.swing.JComponent.compWriteObjectNotify
(JComponent.java:4532)
at javax.swing.JInternalFrame.compWriteObjectNotify
(JInternalFrame.java:1559)
at
javax.swing.JComponent$EnableSerializationFocusListener.writeObject
(JComponent.java:4522)
at java.lang.reflect.Method.invoke(Native Method)
at java.io.ObjectOutputStream.invokeObjectWriter
(ObjectOutputStream.java:1878)
at java.io.ObjectOutputStream.outputObject
(ObjectOutputStream.java:1210)
at java.io.ObjectOutputStream.writeObject
(ObjectOutputStream.java:366)
at java.awt.AWTEventMulticaster.save
(AWTEventMulticaster.java:763)
at java.awt.Component.writeObject(Component.java:4507)
at java.lang.reflect.Method.invoke(Native Method)
at java.io.ObjectOutputStream.invokeObjectWriter
(ObjectOutputStream.java:1878)
at java.io.ObjectOutputStream.outputObject
(ObjectOutputStream.java:1210)
at java.io.ObjectOutputStream.writeObject
(ObjectOutputStream.java:366)
at java.io.ObjectOutputStream.outputArray
(ObjectOutputStream.java:1098)
at java.io.ObjectOutputStream.checkSubstitutableSpecialClasses
(ObjectOutputStream.java:456)
at java.io.ObjectOutputStream.writeObject
(ObjectOutputStream.java:361)
at java.io.ObjectOutputStream.outputClassFields
(ObjectOutputStream.java:1841)
at java.io.ObjectOutputStream.defaultWriteObject
(ObjectOutputStream.java:480)
at java.awt.Container.writeObject(Container.java:1773)
at java.lang.reflect.Method.invoke(Native Method)
at java.io.ObjectOutputStream.invokeObjectWriter
(ObjectOutputStream.java:1878)
at java.io.ObjectOutputStream.outputObject
(ObjectOutputStream.java:1210)
at java.io.ObjectOutputStream.writeObject
(ObjectOutputStream.java:366)
at java.io.ObjectOutputStream.outputArray
(ObjectOutputStream.java:1098)
at java.io.ObjectOutputStream.checkSubstitutableSpecialClasses
(ObjectOutputStream.java:456)
at java.io.ObjectOutputStream.writeObject
(ObjectOutputStream.java:361)
at java.io.ObjectOutputStream.outputClassFields
(ObjectOutputStream.java:1841)
at java.io.ObjectOutputStream.defaultWriteObject
(ObjectOutputStream.java:480)
at java.awt.Container.writeObject(Container.java:1773)
at java.lang.reflect.Method.invoke(Native Method)
at java.io.ObjectOutputStream.invokeObjectWriter
(ObjectOutputStream.java:1878)
at java.io.ObjectOutputStream.outputObject
(ObjectOutputStream.java:1210)
at java.io.ObjectOutputStream.writeObject
(ObjectOutputStream.java:366)
at java.io.ObjectOutputStream.outputArray
(ObjectOutputStream.java:1098)
at java.io.ObjectOutputStream.checkSubstitutableSpecialClasses
(ObjectOutputStream.java:456)
at java.io.ObjectOutputStream.writeObject
(ObjectOutputStream.java:361)
at java.io.ObjectOutputStream.outputClassFields
(ObjectOutputStream.java:1841)
at java.io.ObjectOutputStream.defaultWriteObject
(ObjectOutputStream.java:480)
at java.awt.Container.writeObject(Container.java:1773)
at java.lang.reflect.Method.invoke(Native Method)
/*********** Here is my class (modified for JOS) ****************/
import java.awt.*;
import javax.swing.*;
import JSX.*;
import java.io.*;
public class Frame1 extends JFrame {
JDesktopPane desktop;
JInternalFrame jif;
public Frame1() {
this.getContentPane().setLayout(new
BorderLayout());
this.setSize(600,600);
try {
// create the desktop pane for internal windows
desktop = new JDesktopPane();
desktop.setSize(600, 600);
// create the desktop manager
desktop.setDesktopManager(new
DefaultDesktopManager());
this.getContentPane().add("Center", desktop);
// create an internal window
jif = new JInternalFrame("Kelly Frame");
jif.getContentPane().setLayout(new
BorderLayout());
jif.getContentPane().setSize(200, 200);
desktop.add(jif);
}
catch (Exception e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
Frame1 cera = new Frame1();
try {
// write frame
System.err.println("Writing first");
File file = new File
("CeraFrame.xml");
//("c:\\data\\CeraFrame.xml");
FileOutputStream ostream = new
FileOutputStream(file);
//ObjectOutputStream out = new ObjOut(ostream, true);
//ObjectOutputStream out = new ObjOut(ostream);
ObjectOutputStream out = new ObjectOutputStream(ostream);
out.writeObject(cera);
ostream.close();
out.close();
//read frame
System.err.println("Reading");
FileInputStream fileReader = new FileInputStream(file);
BufferedInputStream bufferedReader = new
BufferedInputStream(fileReader);
//ObjectInputStream in = new ObjIn(bufferedReader);
ObjectInputStream in = new ObjectInputStream(bufferedReader);
Frame1 obj = (Frame1) in.readObject();
fileReader.close();
bufferedReader.close();
in.close();
//After reading frame successfully, I try to write the read frame
again
System.err.println("Writing second");
File file2 = new
File("CeraFrame2.xml");
//File("C:\\data\\CeraFrame2.xml");
ostream = new FileOutputStream(file2);
//out = new ObjOut(ostream, true);
//out = new ObjOut(ostream);
out = new ObjectOutputStream(ostream);
out.writeObject(obj);
ostream.close();
out.close();
obj.show();
}
catch (java.io.IOException ioe) {
System.out.println("CANNOT READ OR WRITE OBJECT");
ioe.printStackTrace();
}
catch (java.lang.ClassNotFoundException ne) {
System.out.println("CANNOT CAST");
ne.printStackTrace();
}
}
}
Send Email
