Java binaries

[js.mdnq]

On Sunday, 17 February 2013 at 09:47:08 UTC, Russel Winder wrote:
> Sorry to come to this thread late, and apologies if I am 
> missing the
> real point to this thread.
>
> On Sun, 2013-02-17 at 10:13 +0100, js.mdnq wrote:
>> On Sunday, 17 February 2013 at 07:53:15 UTC, Walter Bright 
>> wrote:
>> > On 2/16/2013 7:26 PM, js.mdnq wrote:
>> >> Would it ever be possible to compile D source directly to 
>> >> java to take advantage
>> >> of what java offers. (e.g., the ability to run d code 
>> >> inside a browser)
>
> Running Java in the browser is now unlikely to ever happen 
> again.  If
> anything the target should be JavaScript or Dart, and even Dart 
> would be
> a huge risk.
>
>> >> I'm not talking about necessarily fully fledged 
>> >> functionality(obviously stuff
>> >> like asm isn't going to work) but basically the ability to 
>> >> use D's syntax and
>> >> some of it's compiler features(mixins, templates, etc).
>
> A lot of work is going into creating Python executability in 
> browsers.
> Skulpt, Brython, etc., but traction is minimal. Browsers mean 
> HTML5 and
> ECMAScript (aka JavaScript)
>
>> >
>> > Java doesn't have pointers, so right off the bat there'd be 
>> > big problems.
>> 
>> Java does have pointers... you just can't get to them easily. 
>> At the very least, you could allocate and manage your own 
>> chunk of memory and do all the pointer arithmetic yourself on 
>> that chunk. This would require the chunk to be pinned in some 
>> way and the GC to be turned off but it is an option.
>
> There is the possibility of using NIO2 buffers in ways that 
> were never
> envisaged. This is effectively what happened in RTSJ, which was 
> a
> real-time systems framework using Java and JVM. RTSJ sadly was 
> too far
> ahead of its time and so died. The last vestige will die when 
> the Mars
> Rover does.
>
>> Also, have you looked much at sun.misc.Unsafe?
>
> You really don't want to go there ;-)
>
> Obviously for garbage collection and concurrency and 
> parallelism control
> you have to go there so as to subvert the JVM object model. The 
> question
> is that unless you are working on the G1 garbage collector or
> java.util.concurrent primitives, is there any point?
>
>> Or maybe one could use the JNI to write an external memory 
>> manager for each platform and all pointer arithmetic is passed 
>> through that. Of course, if one goes this far then any "javaD" 
>> would need to be able to work well with importing java 
>> libraries to be of any use.
>
> Sounds like a mountain rather than a molehill. We are looking at
> something vaguely analogous to get CUDA and OpenCL working from
> GPars/Groovy/Java. Good for users, very ugly for implementors.
>
> Unless there is a mapping of the semantics of a language to the
> intermediate code of the platform, then it is better not to 
> bash head on
> wall but to go put energies into something more productive. If 
> the D
> semantics cannot be mapped down to the JVM bytecodes, then D is 
> not a
> language you want to run on the JVM. Given
> Java/Scala/Kotlin/Ceylon/Groovy as the static languages and
> Groovy/JRuby/Jython/Closure as the dynamic languages (yes 
> Groovy is
> correctly in both categories!) is there really a market for a 
> minor
> player native code language trying to ease itself onto the JVM 
> platform?
>
> The world is split into native code, PVM, JVM, 
> JavaScript/ECMAScript. D
> only really has a play in one of these, and needs to get real 
> traction
> there first before looking for new lands to conquer. Else it 
> risks being
> seen as a solution looking for a problem to solve.

Everything started out as minor and if D's language features are 
truly good and D is as well designed as some think then people 
will migrate to it. Essentially "If you build it they will come" 
type of scenario.

Those that would use a D for java type of language can't so there 
is no way to measure how successful it would be.

Virtual machine programming has many benefits but we definitely 
do not need another one. Hence, it would be nice to leverage 
java, which already has build up it's user base to further the D 
language paradigm. I like D but so far it doesn't seem to be 
going anywhere. Why? Because one already has all these other 
languages and tools to do the job.

Imagine this:

Suppose with a snap of your fingers you could have the following 
products:

High stable and performant D compiler for all the major 
platforms(including many embedded) with a large collection of 
support tools.

A D virtual machine that runs on many platforms. A D for java 
compiler that compiles almost any D program into java bytecode 
and use java libraries.

etc...

Now, if you had all this stuff magically out there do you think 
that the userbase for D would explode? I do... In fact, it would 
happen for most decent languages. (of course, we could argue 
about the exact details but D would become a major player within 
a few years)

Hence, having this stuff is important for D's success. Of course, 
it may not be possible in some cases or sacrifices have to be 
made. In any case I'm not convinced that a D for java can't be 
implemented and I do feel it would further D's popularity.

Of course, D is still in it's infancy but it would be cool it 
someone was interested in trying to make a D for java and see 
where it goes. I think something useful would come out of it. 
(Please don't say I should do it either...)