This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Suggested changes to Kawa


Gerardo Horvilleur wrote:

1. If you serialize a Kawa list then you can't read it back into memory
again.
There are two cases:

a) If you serialize a gnu.lists.PairWithPosition then you can't
deserialize it again because it doesn't have an empty constructor.
Adding the empty constructor to PairWithPosition solves the problem.

Done and checked into CVS.


b) If you serialize a list then when you deserialize it you always get
an empty list. To fix this I changed the readResolve() method in
gnu.lists.LList from this:
-----------------------------------------------------------
public Object readResolve() throws ObjectStreamException
  {
          return Empty;
  }
-----------------------------------------------------------

to this:

--------------------------------------------------------
public Object readResolve() throws ObjectStreamException
  {
      if (size() == 0)
          return Empty;
      else
          return this;
  }

I instead added an implementation in Pair.java.


2. If you compile a Kawa source as a servlet it doesn't handle a HTTP
POST requests.
To fix this I just added this method to gnu.kawa.servlet.KawaServlet:

    public void doPost(HttpServletRequest request, HttpServletResponse
response)
        throws ServletException, IOException {
        doGet(request, response);
    }

Thanks. I added this.


3. When you serialize a Kawa symbol (which is just an interned
java.lang.String) and then deserialize it, the deserialized symbol is
not interned. This means you can't use eq? to compare deserialized
symbols. I don't have a fix for this yet...

I think this is a bug in JDK - serializing an interned String should result in an interned String.


This is one argument for using gnu.mapping.Symbol to represent
Scheme symbols, like we already do for ELisp and Common Lisp
and QNames for XQuery and XSLT.  But it would be rather a radical
and incompatible change to Kawa, so I think we would need stronger
reasons before changing.  (Better ELisp ELisp compatibility is one
more reason.)
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]