DaVinci machine project - worthy of much publicity

[Michael Neale]

http://openjdk.java.net/projects/mlvm/

MLVM is also a cool name, but DaVinci machine is awesome. I am sure
most here have heard of it, but finally it is hard evidence of the
importance of multiple language support on the JVM for the future (I
know, this is the Java Posse, but I think its still relevant).

Go John Rose !

Now we can return to our regular fisticuffs over Java 3 language
enhancements.

[Christian Catchpole]

Im going to reply simply to get this post back to the top of the list.

It will though require breakdancing robot support.

Rock and/or roll.

[Casper Bang]

It's funny though, isn't this pretty solid evidence that the JVM was
NOT designed for multiple languages?

It hope DaVinci will also help us interoperate with the native
platform, JNI is a nightmare. Let's say I wanted to take a screendump
with the cursor (awt.Robot can't do that and is far too slow), one
should be able to locate the relevant native API's on Windows, Mac and
Linux without having to deal with tools and build bridges etc.

/Casper

On Feb 8, 3:26 pm, Christian Catchpole <christ...@catchpole.net>
wrote:

[Christian Catchpole]

On Feb 8, 10:10 am, Casper Bang <c...@brunata.dk> wrote:
> It's funny though, isn't this pretty solid evidence that the JVM was
> NOT designed for multiple languages?

It was.. as long as they are Java. :) But seriously, while bytecode
may not be optimal (not an AST), you might be able to forgive this as
simply a little indirection on its way to the JIT. But today there
are some concepts, good or bad, that you are stuck with with vanilla
Java. The Java view of classes, objects, methods, GC, threads, native
integration etc. Today you might be hard pressed to support,
stackless, low level parallel etc.

But its all good. We will get there one way or another. How close it
is to original Java is irrelevant if there is a good migration process
or all the Java legacy becomes irrelevant anyway. Im not predicting
which way that will go.

Every now and again I get stuck into C++ to play with fundimental
concepts such as memory managment, state and code dispatch and so
forth... and run screaming realizing how much progress has been made
in platforms such as Java. That's not to say I wont take another look
in a month or so. :)

[robilad]

On Feb 8, 4:10 pm, Casper Bang <c...@brunata.dk> wrote:
> It's funny though, isn't this pretty solid evidence that the JVM was
> NOT designed for multiple languages?
>
> It hope DaVinci will also help us interoperate with the native
> platform, JNI is a nightmare. Let's say I wanted to take a screendump
> with the cursor (awt.Robot can't do that and is far too slow), one
> should be able to locate the relevant native API's on Windows, Mac and
> Linux without having to deal with tools and build bridges etc.

You don't need DaVinci for that, you just take JNA (jna.dev.java.net)
and
off you go. Brought to you by libffi, among other things. ;)

[Casper Bang]

On Feb 8, 5:00 pm, Christian Catchpole <christ...@catchpole.net>
wrote:

> It was.. as long as they are Java. :) But seriously, while bytecode
> may not be optimal (not an AST), you might be able to forgive this as
> simply a little indirection on its way to the JIT. But today there
> are some concepts, good or bad, that you are stuck with with vanilla
> Java. The Java view of classes, objects, methods, GC, threads, native
> integration etc.

Right, some of which made Jim Hugunin of the original Jython flee. I'm
not really after pointer a finger at the bytecode, it's easy to do
with 20-20 hindsight and it served well for 15 years. It just seems
some people like to twist reality a little once a while. Reading the
bytecode and IL specs, it's clear that Java was designed for
interpretation on a platform neutral Java-aware virtual machine,
rather than for language interoperability (in contrast to .NET).

> But its all good. We will get there one way or another. How close it
> is to original Java is irrelevant if there is a good migration process
> or all the Java legacy becomes irrelevant anyway. Im not predicting
> which way that will go.

I hope you are right, and that it will be done though lowering the
relatively high common denominator a bit on the JVM.

