11 ms·

Jvm.go: A JVM written in Go

284 points by tombenner 12y ago

slimsag 12y ago
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?
- pron 12y ago
  Not to take away from the author's effort, a basic JVM is not hard to implement. It's easier than writing a JavaScript or a Ruby interpreter, as the Java bytecode was designed for simple execution. What is a lot of work is writing a high-performance JVM (with a good optimizing JIT and a good GC), getting the details right (especially the Java memory model), and supporting "advanced" features such as JNI and JVMTI.
  - xxs 12y ago
    I was going to say: "the hard part of a JVM is the JIT, GC and the cooperation between. As it stands now I am not sure it's possible to write a good JVM on anything but C/asm level language."... But I see it's already done.
    - chrisseaton 12y ago
      > "I am not sure it's possible to write a good JVM on anything but C/asm level language" Graal is one part of a JVM, the JIT compiler, written in Java [0]. It performs about as well as C2, and sometimes better [1]. [0] http://openjdk.java.net/projects/graal/ http://openjdk.java.net/projects/graal/ [1] http://lampwww.epfl.ch/~hmiller/scala2013/resources/pdfs/paper9.pdf http://lampwww.epfl.ch/~hmiller/scala2013/resources/pdfs/pap...
      - mike_hearn 12y ago
        Chris, although it's slightly off topic I just want to fanboy your work for a second. Your blog posts about how Graal/Truffle can inline C into Ruby and vice-versa and beat Ruby+C, all on the JVM, is the most mind blowing compiler tech I've ever seen. Saying Graal performs about as well as C2 and sometimes better is modest. The Graal/Truffle combo does a lot more than C2 can ever do. It is only really comparable if you ignore the astonishing capabilities it has vs the competition. For readers who are not aware of this work, and who have an interest in VM/compiler technology, I strong recommend checking out Chris' blog and the Graal/Truffle presentations that are floating around. Basically they've built a program that converts simple syntax tree interpreters into full blown JIT compilers. It means that basically any toy scripting language can have similar performance to, say, Javascript on V8, just by writing the base interpreter with their framework. But where it gets really crazy is when you write an interpreter for C or (say) Objective-C, and start to get aggressive speculative just in time compilation with seamless cross language optimisation, to the extent that C code can actually be run on a compacting garbage collector.
        ayrx 12y ago
        > It means that basically any toy scripting language can have similar performance to, say, Javascript on V8, just by writing the base interpreter with their framework. That actually sounds a lot like what RPython from PyPy enables.
        mike_hearn 12y ago
        Yes. Some of the underlying theory is the same, but truffle appears to generalise to other languages a lot better (note: I am not an expert)
        ayrx 12y ago
        Are you aware of any comparisons that shows "truffle appears to generalise to other languages a lot better"? I'd be interested in reading them. :) The performance of various RPython interpreters like PyPy and HippyVM are pretty impressive.
    - pjmlp 12y ago
      There are multiple JVMs written in Java. Besides the sibling post, JikesRVM is one of the most well known ones.
- munificent 12y ago
  > - 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.
  - andrewchambers 12y ago
    Not smart, obvious.
    - guipsp 12y ago
      Which is also smart.
  - millstone 12y ago
    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 12y ago
      And JNI local and global refs and heap walking via JVMTI and …
jaytaylor 12y ago
Will this open the door to utilizing Java libraries from within go apps? Coming soon: scala.go (!)
- mike_hearn 12y ago
  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 12y ago
    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 12y ago
      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.
TheDong 12y ago
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 12y ago
  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 12y ago
    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.
    - steveklabnik 12y ago
      Such schemes are not impossible, as Servo does something similar: https://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ https://blog.mozilla.org/research/2014/08/26/javascript-serv...
    - danbruc 12y ago
      At least if you are interpreting the language just using the garbage collector of the host language will pretty surly simplify the design a lot. Actually a design where every Java object is simply represented by a Go object should give this for free.
    - seabrookmx 12y ago
      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.
