The Second Coming of Java article

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

The Second Coming of Java article

askoh
Administrator
http://www.wired.com/wiredenterprise/2013/09/the-second-coming-of-java/

The article talks about Java Virtual Machine running dynamic languages like Scala and Clojure in addition to Java. What prevents the Smalltalk Virtual Machine from running Java, Scala, Clojure and other JVM languages? Is that something we can ride on to greater awareness and usage of Smalltalk Virtual Machine and Smalltalk?

All the best,
Aik-Siong Koh
Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

Jan Vrany
On 24/11/13 21:19, askoh wrote:
> http://www.wired.com/wiredenterprise/2013/09/the-second-coming-of-java/
>
> The article talks about Java Virtual Machine running dynamic languages like
> Scala and Clojure in addition to Java. What prevents the Smalltalk Virtual
> Machine from running Java, Scala, Clojure and other JVM languages? Is that
> something we can ride on to greater awareness and usage of Smalltalk Virtual
> Machine and Smalltalk?

Well, nothing atually:-) It's already done. Smalltalk/X virtual
machine can run Java bytecode and thus all sort of JVM languages :-)

Cheers, Jan

[1] https://swing.fit.cvut.cz/projects/stx-libjava
[2] Marcel Hlopko, Jan Kurš, Jan Vraný, and Claus Gittinger.
     On the Integration of Smalltalk and Java ̇

 
http://www.esug.org/wiki/pier/Conferences/2012/International-Workshop---IWST-2012/Proceedings.pdf 
, page 1 :-)

[3]
http://www.youtube.com/watch?v=p21z3bAt7b0&list=PLCGAAdUizzH027lLWKXh_44cGuEsay7-R&index=7
[4] https://www.youtube.com/watch?v=p3J554BNEz8




>
> All the best,
> Aik-Siong Koh
>
>
>
> --
> View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

Eliot Miranda-2
In reply to this post by askoh



On Sun, Nov 24, 2013 at 1:19 PM, askoh <[hidden email]> wrote:
http://www.wired.com/wiredenterprise/2013/09/the-second-coming-of-java/

The article talks about Java Virtual Machine running dynamic languages like
Scala and Clojure in addition to Java. What prevents the Smalltalk Virtual
Machine from running Java, Scala, Clojure and other JVM languages? Is that
something we can ride on to greater awareness and usage of Smalltalk Virtual
Machine and Smalltalk?

Time and money.
 

All the best,
Aik-Siong Koh



--
View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.




--
best,
Eliot
Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

kilon.alios
In reply to this post by askoh

Its also way simpler and faster to just make java apps communicate with pharo via sockets. You dont need pharo to run JVM , all you need is a way to communicate with it. So why do it the hard way ?

Στις 24 Νοε 2013 11:20 μ.μ., ο χρήστης "askoh" <[hidden email]> έγραψε:
http://www.wired.com/wiredenterprise/2013/09/the-second-coming-of-java/

The article talks about Java Virtual Machine running dynamic languages like
Scala and Clojure in addition to Java. What prevents the Smalltalk Virtual
Machine from running Java, Scala, Clojure and other JVM languages? Is that
something we can ride on to greater awareness and usage of Smalltalk Virtual
Machine and Smalltalk?

All the best,
Aik-Siong Koh



--
View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

abergel
In reply to this post by askoh
Actually, do I want to have Pharo running on Java? My answer was ‘yes’ a couple of years before. Today, I want to have Pharo (or at least most of it) running in a web browser.

Distributing applications to clients is then so easy...

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On Nov 24, 2013, at 6:19 PM, askoh <[hidden email]> wrote:

> http://www.wired.com/wiredenterprise/2013/09/the-second-coming-of-java/
>
> The article talks about Java Virtual Machine running dynamic languages like
> Scala and Clojure in addition to Java. What prevents the Smalltalk Virtual
> Machine from running Java, Scala, Clojure and other JVM languages? Is that
> something we can ride on to greater awareness and usage of Smalltalk Virtual
> Machine and Smalltalk?
>
> All the best,
> Aik-Siong Koh
>
>
>
> --
> View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

Jan Vrany
In reply to this post by kilon.alios
On 25/11/13 19:17, kilon alios wrote:
> Its also way simpler and faster to just make java apps communicate with
> pharo via sockets.

