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

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. ;)

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.

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

I am *VERY MUCH* interested in this, so count me in. I will gladly join this project!

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.

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

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.

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.

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