slowmovintarget 12y ago
Now put a Lisp on there, quick! Clogure?
- fnordsensei 12y ago
  Shouldn't Clojure work out of the box if it implements the same API as the JVM?
  - slowmovintarget 12y ago
    If it's JLS compliant, absolutely.
tombenner 12y ago
A relevant post by the author (English translation): http://translate.google.com/translate?hl=en&sl=zh-CN&u=http://blog.csdn.net/zxhoo/article/details/44104553 http://translate.google.com/translate?hl=en&sl=zh-CN&u=http:...
deitcher 12y ago
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?
- jaytaylor 12y ago
  Minor note: go is now self-hosted which means it is no longer wrapped in c.
- Leon 12y ago
  There aren't always great reasons behind great hacks. We can appreciate them for the ideas they present, the interesting implementation of features, and the what-if's that can come from expanding the hack further.
- i_s 12y ago
  Depending on how it is done, one benefit could be you'd be able to use java/clojure/scala to build command line tools, something few people do now because of the slow JVM startup time.
  - sitkack 12y ago
    The JVM isn't too slow for command line tools. What is too slow is the size of the executables and the amount of upfront work that secondary runtimes are doing. I can't say anything for Scala, but the startup time of Clojure has nothing to do with the JVM. Pure Java Hello World launches in 90ms on my machine. Jython Hello World takes 1.3 seconds. EDIT: to address all the comments. I am saying the JVM isn't _too_ slow for command line applications. Not ideal, but tolerable. I just tested the startup time of a robovm'ed Hello World: 23ms FWIW. And the resulting executable isn't exactly light weight. $ otool -L Main Main: /usr/lib/libSystem.B.dylib /usr/lib/libiconv.2.dylib /usr/lib/libsqlite3.dylib /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation /usr/lib/libstdc++.6.dylib $ du -sch Main 11M Main
    - 12y ago
binarycrusader 12y ago
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 12y ago
  There's a " LICENSE.txt"[sic] file now. Looks like it's MIT licensed.
filereaper 12y ago
This is a very cool project, I just hope Oracle's lawyers don't descend on this...they have a knack for ruining everything.
- GFK_of_xmaspast 12y ago
  On what grounds.
- lclarkmichalek 12y ago
  Yeah, I mean, just look what they did to the openjdk
  - szabba 12y ago
    Any specifics for the unoriented?
    - saryant 12y ago
      It was sarcasm.
    - mike_hearn 12y ago
      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.
rdtsc 12y ago
Really cool. Thanks for sharing!
gnuvince 12y ago
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.
jamescun 12y ago
This is one way to get generics in Go.
- btzll 12y ago
  slow clap
- anon4 12y ago
  No reified generics though.
perrygeo 12y ago
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/
keyle 12y ago
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 12y ago
  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?).
  - afarrell 12y ago
    Alternately, if you are going super-TDD on things and committing after every test, that pace is also reasonable under the conditions you list. I was at about that rate when I once tried to write a scheme interpreter in javascript in a weekend. I mostly succeeded, but ran out of time before getting done with some special forms.
  - keyle 12y ago
    I don't know about you, but I could maybe keep that pace 3 days. Maybe 5. But 2.5 months?
    - MagerValp 12y ago
      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.
neilellis 12y ago
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.
- kolev 12y ago
  What is the "baggage" of Java? This is just a JVM and Java's JVM has no much more baggage than any other implementation. In order for this to be practical in terms of performance, reliability, and so on, years have to pass and meanwhile Oracle JDK and OpenJDK are not gonna stay still. As a side note, I really wonder how an engineer can use ghetto talk like "crazy sh*t" and especially in this forum here.
  - girvo 12y ago
    > ghetto talk Excuse me?
    - kolev 12y ago
      I'm sorry you're offended, maybe that's part of your lingo, too, but "crazy sht" is ghetto talk. Indeed. A self-respected and honorable engineer pays attention to detail - not only in their work, but in their language as well and especially in the meticulous choice of words. English is not my native tongue, but I respect it very much, and the language I respect does not include phrases such as "crazy sht" - it's a rich and very expressive language and only the severely incapacitated include those in their written communication.