No, it's not simpler nor faster.
Imagine you want to parse and validate XML using Xerces parser
while having your SAX handler written in Smalltalk.

Jan

Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

kilon.alios
I don't see a problem. Sockets provide a way to communicate, sockets nowadays are used almost everywhere. They have their limitations but its a viable , very fast and simple solution. 

Also you can use Redline Smalltalk -> http://www.redline.st/ if you want to run smalltalk on JVM.  

I vaguely remember that Squeak had the Ometa project that was working as a converter between languages , I think Java was supported. 

Plenty of options already. 


On Mon, Nov 25, 2013 at 9:54 PM, Jan Vrany <[hidden email]> wrote:
On 25/11/13 19:17, kilon alios wrote:
Its also way simpler and faster to just make java apps communicate with
pharo via sockets.

No, it's not simpler nor faster.
Imagine you want to parse and validate XML using Xerces parser
while having your SAX handler written in Smalltalk.

Jan


Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

Marcus Denker-4

On 25 Nov 2013, at 21:13, kilon alios <[hidden email]> wrote:

I don't see a problem. Sockets provide a way to communicate, sockets nowadays are used almost everywhere. They have their limitations but its a viable , very fast and simple solution. 

Also you can use Redline Smalltalk -> http://www.redline.st/ if you want to run smalltalk on JVM.  

I vaguely remember that Squeak had the Ometa project that was working as a converter between languages , I think Java was supported. 

Keep in mind that supporting syntax is one thing, semantics is the other… Ometa is just a (very nice) tool for making implementing a parser for syntax easier, very much like PetitParser.
I once did a very, very naive demo of adding other *syntax* to Squeak…


But the problem is that the *semantics* are still that of Smalltalk, and it’s completely not clear for the programmer where the similarity ends.

If you want to have “I can type in examples from my ruby book” compatibility, you need to implement the real semantics, which in many cases
means to re-implement the VM of that other language (in a very slow version) on top of your VM which does not really have the properties to
support those semantics.

There has been more research recently about multi-language VMs… or frameworks to build VMs (PyPy, for example). Without this support, getting 100% correct 
semantic *and* be fast enough (not even fast) is very hard.

  Marcus

Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

Marcus Denker-4
>
> But the problem is that the *semantics* are still that of Smalltalk, and it’s completely not clear for the programmer where the similarity ends.
>
> If you want to have “I can type in examples from my ruby book” compatibility, you need to implement the real semantics, which in many cases
> means to re-implement the VM of that other language (in a very slow version) on top of your VM which does not really have the properties to
> support those semantics.
>
Just imagine things like that...

https://www.destroyallsoftware.com/talks/wat

:-)

        Marcus


Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

Jan Vrany
In reply to this post by kilon.alios
On 25/11/13 20:12, kilon alios wrote:
> I don't see a problem. Sockets provide a way to communicate, sockets
> nowadays are used almost everywhere. They have their limitations but its
> a viable , very fast and simple solution.

OK, let's make an experiment and we'll see :-)

Here's the code that parses XML using Xerces on VM that
runs both Smalltalk and Java:

=======================
factory := JAVA javax xml parsers SAXParserFactory newInstance.
parser := factory newSAXParser getXMLReader.
parser setContentHandler: JavaExamples::CDDatabaseHandler2 new.
[
     parser parse: build_xml.
] on: JAVA java io IOException do:[:ioe|
     Transcript showCR: 'I/O error: ', ioe getMessage.
     ioe printStackTrace
] on: UserNotification do:[:un|
     Transcript showCR: un messageText.
     un proceed.
]
=======================

The handler:

https://bitbucket.org/janvrany/stx-libjava/src/e5fc3aaad7a2a9f06ba1f28e2144eb0acfb1ec13/examples/CDDatabaseHandler2.st?at=development


Now, you implement solution using sockets or any other kind
of RPC.

Then lets write a benchmark and check what's simpler and what's
faster. I would be very interested in results.

Anyway, we're getting bit offtopic I guess. If you want to do proposed
experiment, drop me a private message (unless the list shows
interest :-)

Best, Jan

P.S.: If you like the challenge, then consider small modification
of the code above **without** `un proceed` at the end of handler
of UserNotification.

Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

