Hi,

I just experimented with allowing anyone to post (ie without having
to join) - and in one day, there are 5 spam emails. Sorry about that!

Yahoo egroups used to be great, but it seems just about unusable now,
and it's time for me to host the mailing-list locally.

Any ideas/tips on the best solution? My web-hoster has something
already, so I'll probably just use that.


Cheers,
Brendan

Thank you!  ;)

  -- D

--- Brendan Macmillan
<Brendan.Macmillan@...> wrote:
> Hi,
>
> I just experimented with allowing anyone to post (ie
> without having
> to join) - and in one day, there are 5 spam emails.
> Sorry about that!
>
> Yahoo egroups used to be great, but it seems just
> about unusable now,
> and it's time for me to host the mailing-list
> locally.
>
> Any ideas/tips on the best solution? My web-hoster
> has something
> already, so I'll probably just use that.
>
>
> Cheers,
> Brendan
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> 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/
>
>


__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

This email is to inform you about the release of version '2.1.4doc' 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:
In this version, the manual has been updated, including documentation
of objectReplace, objectResolve, classResolve, and recognition of
either apostrophes or quotes to delimit attribute values.

Project description:
Java Serialization to XML (JSX) allows you to write and read any Java
object graph as XML data with one line of code. You can verify your
data and manipulate it with standard XML tools like DOM, JDOM, and
XSLT. JSX automatically creates a file format/wire protocol for all
Java objects, so that it is always up to date as the code evolves.
When you need backward compatibility, JSX provides the evolution
techniques of Java Object Serialization, and you can also modify the
XML directly. Unlike databinders, such as JAXB and Castor, no
explicit mapping is required, and JSX works for all objects.

Trove categories:
[Development Status  ] 5 - Production/Stable
[Environment         ] Console (Text Based), MacOS X, Other Environment,
Web Environment, Win32 (MS Windows)
[Intended Audience   ] Developers
[License             ] OSI Approved :: GNU General Public License (GPL),
Other/Proprietary License with Free Trial
[Programming Language] Java
[Topic               ] Communications, Database, Software Development,
Software Development :: Libraries, Software Development :: Libraries ::
Java Libraries, Software Development :: Object Brokering, System ::
Archiving, System :: Recovery Tools, Text Processing :: Markup :: XML

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

____________________________| Advertising |____________________________
Etnus TotalView, version 6.3.1 Now Available!

Etnus TotalView, the most advanced debugger on Linux and UNIX, now
supports
AMD's X86-64 based systems and HP-UX on Itanium 2. TotalView has advanced
features absent in other debuggers, such
as data analysis and heap allocation debugging.  Get insight into your
program fast. Try it free today.


http://www.etnus.com/index2.html
____________________________| Advertising |____________________________

Hi all,

A simpler XML format for JSX - what is really nice is that the indentation
level will correspond exactly to how deep the object is from the root.

The existing format will remain, and this new one will perhaps form a
separate product (so don't worry about back-compatibility! They will also be
distinguished in the <jsx> header element).

I would very much like your opinion on a choice I'm facing - so here's your
chance to bring the whole project under your influence and have an impact!
Wow! :-)

The issue is with inheritance of fields: the XML needs to indicate which
superclass defined each field. This is important for shadowed fields (fields
with same name in a superclass) and for evolution. NB: for compatibility
with JOS, the fields must be ordered from superclass to subclass. We can't
get around this.

Here are the two designs (it's a java description, followed by a sketch of
the XML):

OPTION 1
class Sub extends Super {}
<obj class="Sub">
     <class class="Super"/>
     ... // fields from Super
     <class class="Sub"/>
     ... // fields from Sub
</obj>
Note that the class elements are just markers for processing - they don't
enclose anything.

If there is no superclass, we don't need the class element, and so omit it
for simplicity:
class Super {}
<obj class="Super">
     ... // fields from Super
</obj>


OPTION 2
class Sub extends Super {}
<obj class="Sub">
     ... // fields from Super
     <class class="Super"/>
     ... // fields from Sub
</obj>
By putting the class *after* its fields, it is natural to just omit the last
one, and so the simplist case naturally falls out of it (which is nice and
elegant):

class Super {}
<obj class="Super">
     ... // fields from Super
</obj>


DISCUSSION
Despite the elegance of (2), it has a serious problem: stating the class
*after* the fields it refers to is not natural for a human reader - we
expect a description to come first. Consider the first example for (2), of
class Sub. It's easy to be misled, and think that the first lot of fields
come from Sub, and the second lot come from Super - when it's the other way
around. Because human confusion and frustration are the problems I'm trying
to solve rather than a nice logical flow in the abstract, I think that (1)
is the better choice.

But your opinion - as a potential user of this format - is what really
counts! What do you think?

If the format has to change, then I would go with option 1. Although,
for compatibility with 3rd party tools, this is still the best:


class Sub extends Super {}
<obj class="Sub">
     <class class="Super">
         ... // fields from Super
     </class>
     <class class="Sub">
         ... // fields from Sub
     </class>
</obj>


- Mark Collette


Brendan Macmillan wrote:
>
> Hi all,
>
> A simpler XML format for JSX - what is really nice is that the indentation
> level will correspond exactly to how deep the object is from the root.
>
> The existing format will remain, and this new one will perhaps form a
> separate product (so don't worry about back-compatibility! They will also be
> distinguished in the <jsx> header element).
>
> I would very much like your opinion on a choice I'm facing - so here's your
> chance to bring the whole project under your influence and have an impact!
> Wow! :-)
>
> The issue is with inheritance of fields: the XML needs to indicate which
> superclass defined each field. This is important for shadowed fields (fields
> with same name in a superclass) and for evolution. NB: for compatibility
> with JOS, the fields must be ordered from superclass to subclass. We can't
> get around this.
>
> Here are the two designs (it's a java description, followed by a sketch of
> the XML):
>
> OPTION 1
> class Sub extends Super {}
> <obj class="Sub">
>     <class class="Super"/>
>     ... // fields from Super
>     <class class="Sub"/>
>     ... // fields from Sub
> </obj>
> Note that the class elements are just markers for processing - they don't
> enclose anything.
>
> If there is no superclass, we don't need the class element, and so omit it
> for simplicity:
> class Super {}
> <obj class="Super">
>     ... // fields from Super
> </obj>
>
> OPTION 2
> class Sub extends Super {}
> <obj class="Sub">
>     ... // fields from Super
>     <class class="Super"/>
>     ... // fields from Sub
> </obj>
> By putting the class *after* its fields, it is natural to just omit the last
> one, and so the simplist case naturally falls out of it (which is nice and
> elegant):
>
> class Super {}
> <obj class="Super">
>     ... // fields from Super
> </obj>
>
> DISCUSSION
> Despite the elegance of (2), it has a serious problem: stating the class
> *after* the fields it refers to is not natural for a human reader - we
> expect a description to come first. Consider the first example for (2), of
> class Sub. It's easy to be misled, and think that the first lot of fields
> come from Sub, and the second lot come from Super - when it's the other way
> around. Because human confusion and frustration are the problems I'm trying
> to solve rather than a nice logical flow in the abstract, I think that (1)
> is the better choice.
>
> But your opinion - as a potential user of this format - is what really
> counts! What do you think?
>

--- In JSX-ideas@yahoogroups.com, Mark Collette <mcollett@s...> wrote:
> If the format has to change, then I would go with option 1.

Thanks - BTW this isn't a change, just an alternative.

> Although, for compatibility with 3rd party tools,

Really? The main motivation for changing it is to make it easier to
work with, with third-party tools.  Which tools are you thinking of?
Is it that in XPath, the declaring class is just part of the path?

