www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Running D in the Java VM

reply "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
Hey everyone!

I have been experimenting for the past couple of days with an 
idea I had, and since I recently made a little progress I thought 
I would share some of what I have been doing with you. What I 
have done, in a nutshell, is began the process for a language 
converter that takes D source files, converts them into Java 
source files, and then compiles them as Java class files so that 
they can be ran on Java's VM. It is extremely limited in what it 
can do right now, only being able to convert/compile a simple 
Hello World program, but I was proud of myself for getting even 
that far so I wanted to brag. :P

You may want to ask, "Hey, man. D is a great language. Why would 
I ever want to convert it to Java?" Normally, you wouldn't. Java 
blows. What I am envisioning for this project is something quite 
magical in my opinion. If we can take D code and have it compile 
into Java class files, we can then compile them into Android dex 
files. This would make D able to build and run on Android devices 
through its VM. Sure, people are working on getting D to compile 
to ARM binaries, but this could be another option as a Java 
alternative on Android.(eventually)

Unfortunately I do not know much about compilers, but even in the 
last couple of days I feel like I have learned a great deal about 
what kinds of stuff goes into them. Eventually I'd like to make a 
full blown compiler that takes D code and can go right to dex 
files, but that would be something that would happen way down the 
road. In order to get D working on Android sooner, I figured a 
language converter would be the easier route.

I can, and would love to go in to more detail about this, but it 
is getting late and this post is already quite long. Maybe I 
should start a blog about my D escapades? Anyways, I would love 
to hear feedback on this idea! Thanks for your time!
Nov 14 2013
next sibling parent reply Timur Gafarov <gecko0307 gmail.com> writes:
15.11.2013 10:13, Jeremy DeHaan пишет:

 Hey everyone!

 I have been experimenting for the past couple of days with an idea I
 had, and since I recently made a little progress I thought I would share
 some of what I have been doing with you. What I have done, in a
 nutshell, is began the process for a language converter that takes D
 source files, converts them into Java source files, and then compiles
 them as Java class files so that they can be ran on Java's VM. It is
 extremely limited in what it can do right now, only being able to
 convert/compile a simple Hello World program, but I was proud of myself
 for getting even that far so I wanted to brag. :P

 You may want to ask, "Hey, man. D is a great language. Why would I ever
 want to convert it to Java?" Normally, you wouldn't. Java blows. What I
 am envisioning for this project is something quite magical in my
 opinion. If we can take D code and have it compile into Java class
 files, we can then compile them into Android dex files. This would make
 D able to build and run on Android devices through its VM. Sure, people
 are working on getting D to compile to ARM binaries, but this could be
 another option as a Java alternative on Android.(eventually)

 Unfortunately I do not know much about compilers, but even in the last
 couple of days I feel like I have learned a great deal about what kinds
 of stuff goes into them. Eventually I'd like to make a full blown
 compiler that takes D code and can go right to dex files, but that would
 be something that would happen way down the road. In order to get D
 working on Android sooner, I figured a language converter would be the
 easier route.

 I can, and would love to go in to more detail about this, but it is
 getting late and this post is already quite long. Maybe I should start a
 blog about my D escapades? Anyways, I would love to hear feedback on
 this idea! Thanks for your time!


Maybe it would be better to compile D directly into JVM/Dalvik bytecode?
Nov 14 2013
parent "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Friday, 15 November 2013 at 07:30:07 UTC, Timur Gafarov wrote:

 Maybe it would be better to compile D directly into JVM/Dalvik 
 bytecode?


Oh, absolutely. Like I said though, I don't really know that much 
about compilers so I decided to go this route. Also, it's 
actually been a pretty fun project so far and I see no reason to 
do it a different way right now.
Nov 14 2013
prev sibling next sibling parent reply Rory McGuire <rjmcguire gmail.com> writes:
On Fri, Nov 15, 2013 at 9:13 AM, Jeremy DeHaan <dehaan.jeremiah gmail.com>wrote:


 I can, and would love to go in to more detail about this, but it is
 getting late and this post is already quite long. Maybe I should start a
 blog about my D escapades? Anyways, I would love to hear feedback on this
 idea! Thanks for your time!


Nice one, I have to use Java at work, it would be awesome if I didn't have
to.
Would be cool if you make it so that the outputs to java are just trasforms
of the AST that way people could write other types of output such as C.
Nov 14 2013
parent "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Friday, 15 November 2013 at 07:44:20 UTC, Rory McGuire wrote:

 On Fri, Nov 15, 2013 at 9:13 AM, Jeremy DeHaan 
 <dehaan.jeremiah gmail.com>wrote:


 I can, and would love to go in to more detail about this, but 
 it is
 getting late and this post is already quite long. Maybe I 
 should start a
 blog about my D escapades? Anyways, I would love to hear 
 feedback on this
 idea! Thanks for your time!


 Nice one, I have to use Java at work, it would be awesome if I 
 didn't have
 to.
 Would be cool if you make it so that the outputs to java are 
 just trasforms
 of the AST that way people could write other types of output 
 such as C.