philippeback
In reply to this post by abergel
Speaking of which, I'd love to have a go at targeting Emscripten


We can do this by using llvm-gcc producing bitcode.

It may not be too hard to compile things, of course, the next challenge is with all the display and I/O.

But if they can do Unreal3, MESS emulators, and Commodore Emulators, we should be able to do a PharoVM.


Phil





On Mon, Nov 25, 2013 at 8:18 PM, Alexandre Bergel <[hidden email]> wrote:
Actually, do I want to have Pharo running on Java? My answer was ‘yes’ a couple of years before. Today, I want to have Pharo (or at least most of it) running in a web browser.

Distributing applications to clients is then so easy...

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On Nov 24, 2013, at 6:19 PM, askoh <[hidden email]> wrote:

> http://www.wired.com/wiredenterprise/2013/09/the-second-coming-of-java/
>
> The article talks about Java Virtual Machine running dynamic languages like
> Scala and Clojure in addition to Java. What prevents the Smalltalk Virtual
> Machine from running Java, Scala, Clojure and other JVM languages? Is that
> something we can ride on to greater awareness and usage of Smalltalk Virtual
> Machine and Smalltalk?
>
> All the best,
> Aik-Siong Koh
>
>
>
> --
> View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>



Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

Sven Van Caekenberghe-2
In reply to this post by Jan Vrany
Hi Jan,

On 25 Nov 2013, at 22:47, Jan Vrany <[hidden email]> wrote:

> Here's the code that parses XML using Xerces on VM that
> runs both Smalltalk and Java:
>
> =======================
> factory := JAVA javax xml parsers SAXParserFactory newInstance.
> parser := factory newSAXParser getXMLReader.
> parser setContentHandler: JavaExamples::CDDatabaseHandler2 new.
> [
>    parser parse: build_xml.
> ] on: JAVA java io IOException do:[:ioe|
>    Transcript showCR: 'I/O error: ', ioe getMessage.
>    ioe printStackTrace
> ] on: UserNotification do:[:un|
>    Transcript showCR: un messageText.
>    un proceed.
> ]
> =======================

This is really nice and beautiful code. Very well done !

Sven

Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

kilon.alios
In reply to this post by Jan Vrany
I am not familiar with the libraries you referring to nor I have messed with XML (thank god). 

I dont care which is faster I only care which is fast enough. 

I have never benchmarked my sockets but they always have been fast enough for my needs. 


10 seconds for 512 MB does not sound bad to me at all. But then if you want much higher speeds for even bigger data, then sockets are not for you. The data I have played with is in the range of kbs. 

Though I fear that smalltalk will be the bottleneck way before sockets will be. Unless you using a C library via nativeboost or another FFI.  


On Mon, Nov 25, 2013 at 11:47 PM, Jan Vrany <[hidden email]> wrote:
On 25/11/13 20:12, kilon alios wrote:
I don't see a problem. Sockets provide a way to communicate, sockets
nowadays are used almost everywhere. They have their limitations but its
a viable , very fast and simple solution.

OK, let's make an experiment and we'll see :-)

Here's the code that parses XML using Xerces on VM that
runs both Smalltalk and Java:

=======================
factory := JAVA javax xml parsers SAXParserFactory newInstance.
parser := factory newSAXParser getXMLReader.
parser setContentHandler: JavaExamples::CDDatabaseHandler2 new.
[
    parser parse: build_xml.
] on: JAVA java io IOException do:[:ioe|
    Transcript showCR: 'I/O error: ', ioe getMessage.
    ioe printStackTrace
] on: UserNotification do:[:un|
    Transcript showCR: un messageText.
    un proceed.
]
=======================

The handler:

https://bitbucket.org/janvrany/stx-libjava/src/e5fc3aaad7a2a9f06ba1f28e2144eb0acfb1ec13/examples/CDDatabaseHandler2.st?at=development


Now, you implement solution using sockets or any other kind
of RPC.

Then lets write a benchmark and check what's simpler and what's
faster. I would be very interested in results.

Anyway, we're getting bit offtopic I guess. If you want to do proposed
experiment, drop me a private message (unless the list shows
interest :-)

Best, Jan

P.S.: If you like the challenge, then consider small modification
of the code above **without** `un proceed` at the end of handler
of UserNotification.


Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