Perhaps the main thing here is to get rid of the <default>... and the
<class> part is actually OK?

[ it's possible to have several alternative, and see which one people
prefer. ]


Cheers,
Brendan

> this is still the best:
>
>
> class Sub extends Super {}
> <obj class="Sub">
>     <class class="Super">
>         ... // fields from Super
>     </class>
>     <class class="Sub">
>         ... // fields from Sub
>     </class>
> </obj>
>
>
> - Mark Collette
>
>
> Brendan Macmillan wrote:
> >
> > Hi all,
> >
> > A simpler XML format for JSX - what is really nice is that the
indentation
> > level will correspond exactly to how deep the object is from the
root.
> >
> > The existing format will remain, and this new one will perhaps
form a
> > separate product (so don't worry about back-compatibility! They
will also be
> > distinguished in the <jsx> header element).
> >
> > I would very much like your opinion on a choice I'm facing - so
here's your
> > chance to bring the whole project under your influence and have
an impact!
> > Wow! :-)
> >
> > The issue is with inheritance of fields: the XML needs to
indicate which
> > superclass defined each field. This is important for shadowed
fields (fields
> > with same name in a superclass) and for evolution. NB: for
compatibility
> > with JOS, the fields must be ordered from superclass to subclass.
We can't
> > get around this.
> >
> > Here are the two designs (it's a java description, followed by a
sketch of
> > the XML):
> >
> > OPTION 1
> > class Sub extends Super {}
> > <obj class="Sub">
> >     <class class="Super"/>
> >     ... // fields from Super
> >     <class class="Sub"/>
> >     ... // fields from Sub
> > </obj>
> > Note that the class elements are just markers for processing -
they don't
> > enclose anything.
> >
> > If there is no superclass, we don't need the class element, and
so omit it
> > for simplicity:
> > class Super {}
> > <obj class="Super">
> >     ... // fields from Super
> > </obj>
> >
> > OPTION 2
> > class Sub extends Super {}
> > <obj class="Sub">
> >     ... // fields from Super
> >     <class class="Super"/>
> >     ... // fields from Sub
> > </obj>
> > By putting the class *after* its fields, it is natural to just
omit the last
> > one, and so the simplist case naturally falls out of it (which is
nice and
> > elegant):
> >
> > class Super {}
> > <obj class="Super">
> >     ... // fields from Super
> > </obj>
> >
> > DISCUSSION
> > Despite the elegance of (2), it has a serious problem: stating
the class
> > *after* the fields it refers to is not natural for a human
reader - we
> > expect a description to come first. Consider the first example
for (2), of
> > class Sub. It's easy to be misled, and think that the first lot
of fields
> > come from Sub, and the second lot come from Super - when it's the
other way
> > around. Because human confusion and frustration are the problems
I'm trying
> > to solve rather than a nice logical flow in the abstract, I think
that (1)
> > is the better choice.
> >
> > But your opinion - as a potential user of this format - is what
really
> > counts! What do you think?
> >

I just assume that since the XML language uses tag nesting to "contain"
substructure within a structure, that using tags merely as markers would
be a bit of an abuse of the language intentions, which might cause other
tools to not function properly, as they assume nesting instead of
separating.

- Mark Collette


Brendan Macmillan wrote:
>
> --- In JSX-ideas@yahoogroups.com, Mark Collette <mcollett@s...> wrote:
> > If the format has to change, then I would go with option 1.
>
> Thanks - BTW this isn't a change, just an alternative.
>
> > Although, for compatibility with 3rd party tools,
>
> Really? The main motivation for changing it is to make it easier to
> work with, with third-party tools.  Which tools are you thinking of?
> Is it that in XPath, the declaring class is just part of the path?
>
> Perhaps the main thing here is to get rid of the <default>... and the
> <class> part is actually OK?
>
> [ it's possible to have several alternative, and see which one people
> prefer. ]
>
> Cheers,
> Brendan
>
> > this is still the best:
> >
> >
> > class Sub extends Super {}
> > <obj class="Sub">
> >     <class class="Super">
> >         ... // fields from Super
> >     </class>
> >     <class class="Sub">
> >         ... // fields from Sub
> >     </class>
> > </obj>
> >
> >
> > - Mark Collette
> >
> >
> > Brendan Macmillan wrote:
> > >
> > > Hi all,
> > >
> > > A simpler XML format for JSX - what is really nice is that the
> indentation
> > > level will correspond exactly to how deep the object is from the
> root.
> > >
> > > The existing format will remain, and this new one will perhaps
> form a
> > > separate product (so don't worry about back-compatibility! They
> will also be
> > > distinguished in the <jsx> header element).
> > >
> > > I would very much like your opinion on a choice I'm facing - so
> here's your
> > > chance to bring the whole project under your influence and have
> an impact!
> > > Wow! :-)
> > >
> > > The issue is with inheritance of fields: the XML needs to
> indicate which
> > > superclass defined each field. This is important for shadowed
> fields (fields
> > > with same name in a superclass) and for evolution. NB: for
> compatibility
> > > with JOS, the fields must be ordered from superclass to subclass.
> We can't
> > > get around this.
> > >
> > > Here are the two designs (it's a java description, followed by a
> sketch of
> > > the XML):
> > >
> > > OPTION 1
> > > class Sub extends Super {}
> > > <obj class="Sub">
> > >     <class class="Super"/>
> > >     ... // fields from Super
> > >     <class class="Sub"/>
> > >     ... // fields from Sub
> > > </obj>
> > > Note that the class elements are just markers for processing -
> they don't
> > > enclose anything.
> > >
> > > If there is no superclass, we don't need the class element, and
> so omit it
> > > for simplicity:
> > > class Super {}
> > > <obj class="Super">
> > >     ... // fields from Super
> > > </obj>
> > >
> > > OPTION 2
> > > class Sub extends Super {}
> > > <obj class="Sub">
> > >     ... // fields from Super
> > >     <class class="Super"/>
> > >     ... // fields from Sub
> > > </obj>
> > > By putting the class *after* its fields, it is natural to just
> omit the last
> > > one, and so the simplist case naturally falls out of it (which is
> nice and
> > > elegant):
> > >
> > > class Super {}
> > > <obj class="Super">
> > >     ... // fields from Super
> > > </obj>
> > >
> > > DISCUSSION
> > > Despite the elegance of (2), it has a serious problem: stating
> the class
> > > *after* the fields it refers to is not natural for a human
> reader - we
> > > expect a description to come first. Consider the first example
> for (2), of
> > > class Sub. It's easy to be misled, and think that the first lot
> of fields
> > > come from Sub, and the second lot come from Super - when it's the
> other way
> > > around. Because human confusion and frustration are the problems
> I'm trying
> > > to solve rather than a nice logical flow in the abstract, I think
> that (1)
> > > is the better choice.
> > >
> > > But your opinion - as a potential user of this format - is what
> really
> > > counts! What do you think?

This email is to inform you about the release of version '2.1.4doc2' 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:
Bugs in the Memento example have been fixed.

Project description:
Java Serialization to XML (JSX) allows you to write and read any Java
object graph as XML data with one line of code. You can verify your
data and manipulate it with standard XML tools like DOM, JDOM, and
XSLT. JSX automatically creates a file format/wire protocol for all
Java objects, so that it is always up to date as the code evolves.
When you need backward compatibility, JSX provides the evolution
techniques of Java Object Serialization, and you can also modify the
XML directly. Unlike databinders, such as JAXB and Castor, no
explicit mapping is required, and JSX works for all objects.