I don't know if I would ever want to set it up for other 
languages, but currently it is just modifying the D AST, then 
taking that information to create the Java source files. Java and 
D have enough similarities to where that has been pretty straight 
forward thus far. My only problems have been AST related since 
that whole side of things is totally new to me. Brian Schott's 
Dscanner stuff has made it much easier though.

I'd like to write an article somewhere about how it works just 
because I think it's an interesting enough topic, but not sure 
where yet. Especially since I don't have anything for people to 
try out.
Nov 15 2013
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 15 November 2013 at 07:13:34 UTC, Jeremy DeHaan wrote:

 Hey everyone!

 I have been experimenting for the past couple of days with an 
 idea I had, and since I recently made a little progress I 
 thought I would share some of what I have been doing with you. 
 What I have done, in a nutshell, is began the process for a 
 language converter that takes D source files, converts them 
 into Java source files, and then compiles them as Java class 
 files so that they can be ran on Java's VM. It is extremely 
 limited in what it can do right now, only being able to 
 convert/compile a simple Hello World program, but I was proud 
 of myself for getting even that far so I wanted to brag. :P

 You may want to ask, "Hey, man. D is a great language. Why 
 would I ever want to convert it to Java?" Normally, you 
 wouldn't. Java blows. What I am envisioning for this project is 
 something quite magical in my opinion. If we can take D code 
 and have it compile into Java class files, we can then compile 
 them into Android dex files. This would make D able to build 
 and run on Android devices through its VM. Sure, people are 
 working on getting D to compile to ARM binaries, but this could 
 be another option as a Java alternative on Android.(eventually)

 Unfortunately I do not know much about compilers, but even in 
 the last couple of days I feel like I have learned a great deal 
 about what kinds of stuff goes into them. Eventually I'd like 
 to make a full blown compiler that takes D code and can go 
 right to dex files, but that would be something that would 
 happen way down the road. In order to get D working on Android 
 sooner, I figured a language converter would be the easier 
 route.

 I can, and would love to go in to more detail about this, but 
 it is getting late and this post is already quite long. Maybe I 
 should start a blog about my D escapades? Anyways, I would love 
 to hear feedback on this idea! Thanks for your time!


It is an impossible task, because many of the D semantics cannot 
be expressed in JVM/Dalvik bytecode.

--
Paulo
Nov 15 2013
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 15 November 2013 at 08:50:14 UTC, Paulo Pinto wrote:

 On Friday, 15 November 2013 at 07:13:34 UTC, Jeremy DeHaan 
 wrote:

 Hey everyone!

 I have been experimenting for the past couple of days with an 
 idea I had, and since I recently made a little progress I 
 thought I would share some of what I have been doing with you. 
 What I have done, in a nutshell, is began the process for a 
 language converter that takes D source files, converts them 
 into Java source files, and then compiles them as Java class 
 files so that they can be ran on Java's VM. It is extremely 
 limited in what it can do right now, only being able to 
 convert/compile a simple Hello World program, but I was proud 
 of myself for getting even that far so I wanted to brag. :P

 You may want to ask, "Hey, man. D is a great language. Why 
 would I ever want to convert it to Java?" Normally, you 
 wouldn't. Java blows. What I am envisioning for this project 
 is something quite magical in my opinion. If we can take D 
 code and have it compile into Java class files, we can then 
 compile them into Android dex files. This would make D able to 
 build and run on Android devices through its VM. Sure, people 
 are working on getting D to compile to ARM binaries, but this 
 could be another option as a Java alternative on 
 Android.(eventually)

 Unfortunately I do not know much about compilers, but even in 
 the last couple of days I feel like I have learned a great 
 deal about what kinds of stuff goes into them. Eventually I'd 
 like to make a full blown compiler that takes D code and can 
 go right to dex files, but that would be something that would 
 happen way down the road. In order to get D working on Android 
 sooner, I figured a language converter would be the easier 
 route.

 I can, and would love to go in to more detail about this, but 
 it is getting late and this post is already quite long. Maybe 
 I should start a blog about my D escapades? Anyways, I would 
 love to hear feedback on this idea! Thanks for your time!


 It is an impossible task, because many of the D semantics 
 cannot be expressed in JVM/Dalvik bytecode.

 --
 Paulo


Like what? Barring low-level device access, they are both turing 
complete languages and given the necessary transformations a 
complete program in one can always be statically* translated to 
the one in the other. However, efficient java code would be a 
different matter.

