After hearing about GraalVM first time at a PolyConf talk last year I sat down with one of the GraalVM folks and we (well, I was just providing info) did a few performance measurements if this could speed up the startup time (especially for leiningen tasks) - the preliminary results were pretty cool.
So if you're using Clojure and Leiningen and are annoyed by the long startup times... there's potential :)
Performance can vary quite a lot from task to task, also compile times suffer a lot and you lose some dynamic features.
So from what I understand it might be useful for clojure cli apps, but at this point I am not sure it brings a lot, but this is early days.
The cool part is the polyglot capabilities imho.
Then there's the elephant in the room: the licensing and potential changes in the long run.
For clojure if you want decent cli/startup experience there's always cljs, lumo or you can go with something like fennel-lang, a clojure looking lisp that "transpiles" to lua(jit), so 0 overhead compared to lua and super fast startup.
>Performance can vary quite a lot from task to task, also compile times suffer a lot and you lose some dynamic features.
That's actually really bad in Graal. I compiled a few classes project in Java, JS and Ruby. Compilation time was measured in minutes and memory usage most of the time was >8GB.
To be clear (for anyone reading), it's SubstrateVM's whole-program compiler (and corresponding analysis') that does this, not Graal itself -- Graal can be used as an ordinary JVMCI compiler in an ordinary JDK, like HotSpot C2. Graal is really just a very fancy compiler-backend-as-an-API that can emit native code from a CFG (like LLVM, sort of), just written in Java. SubstrateVM uses Graal to emit binary object code from the JVM class files you specify at compile time, when you use the 'native-image' tool -- but it otherwise has a different compilation pipeline entirely (AFAIU.) So Graal can both be used for a JIT or AOT compiler...
SubstrateVM was designed more to make Graal/Truffle based interpreters like TruffleRuby and FastR have fast startup time with small binaries, which is a large and complex project, more than it was meant to compile small, random one-off Java/JVM applications for CLI usage. From what I remember in my few random experiments the compile time isn't quite linear in size at least (e.g. compiling a 10 line Java class file takes 2 minutes, but compiling a 100 line one takes only marginally longer, comparatively.)
(Using SubstrateVM also means that there is no JIT for the JVM class files you compile to native code, so you're dealing with a purely ahead-of-time compilation scheme. Graal's online JIT still kicks in for SubstrateVM-based interpreters like TruffleRuby, however. This is an important distinction to understand.)
Hopefully they can improve the compile time requirements a bit for cases like this, since it's surely more popular and common case that people are looking for, as opposed to writing Truffle-based interpreters.
You'd be surprised, there are people in the community with some clever ideas to do that with a (fast)client/server model and change diffing (incremental builds), but it's super early days.
With tools.deps and the need of some companies for more advanced build setup a lot of people are actually thinking about these issues.
I'm not denying that someone, somewhere is working on something.
But I'd be surprised indeed, I'm not watching the whole clojure space closely, I can only say that no one hit the #leiningen irc channel or posted something on the bugtracker/proposed a PR yet.
And the client/server model.. sure, nailgun and grenchman were a bit clunky, but none of these efforts have gained widespread adoption, afaik. Most people don't just go out of their way to tweak their build tool.
> And the client/server model.. sure, nailgun and grenchman were a bit clunky, but none of these efforts have gained widespread adoption, afaik. Most people don't just go out of their way to tweak their build tool.
I was not thinking about these two, nor was I thinking about a patch for boot/lein.
That said the slow startup issue is only really valid for cli apps (and maybe CI), if your dev workflow relies on re-starting your repl all the time, it's a broken workflow.
There is a group of people that love to say this ("If you're not using a repl or restarting your repl all the time, you're doing it wrong"), but I've been using Lisp for more than 20 years and I don't agree. A repl is nice, and I use one often, but it does have tradeoffs. One is persistent state--It can be quite easy to get your repl into a state where your code works, but if you run the app from scratch it doesn't because definitions are out of sync (e.g. you renamed a function, but forgot to change the name at a call site, so you end up calling an old version of the function.)
Developing in a repl is nice, but it's not the only allowed or legitimate or even good way to do development in Lisp or other dynamic, interactive languages. Clojure has an issue with slow startup (another tradeoff made for good reasons that don't fit everyone's situation)--denigrating other people's development approaches doesn't solve that, it comes off as defensive.
> I've been using Lisp for more than 20 years and I don't agree. A repl is nice, and I use one often, but it does have tradeoffs.
Me neither, and I also carry decent Lisp cred.
I know what I'm doing to the extent that I can write a bunch of code in a file, and have it work, more or less.
If I experiment with changes to code, I want to see the diff (as in git diff).
Actually developing in a REPL seems very scatter-brained; you don't know what you're running since you've been mutating things left and right.
Those that develop in a REPL actually develop in some kind of text editor which sends expressions to the REPL; that's what allows them to save the code properly to a file. Problem is, you now have three versions of the code to keep straight: editor, file and image.
Okay, so you have massaged things into working. Well, which is the code that is working? Obviously, the code that is in the image. But of the textual codes does it correspond to? If you just save the content of every edit buffer to disk, is the code on disk exactly that code that is working in the image?
Even if I have to work with a running image (say there is a lot of state that is difficult to reproduce from a clean start), I'm still going to work with some files, which I will edit and completely save to disk, and load all together as a unit into the running image, instead of evaluating individual expressions out of an edit buffer.
> So you have no excuses not to build your CLI tools in Clojure now.
Well I do disagree with this part, see other sibling comments (not by me). I'm not even sure GraalVM is really production-ready, notwithstanding the potential licensing and long-term issues.
We are starting to do that, and for very simple operations, it works (like scripts for maintenance that we deploy remotely, and run as cron jobs). So far no big surprises, but we were very careful.
The big minefield is that you do not really know which libraries will go boom and where, as any place could make use of class loading.
What licensing issues do you have in mind. Graal and SubstrateVM are all GPL-with-classpath-exception licensed, same as Java itself. It's an open source license.
No, at least not back then. Otherwise we might have an official branch or PR already. I didn't really follow up on this, this was just a quick hack session to see if we could get something like "lein version" or "lein deps" or something to run and compare the speed.
One main problem I also see is the distribution. Currently leiningen only needs "some sort of java executable" and then the rest is pulled in. So would you have to have GraalVM installed or could this also be bootstrapped.
GraalVM is very impressive. But clojure is very much associated with Java/JVM Ecosystem which makes it very hard to convince people to use it. My ruby friends would say oh i cant install clojure because i have to install JVM. Clojurescript like lumo or planck is still better, but it isnt a real backend solution. Clojurescript is great for the frontend though. I think clojure needs a native solution written in Clojure + LLVM that leverages existing C-libs. A seperate JIT/compiler that is not JVM, that is not a language with Borrowed GC + VM.
I love Clojure. The JVM is a catch-22 for the language. Clojure is as successful as it is thanks to the huge JVM ecosystem. But it's true that some (a lot?) of folks won't try it, due to suspicion of Oracle, hatred of Java culture, perceived bloatiness of the JVM, etc.
I know a senior dev who loves Ruby and Elixir and won't consider touching anything in the Java ecosystem ever again after a terrible experience at a government consulting company.
So yeah. I think the best shot I have at convincing him to try it is to point him to something like Clojerl: https://github.com/clojerl/clojerl
I wonder what that terrible experience was and how it could be so bad. After all I've had bad experiences with apps written in C, C++ and Python but I'd still use these tools when necessary. To write off something as huge as the JVM and its ecosystem because of one bad experience seems iffy.
I think the reality is there are a lot of people for whom hatred of anything Java is a fashion statement, a strange geek form of virtue signalling. Oracle is not significantly different to Microsoft or Apple after all - they are all companies that like money and have sued Android related companies over IP rights to obtain lots more of it. If anything Oracle's moral case is a lot stronger as Java represents a much greater investment than FAT32 or rounded rectangles or the other stuff these firms demanded ridiculous sums for. Yet hackers are just A-OK with praising and promoting VS Code, macOS, Swift, etc.
I don't personally mind. The more people who ignore the Java ecosystem for fashion related reasons, the more my competitors reduce their strength and relevance. If your senior dev friend is off writing code in Elixir and struggling with low performance VMs and tiny library ecosystems, I'll be outpacing them with better VMs, better tools and a huge ecosystem of open source libraries. No problem!
It means installing a big runtime they aren't familiar with, and getting their feet wet with a huge ecosystem which spans from weird stacktraces to the standard libraries and beyond, and is associated (somehow wrongly) with boring code and old enterprise solutions.
Clojure stack traces are usually long and somewhat leaky, they are hard to read without (and sometimes even with) preexisting knowledge about Java / JVM / Clojure implementation details.
On the other hand, with some Java/JVM knowledge, they are very helpful. Whenever I come across supposedly nice error messages in most other languages, I'm convinced more and more that stacktraces are one of the right ways to do it...
Actually that is not true, Ruby stack traces are beautiful. Recently i saw a feature called "Did you Mean?" Have you ever seen such a stack trace in any other language? Clojures Stack traces are unreadable. My strategy with clojure debugging is usually commenting code and println thats how bad stack traces are in clojure but the thing is Clojure as a language is very thoughtful and thought provoking much more than any scheme i have seen. And certainly more enjoyable to code in than Ruby.
Folks at-least comment with a good reason before giving negative points for a comment. It helps clarify how the message was received a negative point without a comment is quite pointless and banal.
I am not sure how do i explain this, but a lot of people think about JVM with verbose slow VM code that works in the enterprise. java binary doesnt even follow unix styled cli options. the worded cli options are single hyphenated. There are many oddities associated with JVM/Java which are purely superficial. But yet a lot of people think it is irritation to use JVM, plus the perceived notion of Enterprise bloatware.
I get it, I make broad aesthetic choices about my technology too. Especially to avoid picking up an ecosystem I'd otherwise get to avoid ... so I'll add my own sterotypes.
Aren't all those crticisms double for Ruby? And Node?
You're adding a runtime, a package manager, and packages to your system with all three but two of them are just raw source code ...
> a lot of people think about JVM with verbose slow VM code that works in the enterprise
They are severely misinformed, then, and it would be a good deed to give them an opportunity to learn more about this.
Which is: Java is fast. Its startup time is impressive, and the runtime performance is generally also good. RAM usage could be less impressive, but I read that it can be optimized for memory consumption, achieving pretty good results - I don't have any experience here, so I can't really say.
Anyway, my problem with Java, is that it is not designed to be used on its own. To use it, you need a build system, and the language doesn't give you one; which is why there are many different systems, which you need to navigate somehow. Having to learn these build system (XML? custom Groovy implementation?) is what made me dislike Java. It's not that different in C++ or C#, but it adds to the feeling that you work with an ancient technology, not a modern one.
That's however not the problem with Clojure - it at least has a single build system + package manager - Leiningen. To me, what disqualifies it, is the startup time of its REPL. Well, that's only because I have a luxury of not needing to do anything on the JVM - so I'm speaking from a position of a hobbyist polyglot programmer considering new languages to learn. I would probably reconsider if I had a job where JVM would be a must, but the specific language was not yet chosen (how probable that would be is another matter). Anyway, back on topic: I don't have Clojure on this machine, but last time I tried it, it took more than a second before the prompt appeared. That is slow even when considered on its own, but it borders ludicrous (speed) when compared with other Lisps, which seems to be the right frame of reference here. In that comparison, it's... Well, just to let you know how bad it is, Common Lisp and Chicken Scheme, two Lisps I do have on this machine, have startup (+ shutdown!) times like this:
-▶ time sbcl --eval "(exit)"
This is SBCL 1.4.6-1.fc28, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
sbcl --eval "(exit)" 0,00s user 0,00s system 94% cpu 0,006 total
-▶ time csi -e "(exit)"
csi -e "(exit)" 0,00s user 0,00s system 93% cpu 0,005 total
Now, two things:
1) I get it that "you're supposed to have a deamon process in the background, so you don't need to start that often", but this, in itself, is basically announcing surrender. In Common Lisp you're supposed to do the same, but not by necessity!
2) Yes, I tried alternative runtimes/implementations. Indeed, they are better. However, until they get, provably, 99% the same semantics as the reference implementation, they won't be adopted by any significant amount of people, which has enough of the drawbacks to make me not seriously consider using them. Anecdotally, last time I looked, I've seen lots of lein plugins for setting up projects with ClojureScript on the frontend and some (pure) Clojure Web framework on the backend. There has to be a reason behind that.
TLDR: Java is very fast, Clojure uses JVM in ways which are inherently slow on that VM, but refuses to honestly migrate to a more suitable platform, because of Java ecosystem, which is also a major selling point of the language.
At least, that's my understanding of the situation - if I'm wrong, I'd be happy to get corrected.
I understand, i too had the same apprehension about clojure/JVM before i used it. Though the startup time of clojure was slow, Java is anything but slow. The startup tie has improved quite a low in clojure the past few months, but leiningen is still a pain to use.
> TLDR: Java is very fast, Clojure uses JVM in ways which are inherently slow on that VM.
JVM is really not the best platform for hosting either dynamic languages or functional ones.
Heres the time taken by csi, clojure , racket , sbcl.
>> time csi -e "(exit)"
real 0m0.088s
user 0m0.020s
sys 0m0.027s
>> time clj -e "(System/exit 0)"
real 0m1.944s
user 0m3.272s
sys 0m0.253s
>> time racket -e "(exit)"
real 0m1.100s
user 0m0.503s
sys 0m0.296s
>> time sbcl --eval "(exit)"
real 0m0.060s
user 0m0.023s
sys 0m0.025s
Java might be fast once it's had time to warm up, but its startup time is impressive only in how excruciatingly slow it is.
I wrote a small utility program in Java recently. It was getting slower and slower as it grew, so I profiled it. It turned out the slow parts were every part - the first time that part executes. E.g. parsing the command line arguments was slow the first time, but fast if I did it a second time. Same for reading configuration files, opening sockets, etc. I assume this has to do with a combination of lazy class loading (which is slow) and the JIT compiler not being warmed up.
Unfortunately for Java (and its users), you rarely need to parse your arguments a second time, so you never get to experience the case where Java is fast. It needs to be fast the first time, and it's not.
> To use it, you need a build system, and the language doesn't give you one; which is why there are many different systems, which you need to navigate somehow. Having to learn these build system (XML? custom Groovy implementation?) is what made me dislike Java
This sounds a bit out of date, as the vast majority of builds these days are Gradle, and those that aren't are probably 99% Maven.
However your point stands in that in both cases the build technologies are fairly arcane - few people who use them understand them well and they do form significant pain points whenever you need to go beyond the simple uses.
Ruby is great but its VM is no match for JVM. Still a kid on the block recently started experimenting with JIT. Its a long way to go before YARV can come close to JVM Performance.
oh I knew, it's not about perf, it's about perspective. Kinda like python.. Last week I've read some physicist saying he stopped cpp after 15 years to write python. It was more human friendly to write python and few performant bits in C than dealing with cpp culture. I'm sure that's the same for Java.
It's important to remember that the JVM alone is a huge community. The fact that a lot of Ruby people don't understand the value of the JVM is really their own problem. The JVM is a far better runtime than any of the Ruby VMs, and it has a much better story when it comes to dependency management and packaging.
I don't actually see much value in having Clojure on LLVM as you'd have to build a whole ecosystem from scratch instead of being able to rely on the mature existing ecosystem that the JVM provides.
Actually the JVM is one of the reasons I would recommend clojure. It's a fine piece of engineering; much more solid than most VMs out there. Lots of tools for perf/monitoring/debugging.
Why would you require an existing C lib? These days you have lots of JVM apps doing heavy lifting: from bigdata stuff (hadoop, presto, kafka, others) to webapp stuff (undertow, check techempower benchmarks). For those special cases you can wrap a C lib with FFI, but in my 10+ years of JVM experience I only needed to do it once, and it was because I was streaming video on a jnlp (java swing/java web start) app which worked remarkably well, considering I supported windows,linux and mac.
Thats Difficult, because DHH is against Java, and he refused to use JRuby. I dont see how people will adapt TruffleRuby when their supreme leader refuses to acknowledge any other ruby but MRI.
> friends would say oh i cant install clojure because i have to install JVM
It's interesting how in the software world people whom you'd expect to be entirely rational make decisions based on feelings and hearsay. I don't understand this.
I say "in the software world", because I see more objectivity in hardware design. Hardware engineers rarely black out entire technologies just because they don't feel like it.
> For many real world applications, you'd need to load classes that isn't known at compile time (e.g., a user supplied database jdbc connector).
I'm not familiar with some of the dev patterns here, but why not just load all the classes for the databases you want to support, from the top, and compile them all in? Is that not practical?
> just load all the classes for the databases you want to support
you cannot distribute some connectors (e.g., the oracle connector or the mysql connector), in the case of jdbc anyway.
And it's not always possible to know ahead of time the classes you want to pre-load, if your application is like eclipse with a plugin architecture which can allow users to install custom plugins.
It just hasn't been a limitation in the jvm so libraries end up depending on those tools.
A ton of stuff ends in up doing class loading, bytecode generation, dynamic serialization.
The easiest off the top of my head is webapp containers like Tomcat or Jetty. As it runs your load a whole zip file with a full set of jars on the fly afterwards.
AOT can deal with it. In Java 9 or 10, they added an ability to AOT compile modules. You can still do dynamic classloading with the result, and the JVM still warms up to higher peak performance than you get with a static AOT compiler alone.
The SubstrateVM flavour can't do dynamic classloading or go as fast as HotSpot, it's strictly less powerful and compatible. However the static points-to analysis it does along with other optimisations mean much smaller binaries and memory footprints. If those matter to you and you can sacrifice classloading, great. If you can't, experiment with HotSpot's AOT support (which also uses Graal under the covers) and you can get faster startup time, but without the memory savings.
Clojure apps are typically packaged as standalone uberjars. So, all the classes come from the dependencies that are declared at runtime. The problem you're describing is mostly associated with Java app servers.
Personally, I wonder why class-loading is not possible. In the end either a class exists in the closed-world that existed when the project was compiled, or it does not. Of course you cannot change the JDBC connector after it was compiled!
Maybe they could add a whitelist of "known" entry-points for class loading, as to avoid going through a list of 10,000 inner classes that existed at compile time but nobody will ever instance by name.
> Of course you cannot change the JDBC connector after it was compiled!
no, but you can add, dynamically at run time (such as from a user supplied file) a new implementation of the interface. And because as part of the JDBC interface, a connector is able to register itself too (via classloading magic).
JDBC is just an example of a common plugin architecture for extensible software. But perhaps one way to make this work with AOT is to bring along the AOT compiler, and AOT the connector jar when it is being loaded, and treat that binary same as any dynamically linked library!
What I'm saying is that it breaks when you do a Class.forName(...), while if such class is known to exist at compile time, it is the same as a switch statement on the class name that returns a new object of the same type; and that second form would be a valid operation.
> What I'm saying is that it breaks when you do a Class.forName(...),
but you don't do this. you register the classes according to what is on your file system and you load one that matches your criterions or you ask your user to choose one in a UI of some kind.
What people are talking about is different. It's when the app genuinely loads plugins that weren't available at compile time, or generates bytecode on the fly.
There's some libs that don't quite work with GraalVM yet, due to some unsupported features. I'm guessing these issues will be solved quickly enough, and then we will be able to deploy small binaries :)
I saw the talk live last Friday in ClojuTRE. Someone asked about performance, and IIRC the speaker said that a GraalVM-built native binary tends to run about 50% slower than JVM for long-running tasks.
For some purposes this matters and for some others it doesn't. I can certainly see the benefit of quick startup for e.g. CLI tools. And for servers, the security benefit of running a single standalone binary blob inside a multistage Docker container might be easily worth it.
At a minimum this will be very useful for command line utilities: small memory footprint and good runtime performance. I used to use Gambit Scheme for command line utilities for the same reasons.
Valid point, but to a degree I still see this for the whole Java ecosystem.
Many people over the last 20 years were dissuaded from using Java just because of the looming Oracle "threat".
I'm not advocating to make GraalVM a mandatory dependency, just saying this could be an interesting project for people who are annoyed at the status quo, and there are a lot of startup speed complaints.
Unfortunately my day job has nothing to do with any JVM or Clojure anymore, so I can't divert any time there.
GraalVM is itself an open-source project that is licensed under the exact same license as OpenJDK [1]. Feel free to download it and build it yourself to be extra sure [2]. All the FUD around this stuff and Oracle is a bit comical. It's all... right there.
But it's not "all" there - some things are reserved for the enterprise edition. So if people start adopting it now in the hope that its remaining technical limitations will eventually be adressed, we might discover that the improvements only apply to the EE version, while the open source version is kept more or less where it is to encourage people to pay up.
This is true of every freemium project, from Gitlab to all the commercial Linux distros that sell support+prop extensions on the side. Given that GraalVM is a virtual machine there's strong incentive to push it far and wide. History suggests that VMs that are free and widely available survive and thrive (eg Java and .NET) while VMs that are expensive and/or difficult to redistribute die (eg Smalltalk). Oracle's incentives here, seeing as they want languages and library developers and ultimately application developers to actually deploy on GraalVM, is to go "far and wide" and not deep and narrow when it comes to their customers.
> its remaining technical limitations will eventually be adressed
It's not clear there are any technical limitations that separate CE and EE. Supposedly EE is faster but I don't think anybody has proven this with real benchmarks. All of this is clearly documented in https://www.graalvm.org/docs/faq/.
The native binary produced by Graal CE does not support runtime optimizations - that is EE only. As such, native binaries will start faster, but run slower.
This is true of many, many open source projects and has always been true. My first Linux was SuSE. Had to pay for it. The source was there but if you wanted Linux in an easy to use form, not so much. It was no big deal to pay because I knew it was funding the open source work. My first smartphone was an Android phone. I've paid for them, sometimes mostly to get software upgrades, because the pure open source builds were not as good. I buy a Mac even though I mostly use open source apps available for Linux and even though parts of macOS are themselves open source, because I want the extra proprietary features.
In the end most open source software I use is ultimately funded by better paid-for versions that people opt in to. The sky doesn't fall.
It's not like they did a hostile take over, sued Google for API, and dump their failing project to apache or anything. Or refused to give TCK to apache harmony project. Or hell even tons of anecdote of Oracle buying out services just to bilk people with more money until it rot. Or have a clause for anybody using Oracle DB cannot benchmark.
I feel people easily forget or act as if past actions/history isn't a metric to judge a company by. You can't predict the future with your feeling you can only do it via past data/actions. That or is it tribalism dogma that their bread and butter tech is being harshly criticize?
Google helped sink Sun with their Java fork and they could have bought Sun if they really cared about it.
The only company besides Oracle that cared about Sun assets was IBM, and I very much doubt they would not have done the same thing to Google. After all, Sun would have liked to do it if the bank account had any money left.
There was a limbo period where Sun, circa 2004-2007, had a defacto opposition to any consideration of any Java being open source until OpenJDK came along. I asked the question of senior figures in 2005 and they laughed it off. ONly to then be forced to adapt when Redhat et al wanted an FLOSS java. Thus OpenJDK got a licensing exception.
Ultimately the dev kit for android is a clean room implementation (submitters made legal commitments to that fact). The question pivots on how you feel abut the IP of the java language and the library interfaces being used by someone else.
With the caveat that Android is an incomplete implementation of Java libraries and JVM capabilities, thus not only it increased the bleeding on Sun's finances, to this day it is impossible to pick random Maven Central packages and be sure they actually run on Android.
A scenario that is only going to get worse as Java keeps improving.
I remember exactly what Sun Microsystem did it breached and been waving a carrot in front of Apache about TCK. What's stopping Oracle from giving TCK now? Also that's exactly not the whole truth you're presenting.
> Unfortunately, Sun breached the JSPA in 2006 by licensing the Java SE Compatibility Kit under terms inconsistent with its prior representations to ASF and its obligations under the JSPA, and incompatible with ASF's development of Apache Harmony. ASF urged Sun to honor its agreements, but after Sun persisted in its breach for a year, ASF withdrew from the JCP. At the time, Oracle supported ASF's position that Sun was in breach of the JSPA. But after acquiring Sun, Oracle adopted Sun's policy, disregarding the limits of the JSPA that formed the basis for ASF's participation in the JSP and acceptance of the various TCK licenses.
> Some people easily forget or act as if past actions/history aren't a metric, while others forget who actually did them in first place.
Choosing a video to support half a truth or a part of timeline doesn't mean anything.
> The heart of the issue is that Apache can't certify that its open source Java implementation—called Harmony—conforms with the Java language standards because Oracle refuses to supply the necessary test suites under a suitably open license. Oracle's position on the issue falls afoul of JCP policies, which stipulate that standards and other relevant materials must be freely redistributable and made available under terms that are conducive to enabling third-party open source implementations.
You're deflecting any and all of Oracle's action toward Google should have bought it and well Sun did it first. That's a terrible argument to counter my point of Oracle past actions being terrible toward open source. The "google should have bought Java" is such a hand wave especially when Google did a clean room implementation of Java and involve the issue of if API is copyrightable (https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google...).
Google did such a good job implementating Java that to this day there are still compatibility issues with standard Java, the library is incomplete and not all features of a standard JVM are available in ART.
They just broke Java the same way as Microsoft tried first, but since its the "Do no evil" company it gets a free pass.
Had it been other company and the Google support team would have another opinion.
I care about companies that care about Java, not those that fork the eco-system.
There are several companies playing by the rules, selling JVM implementations since the Sun days, none of them ever had issues either with Sun or Oracle.
Again the main point of my post was the FUD about Oracle and opensource is not base on nothing. Oracle's past actions toward open source shows this. You're welcome to disagree with counter argument, I would like to learn and be wrong if I am wrong (or missing something).
But I failed to see how your personal opinion on fork on java and ecosystem have to do with my original post on Oracle's FUD and past action against open source.
If none of your cases you've bought in this argument/debate is toward this topic then I think you're pushing a narrative and being dogmatic toward Java. I have no beef against the language but I am wary of Oracle. I'm merely refuting/adding toward the comment of the post I'm replying to.
Fair enough, although had IBM bought Sun instead, as no other company cared to do an offer, I doubt that they wouldn't have done exactly the same thing towards Google.
So if you're using Clojure and Leiningen and are annoyed by the long startup times... there's potential :)