Java target -> JavaFX, Groovy, Scala etc. target ?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Java target -> JavaFX, Groovy, Scala etc. target ?

François Rey

The Java target is in the work, and from my understanding will be generating Java source files and not Java bytecode directly, ie it generates .java not .class files.

I'm sure this represents a substantial amount of work, as with any new target language.

I wonder though how feasible would it be to leverage the Java target work in order to produce targets for other languages targetting the JVM, such as JavaFX and Groovy or even Scala.

Could we imagine some base target framework to be derived into Java, JavaFX, Groovy, Scala etc.?

I guess JavaFX syntax is closer to haXe than to Java so I don't know how much of the Java generation logic could be reused. Groovy on the other hand is very similar to Java so I guess there should be some reuse in terms of generation logic. In any case all these JVM languages have access to Java libraries so the Java library integration should be reusable.

Finally, would anyone find it useful to have JavaFX, Groovy or Scala targets?

I guess the JavaFX target would be more in line with the domain haXe is originally targetting, ie rich graphical web app with animation.

Grovvy could also be an interesting target although I wonder why one would use haXe to target Groovy or Scala instead of writing in the original language. I would imagine Groovy to be an easier target than Java because of its support for dynamic typing, properties, and regular expressions. If the overall goal is to run haXe code on top of the JVM and to access the rich ecosystem of Java libraries, then Groovy could be an interesting intermediate layer. The prospect of easier integration with Grails could be of interest.

Feel free to comment, I'm just tossing off some ideas while waiting eagerly for the java target ;)


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Java target -> JavaFX, Groovy, Scala etc. target ?

Justin Donaldson
I really need to catch up on the java target, because my somewhat naive opinion is that compiling to bytecode (a la the swf targets) would be a pretty sensible way to go.  It seems like it would be the only way to allow haXe-ish dynamic variables... unless some sort of hack Map<String,T> workaround was used.  I can't imagine any sort of hack would have decent performance though.  The trade-off of course would be that java compilation optimization for its source is very mature, and is much more thought out than what Adobe seems to have done with AS3.