*very important. There are many code-level concepts in D that are 
not expressible in the JVM, but a static translation doesn't need 
to honor those: it simply needs to make a program that has the 
same observable effects for any given input. This is definitely 
possible, although quite possibly monstrously involved when done 
in detail.
Nov 15 2013
parent Rory McGuire <rjmcguire gmail.com> writes:
Surely the main requirements would be gui and networking? Which would be
completely possible.
 On 15 Nov 2013 12:05, "John Colvin" <john.loughran.colvin gmail.com> wrote:


 On Friday, 15 November 2013 at 08:50:14 UTC, Paulo Pinto wrote:


 On Friday, 15 November 2013 at 07:13:34 UTC, Jeremy DeHaan wrote:


 Hey everyone!

 I have been experimenting for the past couple of days with an idea I
 had, and since I recently made a little progress I thought I would share
 some of what I have been doing with you. What I have done, in a nutshell,
 is began the process for a language converter that takes D source files,
 converts them into Java source files, and then compiles them as Java class
 files so that they can be ran on Java's VM. It is extremely limited in what
 it can do right now, only being able to convert/compile a simple Hello
 World program, but I was proud of myself for getting even that far so I
 wanted to brag. :P

 You may want to ask, "Hey, man. D is a great language. Why would I ever
 want to convert it to Java?" Normally, you wouldn't. Java blows. What I am
 envisioning for this project is something quite magical in my opinion. If
 we can take D code and have it compile into Java class files, we can then
 compile them into Android dex files. This would make D able to build and
 run on Android devices through its VM. Sure, people are working on getting
 D to compile to ARM binaries, but this could be another option as a Java
 alternative on Android.(eventually)

 Unfortunately I do not know much about compilers, but even in the last
 couple of days I feel like I have learned a great deal about what kinds of
 stuff goes into them. Eventually I'd like to make a full blown compiler
 that takes D code and can go right to dex files, but that would be
 something that would happen way down the road. In order to get D working on
 Android sooner, I figured a language converter would be the easier route.

 I can, and would love to go in to more detail about this, but it is
 getting late and this post is already quite long. Maybe I should start a
 blog about my D escapades? Anyways, I would love to hear feedback on this
 idea! Thanks for your time!


 It is an impossible task, because many of the D semantics cannot be
 expressed in JVM/Dalvik bytecode.

 --
 Paulo


 Like what? Barring low-level device access, they are both turing complete
 languages and given the necessary transformations a complete program in one
 can always be statically* translated to the one in the other. However,
 efficient java code would be a different matter.

 *very important. There are many code-level concepts in D that are not
 expressible in the JVM, but a static translation doesn't need to honor
 those: it simply needs to make a program that has the same observable
 effects for any given input. This is definitely possible, although quite
 possibly monstrously involved when done in detail.
Nov 15 2013
prev sibling parent reply "Kai Nacke" <kai redstar.de> writes:
On Friday, 15 November 2013 at 08:50:14 UTC, Paulo Pinto wrote:

 It is an impossible task, because many of the D semantics 
 cannot be expressed in JVM/Dalvik bytecode.


People are always targeting the impossible.
See http://nestedvm.ibex.org/ or 
http://da.vidr.cc/projects/lljvm/ as projects to express C in JVM 
bytecode.

Serious, the only problem is inline assembler. Everything else 
can be translated to JVM byte code.

Regards,
Kai
Nov 15 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 15.11.2013 15:03, schrieb Kai Nacke:

 On Friday, 15 November 2013 at 08:50:14 UTC, Paulo Pinto wrote:

 It is an impossible task, because many of the D semantics cannot be
 expressed in JVM/Dalvik bytecode.


 People are always targeting the impossible.
 See http://nestedvm.ibex.org/ or http://da.vidr.cc/projects/lljvm/ as
 projects to express C in JVM bytecode.

 Serious, the only problem is inline assembler. Everything else can be
 translated to JVM byte code.

 Regards,
 Kai


Thanks for showing me wrong, my statement was based on previous memories 
of failed attempts to target the JVM from C code.

Should have thought better before posting.

--
Paulo
Nov 15 2013
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
On Fri, 2013-11-15 at 09:44 +0200, Rory McGuire wrote:
[…]

 Nice one, I have to use Java at work, it would be awesome if I didn't have
 to.
 Would be cool if you make it so that the outputs to java are just trasforms
 of the AST that way people could write other types of output such as C.


Just use Scala, Ceylon, Kotlin or statically compiled Groovy instead of
Java. Everyone I know who has ever tried it has never looked back.

Management can be handled easily since all the languages interwork well
with Java, so change over to a new language is incremental, it does not
require a revolution.

Java is dead, long live the JVM.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 15 2013
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2013-11-15 at 08:13 +0100, Jeremy DeHaan wrote:

 Hey everyone!
 
 I have been experimenting for the past couple of days with an 
 idea I had, and since I recently made a little progress I thought 
 I would share some of what I have been doing with you. What I 
 have done, in a nutshell, is began the process for a language 
 converter that takes D source files, converts them into Java 
 source files, and then compiles them as Java class files so that 
 they can be ran on Java's VM. It is extremely limited in what it 
 can do right now, only being able to convert/compile a simple 
 Hello World program, but I was proud of myself for getting even 
 that far so I wanted to brag. :P


