I haven't been able to get any info about Allegro's new java intervace
to lisp.
any info? any idea how it compares to Nichael Cramer's LIJOS code?
--
please reply direct to <a ··················@bbn.com">Clint Hyde</a>
I don't have enough time to scan everything I'd like to, and don't
want to miss your answers...
-- clint
Clinton Hyde <·····@bbn.com> writes:
> I haven't been able to get any info about Allegro's new java
> intervace to lisp.
>
> any info? any idea how it compares to Nichael Cramer's LIJOS code?
I'm not even so sure I understand all the ways that this can be
useful and simple to use. I'll have to see it before I can
conceptualize it.
For example, some of the features that Java exlusively has are:
o RMI
o Java-style serialization
o massive class libraries
o Java's own class/method/interface and inheritance system
and a lot more, I'm sure. But CL does not share these features in a
way that seems easy to have them inter-operate. If two systems really
needed to make funcalls on one another, then I'd say "use Corba"
(yuck) since at least several CL implementations support it. If two
systems needed to share data, then I'd say use a relational database.
I can't see how the CLOS overlaps with Java's object model. Not in
any way, shape or form. There'd probably have to be some sort of
JCLOS system, or hopefully MOP extension to make Java-style classes
and interfaces. What's the gain there?
I think the gain would be to somehow be able to use the JVM and
compiled class libraries. If Common Lisp could directly instantiate
Java objects and then invoke methods, and (best of all) share data
between the Lisp applications and Java, that would be a huge win,
since CL is lacking (IMHO) in things like class libraries that Java is
full of (like sound support, lots of imaging, GUI stuff, networking).
How would this work? Could a CL application dump out Java bytecode?
How transparent would this programming layer be? Probably a lot less
than say Franz's AllegroStore or Xanalys's CommonSQL stuff.
dave
David Bakhash <·····@alum.mit.edu> writes:
> I'm not even so sure I understand all the ways that this can be
> useful and simple to use. I'll have to see it before I can
> conceptualize it.
In our web application toolkit IMHO, we have a thin java serialization
layer which we use to communicate with an applet interface component.
The simple RPC protocol consists of calling methods on our Transponder
class, which packages them up as HTTP requests to the server's
transponder element. The results are than serialized into Java
objects and sent back to the applet.
I say "thin" because it's not automatic by any means. Java
serialization is a little fragile and kind of a pain to deal with. We
manually maintain the mappings of Lisp classes into Java classes.
Serialization of all the primitve lisp types is handled for us. You
can grab IMHO from cvs and check it out.
We actually have application which depends heavily upon this
communications channel.
> and a lot more, I'm sure. But CL does not share these features in a
> way that seems easy to have them inter-operate. If two systems really
> needed to make funcalls on one another, then I'd say "use Corba"
> (yuck) since at least several CL implementations support it. If two
> systems needed to share data, then I'd say use a relational database.
Corba is big and fugin ugly, which is why we avoided it in our
situation, which did not require very complex interaction between the
client applet and the lisp server.
--
Craig Brozefsky <·····@red-bean.com>
Lisp Web Dev List http://www.red-bean.com/lispweb
--- The only good lisper is a coding lisper. ---
David Bakhash wrote:
> Clinton Hyde <·····@bbn.com> writes:
>
> > I haven't been able to get any info about Allegro's new java interface
> to lisp.
> >
> > any info? any idea how it compares to Nichael Cramer's LIJOS code?
>
> I'm not even so sure I understand all the ways that this can be
> useful and simple to use. I'll have to see it before I can
> conceptualize it.
>
> For example, some of the features that Java exlusively has are:
>
> o RMI
>
huh? exclusive?
> o Java-style serialization
>
piece o' cake to do in lisp, I've done it to files, someone else wrote
slightly more complete version of same behavior and it was in the CMU CL
library (can't believe I forgot who that was, we both worked at ADS in
that timeframe, early 90s)
> o massive class libraries
>
true. sad, but true. why doesn't CL? it's not like we have any less need
for the same kinds of behaviors...
> o Java's own class/method/interface and inheritance system
>
which is screwy. this "interface" stuff bites royalty. and
single-inheritance: feh! who thinks that's the answer? most of the time
that's fine, but when it isn't, you are in trouble.
>
> and a lot more, I'm sure. But CL does not share these features in a
> way that seems easy to have them inter-operate. If two systems really
> needed to make funcalls on one another, then I'd say "use Corba"
> (yuck) since at least several CL implementations support it. If two
> systems needed to share data, then I'd say use a relational database.
>
we've done the CORBA interface. not pleasant, and ACL-CORBA is *quite*
expensive. simpler to make a private L-J interface and let Java talk CORBA
than to pay the $ for ACL to do it. better to have a clean L<->J
interface...
>
> I can't see how the CLOS overlaps with Java's object model. Not in
> any way, shape or form. There'd probably have to be some sort of
> JCLOS system, or hopefully MOP extension to make Java-style classes
> and interfaces. What's the gain there?
>
depends on what you want to do: Nichael's LIJOS code is serialized
objects, both directions. most of the time that is all I would want. maybe
if I had an RMI mechanism into java, I'd prefer that. at the moment, I
think I want the objects in my own hands. I really don't like the
time-delays associated with lotsa little calls over the net--and my boss
has little tolerance for things being slow.
so the gain is access to Java behaviors that already exist, like JINI. or
SWING. these are the two things I want access to *right now*. I have
~10kloc of JAVA Swing GUI code that is a replacement for the CLIM gui I've
been working the last 3 years. at the moment, because this is a gov't
project, now being aimed at delivery into a mil planning setting, the
whole thing could end up dead because DISA ain't interested in taking on
any Lisp code. so if I replace the gui with Java, that may solve part/most
of the problem--but it's is an awkward interface: right now it's a private
protocol, occasionally breaks; I'd rather push objects over, or XML.
> I think the gain would be to somehow be able to use the JVM and
> compiled class libraries. If Common Lisp could directly instantiate
> Java objects and then invoke methods, and (best of all) share data
> between the Lisp applications and Java, that would be a huge win,
> since CL is lacking (IMHO) in things like class libraries that Java is
> full of (like sound support, lots of imaging, GUI stuff, networking).
>
yeah--why is this? it's not like these aren't solved problems by
now...that relates to my other big Q: what about all that JINI networking
stuff? why haven't we done these things in CL by now? I could use that
stuff today.
>
> How would this work? Could a CL application dump out Java bytecode?
> How transparent would this programming layer be? Probably a lot less
> than say Franz's AllegroStore or Xanalys's CommonSQL stuff.
>
> dave
in any case, this isn't answering the Q I posed--no one seems to have any
info about Allegro J<->L interface, including Franz. I have a nearly
meaningless answer from them about what this is supposed to be...
-- clint
Rahul Jain <············@rice.edu> writes:
> In article <·················@bbn.com> posted on Tuesday, August 29, 2000 9:02 AM, Clinton Hyde <·····@bbn.com> wrote:
> > David Bakhash wrote:
> >
> >> Clinton Hyde <·····@bbn.com> writes:
> >
> >> o massive class libraries
> >>
> >
> > true. sad, but true. why doesn't CL? it's not like we have any less need
> > for the same kinds of behaviors...
>
> Not true and not sad :)
> The CL "class library" is the implementation itself. Most of the Java
> classes are just trying to create the same types of behaviors that are part
> of the CL spec.
What about all the graphics stuff? The 3D libraries? The Swing
stuff? What about threads? and networking? And RMI/Corba? There's
a lot there. I think a lot of it does try to do what Common Lisp does
too, like the Reflection classes.
Of course, some of these things are present in some implementations of
Common Lisp, they vary a lot.
I'd like to see these Java mixins happen, but I have this funny
feeling that it'll be too expensive to use.
dave