I strongly doubt Oracle will ever make any sort of requirement/suggestion that .java files are required for java applications in any specific context (although, after Apple's new dev contract for iPhones, I suppose anything is possible).  Does anyone know if there are any java specific source requirements for given embedded platforms? (e.g. blu-ray players).

I'm also eagerly awaiting the new source option as well, I think targetting the jvm by either approach (source or bytecode) will be a fantastic addition.

Best,
-Justin


2010/4/19 François Rey <lists.motion-twin.com@francois.rey.name>

The Java target is in the work, and from my understanding will be generating Java source files and not Java bytecode directly, ie it generates .java not .class files.

I'm sure this represents a substantial amount of work, as with any new target language.

I wonder though how feasible would it be to leverage the Java target work in order to produce targets for other languages targetting the JVM, such as JavaFX and Groovy or even Scala.

Could we imagine some base target framework to be derived into Java, JavaFX, Groovy, Scala etc.?

I guess JavaFX syntax is closer to haXe than to Java so I don't know how much of the Java generation logic could be reused. Groovy on the other hand is very similar to Java so I guess there should be some reuse in terms of generation logic. In any case all these JVM languages have access to Java libraries so the Java library integration should be reusable.

Finally, would anyone find it useful to have JavaFX, Groovy or Scala targets?

I guess the JavaFX target would be more in line with the domain haXe is originally targetting, ie rich graphical web app with animation.

Grovvy could also be an interesting target although I wonder why one would use haXe to target Groovy or Scala instead of writing in the original language. I would imagine Groovy to be an easier target than Java because of its support for dynamic typing, properties, and regular expressions. If the overall goal is to run haXe code on top of the JVM and to access the rich ecosystem of Java libraries, then Groovy could be an interesting intermediate layer. The prospect of easier integration with Grails could be of interest.

Feel free to comment, I'm just tossing off some ideas while waiting eagerly for the java target ;)


--
haXe - an open source web programming language
http://haxe.org



--
Justin Donaldson
PhD Candidate, Informatics
Indiana University
http://www.scwn.net
aim: iujjd
twitter: jjdonald

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Java target -> JavaFX, Groovy, Scala etc. target ?

Pimm Hogeling
On Mon, Apr 19, 2010 at 16:58, Justin Donaldson <[hidden email]> wrote:
I really need to catch up on the java target, because my somewhat naive opinion is that compiling to bytecode (a la the swf targets) would be a pretty sensible way to go.  It seems like it would be the only way to allow haXe-ish dynamic variables... unless some sort of hack Map<String,T> workaround was used.  I can't imagine any sort of hack would have decent performance though.  The trade-off of course would be that java compilation optimization for its source is very mature, and is much more thought out than what Adobe seems to have done with AS3.
For clarifications, some are working on a Java source code target. As mentioned, this allows us to use one of the very good Java compilers out there, which will hopefully optimise the binaries. There is an other advantage, though: Java source code can be compiled to other things than just JVM binaries. GWT, for instance, allows us to compile Java source code to rich internet applications.

There are, also as mentioned, some problems with haXe's loose typing and dynamicness.

On Mon, Apr 19, 2010 at 16:58, Justin Donaldson <[hidden email]> wrote:
I strongly doubt Oracle will ever make any sort of requirement/suggestion that .java files are required for java applications in any specific context (although, after Apple's new dev contract for iPhones, I suppose anything is possible).  Does anyone know if there are any java specific source requirements for given embedded platforms? (e.g. blu-ray players).
I strongly doubt anything like that will happen, too.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Java target -> JavaFX, Groovy, Scala etc. target ?

Bruno Garcia
On 04/19/2010 09:05 AM, Pimm Hogeling wrote:

> On Mon, Apr 19, 2010 at 16:58, Justin Donaldson <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     I really need to catch up on the java target, because my somewhat
>     naive opinion is that compiling to bytecode (a la the swf targets)
>     would be a pretty sensible way to go.  It seems like it would be the
>     only way to allow haXe-ish dynamic variables... unless some sort of
>     hack Map<String,T> workaround was used.  I can't imagine any sort of
>     hack would have decent performance though.  The trade-off of course
>     would be that java compilation optimization for its source is very
>     mature, and is much more thought out than what Adobe seems to have
>     done with AS3.
>
> For clarifications, some are working on a Java source code target. As
> mentioned, this allows us to use one of the very good Java compilers out
> there, which will hopefully optimise the binaries. There is an other
> advantage, though: Java source code can be compiled to other things than
> just JVM binaries. GWT, for instance, allows us to compile Java source
> code to rich internet applications.
>
> There are, also as mentioned, some problems with haXe's loose typing and
> dynamicness.

Have you looked into the dynamic languages (InvokeDynamic, etc) features
of Java 1.7? Though you would have to measure the benefits (potentially
large in ease of implementation and performance) against the requirement
of having a newer jvm.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Java target -> JavaFX, Groovy, Scala etc. target ?

Justin Donaldson
Hey thanks... I thought I had remembered some kind of newly introduced dynamic aspect for java, but I couldn't remember the actual keyword.

Requiring a new version of the jvm is not such a big deal atm.  It's much easier to convince hosting providers to update java than it is to install something... say... neko.

Java is an interesting target because I get the impression it might stagnate a bit after this 1.7 release (due to the Oracle acquisition). 
http://www.pcworld.com/businesscenter/article/194165/google_exec_worries_over_rudderless_java.html

There are already alternate languages that are breathing new life into Java, like Scala and Groovy.  However, haXe seems to fit a slightly different niche... perhaps being closer to Java syntax than the other two.  Some folks might be more attracted to that, and some of haXe's other language features.

-Justin

On Mon, Apr 19, 2010 at 3:40 PM, Bruno Garcia <[hidden email]> wrote:
On 04/19/2010 09:05 AM, Pimm Hogeling wrote:
On Mon, Apr 19, 2010 at 16:58, Justin Donaldson <[hidden email]
<mailto:[hidden email]>> wrote:

   I really need to catch up on the java target, because my somewhat
   naive opinion is that compiling to bytecode (a la the swf targets)
   would be a pretty sensible way to go.  It seems like it would be the
   only way to allow haXe-ish dynamic variables... unless some sort of
   hack Map<String,T> workaround was used.  I can't imagine any sort of
   hack would have decent performance though.  The trade-off of course
   would be that java compilation optimization for its source is very
   mature, and is much more thought out than what Adobe seems to have
   done with AS3.

For clarifications, some are working on a Java source code target. As
mentioned, this allows us to use one of the very good Java compilers out
there, which will hopefully optimise the binaries. There is an other
advantage, though: Java source code can be compiled to other things than
just JVM binaries. GWT, for instance, allows us to compile Java source
code to rich internet applications.

There are, also as mentioned, some problems with haXe's loose typing and
dynamicness.

Have you looked into the dynamic languages (InvokeDynamic, etc) features of Java 1.7? Though you would have to measure the benefits (potentially large in ease of implementation and performance) against the requirement of having a newer jvm.

--
haXe - an open source web programming language
http://haxe.org



--
Justin Donaldson
PhD Candidate, Informatics
Indiana University
http://www.scwn.net
aim: iujjd
twitter: jjdonald

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Java target -> JavaFX, Groovy, Scala etc. target ?

Stefan Scholl
Justin Donaldson <[hidden email]> wrote:
> Hey thanks... I thought I had remembered some kind of newly introduced
> dynamic aspect for java, but I couldn't remember the actual keyword.
>
> Requiring a new version of the jvm is not such a big deal atm.  It's much
> easier to convince hosting providers to update java than it is to install
> something... say... neko.

But will it be supported by the Dalvik virtual machine (Android)?


--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
<!--[if IE 6]><script>for(x in document.open);</script><![endif]-->


--
haXe - an open source web programming language
http://haxe.org