Well done for having a go and getting somewhere with it, and hopefully
having some fun. However I am not sure this approach will lead to
anything that could go into general production. As others have pointed
out D → Java, source to source translation is probably not the best way
of getting D code to run on JVM. Scala, Groovy and Kotlin compile direct
to class files, i.e. generate JVM bytecode directly. Ceylon also
compiles to bytecode but not to class files. The point here is that Java
source cannot really encode much of the D semantics, whereas they can be
encoded in JVM bytecodes. Now that the JVM has method handles and
invokedynamic, the previous history of how to support non-Java code is
irrelevant: Scala's compilation strategy predates this JVM technology
and it shows; Java 8, Ceylon, Groovy, and Kotlin are using the new JVM
technology to great effect.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 15 2013
parent reply "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Friday, 15 November 2013 at 14:41:32 UTC, Russel Winder wrote:

 On Fri, 2013-11-15 at 08:13 +0100, Jeremy DeHaan wrote:

 Hey everyone!
 
 I have been experimenting for the past couple of days with an 
 idea I had, and since I recently made a little progress I 
 thought I would share some of what I have been doing with you. 
 What I have done, in a nutshell, is began the process for a 
 language converter that takes D source files, converts them 
 into Java source files, and then compiles them as Java class 
 files so that they can be ran on Java's VM. It is extremely 
 limited in what it can do right now, only being able to 
 convert/compile a simple Hello World program, but I was proud 
 of myself for getting even that far so I wanted to brag. :P


 Well done for having a go and getting somewhere with it, and 
 hopefully
 having some fun. However I am not sure this approach will lead 
 to
 anything that could go into general production. As others have 
 pointed
 out D → Java, source to source translation is probably not the 
 best way
 of getting D code to run on JVM. Scala, Groovy and Kotlin 
 compile direct
 to class files, i.e. generate JVM bytecode directly. Ceylon also
 compiles to bytecode but not to class files. The point here is 
 that Java
 source cannot really encode much of the D semantics, whereas 
 they can be
 encoded in JVM bytecodes. Now that the JVM has method handles 
 and
 invokedynamic, the previous history of how to support non-Java 
 code is
 irrelevant: Scala's compilation strategy predates this JVM 
 technology
 and it shows; Java 8, Ceylon, Groovy, and Kotlin are using the 
 new JVM
 technology to great effect.


It is a surprising amount of fun for me actually. I usually work 
on game development stuff(most currently DSFML), so it is a nice 
change of pace. It started as something that I thought could be 
production worthy, but who knows? Since for the long term I want 
this to only be used for Android compilation and not general Java 
VM stuff I was considering making use of version(Android) to 
separate things that are and aren't possible when going from D to 
Java.

In any case, I'll keep working on it more as a 
knowledge/experience gaining project than anything else. So far 
it has been awesome at that for me. If it really starts to look 
good though I will see if I can get people to start using it. ;)
Nov 15 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 15.11.2013 19:39, schrieb Jeremy DeHaan:

 On Friday, 15 November 2013 at 14:41:32 UTC, Russel Winder wrote:

 On Fri, 2013-11-15 at 08:13 +0100, Jeremy DeHaan wrote:

 Hey everyone!

 I have been experimenting for the past couple of days with an idea I
 had, and since I recently made a little progress I thought I would
 share some of what I have been doing with you. What I have done, in a
 nutshell, is began the process for a language converter that takes D
 source files, converts them into Java source files, and then compiles
 them as Java class files so that they can be ran on Java's VM. It is
 extremely limited in what it can do right now, only being able to
 convert/compile a simple Hello World program, but I was proud of
 myself for getting even that far so I wanted to brag. :P


 Well done for having a go and getting somewhere with it, and hopefully
 having some fun. However I am not sure this approach will lead to
 anything that could go into general production. As others have pointed
 out D → Java, source to source translation is probably not the best way
 of getting D code to run on JVM. Scala, Groovy and Kotlin compile direct
 to class files, i.e. generate JVM bytecode directly. Ceylon also
 compiles to bytecode but not to class files. The point here is that Java
 source cannot really encode much of the D semantics, whereas they can be
 encoded in JVM bytecodes. Now that the JVM has method handles and
 invokedynamic, the previous history of how to support non-Java code is
 irrelevant: Scala's compilation strategy predates this JVM technology
 and it shows; Java 8, Ceylon, Groovy, and Kotlin are using the new JVM
 technology to great effect.


 It is a surprising amount of fun for me actually. I usually work on game
 development stuff(most currently DSFML), so it is a nice change of pace.
 It started as something that I thought could be production worthy, but
 who knows? Since for the long term I want this to only be used for
 Android compilation and not general Java VM stuff I was considering
 making use of version(Android) to separate things that are and aren't
 possible when going from D to Java.

 In any case, I'll keep working on it more as a knowledge/experience
 gaining project than anything else. So far it has been awesome at that
 for me. If it really starts to look good though I will see if I can get
 people to start using it. ;)


As info, Dalvik might go away in newer versions of Android following KitKat.

Google has a new backend that AOTs Java code, called ART. It is still 
developer quality though.

http://source.android.com/devices/tech/dalvik/art.html

http://readwrite.com/2013/11/07/google-says-it-could-replace-dalvik-runtime-in-next-version-of-android#awesm=~oni0ryCdWaEmK8

https://news.ycombinator.com/item?id=6655582