kilon.alios
In reply to this post by Marcus Denker-4
I have actually used PyPy , the socket bridge I had created was to make PyPy communicate with cpython embeded in the open source 3d application Blender and vice versa. I wanted to use PyPy to speed up blender cpython. Very friendly community too. AFAIK they had a Smalltalk implementation on top of PyPy but I dont think its maintained anymore. 


On Mon, Nov 25, 2013 at 10:27 PM, Marcus Denker <[hidden email]> wrote:

On 25 Nov 2013, at 21:13, kilon alios <[hidden email]> wrote:

I don't see a problem. Sockets provide a way to communicate, sockets nowadays are used almost everywhere. They have their limitations but its a viable , very fast and simple solution. 

Also you can use Redline Smalltalk -> http://www.redline.st/ if you want to run smalltalk on JVM.  

I vaguely remember that Squeak had the Ometa project that was working as a converter between languages , I think Java was supported. 

Keep in mind that supporting syntax is one thing, semantics is the other… Ometa is just a (very nice) tool for making implementing a parser for syntax easier, very much like PetitParser.
I once did a very, very naive demo of adding other *syntax* to Squeak…


But the problem is that the *semantics* are still that of Smalltalk, and it’s completely not clear for the programmer where the similarity ends.

If you want to have “I can type in examples from my ruby book” compatibility, you need to implement the real semantics, which in many cases
means to re-implement the VM of that other language (in a very slow version) on top of your VM which does not really have the properties to
support those semantics.

There has been more research recently about multi-language VMs… or frameworks to build VMs (PyPy, for example). Without this support, getting 100% correct 
semantic *and* be fast enough (not even fast) is very hard.

  Marcus


Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

askoh
Administrator
In reply to this post by Jan Vrany
Bravo Jan and your collaborators. You have done it.

Anything preventing STX:LIBJAVA from being used in production environments?
Anything preventing Pharo and VisualWorks for using the technology also?

Any plans to do the same for C# DotNET?

All the best,
Aik-Siong Koh
Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

Esteban A. Maringolo
In reply to this post by askoh
Hi,

I'm coming late to this. I don't fully share the vision of Java as a
language having a renaissance, I think it is a mature language, strict
by definition, but solid executionwise. So yes, it's a pain the a** to
develop with it, particularly having programmed with Smalltalk during
a decade.

In the server side, you can do decent stuff with almost any language.
The difference comes more from tooling and
instrumentation (integration with servers, monitoring, etc.). And that
comes with Time and Money as Elliot pointed.

I can talk about what you can do with Java in Android, and it's pretty
impressive.
Android took both Java and Linux and shipped it to the masses (end
users) as no java applet nor Linux distro ever did.

However the use I see in having a Smalltalk running on top of a JVM is
that because there are many chances that JVM will run in the "internet
of things", sensors, appliances and other devices that will come with
only one "platform" shipped from the vendor, and it will be either an
open "HTTP based API", or a full fledged native SDK for the system
running on top of the JVM.

To use Smalltalk in JavaScript Amber is doing a great work, and having
Pharo running in a Browser by means of emscripten or similar sounds
more like an interesting proof of concept rather than a true
advantage. Lively Kernel comes to my mind.

So I'm more interested in having Smalltalk (or Pharo) in the
forthcoming "internet of things" platform, that will be between us
sooner than later. And because of many things (Hi Oracle lobbist!)  I
think it will run on top of the JVM.

Regards!


Esteban A. Maringolo


2013/11/24 askoh <[hidden email]>:

> http://www.wired.com/wiredenterprise/2013/09/the-second-coming-of-java/
>
> The article talks about Java Virtual Machine running dynamic languages like
> Scala and Clojure in addition to Java. What prevents the Smalltalk Virtual
> Machine from running Java, Scala, Clojure and other JVM languages? Is that
> something we can ride on to greater awareness and usage of Smalltalk Virtual
> Machine and Smalltalk?
>
> All the best,
> Aik-Siong Koh
>
>
>
> --
> View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

kilon.alios
In reply to this post by Marcus Denker-4
ROFL thank you Marcus I needed a good laugh. 

I have watched this before, but as always completely forgot about it. I think its great when people don't take coding so seriously and have fun with it. 