Trove categories:
[Development Status  ] 5 - Production/Stable
[Environment         ] Console (Text Based), MacOS X, Other Environment,
Web Environment, Win32 (MS Windows)
[Intended Audience   ] Developers
[License             ] OSI Approved :: GNU General Public License (GPL),
Other/Proprietary License with Free Trial
[Programming Language] Java
[Topic               ] Communications, Database, Software Development,
Software Development :: Libraries, Software Development :: Libraries ::
Java Libraries, Software Development :: Object Brokering, System ::
Archiving, System :: Recovery Tools, Text Processing :: Markup :: XML

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

This email is to inform you about the release of version '2.1.4xslt.doc' 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:
An XSLT example for databinding has been added, that shows how to map
between JSX's XML format and another XML format.

Project description:
Java Serialization to XML (JSX) allows you to write and read any Java
object graph as XML data with one line of code. You can verify your
data and manipulate it with standard XML tools like DOM, JDOM, and
XSLT. JSX automatically creates a file format/wire protocol for all
Java objects, so that it is always up to date as the code evolves.
When you need backward compatibility, JSX provides the evolution
techniques of Java Object Serialization, and you can also modify the
XML directly. Unlike databinders, such as JAXB and Castor, no
explicit mapping is required, and JSX works for all objects.

Trove categories:
[Development Status  ] 5 - Production/Stable
[Environment         ] Console (Text Based), MacOS X, Other Environment,
Web Environment, Win32 (MS Windows)
[Intended Audience   ] Developers
[License             ] OSI Approved :: GNU General Public License (GPL),
Other/Proprietary License with Free Trial
[Programming Language] Java
[Topic               ] Communications, Database, Software Development,
Software Development :: Libraries, Software Development :: Libraries ::
Java Libraries, Software Development :: Object Brokering, System ::
Archiving, System :: Recovery Tools, Text Processing :: Markup :: XML

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 and
categories you're subscribed to in the right column, which you may cancel
by highlighting the project or category in question and clicking the
'delete' button.

Sincerely,
freshmeat.net

____________________________| Advertising |____________________________
This email is sponsored by OSDN's Audience Survey.

Help shape OSDN's sites and tell us what you think.
Take this five minute survey and you could
win a $250 Gift Certificate.


http://www.wrgsurveys.com/2003/osdntech03.php?site=2
____________________________| Advertising |____________________________

Hi,

I downloaded the JSX2.1.4.jar file last week to evaluate this
product in our enterprise ecommerce environment but I got the
following message from weblogic:
"
Thanks for evaluating JSX for 30 days.
If you need more time, please contact company@... (for work)
or non-profit@... (for students, academics and hobbiests)
Buy JSX online at www.jsx.org/buy.html, or contact sales@...
"
However it was ok when I tested it from outside of weblogic
(commandline). Is this the way it is or a bug? I need to find out
how this package performs under high volume stress in the server
side environment. Has anyone here tried out similar approach? It is
a great product and I just need some numbers to convince my boss ...

Thanks,
Hongsheng

Hello everyone,

Has anybody requested the feature of logging deserialization
discrepancies, such as fields deleted or added? This seems to be
necessary to capture the class compatibility issue.

Hongsheng

This email is to inform you about the release of version '2.1.5' 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:
This release makes it easier to convert from your XML format to JSX's
format with XSLT. By allowing you to represent both String and
primitive values with the JSX "primitive" tag, your XSLT no longer
needs to distinguish between the two.

Project description:
Java Serialization to XML (JSX) allows you to write and read any Java
object graph as XML data with one line of code. You can verify your
data and manipulate it with standard XML tools like DOM, JDOM, and
XSLT. JSX automatically creates a file format/wire protocol for all
Java objects, so that it is always up to date as the code evolves.
When you need backward compatibility, JSX provides the evolution
techniques of Java Object Serialization, and you can also modify the
XML directly. Unlike databinders, such as JAXB and Castor, no
explicit mapping is required, and JSX works for all objects.

Trove categories:
[Development Status  ] 5 - Production/Stable
[Environment         ] Console (Text Based), MacOS X, Other Environment,
Web Environment, Win32 (MS Windows)
[Intended Audience   ] Developers
[License             ] OSI Approved :: GNU General Public License (GPL),
Other/Proprietary License with Free Trial
[Programming Language] Java
[Topic               ] Communications, Database, Software Development,
Software Development :: Libraries, Software Development :: Libraries ::
Java Libraries, Software Development :: Object Brokering, System ::
Archiving, System :: Recovery Tools, Text Processing :: Markup :: XML

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 and
categories you're subscribed to in the right column, which you may cancel
by highlighting the project or category in question and clicking the
'delete' button.

Sincerely,
freshmeat.net

____________________________| Advertising |____________________________
Etnus TotalView, version 6.3.1 Now Available!

Etnus TotalView, the most advanced debugger on Linux and UNIX, now
supports
AMD's X86-64 based systems and HP-UX on Itanium 2. TotalView has advanced
features absent in other debuggers, such
as data analysis and heap allocation debugging. Get insight into your
program fast. Try it free today. www.etnus.com/index2.html

www.etnus.com/index2.html
____________________________| Advertising |____________________________

Hi Hongsheng,

You have to close() the ObjectWriter (like other Java streams). See the
download web page an example of this.
www.jsx.org/download.html

A key goal of JSX is for it to work as you expect, so it does not cause this
kind of frustration (which is all too common in daily
life). I discuss some solutions below.


Originally, the XML was closed automatically, because there was no <jsx>
tag.  But this was a problem because JOS allows more than
one object to be serialized to the same stream, and so forming an XML
document with more than one root (which is ill-formed). Thus,
the <jsx> tag is needed to wrap up the potentially multiple roots.

Because it is impossible for JSX to know whether you want to add more
objects to the stream (eg with subsequent writeObject()
calls), or if you have finished, an explicit call to close() is needed so
you can tell it what you want.

Is this feature worth the loss of useability?
Unfortunately for useability, it is very easy to not realize that close() is
necessary, and even if you know, it is even easier to
forget (and it means more typing too). I think that the *only* situation
where writeObject() is called more than once is for
streaming objects (eg over sockets), as you pipeline the process, and don't
know what future objects you want to send (if you did,
you could put them all in an array of Objects instead), and you want to
reuse the one connection, instead of inefficiently opening a
new one for each writeObject().

A solution:
How about I reintroduce automatic closing?  Make this switchable, so you can
turn it off if you want multiple objects. To help you,
JSX could detect subsequent writeObject() calls when automatic closing is
switched "on", and throw an Exception explaining how to
switch it off.

Who would like this? Is it worth doing?


Cheers,
Brendan
PS:
Ideally, I would like to make a different version of JSX customized to
different tasks - then, it will "just work" out of the box,
and you don't have to worry about or even know about these details. For
example, a "socket JSX" and a "persistence JSX". The above
close() is just one of many customizations - the alternative is a plethora
of switches and creeping featurism, which weighs the
whole thing down in complexity (in practice, I might well have all these
switches, but hidden and pre-configured for each use).

Well, typically when one adds a switch, the default behavior (without
the switch) is to do the old behavior. Thus, to omit the close() call,
they'd have to use a switch. This won't save any typing, and I'm not
really a proponen of increasing complexity to save typing, so... I doubt
it's worth doing.

- Mark


> A solution:
> How about I reintroduce automatic closing?  Make this switchable, so you can
> turn it off if you want multiple objects. To help you,
> JSX could detect subsequent writeObject() calls when automatic closing is
> switched "on", and throw an Exception explaining how to
> switch it off.
>
> Who would like this? Is it worth doing?

Hi Hongsheng,