--
Paulo
Nov 15 2013
prev sibling next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
I am *VERY MUCH* interested in this, so count me in. I will gladly join 
this project!
Nov 16 2013
prev sibling next sibling parent reply John J <john.joyus gmail.com> writes:
On 11/15/2013 02:13 AM, Jeremy DeHaan wrote:

 You may want to ask, "Hey, man. D is a great language. Why would I ever
 want to convert it to Java?" Normally, you wouldn't. Java blows. What I
 am envisioning for this project is something quite magical in my
 opinion. If we can take D code and have it compile into Java class
 files, we can then compile them into Android dex files. This would make
 D able to build and run on Android devices through its VM. Sure, people
 are working on getting D to compile to ARM binaries, but this could be
 another option as a Java alternative on Android.(eventually)


My guess is, D will compile to ARM binaries sooner than you could 
complete your D2Java project. Even if you could beat it by an year, 
people would instantly switch to D -> ARM route the moment it's available.

If it should survive as an alternative, Jave should have some more 
advantages over D, even after the D compiles to ARM.
Nov 16 2013
next sibling parent "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Sunday, 17 November 2013 at 05:49:43 UTC, John J wrote:

 On 11/15/2013 02:13 AM, Jeremy DeHaan wrote:

 You may want to ask, "Hey, man. D is a great language. Why 
 would I ever
 want to convert it to Java?" Normally, you wouldn't. Java 
 blows. What I
 am envisioning for this project is something quite magical in 
 my
 opinion. If we can take D code and have it compile into Java 
 class
 files, we can then compile them into Android dex files. This 
 would make
 D able to build and run on Android devices through its VM. 
 Sure, people
 are working on getting D to compile to ARM binaries, but this 
 could be
 another option as a Java alternative on Android.(eventually)


 My guess is, D will compile to ARM binaries sooner than you 
 could complete your D2Java project. Even if you could beat it 
 by an year, people would instantly switch to D -> ARM route the 
 moment it's available.

 If it should survive as an alternative, Jave should have some 
 more advantages over D, even after the D compiles to ARM.


Yeah, with ARM in development I wasn't sure if I should continue, 
which is one of the reasons I only got as far as I did. I 
remembered reading something about using native code for Android 
on the official site, which was something along the lines of "Use 
only for performance critical code, in most cases it won't help, 
blah blah blah" so I figured that this route should be fine in 
terms of performance and what not.

In any case, I have an event I have to organize coming up so I 
wouldn't be able to continue working on this until next year at 
the earliest. It was nice to get some feedback from people 
though. Maybe I'll post again if I have something that I can get 
to compile on Android. :P
Nov 20 2013
prev sibling parent reply "Volcz" <volcz kth.se> writes:
On Sunday, 17 November 2013 at 05:49:43 UTC, John J wrote:

 On 11/15/2013 02:13 AM, Jeremy DeHaan wrote:
 If it should survive as an alternative, Jave should have some 
 more advantages over D, even after the D compiles to ARM.


The Android NDK is only a second class citizen compared to the 
Java SDK. The only use case I have heard of for the NDK is when 
companies have a small C library with common functionality to 
make porting the products to other platforms easier.
Nov 20 2013
next sibling parent reply John J <john.joyus gmail.com> writes:
On 11/21/2013 02:35 AM, Volcz wrote:

 On Sunday, 17 November 2013 at 05:49:43 UTC, John J wrote:

 On 11/15/2013 02:13 AM, Jeremy DeHaan wrote:
 If it should survive as an alternative, Jave should have some more
 advantages over D, even after the D compiles to ARM.


 The Android NDK is only a second class citizen compared to the Java SDK.
 The only use case I have heard of for the NDK is when companies have a
 small C library with common functionality to make porting the products
 to other platforms easier.


I thought NDK would be faster. If that's not the case, then I am mistaken.
I also shouldn't discourage the OP. It's a fun project nevertheless.
Nov 21 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 21.11.2013 16:34, schrieb John J:

 On 11/21/2013 02:35 AM, Volcz wrote:

 On Sunday, 17 November 2013 at 05:49:43 UTC, John J wrote:

 On 11/15/2013 02:13 AM, Jeremy DeHaan wrote:
 If it should survive as an alternative, Jave should have some more
 advantages over D, even after the D compiles to ARM.


 The Android NDK is only a second class citizen compared to the Java SDK.
 The only use case I have heard of for the NDK is when companies have a
 small C library with common functionality to make porting the products
 to other platforms easier.


 I thought NDK would be faster. If that's not the case, then I am mistaken.
 I also shouldn't discourage the OP. It's a fun project nevertheless.


So far the Android team has been very vocal against use of C and C++ in 
Android, given the Sun background of many top level developers, most likely.

It is seen as a necessary evil for game development and porting of 
legacy code.

You only have access to the indispensable set of APIs for game 
development, for everything else you need to use JNI for the Java APIs.

Native code is actually loaded as a shared object into a DalvikVM 
process. An App entry point is always Java code.

Even the new gaming APIs, the Android version of XBox Live, only have a 
Java based implementation.

In KitKat they introduced a new compiler for Java, which performs AOT 
compilation to native code via LLVM, called ART. It is still considered 
experimental and is planned to replace DalvikVM in a future release.

