Hi Thomas,
Some good questions.
I think Thomas Gentsch wrote:
>
> Hello Jessies,
>
> I played with the Jess bsave/bload functions and have a few
> questions/remarks:
>
> 1. a short note in the Jess function list documentation might be helpful
> that the user needs
> to declare the java.io.Serializable interface for all involved Java
> beans (would have saved
> me some time finding out myself :~)
OK, makes sense. This -is- in the JavaBeans spec, but I suppose not
everyone reads that document cover to cover before beginning to work
with Jess :)
>
> 2. I was a little disappointed about the performance - possibly this is
> due to the
> compression/decompression phase (?). If so, would it be possible to
> add a way to
> control this (may be a flag like (bsave <file> <boolean do-compress>)
> or so?
No, it's not the compression, it's the serialization itself. Java
serialization is just a dog. It's possible to improve performance by
doing some of the work explicitly using java.io.Externalizable, but I
haven't gotten around to that yet.
>
> 3. After bloading the result I get errors I don't get when loading Jess
> files normally.
> They complain about non-overloadable methods blah blah.
> My suspicion is that this is because my Java beans have for many
> properties multiple set()
> methods (declared in BeanInfo files). Works fine normally.
> Example:
> class bla {
> int x = 0;
> void setX(int v) { x = v; }
> void setX(String v) { ... }
> int getX() { return x; }
> }
> Looks as if the alternate set() methods are lost ... is that possible
> (rather a Java
> question, but maybe somebody knows)?
>
Hmmm. It's possible that the defclass templates may be reconstructed
incorrectly after deserialization under these
circumstances. java.lang.reflect.Method objects aren't serializable,
so jess has to just save the method name and try to reconstruct the
Method object on deserialization, and these multiple methods with the
same name will clearly interfere. Although I think the existence of
these multiple methods is counter to the spirit of the JavaBeans spec,
I don't think it's explicitly illegal, so Jess should try to handle
them on deserialization. Apparently the java.beans.Introspector class
is dealing with them OK. I will look into this.
> 4. Since this uses some kind of standard Java serialization - is the
> result portable across
> different hardware/OS?
Yes, but not necessarily portable across 1) different JVM versions, or
2) different Jess versions.
>
> Thanks a lot,
> tge
>
> Thomas Gentsch
>
> ---------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> in the BODY of a message to [EMAIL PROTECTED], NOT to the
> list (use your own address!) List problems? Notify [EMAIL PROTECTED]
> ---------------------------------------------------------------------
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