lorddoig 12y ago
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.
- andrewchambers 12y ago
  There are already a few jvm's written in Javascript.
- xigency 12y ago
  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.

284 points by tombenner 12y ago

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?

pron 12y ago
Not to take away from the author's effort, a basic JVM is not hard to implement. It's easier than writing a JavaScript or a Ruby interpreter, as the Java bytecode was designed for simple execution. What is a lot of work is writing a high-performance JVM (with a good optimizing JIT and a good GC), getting the details right (especially the Java memory model), and supporting "advanced" features such as JNI and JVMTI.
- xxs 12y ago
  I was going to say: "the hard part of a JVM is the JIT, GC and the cooperation between. As it stands now I am not sure it's possible to write a good JVM on anything but C/asm level language."... But I see it's already done.
  - chrisseaton 12y ago
    > "I am not sure it's possible to write a good JVM on anything but C/asm level language" Graal is one part of a JVM, the JIT compiler, written in Java [0]. It performs about as well as C2, and sometimes better [1]. [0] http://openjdk.java.net/projects/graal/ http://openjdk.java.net/projects/graal/ [1] http://lampwww.epfl.ch/~hmiller/scala2013/resources/pdfs/paper9.pdf http://lampwww.epfl.ch/~hmiller/scala2013/resources/pdfs/pap...
    - mike_hearn 12y ago
      Chris, although it's slightly off topic I just want to fanboy your work for a second. Your blog posts about how Graal/Truffle can inline C into Ruby and vice-versa and beat Ruby+C, all on the JVM, is the most mind blowing compiler tech I've ever seen. Saying Graal performs about as well as C2 and sometimes better is modest. The Graal/Truffle combo does a lot more than C2 can ever do. It is only really comparable if you ignore the astonishing capabilities it has vs the competition. For readers who are not aware of this work, and who have an interest in VM/compiler technology, I strong recommend checking out Chris' blog and the Graal/Truffle presentations that are floating around. Basically they've built a program that converts simple syntax tree interpreters into full blown JIT compilers. It means that basically any toy scripting language can have similar performance to, say, Javascript on V8, just by writing the base interpreter with their framework. But where it gets really crazy is when you write an interpreter for C or (say) Objective-C, and start to get aggressive speculative just in time compilation with seamless cross language optimisation, to the extent that C code can actually be run on a compacting garbage collector.
      - ayrx 12y ago
        > It means that basically any toy scripting language can have similar performance to, say, Javascript on V8, just by writing the base interpreter with their framework. That actually sounds a lot like what RPython from PyPy enables.
        mike_hearn 12y ago
        Yes. Some of the underlying theory is the same, but truffle appears to generalise to other languages a lot better (note: I am not an expert)
        ayrx 12y ago
        Are you aware of any comparisons that shows "truffle appears to generalise to other languages a lot better"? I'd be interested in reading them. :) The performance of various RPython interpreters like PyPy and HippyVM are pretty impressive.
  - pjmlp 12y ago
    There are multiple JVMs written in Java. Besides the sibling post, JikesRVM is one of the most well known ones.
munificent 12y ago
> - 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.
- andrewchambers 12y ago
  Not smart, obvious.
  - guipsp 12y ago
    Which is also smart.
- millstone 12y ago
  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 12y ago
    And JNI local and global refs and heap walking via JVMTI and …

jaytaylor 12y ago

Will this open the door to utilizing Java libraries from within go apps? Coming soon: scala.go (!)

mike_hearn 12y ago
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 12y ago
  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 12y ago
    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.

TheDong 12y ago

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 12y ago
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 12y ago
  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.
  - steveklabnik 12y ago
    Such schemes are not impossible, as Servo does something similar: https://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ https://blog.mozilla.org/research/2014/08/26/javascript-serv...
  - danbruc 12y ago
    At least if you are interpreting the language just using the garbage collector of the host language will pretty surly simplify the design a lot. Actually a design where every Java object is simply represented by a Go object should give this for free.
  - seabrookmx 12y ago
    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.