So far, from the three major mobile OS, Android is the one more hostile 
to native code, this might change of course.

This is very easy to verify, you just need to check the NDK mailing list 
or the respective documentation.

--
Paulo
Nov 21 2013
prev sibling parent reply "inout" <inout gmail.com> writes:
On Thursday, 21 November 2013 at 07:35:01 UTC, Volcz wrote:

 On Sunday, 17 November 2013 at 05:49:43 UTC, John J wrote:

 On 11/15/2013 02:13 AM, Jeremy DeHaan wrote:
 If it should survive as an alternative, Jave should have some 
 more advantages over D, even after the D compiles to ARM.


 The Android NDK is only a second class citizen compared to the 
 Java SDK. The only use case I have heard of for the NDK is when 
 companies have a small C library with common functionality to 
 make porting the products to other platforms easier.


That's not true. Most games are written entirely with NDK. Many 
applications, too (the app my team shipped recently contains a 
fair amount of C++ code in it, and it only grows).
Nov 21 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 21.11.2013 21:25, schrieb inout:

 On Thursday, 21 November 2013 at 07:35:01 UTC, Volcz wrote:

 On Sunday, 17 November 2013 at 05:49:43 UTC, John J wrote:

 On 11/15/2013 02:13 AM, Jeremy DeHaan wrote:
 If it should survive as an alternative, Jave should have some more
 advantages over D, even after the D compiles to ARM.


 The Android NDK is only a second class citizen compared to the Java
 SDK. The only use case I have heard of for the NDK is when companies
 have a small C library with common functionality to make porting the
 products to other platforms easier.


 That's not true. Most games are written entirely with NDK. Many
 applications, too (the app my team shipped recently contains a fair
 amount of C++ code in it, and it only grows).


NDK only covers game related APIs, mostly.

How much JNI calls do you make in standard applications?

--
Paulo
Nov 21 2013
next sibling parent reply "inout" <inout gmail.com> writes:
On Thursday, 21 November 2013 at 22:02:14 UTC, Paulo Pinto wrote:

 Am 21.11.2013 21:25, schrieb inout:

 On Thursday, 21 November 2013 at 07:35:01 UTC, Volcz wrote:

 On Sunday, 17 November 2013 at 05:49:43 UTC, John J wrote:

 On 11/15/2013 02:13 AM, Jeremy DeHaan wrote:
 If it should survive as an alternative, Jave should have 
 some more
 advantages over D, even after the D compiles to ARM.


 The Android NDK is only a second class citizen compared to 
 the Java
 SDK. The only use case I have heard of for the NDK is when 
 companies
 have a small C library with common functionality to make 
 porting the
 products to other platforms easier.


 That's not true. Most games are written entirely with NDK. Many
 applications, too (the app my team shipped recently contains a 
 fair
 amount of C++ code in it, and it only grows).


 NDK only covers game related APIs, mostly.

 How much JNI calls do you make in standard applications?

 --
 Paulo


Everything accessible from Java is also accessible from NDK (by 
using reflection or by calling Java code from C++), so saying 
"NDK only covers game related APIs" is somewhat wrong.

