>Patrick Logan <······@user2.teleport.com> wrote in article
><············@news1.teleport.com>...
>> This is an example of a good way to integrate Java and Smalltalk. It does
>> not involve shoe-horning Smalltalk into the JVM.
>
>This is basically the point I was trying to make in an earlier post. It's
>*sooo* easy to put Java inside Smalltalk instead of the other way round.
>Why is that? :)
>
We all know the answer to that - most Smalltalks have a better VM
architecture.
Java has a subset of Smalltalk functionality. This we accept as a given.
However, it also misses the point entirely! What are the odds that
JavaSoft,
Netscape, and/or Microsoft will ditch their current efforts in the JVM to
support
a Smalltalk compatible VM? Very close to zero. Yes, you CAN run JVM code
on a
Smalltalk VM. So what? No commercially viable browser includes a Smalltalk
VM.
This effectively dumps Smalltalk off the "platform of the future" (sarcasm
mode
fully on with that description). So what to do?
Possibility 1: New browser, extending JVM with bytecodes allowing Smalltalk
to
run efficiently.
Prognosis: Unlikely to win market share, for obvious reasons. Let's face
it,
Netscape was ahead of the curve in installed systems, and even they were
steam-
rolled by Microsoft. Would a brand new browser have any chance? Do pigs
fly?
Even though it is quite possible the JVM included in the new browser would
be
faster than most (the Smalltalk community does have a few years on JavaSoft,
et. al. in producing VM's), the difference would not make a compelling case
for a user to switch to a no-name browser.
Possibility 2: New plug-in with Smalltalk extended JVM or actual
Smalltalk-oriented VM.
Prognosis: The majority of applets out there are made of Java byte codes.
Why should Joe User need to download some dumbass plug-in to run YOUR app?
I don't even like the proliferation of plug-ins/ActiveX crud that needs to
be installed in my already limited C: drive (bear with me all of you LINUX
users out there). If it ain't delivered with the browser, it ain't gonna be
accepted.
Possibility 3: Convince Java folk to extend JVM to have a more
Smalltalk-friendly
VM.
Prognosis: To increase the odds of sucess, enlist the aid of other dynamic
language developers (Lisp, Dylan, Scheme) and create a concrete proposal for
the design of the VM bytecodes. But the JVM folk got a lot on their plate
and this is not likely to be a high priority. They are more interested in
making Java successful than Smalltalk or any other language. Better shot
than Possibilities 1 & 2, though.
Possibility 4: Write new JVM compatible VM extended to be Smalltalk
friendly. Make sure it has state of the art GC, JIT compilation, etc.
Provide it as a public domain replacement for the JVM's used in Netscape,
IE4.0.
Prognosis: It's a lot of work. It's still a long shot. However, a
public-domain fait accompli that performs better than the current JVMs is a
stronger impetus for the browser companies to adopt the technology than
begging or whining. To help insure that it is adopted, concentrate on
optimizing the JVM bytecodes first. Many hands make light work. Enlist the
help of other dynamic language (Lisp, Scheme, Dylan) developers (you may
have to implement one or two more bytecodes for them, though). All-in-all,
this has the best chance for getting a Smalltalk friendly VM into the
mainstream.
Possibility 5: Do nothing but whine.
Prognosis: Smalltalk slowly stagnates. Price considerations alone make it
less and less viable as even a corporate development environment. Java
environments advance at a faster rate. It's a great development environment
now - how much greater will it be three years from now?
Anyway, Possibility 4 looks better than anything else to me. Any concrete
suggestions out there for extensions to the current JVM to run Smalltalk
code interoperably and efficiently? Or any suggestions for other
alternatives to the possibilities outlined above?
--
Frank A. Adrian
First DataBank
············@firstdatabank.com (W)
······@europa.com (H)
This message does not necessarily reflect those of my employer,
its parent company, or any of the co-subsidiaries of the parent
company.
eXept already has created a browser (not packaged for the public-at-large) that
implements a Smalltalk VM capable of running Java.
Frank A. Adrian wrote:
> <snip>
> No commercially viable browser includes a Smalltalk VM.
> This effectively dumps Smalltalk off the "platform of the future" (sarcasm
> mode
> fully on with that description). So what to do?
"Frank A. Adrian" <············@firstdatabank.com> writes:
> Possibility 4: Write new JVM compatible VM extended to be Smalltalk
> friendly. Make sure it has state of the art GC, JIT compilation, etc.
> Provide it as a public domain replacement for the JVM's used in Netscape,
> IE4.0.
> Prognosis: It's a lot of work. It's still a long shot. However, a
> public-domain fait accompli that performs better than the current JVMs is a
> stronger impetus for the browser companies to adopt the technology than
> begging or whining. To help insure that it is adopted, concentrate on
> optimizing the JVM bytecodes first. Many hands make light work. Enlist the
> help of other dynamic language (Lisp, Scheme, Dylan) developers (you may
> have to implement one or two more bytecodes for them, though). All-in-all,
> this has the best chance for getting a Smalltalk friendly VM into the
> mainstream.
>
This is the *only* possibility that would work the problem with all
the others, (apart from the 'just whining' solution - which on the
face of it deserves serious consideration ;o) ) and much of the
discussion in this thread is that it assumes that the browser VMs are
the *only* ones out there.
As well as the browser VMs (MS+NS), there's the javasoft jre, and
countless other *application* VMs - some on 'unusual' platforms (like
personal organisers). Then there's the M's without the V in the
netstation, javastation, and beasts of that ilk.
Finally, theres other people who have products that emit JVM bytecodes
or spit bytecodes out as something else (eg SuperCede).
In other words, lots and lots of companies have invested heavily in
JVM technology because they believed that they would be able to run
all (JVM) software in the future.
To bring these people on board you would have to produce a
demonstrably better VM, that was publicly available as portable source
code, could be installed on many platforms as a drop-in replacement
for the browser VMs, AND you somehow have to convince one of the big
players to push it through the standards process, and market/support
it.
Tall order.
Of course we always have whining as a fallback....
-Baz
--
"Frank" == Frank A Adrian <············@firstdatabank.com> writes:
Frank> Possibility 4: Write new JVM compatible VM extended to be
Frank> Smalltalk friendly. Make sure it has state of the art GC,
Frank> JIT compilation, etc. Provide it as a public domain
Frank> replacement for the JVM's used in Netscape, IE4.0.
Perhaps I don't remember it very clearly (and I'm not lawyer anyway),
but recently I looked at the copyright notice that comes inside "The
Java Virtual Machine Specification" (Addison Wesley). It seemed to
indicated that I could implement a JVM, but I could not subset *or*
superset the specification.
Perhaps some legal eagle can tell enlighten me on how, and if,
Possibility 4 above can be implemented. I will add that I don't have
the book with me, and my Java programming language books copyright
does not restrict adding to the language (witness Pizza). So perhaps I
don't remember correctly, but hey - it made a strong impression when I
saw it.
Regards,
Shyamal
--
"An optimist is a pessimist with no job experience" - Dogbert
[Ooops....all expressed opinions are mine, not my employers]
Shyamal Prasad wrote:
>
> "Frank" == Frank A Adrian <············@firstdatabank.com> writes:
>
> Frank> Possibility 4: Write new JVM compatible VM extended to be
> Frank> Smalltalk friendly. Make sure it has state of the art GC,
> Frank> JIT compilation, etc. Provide it as a public domain
> Frank> replacement for the JVM's used in Netscape, IE4.0.
>
> Perhaps I don't remember it very clearly (and I'm not lawyer anyway),
> but recently I looked at the copyright notice that comes inside "The
> Java Virtual Machine Specification" (Addison Wesley). It seemed to
> indicated that I could implement a JVM, but I could not subset *or*
> superset the specification.
Nonsense. You're probably just not allowed to call it "Java" or "JVM"
if it's not 100% compliant. Which is why Microsoft want Sun to
relinquish the ownership of the Java trademark.
Gary
--
pub 1024/C001D00D 1996/01/22 Gary Howland <····@hotlava.com>
Key fingerprint = 0C FB 60 61 4D 3B 24 7D 1C 89 1D BE 1F EE 09 06
Shyamal Prasad wrote:
>
> "Frank" == Frank A Adrian <············@firstdatabank.com> writes:
>
> Frank> Possibility 4: Write new JVM compatible VM extended to be
> Frank> Smalltalk friendly. Make sure it has state of the art GC,
> Frank> JIT compilation, etc. Provide it as a public domain
> Frank> replacement for the JVM's used in Netscape, IE4.0.
>
> Perhaps I don't remember it very clearly (and I'm not lawyer anyway),
> but recently I looked at the copyright notice that comes inside "The
> Java Virtual Machine Specification" (Addison Wesley). It seemed to
> indicated that I could implement a JVM, but I could not subset *or*
> superset the specification.
>
> Perhaps some legal eagle can tell enlighten me on how, and if,
> Possibility 4 above can be implemented. I will add that I don't have
> the book with me, and my Java programming language books copyright
> does not restrict adding to the language (witness Pizza). So perhaps I
> don't remember correctly, but hey - it made a strong impression when I
> saw it.
>
Hope Sun doesn't sue me for this <g>
Here's the relevant portion of the copyright notice:
Sun Microsystems, Inc. (SUN) hereby grants to you a fully-paid,
non-exclusive, nontransferable, perpetual, worldwide limited
license (without the right to sublicense) under SUN's
intellectual property rights that are essential to practice this
specification. This license allows and is limited to the
creation and distribution of clean room implementations of this
specification that: (i) include a complete implementation of the
current version of this specification without subsetting or
supersetting; (ii) implement all the interfaces and
functionality of the standard java.* packages as defined by SUN,
without subsetting or supersetting; (iii) do not add any
additional packages, classes or methods to the java.* packages;
(iv) etc. etc. etc.
Section (i) seems to say that you can't add more bytecodes.
peter
In comp.object Peter Burka <······@istar.ca> wrote:
: Section (i) seems to say that you can't add more bytecodes.
How is this reconciled with Sun's own "quick" bytecodes. These are
instructions that the spec says are not required, added for speed, and
their implementation of the VM substitutes "on the fly" for speed
improvements. Does not the spec allow for these kinds of bytecodes?
What about IBM's rumored "universal" virtual machine?
I don't believe the answer is crystal clear.
--
Patrick Logan (H) ·············@teleport.com
(W) ···············@gemstone.com
http://www.gemstone.com
There is no such thing as a free variable.
In article <············@news1.teleport.com>, Patrick Logan
<·················@user1.teleport.com> wrote:
> In comp.object Peter Burka <······@istar.ca> wrote:
>
> : Section (i) seems to say that you can't add more bytecodes.
>
> How is this reconciled with Sun's own "quick" bytecodes. These are
> instructions that the spec says are not required, added for speed, and
> their implementation of the VM substitutes "on the fly" for speed
> improvements. Does not the spec allow for these kinds of bytecodes?
Page 389 of their book says (about using quick bytecodes): "The technique
documented in this chapter is covered by U.S. Patent 5,367,685".
Dave
Patrick Logan wrote in message <············@news1.teleport.com>...
>In comp.object Peter Burka <······@istar.ca> wrote:
>
>: Section (i) seems to say that you can't add more bytecodes.
>
>How is this reconciled with Sun's own "quick" bytecodes. These are
>instructions that the spec says are not required, added for speed, and
>their implementation of the VM substitutes "on the fly" for speed
>improvements. Does not the spec allow for these kinds of bytecodes?
>
I presume you can do what you like internally, including translating
bytecodes to new bytecodes, and translating to native code, as long as you
do not support any additional bytecodes in (external) classfiles.
Roland
Roland PJ Pipex Account wrote in message
<············@plug.news.pipex.net>...
>
>Patrick Logan wrote in message <············@news1.teleport.com>...
>>In comp.object Peter Burka <······@istar.ca> wrote:
>>
>>: Section (i) seems to say that you can't add more bytecodes.
>>
>>How is this reconciled with Sun's own "quick" bytecodes. These are
>>instructions that the spec says are not required, added for speed, and
>>their implementation of the VM substitutes "on the fly" for speed
>>improvements. Does not the spec allow for these kinds of bytecodes?
>>
>
>I presume you can do what you like internally, including translating
>bytecodes to new bytecodes, and translating to native code, as long as you
>do not support any additional bytecodes in (external) classfiles.
That is correct. There is no need to add bytecodes to extend the VM anyhow.
The way to extend the Java VM is with native methods (i.e.
smalltalk.lang.Block). Successful native packages will be adopted by the
Java standard (becoming java.lang.Block or javax.lang.Block). Any future
bytecodes would have to follow that route (and would of course retain their
native method implementation for earlier VM versions).
jim
-----------------------------------------------------------------------
James P. White Netscape DevEdge Champion for IFC
Director of Technology Adventure Online Gaming http://www.gameworld.com
Developers of Gameworld -- Live Action Role-Playing and Strategic Games
···@aognet.net Pagesmiths' home is http://www.pagesmiths.com
James P. White wrote:
> That is correct. There is no need to add bytecodes to extend the VM anyhow.
>
> The way to extend the Java VM is with native methods (i.e.
> smalltalk.lang.Block).
I think that this will be less successful than you think.
Your native methods will need to conform to some standard
or another, hopefully JNI. You can use native code for
performance, or for interface to external stuff not
described in the Java libraries, but I doubt that you
can usefully tinker with the function of the virtual
machine. The workings of the GC are not exposed, nor
are the symbols in a stack trace.
I'm working on a bytecode-to-native compiler, and one thing
we dread is more exciting library stuff that interacts with
the rest of the VM, especially when it comes with a vague
specification (see the "specification" for the 1.1
reflection interface, for instance).
I think you'd be better off figuring out how to define
what you want in terms of existing Java types, and work
with that. Ask yourself, "why do I care about running
Smalltalk on a Java VM?" If the Java VM is deficient
in terms of performance, compared to what you already
have, why are you abandoning what you already have? As
near as I can tell, what you want is a spot on the ubiquity
bandwagon, and I can certainly appreciate that.
However, if that is your goal, you are not going to
obtain it by requiring bytecode changes, or by requiring
native methods (that means native code, written to work
with HotJava, Netscape, and Internet Explorer, on all
the platforms where those browsers work, and that means
that you are expecting those people to download your
native extension, and that they are trusting you are
not the same guys who brought us the Moldovan porno
viewer hack). Whining would be equally effective,
and much easier. Figure out how to do the mapping in
Java as it is now. If the efficiency sucks, fine,
benchmark it, try to figure out how to improve the
mapping. Maybe you write native methods for some
important platforms, but the important thing is that
you have a reference implementation in Java that
*anyone* can run, even if they are a little paranoid
about downloading native code.
> ... Successful native packages will be adopted by the
> Java standard (becoming java.lang.Block or javax.lang.Block).
I think you'd have a better chance if that package were
written in pure Java.
--
David Chase, ·····@world.std.com
David Chase wrote in message <·············@world.std.com>...
>James P. White wrote:
>
>> That is correct. There is no need to add bytecodes to extend the VM
anyhow.
>>
>> The way to extend the Java VM is with native methods (i.e.
>> smalltalk.lang.Block).
>
>I think that this will be less successful than you think.
>Your native methods will need to conform to some standard
>or another, hopefully JNI. You can use native code for
>...
>> ... Successful native packages will be adopted by the
>> Java standard (becoming java.lang.Block or javax.lang.Block).
>
>I think you'd have a better chance if that package were
>written in pure Java.
I was commenting specifically on a prospective new VM that provides direct
support for closures (Smalltalk talk - continuations in Scheme) in addition
to standard Java bytecode. Clearly Smalltalk can target the standard Java
VM (as Scheme and a couple dozen other languages already do) but the
performance of closures/continuations would be highly variable depending on
the JVM implementation. The problem stems from the Java designers' choice
of the "thread" model rather than the more generally useful "continuation
passing" model. Due to both the practical (Smalltalk & Scheme) uses of
closure/continuation and the high level uses (efforts to prove correctness
in Java and the VM will almost certainly have to use the continuation model
rather than the "raw" thread model - ala ML), this is one area of VM
extension that will very likely be fruitful.
I totally agree with your point though, which is the one that I have been
maintaining in this thread, that being that Smalltalk will be targeted at
the standard Java VM and successfully so (to the great commercial benefit of
the Smalltalk community). Longer term issues include taking the first steps
to the inevitable extensions to the VM (the implementation of which is
through native methods not bytecodes - see reflection for example).
jim
-----------------------------------------------------------------------
James P. White Netscape DevEdge Champion for IFC
Director of Technology Adventure Online Gaming http://www.gameworld.com
Developers of Gameworld -- Live Action Role-Playing and Strategic Games
···@aognet.net Pagesmiths' home is http://www.pagesmiths.com
In comp.object Frank A. Adrian <············@firstdatabank.com> wrote:
: What are the odds that JavaSoft, Netscape, and/or Microsoft will ditch
: their current efforts in the JVM to support a Smalltalk compatible VM?
: Very close to zero. Yes, you CAN run JVM code on a Smalltalk VM. So
: what?
So Java/JVM byte codes become the "glue" for Smalltalk to live in a
non-Smalltalk world. This is no different from Smalltalk having to live in
a C/C++ world. Well, there is one difference: it is *easier* for Smalltalk
to live in a Java world than in a C++ world.
: No commercially viable browser includes a Smalltalk VM. This
: effectively dumps Smalltalk off the "platform of the future" (sarcasm
: mode fully on with that description). So what to do?
Choose the best battles. Smalltalk can talk "Java-ese" and so can
browsers, therefore Smalltalk can talk to browsers. Witness the "Route 1"
product, now called what? Classic Blend?
: Why should Joe User need to download some dumbass plug-in to run YOUR
: app?
This is not so outlandish in an enterprise/intranet environment.
--
Patrick Logan (H) ·············@teleport.com
(W) ···············@gemstone.com
http://www.gemstone.com
There is no such thing as a free variable.
eXept already has created a browser (not packaged for the public-at-large) that
implements a Smalltalk VM capable of running Java.
Frank A. Adrian wrote:
> <snip>
> No commercially viable browser includes a Smalltalk VM.
> This effectively dumps Smalltalk off the "platform of the future" (sarcasm
> mode
> fully on with that description). So what to do?