slowmovintarget 12y ago

Now put a Lisp on there, quick! Clogure?

fnordsensei 12y ago
Shouldn't Clojure work out of the box if it implements the same API as the JVM?
- slowmovintarget 12y ago
  If it's JLS compliant, absolutely.

tombenner 12y ago

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

deitcher 12y ago

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?

jaytaylor 12y ago
Minor note: go is now self-hosted which means it is no longer wrapped in c.
Leon 12y ago
There aren't always great reasons behind great hacks. We can appreciate them for the ideas they present, the interesting implementation of features, and the what-if's that can come from expanding the hack further.
i_s 12y ago
Depending on how it is done, one benefit could be you'd be able to use java/clojure/scala to build command line tools, something few people do now because of the slow JVM startup time.
- sitkack 12y ago
  The JVM isn't too slow for command line tools. What is too slow is the size of the executables and the amount of upfront work that secondary runtimes are doing. I can't say anything for Scala, but the startup time of Clojure has nothing to do with the JVM. Pure Java Hello World launches in 90ms on my machine. Jython Hello World takes 1.3 seconds. EDIT: to address all the comments. I am saying the JVM isn't _too_ slow for command line applications. Not ideal, but tolerable. I just tested the startup time of a robovm'ed Hello World: 23ms FWIW. And the resulting executable isn't exactly light weight. $ otool -L Main Main: /usr/lib/libSystem.B.dylib /usr/lib/libiconv.2.dylib /usr/lib/libsqlite3.dylib /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation /usr/lib/libstdc++.6.dylib $ du -sch Main 11M Main
  - 12y ago

binarycrusader 12y ago

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 12y ago
There's a " LICENSE.txt"[sic] file now. Looks like it's MIT licensed.

filereaper 12y ago

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

GFK_of_xmaspast 12y ago
On what grounds.
lclarkmichalek 12y ago
Yeah, I mean, just look what they did to the openjdk
- szabba 12y ago
  Any specifics for the unoriented?
  - saryant 12y ago
    It was sarcasm.
  - mike_hearn 12y ago
    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.

rdtsc 12y ago

Really cool. Thanks for sharing!

gnuvince 12y ago

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.

jamescun 12y ago

This is one way to get generics in Go.

btzll 12y ago
slow clap
anon4 12y ago
No reified generics though.

perrygeo 12y ago

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/

keyle 12y ago

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 12y ago
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?).
- afarrell 12y ago
  Alternately, if you are going super-TDD on things and committing after every test, that pace is also reasonable under the conditions you list. I was at about that rate when I once tried to write a scheme interpreter in javascript in a weekend. I mostly succeeded, but ran out of time before getting done with some special forms.
- keyle 12y ago
  I don't know about you, but I could maybe keep that pace 3 days. Maybe 5. But 2.5 months?
  - MagerValp 12y ago
    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.

neilellis 12y ago

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.

kolev 12y ago
What is the "baggage" of Java? This is just a JVM and Java's JVM has no much more baggage than any other implementation. In order for this to be practical in terms of performance, reliability, and so on, years have to pass and meanwhile Oracle JDK and OpenJDK are not gonna stay still. As a side note, I really wonder how an engineer can use ghetto talk like "crazy sh*t" and especially in this forum here.
- girvo 12y ago
  > ghetto talk Excuse me?
  - kolev 12y ago
    I'm sorry you're offended, maybe that's part of your lingo, too, but "crazy sht" is ghetto talk. Indeed. A self-respected and honorable engineer pays attention to detail - not only in their work, but in their language as well and especially in the meticulous choice of words. English is not my native tongue, but I respect it very much, and the language I respect does not include phrases such as "crazy sht" - it's a rich and very expressive language and only the severely incapacitated include those in their written communication.

lorddoig 12y ago

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.

andrewchambers 12y ago
There are already a few jvm's written in Javascript.
xigency 12y ago
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.