Live data from Hacker News

Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

graalvm.org

21–30 of 141 posts

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#21
post #5

Earlier quoted context omitted.

Maybe it's my ignorance of the Java ecosystem or a lack of imagination but how could a language that requires a heavy runtime be written in itself? Wouldn't you need a runtime for the runtime, and then a runtime for the runtime for the runtime and then...? I can't quite imagine how you'd bootstrap something like that.

You can write a C compiler in Java. The output of the C compiler doesn't depend on the JVM, it would be a regular old program written in C. Writing a Java runtime would be similar, the output would be an executable that doesn't depend on the JVM.

A runtime is not a compiler. The process of bootstrapping a compiler is understood, but if the runtime itself requires a runtime at runtime, that is much more of a turtles all the way down problem than with a runtime less language.

It's like how PyPy is Python but with the asterisk that it's bootstrapped with RPython which is an almost-subset of python so that it doesn't require a runtime.

You could define a statically compilable Java subset (like that which gcj used to accept) and build a runtime in that which would mean omitting features such as reflection but a lot of defacto standard java tooling like Spring Framework would not be compatible.

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#22
post #5

Earlier quoted context omitted.

Maybe it's my ignorance of the Java ecosystem or a lack of imagination but how could a language that requires a heavy runtime be written in itself? Wouldn't you need a runtime for the runtime, and then a runtime for the runtime for the runtime and then...? I can't quite imagine how you'd bootstrap something like that.

It's no different to writing any other compiler for Language X in Language X, and that's a really common thing to do. The Java compiler emits files containing Java Bytecode which are subsequently run by a different invocation of the JVM.

It's different in that the JVM is not a compiler. It's a bit like suggesting writing CPython in Python. It's possible only if the interpreter's Python source can be compiled ahead of time, like PyPy.

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#23
post #22

Earlier quoted context omitted.

It's no different to writing any other compiler for Language X in Language X, and that's a really common thing to do. The Java compiler emits files containing Java Bytecode which are subsequently run by a different invocation of the JVM.

It's different in that the JVM is not a compiler. It's a bit like suggesting writing CPython in Python. It's possible only if the interpreter's Python source can be compiled ahead of time, like PyPy.

> It's possible only if the interpreter's Python source can be compiled ahead of time, like PyPy.

That's what it does.

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#24
post #16
post #4

somehow I'm in disbelief. as in - why is this news #1?

Java isn't cool and most HN'ers aren't interested in it.

Isn't this more about the GraalVM, as an alternate runtime to the JVM, than it is about Java, since the other JVM-target languages can leverage it also?

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#25
post #21

Earlier quoted context omitted.

You can write a C compiler in Java. The output of the C compiler doesn't depend on the JVM, it would be a regular old program written in C. Writing a Java runtime would be similar, the output would be an executable that doesn't depend on the JVM.

A runtime is not a compiler. The process of bootstrapping a compiler is understood, but if the runtime itself requires a runtime at runtime, that is much more of a turtles all the way down problem than with a runtime less language. It's like how PyPy is Python but with the asterisk that it's bootstrapped with RPython which is an almost-subset of python so that it doesn't require a runtime. You could define a statical…

> You could define a statically compilable Java subset (like that which gcj used to accept) and build a runtime in that which would mean omitting features such as reflection but a lot of defacto standard java tooling like Spring Framework would not be compatible.

But the JVM you build using your statically compilable Java subset can then run the Spring Framework or whatever.

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#26
post #2

Maybe we will soon see the Java Virtual Machine implemented wholly in (a subset of) Java...

There was a java implementation of a JVM, jikes rvm.

I haven't looked at it for ages and looking at Wikipedia it seems dead, so curious if there is any newer attempts....

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#27
post #26
post #2

Maybe we will soon see the Java Virtual Machine implemented wholly in (a subset of) Java...

There was a java implementation of a JVM, jikes rvm. I haven't looked at it for ages and looking at Wikipedia it seems dead, so curious if there is any newer attempts....

> so curious if there is any newer attempts....

You're commenting on an article about a newer attempt?

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#28
post #8
post #3

Earlier quoted context omitted.

It's a good point, after so long why the JVM is not written in Java actually? For example the Go runtime and I think C# as well are written in their respective language. https://github.com/golang/go/tree/master/src/runtime https://github.com/dotnet/runtime

Java isn't as performant as C++. BTW, how do you implement a garbage collector with a garbage-collected language?

Java often is as fast as cpp, sometimes faster. JIT gives it a huge advantage and c2 is pretty much state of the art these days.

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#29
post #21

Earlier quoted context omitted.

A runtime is not a compiler. The process of bootstrapping a compiler is understood, but if the runtime itself requires a runtime at runtime, that is much more of a turtles all the way down problem than with a runtime less language. It's like how PyPy is Python but with the asterisk that it's bootstrapped with RPython which is an almost-subset of python so that it doesn't require a runtime. You could define a statical…

> You could define a statically compilable Java subset (like that which gcj used to accept) and build a runtime in that which would mean omitting features such as reflection but a lot of defacto standard java tooling like Spring Framework would not be compatible. But the JVM you build using your statically compilable Java subset can then run the Spring Framework or whatever.

Sure, but that subset is only "kind of Java" just like RPython or CPython code is only "kind of Python". It's like calling a C compiler a C++ or Objective-C compiler because C is a subset of those languages.

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#30
Wonderful news! I was always scared that Oracle could slap some $$$ licensing scheme for GraalVM, but this proves me wrong. I'm not following other parts of GraalVM development, except Native Image capability, but I must say that, IMHO, GraalVM/native-image is one of the best things after sliced bread and JVM out there. Native Image shows true power when it has to compile higher-level languages than Java, like Scala, Clojure, or Kotlin, and it compiles them pretty darn well.
Post reply on HN