I agree also that no pharoer would be against Java coming to pharo , the problem is who is going to do it. There so many great ideas out there, but actually doing the work is both hard and time consuming.  


On Mon, Nov 25, 2013 at 10:44 PM, Marcus Denker <[hidden email]> wrote:
>
> But the problem is that the *semantics* are still that of Smalltalk, and it’s completely not clear for the programmer where the similarity ends.
>
> If you want to have “I can type in examples from my ruby book” compatibility, you need to implement the real semantics, which in many cases
> means to re-implement the VM of that other language (in a very slow version) on top of your VM which does not really have the properties to
> support those semantics.
>
Just imagine things like that...

https://www.destroyallsoftware.com/talks/wat

:-)

        Marcus



Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

Jan Vrany
In reply to this post by askoh
On 26/11/13 03:28, askoh wrote:
> Bravo Jan and your collaborators. You have done it.

Thanks.
>
> Anything preventing STX:LIBJAVA from being used in production environments?

Good question. STX:LIBJAVA is still a research phase. However, if
everything goes fine, we might have first project using it for real
in couple months.

> Anything preventing Pharo and VisualWorks for using the technology also?
>
Short answer: Time and money.
The way we did it requires significant changes to the virtual machine
(as we believe this is the only way to get a decent performance).
Indeed, if somebody going to pay for it, everything's possible ;-)

> Any plans to do the same for C# DotNET?

No, unless we get substantial funding for yet another project :-)

Now I thing it would be better to continue discussing STX:LIBJAVA in
its mailing list [1] rather than here. So I encourage everyone who's
interested to move and continue there.

[1] https://groups.google.com/forum/#!forum/stxlibjava-dev

>
> All the best,
> Aik-Siong Koh
>
>
>
> --
> View this message in context: http://forum.world.st/The-Second-Coming-of-Java-article-tp4724932p4725246.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

SergeStinckwich
On Tue, Nov 26, 2013 at 10:54 AM, Jan Vrany <[hidden email]> wrote:

> On 26/11/13 03:28, askoh wrote:
>>
>> Bravo Jan and your collaborators. You have done it.
>
>
> Thanks.
>
>>
>> Anything preventing STX:LIBJAVA from being used in production
>> environments?
>
>
> Good question. STX:LIBJAVA is still a research phase. However, if everything
> goes fine, we might have first project using it for real
> in couple months.
>

What is important is also the licence. Do you use an open-source licence ?

>> Anything preventing Pharo and VisualWorks for using the technology also?
>>
> Short answer: Time and money.
> The way we did it requires significant changes to the virtual machine
> (as we believe this is the only way to get a decent performance). Indeed, if
> somebody going to pay for it, everything's possible ;-)

You should try to ask ESUG about financial support.

Regards,
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

Reply | Threaded
Open this post in threaded view
|

Re: The Second Coming of Java article

Jan Vrany
On 26/11/13 10:40, Serge Stinckwich wrote:

> On Tue, Nov 26, 2013 at 10:54 AM, Jan Vrany <[hidden email]> wrote:
>> On 26/11/13 03:28, askoh wrote:
>>>
>>> Bravo Jan and your collaborators. You have done it.
>>
>>
>> Thanks.
>>
>>>
>>> Anything preventing STX:LIBJAVA from being used in production
>>> environments?
>>
>>
>> Good question. STX:LIBJAVA is still a research phase. However, if everything
>> goes fine, we might have first project using it for real
>> in couple months.
>>
>
> What is important is also the licence. Do you use an open-source licence ?

Strictly speaking - no. For various, historical reasons.

The Smalltalk part STX:LIBJAVA support code is available under
the same terms as Smalltalk/X itself [1].

The code of the VM is not publicly available for various reasons,
though it is possible to get an access. Ask Claus Gittinger if
you're interested in details.

>
>>> Anything preventing Pharo and VisualWorks for using the technology also?
>>>
>> Short answer: Time and money.
>> The way we did it requires significant changes to the virtual machine
>> (as we believe this is the only way to get a decent performance). Indeed, if
>> somebody going to pay for it, everything's possible ;-)
>
> You should try to ask ESUG about financial support.
>

Maybe I should. But frankly - how many people in this community are like
"That would be great, I need this feature!" Raise hands. :-)

Cheers, Jan

[1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/README?view=markup


123