Complexity and starting over on the JVM (ideas)

Paul D. Fernhout pdfernhout at kurtz-fernhout.com
Sat Feb 9 01:47:08 UTC 2008


Tempting, but I myself won't ask to see the code, because until I know the
exact licensing conditions and availability of something (and deem them
acceptable), I don't want to look at it or invest time in it (even if I
stumble upon stuff). Too much other stuff out there with clear licenses I
can be sure to draw from. And I already got stuck once with a person month
of code I wrote I could not release because of a lack of clarity going into
a collaboration as to the licensing of the original source materials and the
output.

Also, no disrespect intended, especially because I think what you did with
Smalltalk and Squeak is really cool (both with this Squeak on the JVM and in
the past), but in the long term somehow I'm personally still inclined for
reasons related to licensing clarity, as well as having the image defined
purely as source code, as well as to improve modularity, on putting
Squeak-derived tools and applications around a GNU/Smalltalk-derived core
running on a hand-coded VM (or more likely just some hand written glue code
for using Java objects from Squeak). At least, that's the way I am leaning
now, for various reasons most of which I've outlined in this thread. Maybe
it won't work out in practice, I'll see. But someone like you will have to
admit how much fun that might be, watching the system grow in functionality
bit by bit and understanding every piece you add as you add it (even if the
whole might start doing unexpected things eventually. :-)

But, if you had the time, I'd sure be happy to learn more about any unusual
aspects of the general architecture if you can describe it simply. As a
simple answer to that, is it still organized as Michael outlined: "It's very
nice code, and nicely modularised into just 8 classes and 1 interface: the
Squeak interface defines constants. The Main and Starter classes are
wrappers to get everything running. Then there are SqueakVM and
SqueakPrimitiveHandler for execution, Screen and BitBlt for displaying, and
SqueakImage and SqueakObject for representing living things."

And how many pages or lines of Java code (roughly) did that turn out to be?

And also, did you write a Smalltalk->Java translator to make the VM or did
you code it by hand?

I'd be curious about anything you could say about the license of the Java
part (or Smalltalk->Java translator). X/MIT? Squeak? Other (Sun's Java or
GPL+Exception)? (Even LGPL is fine with me, by the way, as I expect to be
using that if I draw from GNU/Smalltalk for the core.) Though I know until
its formally released maybe you can't make promises as to license, so feel
free to not answer that. Still, I would expect that those classes would all
be very useful in whatever implementation anyone worked on for the JVM.

These questions would all take longer to answer, or might have proprietary
or personal answers, so feel free to skip them. In general, it would be nice
to learn what parts were hardest to do or where you had to write a lot more
Java code than expected (or even, what parts were surprisingly easy).
Although perhaps that would be too specific to you to know if it applies to
any such effort? It would be nice to get a general impression of how many
Squeak classes it has (if different form a standard image), how it performs
relative to Squeak in C on the same hardware, or what parts of the Squeak VM
the JVM struggles with (if you profiled it), or if it exposed any (publicly
known) JVM problems or weaknesses any such effort might encounter. I'd like
to learn if it involved refactoring or changing any of the Squeak core
classes (or if you just used essentially a release image or something
similar). It would be nice to know what version(s) of Squeak you drew from.
It would be nice to know if newer JVMs (like six or seven) make it perform a
lot better. Also, compared to the C, it would be nice to know if you though
the Java code seemed as beautiful or elegant? Did you find the tools as
reasonable as ones for C? I'd be curious what setup you used to develop and
test it too, just out of curiosity (Eclipse, Sun's tools? Other?). Does the
system feel stable to you (that is, relatively to Squeak on a VM in C)? Or
anything else related to an overview to get everyone even more tempted. :-)

Essentially, anything non-proprietary you might want to later put in a
lengthy "readme" file or an informative pre-announcement is what I would
love to know right now. Or a pointer to such if it already exists on the
public web. :-)

This is unrelated, but as long as I'm asking, :-) feel free to say no
comment, I'd be curious if you were involved or in touch at all with Sun's
effort to make the JVM have better support for dynamic languages (like JRuby
or Jython, or, hopefully, a Squeak/JVM. :-) No Smalltalkers listed here,
sadly, but it was years ago:
  "Sun warms to Dynamic Languages: Summit Held" (Dec. 2004)
  http://www.theserverside.com/news/thread.tss?thread_id=30462
That's just to get a sense of how much the JVM might (in theory) continue to
improve in a Smalltalk-ish direction if there was an actively used Smalltalk
on the JVM and someone there who cared about it.

--Paul Fernhout

Dan Ingalls wrote:
>>> 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?
>> In my opinion, the key of success for JRuby, Rhino, JScheme, Jython is
>> to enable interaction with Java. When Dan will release its source, I
>> might port Athena on his VM. But again, interaction with Java is
>> crucial.
> 
> FWIW, since Potato is in the release process here, I'd be happy to send a
> private copy to anyone until it's official.  It should be easy to
> evaluate the convenience of inter-operating with Java (I think pretty
> simple).  Just send me a message.



More information about the Squeak-dev mailing list