Loading ...
Sorry, an error occurred while loading the content.

Re: Fwd: NSXML... replacement

Expand Messages
  • Brendan Macmillan
    Hi Matthew, Thanks for the post - a detailed reply follows. It would be great if you could you forward it back to their list, please? Cheers, Brendan --
    Message 1 of 4 , Jul 17, 2004
    View Source
    • 0 Attachment
      Hi Matthew,

      Thanks for the post - a detailed reply follows. It would be great if
      you could you forward it back to their list, please?
      Cheers,
      Brendan
      --


      Matthew Shields forwarded the post on serialization to the JSX
      mailing list, and I'm responding to the stacktrace from JSX.

      Before I begin, I'd strongly suggest XMLEncoder if you are
      serializing only Swing components, as that's what it was primarily
      designed for. More on this in (2) below.


      (1). The error occurs when JSX tries to serialize an instance of
      javax.swing.ImagineIcon:

      > apple.awt.EventQueueExceptionHandler Caught Throwable :
      > java.lang.IllegalAccessError: getSource() not valid for CImage
      > at apple.awt.CImage.getSource(CImage.java:128)
      > at java.awt.image.PixelGrabber.<init>(PixelGrabber.java:103)
      > at javax.swing.ImageIcon.writeObject(ImageIcon.java:412)

      The problem occurs within the "writeObject" method of that class,
      which handles its serial format, and which JSX calls -I've appended
      the code from ImagineIcon below, so you can see what I mean. This
      method uses the PixelGrabber class to extract the data from the icon
      image in order to serialize only that data. In the course of doing
      this, it calls Apple-specific code (the getSource() method of
      apple.awt.CImage) - and this is the trouble.

      Apple seems to have written a check into their code which prevents
      any third-party code from executing the "getSource" method, so that
      only the built-in serialization can use it, and not third-party
      reimplementations, like JSX.

      (NB: JSX isn't serializing this Apple-specific class; it's merely
      used by ImageIcon to assist in serializing itself.)

      Also: XStream doesn't have give this error because it doesn't call
      writeObject - and so doesn't actually serialize classes properly that
      rely on writeObject being called, such as this one. The lack of an
      explicit error does not mean serialization has been successful.


      (2). XMLEncoder is a better solution for serializing swing
      components - it was designed with this purpose specifically in mind,
      even though it is stated to be for java beans. In fact, the javadocs
      for all swing classes contain this warning:

      * <strong>Warning:</strong>
      * Serialized objects of this class will not be compatible with
      * future Swing releases. The current serialization support is
      * appropriate for short term storage or RMI between applications
      running
      * the same version of Swing. As of 1.4, support for long term
      storage
      * of all JavaBeans<sup><font size="-2">TM</font></sup>
      * has been added to the <code>java.beans</code> package.
      * Please see {@link java.beans.XMLEncoder}.


      (3). Finally, there's an interesting point about transient, and how
      it's inadequate to precisely specify the objects to be serialized.
      This issue was also brought up by a JSX user a few days ago, and we
      there are some ways of doing this.


      Cheers,
      Brendan
      --
      PS: following is the relevant source for the stacktrace:

      > apple.awt.EventQueueExceptionHandler Caught Throwable :
      > java.lang.IllegalAccessError: getSource() not valid for CImage
      > at apple.awt.CImage.getSource(CImage.java:128)
      > at java.awt.image.PixelGrabber.<init>(PixelGrabber.java:103)
      > at javax.swing.ImageIcon.writeObject(ImageIcon.java:412)


      javax.swing.ImageIcon.writeObject(ImageIcon.java:412):
      -----------------------------------------------------
      private void writeObject(ObjectOutputStream s)
      throws IOException
      {
      s.defaultWriteObject();

      int w = getIconWidth();
      int h = getIconHeight();
      int[] pixels = image != null? new int[w * h] : null;

      if (image != null) {
      try {
      PixelGrabber pg = new PixelGrabber(image, 0, 0, w, h,
      pixels, 0, w);
      pg.grabPixels();
      if ((pg.getStatus() & ImageObserver.ABORT) != 0) {
      throw new IOException("failed to load image
      contents");
      }
      }
      catch (InterruptedException e) {
      throw new IOException("image load interrupted");
      }
      }

      s.writeInt(w);
      s.writeInt(h);
      s.writeObject(pixels);
      }


      java.awt.image.PixelGrabber.<init>(PixelGrabber.java:103):
      ---------------------------------------------------------
      public PixelGrabber(Image img, int x, int y, int w, int h,
      int[] pix, int off, int scansize) {
      this(img.getSource(), x, y, w, h, pix, off, scansize);
      }


      apple.awt.CImage.getSource(CImage.java:128):
      -------------------------------------------
      [Does apple distribute source for this? Maybe there is a simple flag
      to set that will allow access for third-party tools?]

      The stacktract indicates the "img" object is of
      class "apple.awt.CImage", which is a subclass of Image. The
      IllegalAccessError occurs when its getSource() method is invoked.
      Presumably, apple.awt.CImage has a check at line 128, to prevent
      third party code from doing this. Does anyone have acces to that
      source?

      --- In JSX-ideas@yahoogroups.com, matthew shields
      <matthew.shields@a...> wrote:
      > There has been some discussion of JSX and some of it's alternatives
      on
      > the Apple Java-dev mailing list. I thought I'd cross post some of
      the
      > discussion just in case anyone wants to make any comments back to
      them
      > about JSX usage. It's normally a very good list with lively
      discusions.
      >
      > Regards Matt
      >
      > Begin forwarded message:
      >
      > > From: Michael Hall <mikehall@s...>
      > > Date: 16 July 2004 11:24:09 GMT-07:00
      > > To: "Paul R. Summermatter" <paulrs@l...>
      > > Cc: java dev <java-dev@l...>
      > > Subject: Re: NSXML... replacement
      > >
      > > On Tuesday, July 13, 2004, at 10:03 AM, Paul R. Summermatter
      wrote:
      > >
      > >> Paul,
      > >>
      > >> On Jul 13, 2004, at 9:03 AM, Paul Libbrecht wrote:
      > >>
      > >>> Paul,
      > >>>
      > >>> I presume you have looked at Jakarta Commons Betwixt and most
      of the
      > >>> JAXB implementations...
      > >>> Also, such things as the "hibernate" project are probably
      helpful.
      > >>
      > >> I hadn't looked at Jakarta Commons Betwixt, but I did just
      now, and
      > >> it appears to be yet another API for mapping beans to and from
      XML.
      > >> Similar to the beans based APIs, JAXB requires meta-data. I'm
      > >> looking for something that serializes Serializable objects to
      XML.
      > >>
      > >> Interestingly enough, I asked a friend of mine about this
      just now,
      > >> and he located this product:
      > >>
      > >> http://www.jsx.org
      > >>
      > > OK well I was curious enough on this to take a quick look, both
      at jsx
      > > and the xstream also mentioned but I don't find the post on that
      one
      > > anymore. Not a lot of other follow up I noticed.
      > > I decided to give them, jsx and xstream, an arguably unfair test.
      As I
      > > mentioned somewhat recently I use serialization as the save
      option for
      > > my application and have come up with some code of my own to allow
      that
      > > to include the Aqua L&F Swing gui.
      > > Just starting the application and then doing an immediate save.
      (This
      > > actually only saves a subset of the applications objects but that
      an
      > > ignorable detail). I hprof'd it for memory sites usage, why will
      > > become clearer shortly.
      > > So I get a 100KB serialized file and a 27.8MB java.hprof.txt file
      and
      > > it runs through and I should be able to deserialize the file and
      that
      > > should run through. Part of the results of the sites summary...
      > >
      > > SITES BEGIN (ordered by live bytes) Fri Jul 16 12:43:13 2004
      > > percent live alloc'ed stack class
      > > rank self accum bytes objs bytes objs trace name
      > > 1 3.09% 3.09% 268320 258 268320 258 33650 [I
      > > 2 3.07% 6.16% 266240 256 266240 256 34186 [I
      > > 3 2.14% 8.30% 185512 40 191648 42 179 [B
      > > 4 1.63% 9.94% 141552 1328 152640 1405 276 [C
      > > 5 1.37% 11.31% 119112 2127 181328 3238 25128
      > > java.lang.reflect.Method
      > > 6 1.26% 12.57% 109032 1564 109032 1564 284 [C
      > > 7 1.25% 13.81% 108072 237 108072 237 16164
      > > utillib.widgets.SwingCheckboxMenuItem
      > > 8 0.89% 14.71% 77560 1385 77560 1385 0
      java.lang.Class
      > > 9 0.88% 15.58% 76104 906 253680 3020 25196
      java.lang.Object
      > > 10 0.88% 16.46% 76104 906 258048 3072 25185
      java.lang.Object
      > >
      > > So the first 10 entries use about 16.5% of the total memory.
      > >
      > > OK, how about xstream? It didn't succeed so I can't talk about
      XML or
      > > anything like that. It didn't run into any serialization problems
      > > though but eventually ran out of memory. Hard to say how far it
      really
      > > got along but not running into serialization problems is
      impressive.
      > > It's hprof looks like...
      > >
      > > SITES BEGIN (ordered by live bytes) Fri Jul 16 09:52:54 2004
      > > percent live alloc'ed stack class
      > > rank self accum bytes objs bytes objs trace name
      > > 1 4.31% 4.31% 281232 5859 282816 5892 39248
      > > java.lang.reflect.Field
      > > 2 4.11% 8.42% 268320 258 268320 258 33577 [I
      > > 3 4.08% 12.50% 266240 256 266240 256 34215 [I
      > > 4 2.84% 15.34% 185512 40 191648 42 179 [B
      > > 5 2.17% 17.51% 141552 1328 152640 1405 276 [C
      > > 6 1.67% 19.18% 109032 1564 109032 1564 284 [C
      > > 7 1.66% 20.83% 108072 237 108072 237 16144
      > > utillib.widgets.SwingCheckboxMenuItem
      > > 8 1.57% 22.40% 102432 3201 102432 3201 39317
      > > java.util.TreeMap$Entry
      > > 9 1.50% 23.90% 97984 3062 97984 3062 39316
      > > java.util.TreeMap$Entry
      > > 10 1.18% 25.08% 77000 1375 77000 1375 0
      java.lang.Class
      > >
      > > Uses 10% more memory in the first 10 entries. You get into some
      > > TreeMap stuff that I would guess is xstream's implementation of
      > > serialized marshalling. It did indicate supporting 3 different
      > > marshalling strategies, one that was supposed to use less memory
      but I
      > > would _guess_ xstream entails a certain amount of extra memory
      > > overhead since I think it is doing pretty much it's own
      serialization
      > > off of reflection. This a quick look so my understanding of these
      can
      > > definitely be wrong.
      > >
      > > I didn't really check JSX for memory since it errored for a
      different
      > > reason.
      > >
      > > apple.awt.EventQueueExceptionHandler Caught Throwable :
      > > java.lang.IllegalAccessError: getSource() not valid for CImage
      > > at apple.awt.CImage.getSource(CImage.java:128)
      > > at java.awt.image.PixelGrabber.<init>(PixelGrabber.java:103)
      > > at javax.swing.ImageIcon.writeObject(ImageIcon.java:412)
      > >
      > > Sort of odd, not strictly a 'not serializable' error. We may of
      had
      > > similar CImage related errors come up on the list actually. But
      still
      > > the question might be why is it trying to serialize a very
      platform
      > > specific class? The jvm provider certainly has no responsibility
      to
      > > make these implementation classes serializable and if they are
      made so
      > > it still won't do a lot of good cross-platform I would have to
      > > imagine. Not everything may be serializable and probably
      shouldn't be.
      > > Personal opinion maybe because I haven't figured out how to use
      it
      > > correctly but the transient modifier is woefully inadequate to
      > > handling very much of this.
      > >
      > > Java data object persistence is sort of interesting to me since
      I've
      > > tinkered with it a little bit in relation to my applications save
      > > option.
      > > Although I think for WebObjects and other j2ee geared
      undertakings the
      > > persistence interest tends to remain sql ones usually doesn't it?
      > > Maybe though I'll take a look at what it would take to involve
      xml in
      > > some of what my stuff is doing. That the chosen persistence
      solution I
      > > guess for Sun and most these others and although bulkier than
      straight
      > > serialization probably not a bad choice overall.
      > > There still seems to be a bit of an art involved in getting
      something
      > > working though rather than some surefire automagical process. A
      rather
      > > belated 2 cent addition to the 2 cents I already put out on this.
      At
      > > least its 4 cents worth interesting to me.
      > >
      > > Mike Hall <mikehall at spacestar dot net>
      > > <http://www.spacestar.net/users/mikehall>
      > > _______________________________________________
      > > java-dev mailing list | java-dev@l...
      > > Help/Unsubscribe/Archives:
      > > http://www.lists.apple.com/mailman/listinfo/java-dev
      > > Do not post admin requests to the list. They will be ignored.
      > >
      > >
      > --
      > Matthew S. Shields BSc(hons), Research Associate Triana-Grid
      Project,
      > School's of Physics & Astronomy/Computer Science, Cardiff University
      > http://www.cs.cf.ac.uk/User/M.S.Shields/
      > email: matthew.shields@a... or m.s.shields@c...
    • Matthew Shields
      Reply from the Java-dev list. Matt ... -- Matthew S. Shields BSc(hons), Research Associate Triana-Grid Project, School s of Physics & Astronomy/Computer
      Message 2 of 4 , Jul 19, 2004
      View Source
      • 0 Attachment
        Reply from the Java-dev list.

        Matt

        Begin forwarded message:

        > From: Michael Hall <mikehall@...>
        > Date: 19 July 2004 13:10:20 BST
        > To: Matthew Shields <matthew.shields@...>
        > Cc: java-dev@...
        > Subject: Re: NSXML... replacement
        >>>
        >>> Before I begin, I'd strongly suggest XMLEncoder if you are
        >>> serializing only Swing components, as that's what it was primarily
        >>> designed for. More on this in (2) below.
        >>>
        > Interesting and I didn't know that. Swing was a particular concern as
        > the problem that got me more interested in serialization and how it
        > functions and how well it actually functions. As far as the L&F went
        > it didn't serialize well to start out with for Aqua. Maybe this means
        > Swing with the Metal L&F which I think is supposed to be ensured will
        > serialize?
        > I wondered as one possibility if you could for serialization cut over
        > from the current L&F to metal, serialize and reverse for deserialize.
        > I suspected if it did work having the gui suddenly started changing
        > appearance would be a little disconcerting.
        >
        >>>
        >>> (1). The error occurs when JSX tries to serialize an instance of
        >>> javax.swing.ImagineIcon:
        >>>
        > The error was somewhat unique and I think getting at the ImageProducer
        > or some other implementation detail of CImage has come up before. I
        > think maybe one mention was using CImage for drag and drop of PICT
        > format or something? Some undocumented feature that ran into problems
        > with the CImage implementation lacking something as a snag. The valid
        > Apple response was as I recall that normally applications should not
        > need to be concerned with the implementation specifics. So despite
        > doing something good the desired behavior was a bug not a feature. Or
        > not anything to count on anyhow.
        >
        >>> Also: XStream doesn't have give this error because it doesn't call
        >>> writeObject - and so doesn't actually serialize classes properly that
        >>> rely on writeObject being called, such as this one. The lack of an
        >>> explicit error does not mean serialization has been successful.
        >>>
        > Odd, I just put more time into working with XStream where this to some
        > extent seemed to be working. I wanted to see if by using normal
        > methods I could reduce some of the considerable size of the serialized
        > objects XML file. I was successful by using transient in getting it
        > under a meg. One XStream example seemed to suggest it didn't serialize
        > either 'transient' or 'static'. I didn't remember hearing anywhere
        > about static and serialization so that was a bit of a surprise but I
        > haven't given it much thought yet.
        > They will be considerably incompatible with normal Serialization if
        > they honor the 'transient' but do not do readObject() allowing it's
        > possible replacement? I haven't done the deserialize yet so this could
        > be correct, it will be sort of disappointing if it is absent without a
        > pretty good alternative.
        > If of any interest to anyone I uploaded my application yesterday and
        > it will now try to use XStream to do it's 'save' option if it is in
        > classpath. Eventually that needs better control as well but works well
        > enough for testing.
        > I hesitate to do more looking at JSX than what I have as it is now
        > commercial and I just don't have the budget.
        >
        >>>
        >>> (2). XMLEncoder is a better solution for serializing swing
        >>> components - it was designed with this purpose specifically in mind,
        >>> even though it is stated to be for java beans. In fact, the javadocs
        >>> for all swing classes contain this warning:
        >>>
        >>> * <strong>Warning:</strong>
        >>> * Serialized objects of this class will not be compatible with
        >>> * future Swing releases. The current serialization support is
        >>> * appropriate for short term storage or RMI between applications
        >>> running
        >
        > This has been the blurb with all serialized classes for a while.
        >
        >>> * the same version of Swing. As of 1.4, support for long term
        >>> storage
        >>> * of all JavaBeans<sup><font size="-2">TM</font></sup>
        >>> * has been added to the <code>java.beans</code> package.
        >>> * Please see {@link java.beans.XMLEncoder}.
        >
        > This part is newer. Whether JavaBeans and XML is the ultimate solution
        > for long term persistence of java objects is sort of the general
        > question. The JSX people must not figure that it is such a solution
        > for all cases as they have money on the line saying otherwise.
        >
        >>> (3). Finally, there's an interesting point about transient, and how
        >>> it's inadequate to precisely specify the objects to be serialized.
        >>> This issue was also brought up by a JSX user a few days ago, and we
        >>> there are some ways of doing this.
        >>>
        > It still seems flakey to me, hard to say where references are coming
        > from at times that cause the object to continue being serialized or
        > attempted serialized if it can't be even after it's marked
        > 'transient'. I was able with what almost at times seemed trial and
        > error to significantly reduce the size of the XStream marshalled
        > object. Again though it's yet to be seen how well that converts back
        > to my applications GUI.
        >
        > Thanks for the response. I do still find this interesting and plan on
        > putting some more time into it.
        >
        > Mike Hall <mikehall at spacestar dot net>
        > <http://www.spacestar.net/users/mikehall>
        >
        >
        --
        Matthew S. Shields BSc(hons), Research Associate Triana-Grid Project,
        School's of Physics & Astronomy/Computer Science, Cardiff University
        http://www.cs.cf.ac.uk/User/M.S.Shields/
        email: matthew.shields@... or m.s.shields@...
      • Matthew Shields
        This is the reply from the Java-Dev list ... -- Matthew S. Shields BSc(hons), Research Associate Triana-Grid Project, School s of Physics & Astronomy/Computer
        Message 3 of 4 , Aug 2, 2004
        View Source
        • 0 Attachment
          This is the reply from the Java-Dev list

          Begin forwarded message:

          > From: Michael Hall <mikehall@...>
          > Date: 30 July 2004 16:28:28 BST
          > To: Matthew Shields <matthew.shields@...>
          > Cc: java-dev@...
          > Subject: Re: NSXML... replacement
          >
          > On Friday, July 30, 2004, at 08:35 AM, Matthew Shields wrote:
          >
          >> Forwarded from Brendan, the author of JSX.
          >>
          >> Begin forwarded message:
          >>
          >> From: "Brendan Macmillan" <Brendan.Macmillan@...>
          >> Date: 28 July 2004 17:56:13 BST
          >> To: <JSX-ideas@yahoogroups.com>
          >> Subject: Re: [JSX] Fwd: NSXML... replacement
          >> Reply-To: JSX-ideas@yahoogroups.com
          >>
          >> Hi Matt,
          >>
          >> Sorry for the delayed reply! Would it be better if I joined the apple
          >> mailing list
          >> or something, so you don't have to act as a router?
          >>
          > Well it seems we have at least one other person this interests. You
          > could go direct to me I guess
          > mikehall at spacestar.net
          > Actually this is still what I'm looking at but going from XML to java
          > objects has still not been successful for my application so I hesitate
          > to say much since I could run into what amounts to a show stopper any
          > second that makes most of what I've done the last week or two pretty
          > much wasted effort. So please forgive me if for now what I say is kind
          > of brief.
          >
          >>
          >>>>>>> Before I begin, I'd strongly suggest XMLEncoder if you are
          >>>>>>> serializing only Swing components, as that's what it was
          >>>>>>> primarily
          >>>>>>> designed for. More on this in (2) below.
          >>>>>>>
          >>>>> Interesting and I didn't know that. Swing was a particular concern
          >>>>> as
          >>>>> the problem that got me more interested in serialization and how it
          >>>>> functions and how well it actually functions. As far as the L&F
          >>>>> went
          >>>>> it didn't serialize well to start out with for Aqua. Maybe this
          >>>>> means
          >>>>> Swing with the Metal L&F which I think is supposed to be ensured
          >>>>> will
          >>>>> serialize?
          >>>>> I wondered as one possibility if you could for serialization cut
          >>>>> over
          >>>>> from the current L&F to metal, serialize and reverse for
          >>>>> deserialize.
          >>>>> I suspected if it did work having the gui suddenly started changing
          >>>>> appearance would be a little disconcerting.
          >>
          >> I would expect serialization is supposed to work with all L&F (altho
          >> the
          >> standard ones would probably get more testing, and bug fixes, and
          >> therefore be
          >> more reliable). Ive found a few bugs in java serialization for swing
          >> (and their
          >> code is a mess), which is probably partly motivated Suns switch to
          >> XMLEncoder.
          >>
          >
          > I think from what's been indicated on this list is the cross-platform
          > Metal laf is the only serializable but I may not remember correctly or
          > the original person stating that might of been mistaken.
          >
          >>
          >>>>>>> (1). The error occurs when JSX tries to serialize an instance of
          >>>>>>> javax.swing.ImagineIcon:
          >>>>>>>
          >>>>> The error was somewhat unique and I think getting at the
          >>>>> ImageProducer
          >>>>> or some other implementation detail of CImage has come up before. I
          >>>>> think maybe one mention was using CImage for drag and drop of PICT
          >>>>> format or something? Some undocumented feature that ran into
          >>>>> problems
          >>>>> with the CImage implementation lacking something as a snag. The
          >>>>> valid
          >>>>> Apple response was as I recall that normally applications should
          >>>>> not
          >>>>> need to be concerned with the implementation specifics. So despite
          >>>>> doing something good the desired behavior was a bug not a feature.
          >>>>> Or
          >>>>> not anything to count on anyhow.
          >>
          >> Did you serialized exactly the same object with Java serialization,
          >> that JSX had
          >> problems with? JSX fixes some of the bugs in Java serialization, so
          >> quite often
          >> I find that JSX actually works better than it. From what you are
          >> saying
          >> maybe Java serialization would have the same problem as JSX in this
          >> specific case?
          >
          > My current efforts are still pretty much into XStream since that
          > remains active Open Source. I already have something on my to-do list
          > where an open source project was taking commercial and the activity of
          > the original open source start up code is questionable but probably
          > mostly inactive. Not that it isn't good code, it's not current and not
          > where the current effort is going.
          > If you are real interested in what I thought you indicated is probably
          > a OS/X quirk I am currently unemployed myself and would be happy to
          > come to some sort of terms for taking a look at it?
          >
          >>
          >>
          >>>>>>> Also: XStream doesn't have give this error because it doesn't
          >>>>>>> call
          >>>>>>> writeObject - and so doesn't actually serialize classes properly
          >>>>>>> that
          >>>>>>> rely on writeObject being called, such as this one. The lack of
          >>>>>>> an
          >>>>>>> explicit error does not mean serialization has been successful.
          >>>>>>>
          >>>>> Odd, I just put more time into working with XStream where this to
          >>>>> some
          >>>>> extent seemed to be working. I wanted to see if by using normal
          >>>>> methods I could reduce some of the considerable size of the
          >>>>> serialized
          >>>>> objects XML file. I was successful by using transient in getting it
          >>>>> under a meg. One XStream example seemed to suggest it didn't
          >>>>> serialize
          >>>>> either 'transient' or 'static'. I didn't remember hearing anywhere
          >>>>> about static and serialization so that was a bit of a surprise but
          >>>>> I
          >>>>> haven't given it much thought yet.
          >>>>> They will be considerably incompatible with normal Serialization if
          >>>>> they honor the 'transient' but do not do readObject() allowing it's
          >>>>> possible replacement?
          >>
          >> That is the big problem with XStream. It's actually on their critical
          >> list:
          >> http://jira.codehaus.org/browse/XSTR-92
          >>
          >> XStream seems like an early version of JSX1. (that's the GPL open
          >> source
          >> version of JSX).
          >>
          >> JSX2 is the commercial version (superior performance, and has a
          >> redesigned XML
          >> format which is more verbose than JSX1, because more comprehensive
          >> and logical.
          >> The XML format is fixed, with a static schema, so it is simpler to
          >> access with
          >> other tools such as XQuery, XSLT etc).
          >>
          >>>>> I haven't done the deserialize yet so this could
          >>>>> be correct, it will be sort of disappointing if it is absent
          >>>>> without a
          >>>>> pretty good alternative.
          >>
          >> Well, it might seem to work; but it's hard to imagine it working
          >> correctly,
          >> since Swing uses writeObject() and readObject() extensively, and
          >> relies heavily
          >> on the (de)serialization order of superclasses. Really, it's more
          >> abuse than
          >> reliance (they themselves comment in the source that it's a hack).
          >>
          > There are as you indicate workarounds for these sorts of issues and
          > these are what I have been investigating. Best would be if XStream
          > could just use readObject of course. So one try I have in place is
          > check to see a given Object has a serialization readObject method. If
          > so I try to writeObject the object as-is and then convert that to a
          > ObjectInputStream I pass back to the object to be able to readObject
          > on. This should work for a lot of the type readObject usage I myself
          > do which goes something like....
          >
          > transient Object tempobj1 = new Object();
          > transient Object tempobj2 = new Object();
          >
          > private readObject(ObjectInputStream ois) throws IOException {
          > ois.readDefaultObject();
          > tempobj1 = new Object();
          > tempobj2 = new Object();
          > }
          >
          > Unfortunately a lot of the core java classes seem to like to include
          > extra data that is restored in the readObject like...
          >
          > Object tempobj1 = new Object();
          > Object tempobj2 = new Object();
          >
          > private readObject(ObjectInputStream ois) throws IOException {
          > ois.readDefaultObject();
          > tempobj1 = ois.readObject();
          > tempobj2 = ois.readObject();
          > }
          >
          > My readObject will get an EOF exception here and I'm forced to come up
          > with another solution.
          >
          > Subtler for XStream is unconverted 'transient' fields suddenly causing
          > NullPointerExceptions. I'm running into these for Frame and Window now
          > as about my only remaining exceptions being thrown so I might be close
          > to finished. I've worked back that far so I might be close to
          > finished. Of course I might get that figured out and still find out
          > that nothing correctly references what it's supposed to, so even once
          > I've worked back to the top of the graph root there might still be
          > show stoppers I've had all along the way. But somehow a lot of this
          > must usually work for XStream so I'm hoping not.
          > What I'm still actually seeing is what I've been seeing all along, a
          > correctly titled but completely empty Frame.
          >
          >>
          >>>>> If of any interest to anyone I uploaded my application yesterday
          >>>>> and
          >>>>> it will now try to use XStream to do it's 'save' option if it is in
          >>>>> classpath. Eventually that needs better control as well but works
          >>>>> well
          >>>>> enough for testing.
          >>>>> I hesitate to do more looking at JSX than what I have as it is now
          >>>>> commercial and I just don't have the budget.
          >>
          >> JSX1 is GPL (free), although it's not really supported anymore.
          >>
          >> However, I am considering a very economical non-commercial license
          >> for JSX2
          >> (with a token price of something like $9.95).
          >>
          >> However, if you are saving Swing components, I highly recommend that
          >> you at
          >> least check out XMLEncoder (read: you must! you must!). It's a
          >> standard part of
          >> Java now, after all: java.beans.XMLEncoder.
          >> http://java.sun.com/j2se/1.4.2/docs/api/java/beans/XMLEncoder.html
          >>
          >> The downside is that it only works automatically with beans - you can
          >> write
          >> delegates, but they are awkward and counter-intuitive (it would be
          >> easier to
          >> make your classes into beans than write a delegate, I think).
          >>
          >> I think other approach to serializing Swing components will have
          >> problems sooner
          >> or later.
          >
          > I guess the more general problem still interests me and seeing how far
          > I can get trying to solve it with XStream for now. Not just an
          > interest in the Swing components.
          >>
          >>
          >>>>>>> * <strong>Warning:</strong>
          >>>>>>> * Serialized objects of this class will not be compatible with
          >>>>>>> * future Swing releases. The current serialization support is
          >>>>>>> * appropriate for short term storage or RMI between applications
          >>>>>>> running
          >>>>>
          >>>>> This has been the blurb with all serialized classes for a while.
          >>
          >> hmmmm, I've seen lots of Serializable classes that don't have this
          >> warning; the
          >> only place I've seen it is on Swing components. But I could be wrong
          >> - vould you
          >> point out one example of this warning on a non-Swing class please?
          >>
          > I could be wrong. Good documentation is nice but it doesn't change the
          > code one way or the other. If the blurb was true for Swing it should
          > properly have been included anywhere Java uses serialization shouldn't
          > it of?
          >
          >>
          >>>>>
          >>>>>>> * the same version of Swing. As of 1.4, support for long term
          >>>>>>> storage
          >>>>>>> * of all JavaBeans<sup><font size="-2">TM</font></sup>
          >>>>>>> * has been added to the <code>java.beans</code> package.
          >>>>>>> * Please see {@link java.beans.XMLEncoder}.
          >>>>>
          >>>>> This part is newer. Whether JavaBeans and XML is the ultimate
          >>>>> solution
          >>>>> for long term persistence of java objects is sort of the general
          >>>>> question. The JSX people must not figure that it is such a solution
          >>>>> for all cases as they have money on the line saying otherwise.
          >>
          >> The XMLEncoder solution is good for Swing components (but not much
          >> else, IMHO).
          >>
          >> The thing about Serialization is that it is a standard, that has been
          >> established and relied on for years. It is extraordinarily hard to go
          >> against
          >> such a standard. For example, I believe Pentiums are still compatible
          >> with 8086
          >> instruction set - Intel has tried to break compatibility recently
          >> (because they
          >> must really hate living with all their mistakes of over 10 years
          >> ago), but all
          >> they did was create an opportunity for AMD. And of course, the
          >> PowerPC seems
          >> much better than Intel's offerings... yet the PC is still ahead,
          >> because of the
          >> standard. It's even gaining ground away from Unix hardware, because
          >> of Linux
          >> running on Intel.
          >>
          >> So, despite its flaws, Java serialization works, and as a firmly
          >> entrenched
          >> standard, is here to stay. It reminds me of this C quote:
          >> C is quirky, flawed and an enormous success. (Dennis Ritchie)
          >>
          >
          > java.io.Serializable with the Object streams was an exceptionally good
          > first try I'd say as well.
          >
          >>
          >>>>>>> (3). Finally, there's an interesting point about transient, and
          >>>>>>> how
          >>>>>>> it's inadequate to precisely specify the objects to be
          >>>>>>> serialized.
          >>>
          >>>>> It still seems flakey to me, hard to say where references are
          >>>>> coming
          >>>>> from at times that cause the object to continue being serialized or
          >>>>> attempted serialized if it can't be even after it's marked
          >>>>> 'transient'. I was able with what almost at times seemed trial and
          >>>>> error to significantly reduce the size of the XStream marshalled
          >>>>> object. Again though it's yet to be seen how well that converts
          >>>>> back
          >>>>> to my applications GUI.
          >>
          >> Your perspective is interesting! I think the Java serialization
          >> wasn't designed
          >> for size limitation (which you are interested in), but for a
          >> simple-to-use and
          >> *correct* persistence/transmission mechanism. You are thinking of it
          >> as a sort
          >> of as a database, I guess? But the designers were interested in
          >> whether a
          >> specific object needs this other object (and so it can be made
          >> transient) - and
          >> so it doesn't matter if that object is needed by some other object,
          >> and so gets
          >> serialized anyway. They had a very class-based perspective, where I
          >> think you
          >> are taking a god's eye view, on the entire graph as a whole (not just
          >> what one
          >> class needs in isolation). There's a danger with deleting objects,
          >> because what
          >> if it really is needed by some other object? So, you need a God's eye
          >> view for
          >> this kind of decision.
          >>
          >> Instead of specifying whether to serialize a specific *reference* or
          >> not, I
          >> think you'd like specify whether a particular *object* should be
          >> serialized or
          >> not.
          >>
          >> I'm currently writing a tool to transform object graphs (using JSX),
          >> and so this
          >> kind of issue is very interesting to me. One transformation could
          >> be, for
          >> example, to remove certain objects from the graph. The only
          >> difficulty is how to
          >> specify which objects are to be removed.
          >>
          > Just using a lot of 'transient' reduces size considerably. Not
          > serializing an object and it's complete graph is obviously going to
          > reduce size. After I got as far as I got using 'transient' I started
          > using some of my own replacement tricks that I won't get into now, but
          > these have now gotten the size down to 320K, this XML text which you
          > expect to be bigger than binary by it's nature. So a good replacement
          > technique can come in handy if the situation is one where grabbing an
          > entire graph is a problem. We could maybe get into that off-list if
          > you like.
          >
          >>
          >> Very interesting! I think serialization is potentially immensely
          >> powerful, but
          >> it's not yet fully developed.
          >>
          > Yep still interests me or I'd be looking at something else right now.
          > Thanks again for the reply. Maybe point for point with full quotes may
          > of gone as far as it should for the current topic for now though.
          >
          >>
          >> Cheers,
          >> Brendan
          >> _______________________________________________
          >> java-dev mailing list | java-dev@...
          >> Help/Unsubscribe/Archives:
          >> http://www.lists.apple.com/mailman/listinfo/java-dev
          >> Do not post admin requests to the list. They will be ignored.
          >>
          >>
          > Mike Hall <mikehall at spacestar dot net>
          > <http://www.spacestar.net/users/mikehall>
          > _______________________________________________
          > java-dev mailing list | java-dev@...
          > Help/Unsubscribe/Archives:
          > http://www.lists.apple.com/mailman/listinfo/java-dev
          > Do not post admin requests to the list. They will be ignored.
          >
          >
          --
          Matthew S. Shields BSc(hons), Research Associate Triana-Grid Project,
          School's of Physics & Astronomy/Computer Science, Cardiff University
          http://www.cs.cf.ac.uk/User/M.S.Shields/
          email: matthew.shields@... or m.s.shields@...
        Your message has been successfully submitted and would be delivered to recipients shortly.