Announcement

**vein** · 23 April 2019, 05:38 AM

Originally posted by Apokalypz View Post

Dude, WTF is up with their recent licensing change for Oracle and Open JDKs for 11??? How are they mixing a commercial license with the GPLv2? I thought the later forbids the former. Unless they keep 2 separate build trees, one commercial licensed blob and one GPLv2. Supposedly OpenJDK and Oracle JDK will be feature identical going forward. It never ceases to amaze me how many issues revolve around a simple software language/bytecode runtime.

Their licensing is totally fucked up. I recommend you to check the other jdk versions out there. Because of the licensing, there are free jdks from aws, zulu, redhat... Etc.

**audir8** · 23 April 2019, 06:57 AM

Originally posted by kpedersen View Post

This guys first attempt was 40 days. He mentions that he would use yacc or flex if he was to do it again saving quite a bit of time.
https://www.sigbus.info/how-i-wrote-...n-40-days.html

And Bellard's OTCC (to win an obfuscated C competition) shows that someone with his skill and knowledge likely could get a functional one going.

This one (written in python) was a couple of weeks: https://github.com/ShivamSarodia/ShivC

Sure, they might not be professional quality or you and I may not be skilled enough to do it but what exactly do you think would be a problem?

Unlike a JVM, it is a much smaller task. That is pretty much exactly my point. Getting one of these up to a professional capacity would likely still be a trivial task compared to porting the JVM to a different architecture. And that is not good :/

Ugh, I know. It is a tad scary. Luckily I can avoid Javascript; however I do depend on Java for a couple of projects and I am starting to get cold feet on the whole ecosystem if it is so... expansive!

The added Jit in Node.js adds overhead ontop compared to i.e Duktape or Lua. And I am sure it provides a few more bells and whilstles compared to (the tiny in comparison) LuaJIT, but surely it must be an absolute bi*ch to maintain. Luckily Node.js has quite a big company behind it for now. What about in the future though?

As far as I recall, gcj is dead but I wonder if that would have been a more elegant and maintainable route in the long run. GCC isn't small but it also achieves a lot more than simply a VM and bytecode compiler.

The basics of GC and IO are the same in every language that has them. The Java implementations probably are the most optimized among all other VM/JIT languages/runtimes. Scala might write it's own IO libraries and the runtime could be the JVM or scala-native (if you want to talk about language specific JVM-alternatives). You can also use the AOT compiler if you want in OpenJDK, it's there, just like GCJ.

Maybe we won't have type erasure some day, though I mostly think the code and binary size is alright for Java as a language and JVM as a runtime for all the capabilities on offer.

**mcloud** · 23 April 2019, 10:29 AM

Originally posted by kpedersen View Post

Had a look through the source code just for fun and... wow, if these large corporations lose interest in Java, it is absolutely dead in the water. Just the i.e GC or network modules alone are larger than all the code myself or my company has ever written! We are talking hundreds of thousands of lines just for two very minor components on a very small subset of platforms (x86, ARM).

Don't get me wrong, no issues with Java; but can things not be a bit simpler? It would hurt me but I could write a C compiler in a year or so. People more skilled than me could probably write one in a week. But this monstrosity of a VM alone (let alone the compiler / optimiser) is surely not maintainable!
:/

Not wanting to feed the trolls, but have you seen how complex SSL/TLS plus all the other signing stuff plus hardware crypto for PCKS 12 and stuff? No one seems to be doing that simpler anywhere. Most languages don't even get all the stuff the JVM has unless you pull in lots of code as well. And even the ones that do (eg: C/C++), they don't even come close to the JVM API ease of use

**kpedersen** · 23 April 2019, 11:01 AM

Originally posted by mcloud View Post

Not wanting to feed the trolls, but have you seen how complex SSL/TLS plus all the other signing stuff plus hardware crypto for PCKS 12 and stuff? No one seems to be doing that simpler anywhere. Most languages don't even get all the stuff the JVM has unless you pull in lots of code as well. And even the ones that do (eg: C/C++), they don't even come close to the JVM API ease of use

I think possibly the SSL/TLS stuff could be an optional library rather than the JRE but I suppose that isn't really my point. If this is written in 100% pure Java (no i.e JNI) then it isn't really a dependency that I am worried about (because it cannot possibly fail to compile or need maintenance unless the Java language changes considerably).

I was looking entirely at the sheer volume of (sometimes very platform specific) C and C++ code required to support the JRE and JVM. I guess it kinda makes me cringe when people say that Java is portable. The language may be but the JVM and large chunks of the JRE most certainly are not. I feel that some work to reduce that could be a big benefit. It is certainly possible, J2ME for example running on relatively small micro controllers.

Originally posted by audir8 View Post

The basics of GC and IO are the same in every language that has them.

True enough and as far as I know, scanning the stack in C *needs* platform specific code (some stacks grow upwards, whilst some grow downwards). One good attempt at using std C for this is here: https://github.com/orangeduck/tgc (using a volatile variable to find the location on the stack to avoid register storage).

However Java's implementation is still pretty massive. Not just Java of course, so is Mono's (https://raw.githubusercontent.com/mo...sgen/sgen-gc.c).

Edit: And jeez, look at dotnets implementation: https://raw.githubusercontent.com/do.../src/gc/gc.cpp
A cool 37597 lines in one file. Too big to display in the standard GitHub interface. Imagine being given the task of porting that to a 128-bit architecture in 20 years

**audir8** · 23 April 2019, 03:19 PM

Originally posted by kpedersen View Post

True enough and as far as I know, scanning the stack in C *needs* platform specific code (some stacks grow upwards, whilst some grow downwards). One good attempt at using std C for this is here: https://github.com/orangeduck/tgc (using a volatile variable to find the location on the stack to avoid register storage).

However Java's implementation is still pretty massive. Not just Java of course, so is Mono's (https://raw.githubusercontent.com/mo...sgen/sgen-gc.c).

Edit: And jeez, look at dotnets implementation: https://raw.githubusercontent.com/do.../src/gc/gc.cpp
A cool 37597 lines in one file. Too big to display in the standard GitHub interface. Imagine being given the task of porting that to a 128-bit architecture in 20 years

Well, compared to mono and .net, hotspot's gc code is a small wonder:

jdk8/jdk8/hotspot: 87ee5ee27509 /src/share/vm/gc_interface/

https://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/gc_interface

jdk8/jdk8/hotspot: 87ee5ee27509 /src/share/vm/gc_implementation/

https://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/gc_implementation