> Yeah ... Its all about expectation. In my case I have a conversion
> program that runs from command line. As long as I flush the output
> stream, there is really no need for me to close() the stream, which is
> why I prefer the openXml() and closeXml() better. It's true that people
> can still forget to call these methods, but because it is a somewhat new
> face in the example code, the chance will be lower. The auto approach
> makes the api more complicated because you have to provide ways to turn
> it on/off, query it, and still you need to remind user to close the
> stream when the auto mode is turned off.
This is becoming complicated now, so I think I'll just leave it as it is.

> One other thing I realize is that the
> serialization-deserialization-serialization sequence against an object
> does not always generate the same out xml. Are you aware of this? It
> seems to happen on HashMap objects.

IIRC, that happens because the the default hashes are based on actual memory
locations, which can change when re-serialized. The
same thing happens with JOS (to see this, change ObjectWriter/Reader to
ObjectOutputStream/InputStream, output to a file and
compare).

I found this annoying when testing JSX; you are making me think that it might be
better for me to write a delegate for HashMap,
which writes out the contents in a way that doesn't have this problem. But this
might be impossible, because there is no simple way
I can see to define a canonical ordering. If you just use an iterator, the
ordering will be determined by the keys... which can
determined by actual memory locations (back where we started).


Cheers,
Brendan

