Hi

Assuming interoperability with Java is your top concern (and not with
existing Smalltalk code):
Wait for Java 1.7:
http://blogs.sun.com/jrose/entry/notes_on_an_architecture_for
Use a MOP instead of wrappers/proxies:
http://dynalang.sourceforge.net/

Compromise, use Java where you can. E.g. use ArrayList and HashMap
instead of OrderedCollection and Dictionary.

Cheers
Philippe

2008/2/6, Paul D. Fernhout <pdfernhout at kurtz-fernhout.com>:
> Wow, Athena looks cool! I'd tried to leverage SmallWorld but not got past
> the image being binary. I had wanted completely to build from source.
>
> If Athena and Spoon and Dan's project and a few other projects and people
> could get together somehow, then we might have something even greater, and
> not several people working mostly on their own. But coming up with a shared
> vision might be hard?
>
> Here are some ideas for Java<-->Smalltalk interoperability. Not necessarily
> stuff you might want to do with Athena (for memory reasons), but I put it
> here for future reference (including a possible future reply to Dan). This
> is just a sketch, and assumes an ideal of ignoring memory use for ease of
> implementation, debugging, and minimizing complexity.
>
> Here is an idea for using native Java/JVM objects for Smalltalk objects
> instead of implementing them on top of the JVM as bytes. Smalltalk method
> dispatching would be handled specially (above Java) but the instances
> themselves would be Java objects and use the Java garbage collector.
>
> Have a Java class "SmalltalkProxy" which supports one method like
> "processMessage". That function takes an argument of a
> "SmalltalkMessageAndStackFrame" which essentially stores the information in
> a message and then, if the message is processed, some stack information.
> This SmalltalkProxy class has only two fields -- the proxied Java/JVM
> "Object" and a boolean "became" flag.
>
> The "processMessage" function is essentially an elaboration of the code I
> posted at the beginning of this thread. It knows how to look at the proxy
> and decide how to send the message to it. There are at least three
> dispatching cases for a message. If the proxied object is a plain Java
> object, a function gets called if one matches the message pattern. If the
> Java object has a "processMessage" method, it gets called. If the object is
> a Java/JVM class "SmalltalkInstance" class instance, then Smalltalk-ish
> dispatching happens, and the message can also be used as a stack frame item.
> (This merging messages and stack frames is a departure from typical
> implementations and implies a big performance hit.)
>
> For design simplicity and run-time extensibility, that "SmalltalkInstance"
> class might have a few fields even if they were not usually all used. They
> might be:
> * class (usually a reference to another "SmalltalkInstance")
> * dictionary of instance variables (not an array since I don't want to
> bother for recompiles in keeping things up to date, and for debugging we can
> have symbols as selectors not indexes)
> * dictionary of locally overridden methods (for prototype support)
> * array of Java/JVM objects
> * array of binary data
>
> Obviously, that expanded structure might be what is tried at first, and then
> optimizations of all that might be made later.
>
> Swapping object identities is handled at the proxy level -- the two proxied
> objects are just exchanged. So you can see the Proxy level is acting a bit
> like an object table.
>
> "Becomes" might be handled by changing the became field to true and then
> changing the proxy to the new object. After that, the dispatching will work
> differently and just be passed onto the new object without further processing.
>
> One can also merge the Smalltalk and the SmalltalkInstance class, but
> swapping then becomes a matter of exchanging the embedded Java objects.
> However, then directly proxied Java objects can no longer easily have their
> identities swapped (it would require directly replacing all references in
> all Smalltalk instance objects). But that might be OK -- you'd just get an
> exception that Java objects cannot support "become".
>
> Calling into Smalltalk from Java I haven't thought through. I know Jython
> does it but I have not looked at that. I suspect you could intercept an
> exception and do something. I'm assuming exceptions could go up the message
> stack, but I admit that throwing them across intervening Java function calls
> within the method stack could be problematical -- the message stack might
> need to be annotated somehow in those cases before calling the function,
> another performance hit.
>
> Now, this approach has a higher memory cost. And it also has a loss of
> runtime performance for Smalltalk code. But I think if you merged in support
> for Scala (a JVM language which is typed and fast) to compile bottleneck
> code from Smalltalk->Scala->JVM, the hybrid mix might be pretty fast.
> Equivalent to the successful CPython/C mix. Or that would be my hope at least.
>
> I might even throw Jython into the mix too. :-) Here is a Smalltalk-like
> parser in Jython:
> http://patapata.svn.sourceforge.net/viewvc/patapata/tags/PataPata_v204/Pointrel/smalltalkToPython.py?revision=315&view=markup
> that could be elaborated on for bootstrapping into a pure
> Smalltalk-in-Smalltalk-on-the-JVM compiler.
>
> One could then build tools within this Squeak-like environment which support
> Smalltalk, Scala, Java, and Jython in an Eclipse-like way (maybe even
> pulling in Eclipse components entirely -- it's just Java right?), but using
> an RDF-like (or Pointrel-ish) approach for storing content instead of files.
> And the image would be written out by the proxies as Smalltalk source
> code,making for a slower loading and writing process, but an understandable
> image. SO it's a polyglot system. :-) I wrote on that in 1996 (was that
> really twelve years ago?
>    "Squeak and the Babel of programming languages"
> to Squeak list. Would be nice to finally see it happen on a free platform.
>
> Anyway, just outlining some ideas. Not sure if they will work out in
> practice. :-)
>
> --Paul Fernhout
>
> Bergel, Alexandre wrote:
> >> Does it have nay hope to be supported by a community? Does it take
> >> advantage
> >> of the Java/JVM platform, including threading and multi-processor
> >> support?
> >> Or interoperate easily back and forth with Java libraries like Jython
> >> can?
> >
> > I haven't looked at deeply, but I strongly suspect that no interaction
> > is actually possible with Java.
> >
> > I am currently working on this.
> > http://bergel.eu/athena for more info
>
>
>