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

Re: Bug??

Expand Messages
  • mcuenca2@matiascuenca.com.ar
    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
    Message 1 of 7 , Oct 22, 2001
    View Source
    • 0 Attachment
      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
    • bren@mail.csse.monash.edu.au
      Hi Matias, ... 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
      Message 2 of 7 , Oct 22, 2001
      View Source
      • 0 Attachment
        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
      • mcuenca2@matiascuenca.com.ar
        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
        Message 3 of 7 , Oct 22, 2001
        View Source
        • 0 Attachment
          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
        • bren@mail.csse.monash.edu.au
          Hi again Matias, It s really good to see that the more compact version is already being useful! ... Yes, I think so... ... and ... This is an appealing idea -
          Message 4 of 7 , Oct 22, 2001
          View Source
          • 0 Attachment
            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
          Your message has been successfully submitted and would be delivered to recipients shortly.