I can only tell about our application, but it has a lot of JNI 
code. It is mostly used as a message passing mechanism between  
Java and C++ (which live in separate threads so that Java GC 
doesn't stop native code execution).

It's still experimental, but offloading some of the Java logic to 
C++ gave as a significant performance boost, especially 
noticeable on low-end devices.

A good example of the Java/C++ mix is a Chrome browser in 
Android. I'd say it's 50% Java/50% C++ (not counting the WebKit 
part).
Nov 21 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 21.11.2013 23:33, schrieb inout:

 On Thursday, 21 November 2013 at 22:02:14 UTC, Paulo Pinto wrote:

 Am 21.11.2013 21:25, schrieb inout:

 On Thursday, 21 November 2013 at 07:35:01 UTC, Volcz wrote:

 On Sunday, 17 November 2013 at 05:49:43 UTC, John J wrote:

 On 11/15/2013 02:13 AM, Jeremy DeHaan wrote:
 If it should survive as an alternative, Jave should have some more
 advantages over D, even after the D compiles to ARM.


 The Android NDK is only a second class citizen compared to the Java
 SDK. The only use case I have heard of for the NDK is when companies
 have a small C library with common functionality to make porting the
 products to other platforms easier.


 That's not true. Most games are written entirely with NDK. Many
 applications, too (the app my team shipped recently contains a fair
 amount of C++ code in it, and it only grows).


 NDK only covers game related APIs, mostly.

 How much JNI calls do you make in standard applications?

 --
 Paulo


 Everything accessible from Java is also accessible from NDK (by using
 reflection or by calling Java code from C++), so saying "NDK only covers
 game related APIs" is somewhat wrong.


I know, but I was addressing it from the pure point of view. Specially 
when you compare C++ programming with NDK and what iOS/WP 8 SDKs offer 
to C++ developers.



 I can only tell about our application, but it has a lot of JNI code. It
 is mostly used as a message passing mechanism between Java and C++
 (which live in separate threads so that Java GC doesn't stop native code
 execution).

 It's still experimental, but offloading some of the Java logic to C++
 gave as a significant performance boost, especially noticeable on
 low-end devices.

 A good example of the Java/C++ mix is a Chrome browser in Android. I'd
 say it's 50% Java/50% C++ (not counting the WebKit part).


That was what I was expecting.

Currently I am using C++ for a small graphics demo that should be 
multiplatform across OS handsets.

Thanks for the feedback.


--
Paulo
Nov 21 2013
prev sibling parent reply John J <john.joyus gmail.com> writes:
On 11/21/2013 05:02 PM, Paulo Pinto wrote:

 Am 21.11.2013 21:25, schrieb inout:

 On Thursday, 21 November 2013 at 07:35:01 UTC, Volcz wrote:

 On Sunday, 17 November 2013 at 05:49:43 UTC, John J wrote:

 On 11/15/2013 02:13 AM, Jeremy DeHaan wrote:
 If it should survive as an alternative, Jave should have some more
 advantages over D, even after the D compiles to ARM.


 The Android NDK is only a second class citizen compared to the Java
 SDK. The only use case I have heard of for the NDK is when companies
 have a small C library with common functionality to make porting the
 products to other platforms easier.


 That's not true. Most games are written entirely with NDK. Many
 applications, too (the app my team shipped recently contains a fair
 amount of C++ code in it, and it only grows).


 NDK only covers game related APIs, mostly.

 How much JNI calls do you make in standard applications?


Another language, Delphi also uses the NDK for full Android applications.
It creates a .so lib file for each application along with a minimal Java 
class that loads the native code.

http://blog.marcocantu.com/blog/compiling_android_apps_delphi.html
Nov 21 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 22.11.2013 00:52, schrieb John J:

 On 11/21/2013 05:02 PM, Paulo Pinto wrote:

 Am 21.11.2013 21:25, schrieb inout:

 On Thursday, 21 November 2013 at 07:35:01 UTC, Volcz wrote:

 On Sunday, 17 November 2013 at 05:49:43 UTC, John J wrote:

 On 11/15/2013 02:13 AM, Jeremy DeHaan wrote:
 If it should survive as an alternative, Jave should have some more
 advantages over D, even after the D compiles to ARM.


 The Android NDK is only a second class citizen compared to the Java
 SDK. The only use case I have heard of for the NDK is when companies
 have a small C library with common functionality to make porting the
 products to other platforms easier.


 That's not true. Most games are written entirely with NDK. Many
 applications, too (the app my team shipped recently contains a fair
 amount of C++ code in it, and it only grows).


 NDK only covers game related APIs, mostly.

 How much JNI calls do you make in standard applications?


 Another language, Delphi also uses the NDK for full Android applications.
 It creates a .so lib file for each application along with a minimal Java
 class that loads the native code.

 http://blog.marcocantu.com/blog/compiling_android_apps_delphi.html


There are lots of them, that is not the point.

The problem is that Android's API is mainly Java, which forces JNI 
marshalling and control switch between Dalvik and native code.

So if you care about performance in native code, you need to take care 
how Android APIs are being called.

Otherwise the performance benefits of native code vs Dalvik are throw 
out of the window.

Not to mention that Google leaves to the developers the effort of 
creating the JNI wrappers themselves, instead of providing a nice C++ 
API for them.

--
Paulo
Nov 21 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Friday, 22 November 2013 at 05:30:00 UTC, Paulo Pinto wrote:

 Am 22.11.2013 00:52, schrieb John J:

 On 11/21/2013 05:02 PM, Paulo Pinto wrote:

 Am 21.11.2013 21:25, schrieb inout:

 On Thursday, 21 November 2013 at 07:35:01 UTC, Volcz wrote:

 On Sunday, 17 November 2013 at 05:49:43 UTC, John J wrote:

 On 11/15/2013 02:13 AM, Jeremy DeHaan wrote:
 If it should survive as an alternative, Jave should have













 Not to mention that Google leaves to the developers the effort 
 of creating the JNI wrappers themselves, instead of providing a 
 nice C++ API for them.


almost:

http://developer.android.com/reference/android/app/NativeActivity.html
Nov 21 2013
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 22 November 2013 at 07:48:34 UTC, eles wrote:

 On Friday, 22 November 2013 at 05:30:00 UTC, Paulo Pinto wrote:

 Am 22.11.2013 00:52, schrieb John J:

 On 11/21/2013 05:02 PM, Paulo Pinto wrote:

 Am 21.11.2013 21:25, schrieb inout:

 On Thursday, 21 November 2013 at 07:35:01 UTC, Volcz wrote:

 On Sunday, 17 November 2013 at 05:49:43 UTC, John J wrote:

 On 11/15/2013 02:13 AM, Jeremy DeHaan wrote:
 If it should survive as an alternative, Jave should have













 Not to mention that Google leaves to the developers the effort 
 of creating the JNI wrappers themselves, instead of providing 
 a nice C++ API for them.


 almost:

 http://developer.android.com/reference/android/app/NativeActivity.html


That is a Java class full of native methods for calling into 
native code from Dalvik.

Now lets say you are doing a game, so NDK already provides the 
necessary C, C++, OpenGL libraries.

Do you want to use Renderscript for GPGPU code? Well if targeting 
Android versions lower than 4.4, you need to write the JNI 
bindings yourself.

Do you want to allow the players to share their games 
achievements via Google Play Game Services?

Then you need to write the JNI bindings yourself. But fear not, 
Google has made a video about it, 
http://www.youtube.com/watch?v=dxI5bReatJw. Lets see if part 2 
ever comes up.

If you need more than graphics, sound or sensors manipulation, 
then you need JNI.



--
Paulo
Nov 22 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-22 06:30, Paulo Pinto wrote:
  that Google leaves to the developers the effort of

 creating the JNI wrappers themselves, instead of providing a nice C++
 API for them.


I guess they want their developers to use Java. Otherwise they would 
have made C++ a first class citizens and not force C++ to go through Java.

-- 
/Jacob Carlborg
Nov 22 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 22 November 2013 at 12:45:19 UTC, Jacob Carlborg wrote:

 On 2013-11-22 06:30, Paulo Pinto wrote:
  that Google leaves to the developers the effort of

 creating the JNI wrappers themselves, instead of providing a 
 nice C++
 API for them.


 I guess they want their developers to use Java. Otherwise they 
 would have made C++ a first class citizens and not force C++ to 
 go through Java.


Certainly, that is also one of the reasons why they have come up 
with Renderscript and are now moving to native compiled Java post 
KitKat.

I don't have any issue with Java and do like the language, but it 
has lost its place if you care about portable code across mobile 
platforms.

Hence why I am using C++, as it is the only common language 
across all SDKs thus requiring minimal setup to get going.


--
Paulo
Nov 22 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 22 November 2013 at 13:36:08 UTC, Paulo Pinto wrote:

 I don't have any issue with Java and do like the language, but 
 it has lost its place if you care about portable code across 
 mobile platforms.


Ironic, much? :p
Nov 22 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 22.11.2013 17:15, schrieb John Colvin:

 On Friday, 22 November 2013 at 13:36:08 UTC, Paulo Pinto wrote:

 I don't have any issue with Java and do like the language, but it has
 lost its place if you care about portable code across mobile platforms.


 Ironic, much? :p


Sadly yes. There is hope with RoboVM, but that is community driven.

Oracle seems more interested into pushing HTML5 frontends with Java 
running on the server side.

Last year that made some PR announcements about Java support for iOS and 
Android. When what they actually had was an ADF web application!

--
Paulo
Nov 22 2013
prev sibling parent =?UTF-8?B?IlLDqW15IE1vdcOremEi?= <remy.moueza gmail.com> writes:
I haven't tried it, but here is an idea to target the JVM:

- use ldc `-output-ll` option to generate LLVM IR.
- use the LLJVM backend to generate some Jasmin assembly code 
from the LLVM IR ( as described on 
https://github.com/davidar/lljvm)
- link with the LLJVM linker.

This may produce some java bytecode, but to have something 
working properly I suppose the D runtime should also be compiled 
along with Phobos.

This may be a faster way to get to the JVM than writing a source 
translator. However, this is not the best way to get Java 
compatability since it does not seems to be possible to access 
the Java library from the input D code.

On Friday, 15 November 2013 at 07:13:34 UTC, Jeremy DeHaan wrote:

 Hey everyone!

 I have been experimenting for the past couple of days with an 
 idea I had, and since I recently made a little progress I 
 thought I would share some of what I have been doing with you. 
 What I have done, in a nutshell, is began the process for a 
 language converter that takes D source files, converts them 
 into Java source files, and then compiles them as Java class 
 files so that they can be ran on Java's VM. It is extremely 
 limited in what it can do right now, only being able to 
 convert/compile a simple Hello World program, but I was proud 
 of myself for getting even that far so I wanted to brag. :P

 You may want to ask, "Hey, man. D is a great language. Why 
 would I ever want to convert it to Java?" Normally, you 
 wouldn't. Java blows. What I am envisioning for this project is 
 something quite magical in my opinion. If we can take D code 
 and have it compile into Java class files, we can then compile 
 them into Android dex files. This would make D able to build 
 and run on Android devices through its VM. Sure, people are 
 working on getting D to compile to ARM binaries, but this could 
 be another option as a Java alternative on Android.(eventually)

 Unfortunately I do not know much about compilers, but even in 
 the last couple of days I feel like I have learned a great deal 
 about what kinds of stuff goes into them. Eventually I'd like 
 to make a full blown compiler that takes D code and can go 
 right to dex files, but that would be something that would 
 happen way down the road. In order to get D working on Android 
 sooner, I figured a language converter would be the easier 
 route.

 I can, and would love to go in to more detail about this, but 
 it is getting late and this post is already quite long. Maybe I 
 should start a blog about my D escapades? Anyways, I would love 
 to hear feedback on this idea! Thanks for your time!
Nov 23 2013