> -----Original Message-----
> From: Brendan Macmillan
> [mailto:Brendan.Macmillan@...]
> Sent: Friday, February 13, 2004 1:46 AM
> To: Hongsheng Chen
> Subject: Re: [JSX] evaluation expires prematurely
>
>
> Are you saying that when you see the close() method, you thought it was
> just an ordinary stream close(), which is often optionally (unless you
> need to flush the stream). Because you were familiar with this role of
> close(), it did not occur to you that close() might have another role?
>
> Therefore, naming it as openXML() and closeXML() makes it clear to the
> user that these are different from the ordinary close() - provided of
> course that they see them (in an example, or maybe in the javadocs).
>
> I am guessing that you saw the close() in the examples, and thought,
> "Oh, he's just being correct because it's an example. It's no more
> important than usual". Maybe you didn't even notice the close()
> explicitly, because it's something familar.
>
> In other words, the cause of the problem for you is that close() was
> important in a way that you didn't expect, so the link between you not
> using
> close() and there being </tag> was not apparent at all.
>
> I've been taking the view that users *should* use close() anyway, and if
> they don't, then they are doing something wrong. While that view might
> be technically correct, in practice, streams often aren't closed,
> because it's not necessary - and because no link is apparent between
> this and the lack of </jsx>, it's hard to correct it.
>
> The problem I fear with using closeXML() is that users won't realize
> that they need to do this, so it would be little better than using
> close() as is. For this reason, I really like the idea of making it
> close itself automatically - with an Exception if you try to send more
> than one object graph, telling you how to fix it.
>
>
> Cheers,
> Brendan
> ----- Original Message -----
> From: "Hongsheng Chen" <hongsheng.chen@...>
> To: "Brendan Macmillan" <Brendan.Macmillan@...>
> Sent: Friday, February 13, 2004 2:05 AM
> Subject: RE: [JSX] evaluation expires prematurely
>
>
> >
> > Thanks, Brendan. I added close() and it worked. I think the manual
> > close approach makes more sense. We can even make it more explicit: do
>
> > something like writer.openXml(), writer.closeXml() instead of using
> > the standard close() method. That way the user should be aware it is
> > his full responsibility to manage what is included in the xml.
> >
> > --Hongsheng
> >
> > -----Original Message-----
> > From: Brendan Macmillan
> > [mailto:Brendan.Macmillan@...]
> > Sent: Wednesday, February 11, 2004 8:24 PM
> > To: Hongsheng Chen
> > Subject: Re: [JSX] evaluation expires prematurely
> >
> >
> > Hi Hongsheng,
> >
> > You have to close() the ObjectWriter (like other Java streams). See
> > the download web page an example of this. www.jsx.org/download.html
> >
> > A key goal of JSX is for it to work as you expect, so it does not
> > cause this kind of frustration (which is all too common in daily
> > life). I discuss some solutions below.
> >
> >
> > Originally, the XML was closed automatically, because there was no
> > <jsx> tag.  But this was a problem because JOS allows more than one
> > object to be serialized to the same stream, and so forming an XML
> > document with more than one root (which is ill-formed). Thus, the
> > <jsx> tag is needed to wrap up the potentially multiple roots.
> >
> > Because it is impossible for JSX to know whether you want to add more
> > objects to the stream (eg with subsequent writeObject() calls), or if
> > you have finished, an explicit call to close() is needed so you can
> > tell it what you want.
> >
> > Is this feature worth the loss of useability?
> > Unfortunately for useability, it is very easy to not realize that
> > close() is necessary, and even if you know, it is even easier to
> > forget (and it means more typing too). I think that the *only*
> > situation where
> > writeObject() is called more than once is for streaming objects (eg
> over
> > sockets), as you pipeline the process, and don't know what future
> > objects you want to send (if you did, you could put them all in an
> array
> > of Objects instead), and you want to reuse the one connection, instead
> > of inefficiently opening a new one for each writeObject().
> >
> > A solution:
> > How about I reintroduce automatic closing?  Make this switchable, so
> > you can turn it off if you want multiple objects. To help you, JSX
> > could detect subsequent writeObject() calls when automatic closing is
> > switched "on", and throw an Exception explaining how to switch it off.
> >
> > Who would like this? Is it worth doing?
> >
> >
> > Cheers,
> > Brendan
> > PS:
> > Ideally, I would like to make a different version of JSX customized to
>
> > different tasks - then, it will "just work" out of the box, and you
> > don't have to worry about or even know about these details. For
> > example, a "socket JSX" and a "persistence JSX". The above
> > close() is just one of many customizations - the alternative is a
> > plethora of switches and creeping featurism, which weighs the whole
> > thing down in complexity (in practice, I might well have all these
> > switches, but hidden and pre-configured for each use).
> >
> > --
> > Brendan.Macmillan@... +61 3 9905 1502 www.jsx.org
> > ----- Original Message -----
> > From: "Hongsheng Chen" <hongsheng.chen@...>
> > To: "Brendan Macmillan" <Brendan.Macmillan@...>
> > Sent: Thursday, February 12, 2004 12:47 PM
> > Subject: RE: [JSX] evaluation expires prematurely
> >
> >
> > >
> > > Hi Brendan,
> > >
> > > I am facing some problems ... quite a lot of the xml files generated
>
> > > using JSX full package( both full and trial version) are having the
> > > "jsx" tag not closed, which renders the entire generated xml
> > > useless! Could you please have this fixed? We are thinking to buy
> > > this product for our next release but we just can not go if this bug
>
> > > is still there.
> > >
> > > Thanks,
> > > Hongsheng
> > >
> > >
> > > -----Original Message-----
> > > From: Brendan Macmillan
> > > [mailto:Brendan.Macmillan@...]
> > > Sent: Wednesday, February 04, 2004 5:13 PM
> > > To: Hongsheng Chen
> > > Subject: Re: [JSX] evaluation expires prematurely
> > >
> > >
> > > > 1. does this package handle inner classes well?
> > > Yes
> > >
> > > > 2. Is there an option to purchase source code as well? Just want
> > > > to know all the purchase options available.
> > > No
> > >
> > > > 3. Is there any way to confiure the log or does it actually log
> > > > any error/warning messages?
> > > There is no log.
> > >
> > > > I am trying to use it to migrate old serialized java objects saved
>
> > > > in db and then completely replace the jdk serialized objects
> > > (very
> > > > large object graph) with the JSX ones. It would be nice if I can
> > > > find out how well the migration works so I can write custom code
> > > > to handle special cases if necessary.
> > > >
> > > > I have not tried out the full package yet, but from the demo
> > > > package
> >
> > > > it seems to be twice as slow compared to the JDK serialization and
>
> > > > the resulted file is about 4 times as big. While it is reasonable
> > > to
> > > > expect it will be slower and bigger, is there any plan to improve
> > > > it?
> > > No.
> > >
> > > > If all goes well this solution will save us a lot of time and
> > > > money and I have been looking for similar approach for quite a
> > > > while.
> > > I
> > > > love this non-binding, non-intrusive feature. Don't worry about
> > > license,
> > > > although we may need to go through our legal department because it
> > > will
> > > > be an international purchase.  Do you have any US presence which
> > > > may
> >
> > > > make our life easier?
> > > No.
> > >
> > > Use the purchase page: www.jsx.org/buy/html
> > >
> > >
> > > Brendan
> > > >
> > > > --Hongsheng
> > > >
> > > > -----Original Message-----
> > > > From: Brendan Macmillan
> > > > [mailto:Brendan.Macmillan@...]
> > > > Sent: Wednesday, February 04, 2004 10:44 AM
> > > > To: JSX-ideas@yahoogroups.com
> > > > Subject: Re: [JSX] evaluation expires prematurely
> > > >
> > > >
> > > > Attached is the full JSX jar (which does not expire). This will
> > > > work in weblogic.
> > > >
> > > > The same license applies as from the website when you downloaded
> > > > the
> >
> > > > first one.
> > > >
> > > > You can only use it for evaluation, and you must stop using it
> > > > after 30 days. You can't copy distribute, etc etc etc.
> > > >
> > > > ----- Original Message -----
> > > > From: "Hongsheng Chen" <hchen@...>
> > > > To: <JSX-ideas@yahoogroups.com>
> > > > Sent: Wednesday, February 04, 2004 11:08 AM
> > > > Subject: [JSX] evaluation expires prematurely
> > > >
> > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I downloaded the JSX2.1.4.jar file last week to
> > > > evaluate this
> > > > > product in our enterprise ecommerce environment but I
> > > > got the
> > > > > following message from weblogic:
> > > > > "
> > > > > Thanks for evaluating JSX for 30 days.
> > > > > If you need more time, please contact company@...
> > > > (for work)
> > > > > or non-profit@... (for students, academics and
> > > > hobbiests)
> > > > > Buy JSX online at www.jsx.org/buy.html, or contact
> > > > sales@...
> > > > > "
> > > > > However it was ok when I tested it from outside of
> > > > weblogic
> > > > > (commandline). Is this the way it is or a bug? I need
> > > > to find out
> > > > > how this package performs under high volume stress in
> > > > the server
> > > > > side environment. Has anyone here tried out similar
> > > > approach? It is
> > > > > a great product and I just need some numbers to
> > > > convince my boss ...
> > > > >
> > > > > Thanks,
> > > > > Hongsheng
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Yahoo! Groups Links
> > > > >
> > > > > To visit your group on the web, go to:
> > > > > http://groups.yahoo.com/group/JSX-ideas/
> > > > >
> > > > > To unsubscribe from this group, send an email to:
> > > > > JSX-ideas-unsubscribe@yahoogroups.com
> > > > >
> > > > > Your use of Yahoo! Groups is subject to:
> > > > > http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > Yahoo! Groups Sponsor
> > > > ADVERTISEMENT
> > > > Click to learn more...
> > > >
> > > <http://rd.yahoo.com/SIG=12cqet9oi/M=243273.4510124.5685162.1261774/
> > > D=
> > > eg
> > > >
> > > roupweb/S=1706030390:HM/EXP=1075999263/A=1750744/R=0/*http://servedb
> > > y.
> > > ad
> > > > vertising.com/click/site=552006/bnum=1075912863193258>
> > > >
> > > >
> > > <http://us.adserver.yahoo.com/l?M=243273.4510124.5685162.1261774/D=e
> > > gr
> > > ou
> > > > pmail/S=:HM/A=1750744/rand=171621696>
> > > >
> > > >
> > > >   _____
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > > * To visit your group on the web, go to:
> > > > http://groups.yahoo.com/group/JSX-ideas/
> > > >
> > > > * To unsubscribe from this group, send an email
> > > > to:
> > > > JSX-ideas-unsubscribe@yahoogroups.com
> > > > <mailto:JSX-ideas-unsubscribe@yahoogroups.com?subject=Unsubscribe>
> > > >
> > > > * Your use of Yahoo! Groups is subject to the
> > > > Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
> > > >
> > > >
> > > >
> > >
> >
> >
>
>

> Well, typically when one adds a switch, the default behavior (without
> the switch) is to do the old behavior. Thus, to omit the close() call,
> they'd have to use a switch. This won't save any typing, and I'm not
> really a proponen of increasing complexity to save typing, so... I doubt
> it's worth doing.

I did say the default behaviour would be automatic close, otherwise you are
right it wouldn't make sense. This is what JSX used to
do, and users had much fewer problems with it than the present solution. The
only problems were for multiple-writeObject() - and
they were rare.

This would not affect most users expecting the old behaviour, because having a
manual close does no harm.

The only users affected would be those who use JSX with multiple writeObject()s.
It would break their code, by throwing an exception
which tells them how to fix it. This isn't so terrrible; but it's not 100% nice
either.

A clean solution would be a fresh project, that will not cope with multiple
writeObject()s. Much, much simpler.

I really dislike it in those rare cases when users are frustrated by JSX - the
ideal is for JSX to "just work", and the only way to
do this is to target a specific usage, and make JSX fit in with the expectations
of someone using it that way.

If you try to be too general, you end up serving too many masters, making for
complexity and awkward compromises (that turn out not
to cover all the cases anyway). We are not that smart to see all cases (unless
we do the mathematician's trick, of explicitly
restricting the domain, and spend a lot of time constructing proofs that
everything works in that domain).

Anyway, I just want to save the next Hongsheng the frustration he experienced.
That's very important to me.


Cheers,
Brendan

> > A solution:
> > How about I reintroduce automatic closing?  Make this switchable, so you can
> > turn it off if you want multiple objects. To help you,
> > JSX could detect subsequent writeObject() calls when automatic closing is
> > switched "on", and throw an Exception explaining how to
> > switch it off.
> >
> > Who would like this? Is it worth doing?
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>

This email is to inform you about the release of version '2.1.6' 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:
For convenience, the XML document is now closed  automatically even if
you forget to close the  ObjectWriter stream. This feature can be
switched off  with setAutoClose(false).

Project description:
Java Serialization to XML (JSX) allows you to write and read any Java
object graph as XML data with one line of code. You can verify your
data and manipulate it with standard XML tools like DOM, JDOM, and
XSLT. JSX automatically creates a file format/wire protocol for all
Java objects, so that it is always up to date as the code evolves.
When you need backward compatibility, JSX provides the evolution
techniques of Java Object Serialization, and you can also modify the
XML directly. Unlike databinders, such as JAXB and Castor, no
explicit mapping is required, and JSX works for all objects.

Trove categories:
[Development Status  ] 5 - Production/Stable
[Environment         ] Console (Text Based), MacOS X, Other Environment,
Web Environment, Win32 (MS Windows)
[Intended Audience   ] Developers
[License             ] OSI Approved :: GNU General Public License (GPL),
Other/Proprietary License with Free Trial
[Programming Language] Java
[Topic               ] Communications, Database, Software Development,
Software Development :: Libraries, Software Development :: Libraries ::
Java Libraries, Software Development :: Object Brokering, System ::
Archiving, System :: Recovery Tools, Text Processing :: Markup :: XML

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 and
categories you're subscribed to in the right column, which you may cancel
by highlighting the project or category in question and clicking the
'delete' button.

Sincerely,
freshmeat.net

____________________________| Advertising |____________________________
Access 2,000 tech books online from Addison-Wesley, O'Reilly and more!

With Safari Bookshelf on OSDN developers can search, read, and download
chapters from a virtual library featuring thousands of best-selling
books.
Try it FREE now.

Visit  http://osdn.safaribooksonline.com/?g=osdnfm
____________________________| Advertising |____________________________

Hi Bent,

I think Xrayrivet might suit your needs better. It is based on the JSX
engine, but does not alias Strings. The XML is also much simpler. I would
appreciate if you would try it out, and tell me what problems you have. I
can then iterate quickly, to make it work for you. How does that sound?
http://www.jsx.org/xrayrivet/xrayrivet.html

It does not mention your usage, but it sounds like a good match.

Warning: It is *very* alpha, but it's easy for me to improve it quickly
because the completeness of JSX is right there under the hood. It's more a
question of what to do first.


JSX:
You are right that Strings can't form circular references, but there can be
multiple references to the same String (as you saw). JSX needs to work this
way to be correct for serialization: Strings are aliased so that == works
correctly if there are multiple references to the same String.

BTW: here's how to tell if references are circular: keep a stack of the
objects above you (from root to the current node). A reference is circular
if and only if it refers to an object in that stack.

But I'm more interested in making useful products; and I think your usage of
JSX is a popular one.


Cheers,
Brendan

> Hello,
>
> I have tried out JSX2 and found the following minor annoyance. While I
> realize that it works like this because of issues caused by circular
> data structures (and for all I know, perhaps JOS _requires_ it to be
> like this), I still wanted to mention it.
>
> If I serialize an object graph that has a number of empty strings in
> it, then the first string will be serialized with its value and the
> rest will just idref it. This proves inconvenient when I later want to
> edit the XML files and input real strings. In particular, if I want to
> edit the one string that everyone else is referencing, I have to
> remember to move the reference string to somewhere else or all other
> strings will also have changed.
>
> It would have been much more edit-friendly if all strings were always
> serialized with their full values regardless of whether or not other
> strings in the object graph happen to have the same value.
>
> While the same argumentation holds for all other data types as well, I
> imagine it is non-trivial to determine if any given object would cause
> a loop. Strings, however, are guaranteed not to cause loops since they
> don't actually refer to other objects and they can't be subclassed to
> do so either.
>
> Again, I'm not sure if this approach would break other aspects of
> serialization. That's for you to know and for me to speculate over :-)
>
> Cheers
> Bent D
> --
> Bent Dalager - bcd@... - http://www.pvv.org/~bcd
>                                     powered by emacs
>

Hi Bent,

Note: I've cc'ed this to the list, because I think others may be interested.

> > I think Xrayrivet might suit your needs better. It is based on the JSX
> > engine, but does not alias Strings. The XML is also much simpler. I
would
> > appreciate if you would try it out, and tell me what problems you have.
I
> > can then iterate quickly, to make it work for you. How does that sound?
> > http://www.jsx.org/xrayrivet/xrayrivet.html
>
> I gave it a quick test run and found that I need more mappings than
> what it currently has. Specifically, it failed on primitives.

It should work on primitives (unless within an array - it doens't handle
arrays at the moment).

> I am using JSX as a component in a development tool we're using
> internally, in which we work with moderately complex data structures
> (they're basically deeply nested structures generated from IDL struct
> declarations). As it is, it will at least need to support primitives,
> nested objects and nested arrays for it to be of any immediate use. I
> don't think our already pressed developers will have much patience
> with xrayrivet if it proves to have a lot of problems. (I'd say that
> we could try it out in a quiet period, but there aren't any :-)

It doesn't support arrays at the moment.
Primitives should be OK - less of course, they are within an array :-)
Nested objects should be OK, as well as primitive values.

I need to ask: do you have *any* cyclic or multiple references (apart from
the Strings), that you need preserved?

The goal of the project is to be able to map any Java object graph to any
XML document, and
most XML documents don't provide a way to represent such references, and
introducing some mechanism (such as JSX's approach) would be an error in
terms of the XML document.

Arrays present two more problems for this goal:
(1). Arrays have a runtime length - but this can't always be recorded
explicitly, because many XML documents don't have an explicit length for
lists. In general, you also can't solve this by storing the lenght in a
separate mapping (or binding) document, because it can vary at runtime. The
"obvious" solution is to record the runtime length implicitly, in terms of
the components of the array. Just count them.

It's a little bit of work to implement this, because you have to do it for
each primitive type separately(mostly cut and paste tho, simulating
generics).

(2). Null values are needed by arrays of objects (for example, as <null/>) -
but many XML documents don't use a null element. The truth is, to map to
such a document, any null values found in the objects would be an error,
because there is nothing to map them to. Unfortunately, arrays of objects
quite commonly have an unused portion, of trailing nulls.

Of course, these considerations don't apply to your case, because you aren't
mapping to a target XML document. You just want to be able to enter Strings
by hand (IIUC)


> If, on the other hand, there is hope for getting it up to speed
> relatively easily, it is a somewhat more promising proposition. I am
> sure they _will_ appreciate the ease-of-edit they might be getting
> once it's ready for prime time. I've just finished a basic GUI-based
> editor for these data structures, though, and if they fall in love
> with that (I can only hope :-), they might not see the benefit of
> xrayrivet.
>
> I would personally like to have the "just use emacs" fallback though,
> so I'll try to pitch it to them and see what they say. An
> easier-to-edit XML format would very handy after all.
>
> How will licensing work for xrayrivet?

I'm not sure about this at the moment, but it would probably be the same as
for JSX.


> > It does not mention your usage, but it sounds like a good match.
> >
> > Warning: It is *very* alpha, but it's easy for me to improve it quickly
> > because the completeness of JSX is right there under the hood. It's more
a
> > question of what to do first.
>
> Is it "just" a question of writing the XSL scripts for it?

No - there is a declarative mapping that you write once, and which is used
for mapping in both directions (with XSL, you'd have to write two scripts).
Plus, the mapping is specifically for Java and XML, so it is much simpler
for this specific task. It's "XML databinding".

> Using XSL
> to morph JSX's output _does_ immediately strike me as a good idea, but
> I am somewhat wary of the complexity that might be involved in the XSL
> scripts. How readable do they become?

You can do it, but they aren't very readable. It depends on what you need to
do. There are example scripts in the JSX manual (towards the end) for
evolving classes; and other example for XML databinding on the front page
(www.jsx.org). You can get some kind of a sense of the complexity.

> > JSX:
> > You are right that Strings can't form circular references, but there can
be
> > multiple references to the same String (as you saw). JSX needs to work
this
> > way to be correct for serialization: Strings are aliased so that ==
works
> > correctly if there are multiple references to the same String.
>
> I can see that you don't want the serialize->deserialize cycle to
> break the == operator. Many data structures may rely on it after
> all. Reading between the lines (and extrapolating a bit), I am
> guesssing that I may get a long way if I put new String("") into my
> data structures rather than just "" ... I take it the refids only get
> inserted if string1==string2 and not necessarily if
> string1.equals(string2) ? (I build default instances of the IDL
> structs myself using reflection, so I control what initially goes into
> them.)

Yes. I almost sent you a follow up last night, suggesting that; I'm glad my
explanation was clear enough for you to be able to put it to use right away.
:-)

> I suppose I should just try it and see what happens :-)


Bottom line:  if you do fit within the target goal above, then I estimate
1-2 weeks maximum until it's ready to go. But if you need some references
(cyclic or multiple), then it's a conflict with the above goal, and much as
I regret it, I can't do it as part of this particular project.

So, let me know. :-)


Cheers,
Brendan

Hi Bent,

I'll reply to your other comments in a separate email.

> > Perhaps a low-risk way for you to proceed is for neither of us to commit
to
> > anything? If I implement something that you need, you could check it
(which
> > I think is pretty quick?), iterating around this loop until it does what
you
> > want.
>
> Yes, this seems quite doable.

Cool.

> > Questions:
> > 1. Why do you have arrays instead of collections? (are they of
primitives?)
>
> I have a number of IDL files defining structs containing, among other
> things, IDL sequences. These get converted into Java classes by an
> IDL-to-Java compiler that we have no control over. The end result uses
> arrays and not collections to represent sequences (this may be
> required by the CORBA-to-Java mapping specification for all I know). I
> cannot change these classes. It is these IDL-originated structures
> that we want to edit in order to build arbitrary CORBA objects to send
> across the network for testing purposes.
>
> The arrays we use can hold primitives and they can hold objects.
>
> The primary reason I am using JSX in the first place is that the IDL
> compiler doesn't support making the generated classes Serializable and
> since I can't change the resulting code myself (well, I could, but it
> would be a nightmare) I needed something that could serialize any old
> object.

Interesting, thanks for the background!

JSX is non-intrusive, which is a great strength when you have to (or prefer
to) not change existing code.

> As we discussed previously, I believe that I can relax that particular
> requirement to "any old object with a non-cyclic member hierarchy".
>
> As a matter of interest, if you _do_ pass a cyclic hierarchy to
> xrayrivet, how will it react? Will it identify the problem and throw
> an exception?

Hmm... it is driven by JSX internally, so that these would be passed as
references. At the moment, xrayrivet just ignores references, but for a
final implementation, it should thrown an exception (which would be
switchable on/off). IOW, this is polish, which is easy to deal with later.


> > 2. Do you have nulls in your object arrays? (even trailing)?
>
> There certainly can be. While our CORBA implementation doesn't support
> sending null values, there can be null values in the structures while
> the developer is building them and he might very well decide he wants
> to save such an unfinished structure to file to continue work on it
> later.

Just to be 100% clear pedantic (because it makes a big difference later): in
structures, yes; but would there be nulls in *arrays*?

> Now, truth be told, I am somewhat ambivalent about letting the
> developer put nulls into the structures since it would be a mistake to
> have them there when trying to send the object over CORBA (and that is
> the whole point after all). While we may decide to remove this
> possibility in the future (after the developers have some experience
> with using the tool), it will likely stay in for at least several
> weeks.

So you only need it for development. OK - we'll see how this goes.


Additional Requirements Summary:
- arrays of primitives
- arrays of Objects
- structs with nulls in them
- arrays of Objects, with nulls in them (?)


Cheers,
Brendan

Hi Bent,

> > BTW: The microsoft C# guy criticises Java's generics for being
> > inefficient in this way IIRC, but probably in many cases it just
> > doesn't matter. I mean, if you really want efficiency, use C. But
> > computers are just absurdly fast these days, so it usually makes
> > no discernable difference.
>
> I expect he's criticising the implicit casting that goes on in Java
> generics. In theory, casting is expensive, but I'm not convinced that
> this is the case in a single-inheritance system such as Java. Checking
> the correctness of a cast in Java should really be quite cheap if
> you're clever about it.

It's from the Artima article, he mentions casting, and also that the
inefficientcy of autoboxing:

# Anders Hejlsberg:
# For example, with Java generics, you don't actually get any of
# the execution efficiency that I talked about, because when you
# compile a generic class in Java, the compiler takes away the
# type parameter and substitutes Object everywhere. So the
# compiled image for List<T> is like a List where you use
# the type Object everywhere. Of course, if you now try
# to make a List<int>, you get boxing of all the ints.
# So there's a bunch of overhead there.
http://www.artima.com/intv/generics2.html


> Anyway, as you say, one really has to measure to find out for sure if
> it's an issue for any particular application. In your case, just
> copying the algorithm multiple times is probably a more effecient
> approach than profiling both solutions and then choosing one :-)

:-) Yes, I think so. I kind of like the possibility of discovering I'm
wrong, when I do profile it in future.


> > JSX and xrayrivet would be sold as separate products, so if you wanted
both,
> > you would need two licenses. If you only wanted JSX or xrayrivet, then
it
> > would be one license.
>
> As a practical issue, if you have xrayrivet won't you also effectively
> have JSX bundled with it? How would you prevent xrayrivet users from
> calling the JSX API directly? Does Java offer a solution for this in
> its security mechanisms (I don't think so, but am not entirely up to
> date on JAR features) or would you make a custom JSX (with everything
> having package scope in stead of public, for instance) for bundling
> that was effectively uncallable from the outside?

I had the idea of a making a single hidden version of JSX, that was
common to both, and having an extra wrapper class for JSX, with
public methods, that would only be present in the "JSX" jar.
This makes it easy to control at configuration time in ant. But it
does add an extra layer of complexity. Now that you raise it,
I think a runtime check is simpler and efficient (it's only checked
once per object graph). But I haven't given it much thought yet.

Thanks very much for thinking on this! :-)

hehehe I estimate that open source, without any worry at all
about security and business-related issues, is at least three
times easier than commercial software. If you aren't making
a reusable component, then it is three times easier again. And if
you forget ease of use, then it's yet another three times easier
(as esr claims often is the case). By this reckoning, such an
open source is 27 times easier than commercial software.


Cheers,
Brendan

This email is to inform you about the release of version '2.1.7' 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:
A minor bug that duplicated the final close tag was  fixed.

Project description:
Java Serialization to XML (JSX) allows you to write and read any Java
object graph as XML data with one line of code. You can verify your
data and manipulate it with standard XML tools like DOM, JDOM, and
XSLT. JSX automatically creates a file format/wire protocol for all
Java objects, so that it is always up to date as the code evolves.
When you need backward compatibility, JSX provides the evolution
techniques of Java Object Serialization, and you can also modify the
XML directly. Unlike databinders, such as JAXB and Castor, no
explicit mapping is required, and JSX works for all objects.

Trove categories:
[Development Status  ] 5 - Production/Stable
[Environment         ] Console (Text Based), MacOS X, Other Environment,
Web Environment, Win32 (MS Windows)
[Intended Audience   ] Developers
[License             ] OSI Approved :: GNU General Public License (GPL),
Other/Proprietary License with Free Trial
[Programming Language] Java
[Topic               ] Communications, Database, Software Development,
Software Development :: Libraries, Software Development :: Libraries ::
Java Libraries, Software Development :: Object Brokering, System ::
Archiving, System :: Recovery Tools, Text Processing :: Markup :: XML

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 and
categories you're subscribed to in the right column, which you may cancel
by highlighting the project or category in question and clicking the
'delete' button.

Sincerely,
freshmeat.net

Enter your vote today!  A new poll has been created for the
JSX-ideas group:

How likely is it that you would
recommend JSX to a friend or colleague?
(on a scale of 1-10)

   o 1 not at all likely
   o 2
   o 3
   o 4
   o 5 neutral
   o 6
   o 7
   o 8
   o 9
   o 10 extremely likely


To vote, please visit the following web page:

http://groups.yahoo.com/group/JSX-ideas/surveys?id=1185488

Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the Yahoo! Groups
web site listed above.

Thanks!

Enter your vote today!  A new poll has been created for the
JSX-ideas group:

How do you use JSX?

   o Non-intrusive XML databinding
   o Upgrading persisted data (evolution)
   o Human-readable data (so you can see the object)
   o Distributing data over the network
   o Persistence (nested/recursive; and the not “Serializable”)
   o --other-- email us and we'll include it!   jsx@...


To vote, please visit the following web page:

http://groups.yahoo.com/group/JSX-ideas/surveys?id=1185490

Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the Yahoo! Groups
web site listed above.

Thanks!

o 5 neutral

On Tue, 09 Mar 2004 JSX-ideas@yahoogroups.com wrote :
>
>Enter your vote today!  A new poll has been created for the
>JSX-ideas group:
>
>How likely is it that you would
>recommend JSX to a friend or colleague?
>(on a scale of 1-10)
>
>  o 1 not at all likely
>  o 2
>  o 3
>  o 4
>  o 5 neutral
>  o 6
>  o 7
>  o 8
>  o 9
>  o 10 extremely likely
>
>
>To vote, please visit the following web page:
>
>http://groups.yahoo.com/group/JSX-ideas/surveys?id=1185488
>
>Note: Please do not reply to this message. Poll votes are
>not collected via email. To vote, you must go to the Yahoo! Groups
>web site listed above.
>
>Thanks!
>
>
>
>
>
>
>
>------------------------ Yahoo! Groups Sponsor ---------------------~-->
>Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
>Printer at MyInks.com. Free s/h on orders $50 or more to the US & Canada.
>http://www.c1tracking.com/l.asp?cid=5511
>http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/2U_rlB/TM
>---------------------------------------------------------------------~->
>
>
>Yahoo! Groups Links
>
><*> To visit your group on the web, go to:
>      http://groups.yahoo.com/group/JSX-ideas/
>
><*> To unsubscribe from this group, send an email to:
>      JSX-ideas-unsubscribe@yahoogroups.com
>
><*> Your use of Yahoo! Groups is subject to:
>      http://docs.yahoo.com/info/terms/
>
>

Hi Ramar,

Thanks for your vote, but the idea is to go to the URL mentioned, and vote
by clicking on one of the boxes there. As the email says:

To vote, please visit the following web page:
http://groups.yahoo.com/group/JSX-ideas/surveys?id=1185488


many thanks,
Brendan
----- Original Message -----
From: "sridharan sri ramar" <shreedhar_13@...>
To: <JSX-ideas@yahoogroups.com>
Sent: Wednesday, March 10, 2004 3:33 AM
Subject: Re: [JSX] New poll for JSX-ideas


>
> o 5 neutral
>
> On Tue, 09 Mar 2004 JSX-ideas@yahoogroups.com wrote :
> >
> >Enter your vote today!  A new poll has been created for the
> >JSX-ideas group:
> >
> >How likely is it that you would
> >recommend JSX to a friend or colleague?
> >(on a scale of 1-10)
> >
> >   o 1 not at all likely
> >   o 2
> >   o 3
> >   o 4
> >   o 5 neutral
> >   o 6
> >   o 7
> >   o 8
> >   o 9
> >   o 10 extremely likely
> >
> >
> >To vote, please visit the following web page:
> >
> >http://groups.yahoo.com/group/JSX-ideas/surveys?id=1185488
> >
> >Note: Please do not reply to this message. Poll votes are
> >not collected via email. To vote, you must go to the Yahoo! Groups
> >web site listed above.
> >
> >Thanks!
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
> >
>
>
>
>
> Ramar Sridharan
> shreedhar_13@...
> sneha_1999@...
> 491797773747
>

There has been a great deal of demand for JSX, from students who
simply can't afford JSX, and find that 30 days isn't enough to
complete a project.

To help solve this, we are trying out an "academic version" of JSX,
that does not expire after 30 days, and which is only available to
students (and academics):
       www.jsx.org/academic

This version is free (as in beer/no charge) - but you may only use it
for academic purposes, and you may not distribute it. (If friends or
colleagues are interested, tell them they can get their own, from the
website: www.jsx.org).

I would much appreciate feedback on this - whether it helps or not,
any problems you have with it, or with the idea of it.


Here's the URL again:
    www.jsx.org/academic


Please be warned: it's slow to respond at the moment.  It's a PHP
script, but they are not usually that slow... I think our hoster may
be running extra slowly at the moment for some reason.  Anyway,
please don't give up, just because it seems too slow :-)


Cheers,
Brendan

This email is to inform you about the release of version '2.1.8' 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 JSX comment at the start of the XML is now much  shorter and less
intrusive, and a free academic  version is now available.

Project description:
Java Serialization to XML (JSX) allows you to write and read any Java
object graph as XML data with one line of code. You can verify your
data and manipulate it with standard XML tools like DOM, JDOM, and
XSLT. JSX automatically creates a file format/wire protocol for all
Java objects, so that it is always up to date as the code evolves.
When you need backward compatibility, JSX provides the evolution
techniques of Java Object Serialization, and you can also modify the
XML directly. Unlike databinders, such as JAXB and Castor, no
explicit mapping is required, and JSX works for all objects.

Trove categories:
[Development Status  ] 5 - Production/Stable
[Environment         ] Console (Text Based), MacOS X, Other Environment,
Web Environment, Win32 (MS Windows)
[Intended Audience   ] Developers
[License             ] Free For Educational Use, Other/Proprietary License
with Free Trial
[Programming Language] Java
[Topic               ] Communications, Database, Software Development,
Software Development :: Libraries, Software Development :: Libraries ::
Java Libraries, Software Development :: Object Brokering, System ::
Archiving, System :: Recovery Tools, Text Processing :: Markup :: XML

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 and
categories you're subscribed to in the right column, which you may cancel
by highlighting the project or category in question and clicking the
'delete' button.

Sincerely,
freshmeat.net

Hello,
I've been using a trial version of JSX, as part of an IT project here
in Paris.
First thought: great! It does many things that other tools like
skaringa were not able to do.
Then, we changed most of our objects to Externalizable to speed up
serialization. The XML we got was completely different: one big ugly
byte array. Suprising, but logical: since we broke down the whole
serialization all the way to the native type.

Hence, my suggestion: provide a way to ignore Externalizable,
in the constructors for example:
ObjectWriter out = new ObjectWriter(false);
ObjectReader in = new ObjectReader(false);

This is critical to us: we cannot use JSX as is. If you provide us
with a fix to this, we'll use JSX and buy a site (maybe enterprise if
I convince my boss) distribution license.

Thanks.

Hi Nicolas,

I'm assuming that you are also using JOS, or else there'd be no point in
implementing Externalizable, since you don't want it for JSX?

To ensure I understand: you want
     - JOS to use Externalizable, but
     - JSX to not use it?

I'm reluctant to add in non-standard features like this (even if a useful
hack), because simplicity is a very important value behind the project. I
don't want to clutter up the API - that happened with a previous version of
JSX.

I could do a one-off hack for you, which would solve your specific problem,
while avoiding my API concern.

How does that sound?


Cheers,
Brendan
----- Original Message -----
From: "nicolascorreard" <nicolas_correard@...>
To: <JSX-ideas@yahoogroups.com>
Sent: Tuesday, March 16, 2004 8:52 PM
Subject: [JSX] why always rely on Externalizable


> Hello,
> I've been using a trial version of JSX, as part of an IT project here
> in Paris.
> First thought: great! It does many things that other tools like
> skaringa were not able to do.
> Then, we changed most of our objects to Externalizable to speed up
> serialization. The XML we got was completely different: one big ugly
> byte array. Suprising, but logical: since we broke down the whole
> serialization all the way to the native type.
>
> Hence, my suggestion: provide a way to ignore Externalizable,
> in the constructors for example:
> ObjectWriter out = new ObjectWriter(false);
> ObjectReader in = new ObjectReader(false);
>
> This is critical to us: we cannot use JSX as is. If you provide us
> with a fix to this, we'll use JSX and buy a site (maybe enterprise if
> I convince my boss) distribution license.
>
> Thanks.
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>