I'd recommend going though Ted Neward's recent blog entries, as he
attended the Lang.NET Symposium with quite an interesting group of
developers (Jim Hugunin, Anders Hejlsberg, Miguel de Igasa, John Rose
etc.). There's a few important statements there, such as Ted
concluding on DaVinci and the DLR: "...there really were more
parallels there than I'd thought there'd be, meaning there's less
interesting bits for each side to learn from the other" as well as
Hejlsberg stating: "The taxonomies of programming languages are
breaking down. I think that languages are fast becoming amalgam... I
think that in 10 years, there won't be any way to categorize languages
as dynamic, static, procedural, object, and so on.". There's suppose
to be video coming, but for now the best coverage is from Ted's blog:
http://blogs.tedneward.com/

/Casper

[Casper Bang]

On Feb 8, 5:28 pm, robilad <dalibor.to...@googlemail.com> wrote:
> You don't need DaVinci for that, you just take JNA (jna.dev.java.net)
> and
> off you go. Brought to you by libffi, among other things. ;)

Thanks robilad, I'm aware of JNA, my point was simply that
interoperability (language or platform) was never part of Java's
philosophy. :)

/Casper

[robilad]

Never say never ... At least since the scripting engine JSR thingy,
there is an effort to interoperate with some other ecosystems. Sure,
it's a lot higher / simpler than a MOP, etc. but hey, the change of
philosophy started a while ago. Getting it right at the low level is
non-trivial, but if you are interested in the subject, there are years
of VM research based on Kaffe on meta object protocols, and all of
that fun, odd stuff. People have been using gcj to make python, perl &
ruby code interoperate since forever, basically, etc.

The only new thing is that it's finally becoming acceptable in the
mainstream as an idea that both the JVM should be able to 'run the
world', and the 'world should be able to run code written in
java' (GWT, android, etc.), and that means one gets a chance to do it
'right' at the VM level, without having to resort to either 'forking'
the VM spec, or to hack around the limitations of the VM spec.

Punk's not dead, it's tomorrow's pop. ;)

[Michael Neale]

On Feb 9, 1:10 am, Casper Bang <c...@brunata.dk> wrote:
> It's funny though, isn't this pretty solid evidence that the JVM was
> NOT designed for multiple languages?

Well maybe in initial design (obviously it was only designed for one
language), but in practice, Charles Nutter seems to think otherwise:

http://headius.blogspot.com/2008/01/langnet-2008-day-1-thoughts.html

.Net is in the same boat with a slightly smaller paddle, in a similar
spot in the creek (if that metaphor makes sense).

>
> It hope DaVinci will also help us interoperate with the native
> platform, JNI is a nightmare. Let's say I wanted to take a screendump
> with the cursor (awt.Robot can't do that and is far too slow), one
> should be able to locate the relevant native API's on Windows, Mac and
> Linux without having to deal with tools and build bridges etc.

JNA

[Michael Neale]

On Feb 9, 2:51 am, Casper Bang <c...@brunata.dk> wrote:

>
> Right, some of which made Jim Hugunin of the original Jython flee.

That or getting poached by microsoft will do that to you. The original
jython was pretty basic, what he failed to do the Rhino people did
years ago, far more successfully, without any of the whining (and it
still works to this day).

I'm
> not really after pointer a finger at the bytecode, it's easy to do
> with 20-20 hindsight and it served well for 15 years. It just seems
> some people like to twist reality a little once a while. Reading the
> bytecode and IL specs, it's clear that Java was designed for
> interpretation on a platform neutral Java-aware virtual machine,
> rather than for language interoperability (in contrast to .NET).
>

I think Charles and others desire is to have the ability to have non
class bytecode in the VM, which you can then group together to keep
most languages happy (as no one will ever agree what a "class" or
"object" means in a cross language way, so why not give up and make
functions the top level construct). Maybe it will happen. But the
current one method per generated class per classloader (so it can be
GCed) is not terribly scalable, neither is the implement a VM on top
of a VM approach that others do.

[Casper Bang]

The slides from the recent Da Vinci Machine talk at Lang.NET symopsium
2008 have been released:
http://langnetsymposium.com/talks/Slides/LangNetDVMTalk.pdf

Video suppose to be coming soon.

/Casper