
Jvm.go: A JVM written in Go - tombenner
https://github.com/zxh0/jvm.go
======
neilellis
If I could upvote this a 1000 times I would.

We need more people doing crazy sh*t like this. Java is a fantastic runtime -
and a great language. But it has a huge amount of baggage. I'd love to see
experiments int the open source arena playing around with alternatives to the
standard Oracle JVM.

I'd love to see Android like alternatives for the desktop that re-use java's
syntax but have less baggage and are not tied to Sun's view of what Java
should be (Oracle's view of the language is actually a lot better than Sun's
thank god).

There are countless Java developers who would like to reuse their knowledge
but in a different set up. E.g. desktop not server, lightweight not
heavyweight, systems level (like go/python) etc.

I keep hoping that one of these JVMs will end up going in their own direction
one day not trying to achieve official Java compatibility.

Anyway kudos to the author.

~~~
threeseed
You do realise that Oracle's JVM isn't the only one and there are many open
source JVM alternatives. Quite a few of which are designed for lightweight
systems:

[http://en.wikipedia.org/wiki/List_of_Java_virtual_machines](http://en.wikipedia.org/wiki/List_of_Java_virtual_machines)

And I have no idea what you mean by baggage. I am assuming you mean "features"
like JNI, JMX etc ?

If that is the case then the modularisation of the JVM is something that has
been underway for a number of years now. It is targeted for Java 9 release:

[http://openjdk.java.net/projects/jigsaw/](http://openjdk.java.net/projects/jigsaw/)

And there is no difference in the way Oracle or Sun has managed the JVM.
Changes are still made through the JSR/JEP process.

And finally again no idea what you mean by countess Java developers wanting to
reuse their knowledge but in a different environment.

Android is already an option as is Swing but honestly does anyone care about
desktop apps these days ?

~~~
bjourne
Baggage: [http://stackoverflow.com/questions/313584/what-is-the-
concep...](http://stackoverflow.com/questions/313584/what-is-the-concept-of-
erasure-in-generics-in-java)

Yes there are many JVM:s but most of them aren't any good.

~~~
mike_hearn
They're working on real generics for the JVM, but it's a lot of work,
especially to preserve compatibility (which is why it wasn't done beforehand).
If you throw out compatibility it's still a lot of work though, plus you no
longer have any of the libraries.

I guess if you mean by "not any good" they're slower/less featureful than the
original HotSpot JVM, then, well, yes..... you get what you pay for (in terms
of resource usage).

~~~
bjourne
Where have you heard that? Generics were implemented using type erasure long
ago because it was deemed to hard and would break to much existing code to
implement them correctly. What has change to make it feasible now? Not saying
you're wrong but I haven't seen any mention of any work in that direction.

~~~
mike_hearn
Look for project Valhalla. It's doing value types, which means you will be
able to write List<int> amongst other things. Obviously that means the int
type cannot be erased in that context.

Nothing in particular has changed, but full generics C++ style imply value
types, and value types are now on the table whereas before they were not
(other higher priorities, I guess).

------
jamescun
This is one way to get generics in Go.

~~~
btzll
_slow clap_

------
binarycrusader
This looks really neat, but there's no license or copyright notices as far as
I can tell. Author, please add a license to your repository!

~~~
hobarrera
There's a " LICENSE.txt"[sic] file now. Looks like it's MIT licensed.

------
keyle
1600 commits by one dude? 700 commits in January? An average of 23 commits a
day? 12,000 lines written and 7,000 removed just that month. An average of 640
commits per month.

I may be naive. Am I missing something or this guy is an incredible code
machine?

~~~
neilellis
Nah, that's a perfectly reasonable pace to work at when you have:

* Predefined explicit requirements (a tight spec).

* No distractions.

* No colleagues (i.e. you're working on a non-blocking single thread of execution).

* Enthusiasm.

* An unhealthy enjoyment of coding.

I have worked at this pace and I'm sure many others have, but you need to have
those pre-requisites (and they are RARE!).

Bare in mind that if you're the only developer those commits probably haven't
been tested and you're not worrying about damaging other people's code.

Of course, you can't scale that model :-)

Which btw is a fantastic real world analogy of why multi-threading can suck
horrifically in some cases and why that parallel execution isn't always a good
thing.

NOTE: None of that takes a way from a totally awesome and fearless project to
take on and complete (which I believe it is?).

~~~
keyle
I don't know about you, but I could maybe keep that pace 3 days. Maybe 5. But
2.5 months?

~~~
MagerValp
When I fall in love with a personal project, it happens to me too. The
important factor is that I don't have anyone else to explain myself to, no one
blocking my changes, I own the whole project from the bottom all the way to
the top - it's basically just a giant positive feedback loop.

I checked my stats and over the last six weeks I have dedicated my spare time
(of which there has been more than usual, but I have a family and work 9-5) to
my current project, and I've averaged 7 commits per day with 59308 lines
added, 22903 deleted.

I am feeling a little burnt out now, but fortunately the code is essentially
done and all that's left is a little mop up and writing a blog post.

------
slimsag
First off -- this is really impressive! Is the author present here? I wonder:

\- How is the performance?

\- Is a GC implemented separately or is the Go one directly used (awesome!)?

\- How do calls to native JNI things operate (through CGO)? Does it work?

~~~
munificent
> \- How is the performance?

I'm guessing not great. Looks like a simple bytecode interpreter using
interface virtual dispatch on the instructions (!).

> \- Is a GC implemented separately or is the Go one directly used (awesome!)?

As far as I can tell, it just uses the native Go GC, which is smart.

~~~
millstone
Java supports exotic reference types like weak references. These require close
integration with the GC, and Go doesn't support them, so Go's GC can't be used
to implement them.

~~~
needusername
And JNI local and global refs and heap walking via JVMTI and …

------
perrygeo
While we're at it, wonder if it runs JGo? Go compiled to java bytecode running
on a JVM built in Go.

[https://code.google.com/p/jgo/](https://code.google.com/p/jgo/)

------
tombenner
A relevant post by the author (English translation):
[http://translate.google.com/translate?hl=en&sl=zh-
CN&u=http:...](http://translate.google.com/translate?hl=en&sl=zh-
CN&u=http://blog.csdn.net/zxhoo/article/details/44104553)

------
lorddoig
This is cool, but now there's a risk that tomorrow will bring us JVM.js with a
kickstarter, trendy logo, and a subtle but distinct whiff of moral
superiority.

Edit: so I really am a cynic, I count at least two on the first page and
neither are at all as wanky as my imagination likes to think.

~~~
xigency
That is the benefit of working on hard problems that are almost entirely
technical. Especially if you are working alone, and usually not getting paid,
it's easy to not get distracted by fad movements or popularization in simply
writing software. But unfortunately, it usually ends up being a total waste of
time.

------
slowmovintarget
Now put a Lisp on there, quick! Clogure?

~~~
fnordsensei
Shouldn't Clojure work out of the box if it implements the same API as the
JVM?

~~~
slowmovintarget
If it's JLS compliant, absolutely.

------
jaytaylor
Will this open the door to utilizing Java libraries from within go apps?

Coming soon: scala.go (!)

~~~
mike_hearn
No - for that you'd need a Go implementation on the JVM.

Last time I checked there was a half finished student project that does this.
But not a full implementation. That's a shame. I've encountered a Go shop that
was really suffering from things as basic as "our best debugger is gdb which
doesn't really work" and "how do we get a stack trace from our running
program?".

The Go crowd like to talk about how Go programs are small and standalone, but
obviously the HotSpot JVM is not just a big pile of NOPs. You can get very
small implementations of Java too, but only by cutting lots of useful
functionality.

I bet if a company produced a solid, compliant Go for the JVM, that'd be a
license to print money. I feel like lots of startups are coding themselves
into a corner by relying on the relatively new and simple Go runtime. If they
could bring their code across to the JVM and get access to all the useful
tools it has, that'd be worth some money.

~~~
bkeroack
Go on the JVM completely defeats one of the biggest Go selling points for me:
compilation to native code.

Debuggers are definitely a weak spot, though, I agree. Luckily it's being
worked on
([https://github.com/derekparker/delve](https://github.com/derekparker/delve)).

~~~
mike_hearn
What precise benefits do you look for?

Bear in mind "compile to native code" is a bit vague. JVMs compile bytecodes
to native code too, they just do it on the fly instead of ahead of time. If
you mean "single executable" then there are ways to do that with Java too,
check out the downloadable demos on the Avian website. But many native apps
are not single files and have lots of libraries they depend on, so the
distinction there isn't obvious either.

~~~
bkeroack
One of the hats I wear is "DevOps"/"SRE" (among other things). To me the JVM
is another big layer of complexity between the code and the hardware it runs
on that makes debugging and performance analysis that much more complicated.
Granted, it also brings tools to the table (JMX, etc). However given the
choice I'll nearly always pick an application that compiles directly to a
native machine code binary. It's ironic to me that the JVM was conceived as a
portability panacea ("write once, run anywhere") yet outside of mobile
virtually everything runs on x86(-64). So with the JVM we have this thick,
unnecessary VM layer that penalizes (in terms of performance and complexity)
all code running on it.

The fact that Go programs are all statically-linked (easy deployment, no weird
dependency issues) and are reasonably safe given idiomatic coding patterns are
nice bonuses.

------
gnuvince
Very cool project, I like the focus on readability (even if at the cost of
performance): that makes it a good example to show to people who want to learn
about the implementation of languages and VMs.

------
rdtsc
Really cool. Thanks for sharing!

------
deitcher
It is pretty impressive as a project, but I am not sure I get the point. JVM
already exists, so we can run Java programs. Go exists so we can compile Go
programs. What do I get from running a Java program in a Go-built JVM over a
C-built JVM?

~~~
danellis
I've noticed from HN headlines that there's an odd focus on what programming
language something is written in. Often they'll take the form of "A <thing
that is already common> written in <recently popular language>", rather than a
real USP. It's especially odd from a community that places so much emphasis on
the importance of a good pitch.

~~~
skybrian
It's important for libraries. If you're writing in Go, a Java library doesn't
help you much. Think of it as an easy way to qualify leads.

For apps, it matters less but you still have to think about how easy it is to
modify. That's why we care about open source, right?

~~~
mike_hearn
This is the wrong way around for that. It won't give you Java/Go interop.

------
filereaper
This is a very cool project, I just hope Oracle's lawyers don't descend on
this...they have a knack for ruining everything.

~~~
lclarkmichalek
Yeah, I mean, just look what they did to the openjdk

~~~
szabba
Any specifics for the unoriented?

~~~
mike_hearn
The Oracle JVM is virtually all open source under a different name (OpenJDK)
and there are lots of other JVMs out there. Oracle won't care about this
project.

------
TheDong
Oh, yay, we can now get DOUBLE GC PAUSES!

I wish the README had more information about the reason this project exists.
Is it just a fun toy jvm for learning? Is it meant to be eventually
production-ready and performant?

Just knowing whether something is meant as a learning project or for
production use vastly changes how people will approach it and I just can't
tell with this one.

~~~
jaytaylor
glancing through the source code I don't see any reason there would be double
gc pauses. This appears to be a full jvm, not exec.Command("java", ...).Run().

~~~
BinaryIdiot
The JVM handles the garbage collection for Java so if someone writes a JVM in
a garbage collected language I would suspect two garbage collectors to be
running (one for GO and one for the bytecode the JVM is running).

It would be an interesting concept to pass through Java objects for the GO
garbage collector to deal with but that sounds incredibly difficult or
impossible.

~~~
seabrookmx
But that's exactly what he does if you read his (poorly translated) blog
posts.

I think it's actually much simpler to do it this way. It keeps the mapping
between Java and Go constructs much tighter.

~~~
BinaryIdiot
Ah I didn't see those so I'll have to take a look. The reason I thought it was
very difficult and maybe even impossible was mostly because passing through to
GO changes the behavior or Java to a point where it could cause some adverse
affects in applications tuned or expecting it to work as the other JVMs work.

Still a cool project either way.

~~~
seabrookmx
For many things that may be the case, but to my knowledge Java doesn't make
any strict assumptions about garbage collection. You can get drastically
different behavior just by passing different parameters to your JVM for
instance.

As long as the Go garbage collection works, it shouldn't affect how the
program runs. That's kind of the whole point of GC. Hell, you could write a
toy VM with _no_ garbage collection, and it would work fine until you blew
your memory.

