This changed in Java 7. OpenJDK is now the reference implementation, and thus "the JVM"
I really want to appreciate more of the wider ecosystem and the tech that underpins it. I don't see the point in implementing what is proven on the JVM on the CLR.
Concentrate on the businesses business (the core domain), not plumbing. In short learning more about these techs in paramount.
Here's Lockheed Martin announcing that they chose a (propriety) JVM to run "several critical subsystems" of the Aegis system in 2006[0].
Here's them announcing said project passing operational trials fours years later[1]. Surprisingly fast for a military project.
[0] http://www.atego.com/pressreleases/pressitem/lockheed-martin...
[1] http://www.atego.com/pressreleases/pressitem/aonix-perc-ultr...
See here for some background and some related links (http://www.javaworld.com/article/2906981/java-app-dev/little...). There's recently been a lot of activity around RTSJ 2.0 (real-time specification for Java)[4], JSR-282, led by Aicas, and JSR-302[5] -- also led by Aicas -- which is built on top of RTSJ and meant to support DO-178B certified, safety-critical applications. I see that JSR-302 is marked inactive[6], which means it hasn't had a milestone in the past year, but I think that the relevant JVMs already implement it (or something similar), even if it hasn't been ratified as a standard.
I can tell you that for us, at least 10 years ago, it was a remarkable success, and saved us a lot of time vs. developing in C or Ada, but that was for code running on large servers. I haven't had experience with RTSJ on embedded devices. Many others have, but I doubt they read HN.
You probably want to keep DSP in C, but for everything else Java may save you a lot of time and money.
[1]: http://www-03.ibm.com/software/products/en/real-time
[3]: http://www.atego.com/products/atego-perc/
[4]: https://www.aicas.com/cms/en/rtsj
[5]: http://download.oracle.com/otn-pub/jcp/safety_critical-0_94-...
> I can tell you that for us, at least 10 years ago, it was a remarkable success, and saved us a lot of time vs. developing in C or Ada, but that was for code running on large servers.
To what do you attribute the time savings? I'm interested in using the JVM because I'm thinking I'll have an advantage in debugging over C. Would that be true, in your experience? Do you think that it was easier to develop using the JVM under your quality system than it would have been under C or Ada?
> I haven't had experience with RTSJ on embedded devices. Many others have, but I doubt they read HN.
Yeah... Do you know of a good mailing list or forum for embedded systems?
It's just much easier to produce correct code in Java than in C (or even Ada). The bigger and more complex the software -- the bigger the gains (it's easy to write simple/small programs in any language). We also used NASA's open-source Java PathFinder to verify parts of the code (there are model checkers for C, too, and others for Java). This paper (https://ti.arc.nasa.gov/m/groups/rse/papers/lindstrom-rtembe...) describes applying JPF to the realtime scheduling aspects of RTSJ (something we didn't do).
> Do you know of a good mailing list or forum for embedded systems?
Sadly, no, but others here might.
While HotSpot and the CLR are more similar -- at least in their goals -- than different, and each is ahead of the other in some respects and behind in others, I'd say that the most interesting features of HotSpot are its JIT and GCs (it comes with a few) that are years ahead of anything else used in any other environment in the industry (well, except Azul that sells a modified HotSpot with a "pauseless" GC that never pauses the application for more than a few microseconds). In my opinion, the most exciting development regarding HotSpot is the work being done on HotSpot's next generation optimizing JIT called Graal, that comes with an a complementary language toolkit called Truffle[2]. It pushes the envelopes further with regards to HotSpot's defining feature -- speculative optimization and deoptimization -- and lets the user (if they wish) control the code generation through a clever API.
Another important feature of any compliant SE JVM is bytecode manipulation. It allows modifying libraries after they've been compiled -- either on disk or during the class loading process. One use is dependency namespacing, aka shadowing (if your program depends on libraries A and B, and they each depend on different, incompatible versions of library C, shadowing can hide the two versions of C from each other). But one of the coolest things is the ability to transform (and de-transform) bytecode of running classes (to inject, say, tracing).
Since HotSpot is part of OpenJDK, all work on it (including Graal and Truffle) is open-source (and has been for a few years now). The OpenJDK as a whole is probably the world's second largest open-source project (in terms of contributors), after the Linux kernel. The main contributors are, of course, Oracle and IBM (the latter to a much lesser degree), but also Google, Intel, Apple, Twitter and many more.
[1]: https://www.youtube.com/watch?v=uL2D3qzHtqY
[2]: https://wiki.openjdk.java.net/display/Graal/Publications+and...