
Native Clojure with GraalVM - sandGorgon
https://www.innoq.com/en/blog/native-clojure-and-graalvm/
======
sandGorgon
One problem is that Graal is still on Java 8 (nearly two versions behind of
latest stable) because it is marked as LTS. I think that's a bad decision for
a bleeding edge piece of technology anyway - a lot of of the components that
Graal needs are batteries-included in later Java releases.

And most importantly, there's this -
[https://news.ycombinator.com/item?id=16919776](https://news.ycombinator.com/item?id=16919776)
( Java SE 8 business users must buy a licence from Jan 2019 to receive
updates)

------
viach
There are 2 download options for GraalVM - one with words "additional
performance, security, and scalability" and another, well, without them. Does
it mean that all the goodness of this technology is only available in the
very, very paid option? In other words, it's not for startups who are trying
to bootstrap themselves, right?

~~~
peoplewindow
No, SubstrateVM and Graal are both open source.

The enhanced versions compile to faster code, pretty much. You can do without
them if you don't want to pay.

~~~
jadbox
I'm curious just how "optimized" and the paid version is (or how crippled the
free version in comparison).

~~~
chrisseaton
Try it yourself - both can be evaluated for free.

------
dindresto
GraalVM still does not support Windows, does it?

~~~
cdrtz
GraalVM in the context of OpenJDK already runs on Windows. Native image
generation on Windows is under development, should be available in the coming
months.

------
dustingetz
so no eval at runtime which seems not to be such a big deal; we can develop at
repl and then bake images for prod

~~~
fnordsensei
Some of the Cognitect veterans have pointed out that being able to connect
directly to an instance and evaluating code at runtime has been invaluable for
debugging issues for their clients.

~~~
setzer22
However, I don't see a use case for GraalVM in long-lived server applications.
For that, regular JVM clojure will do just fine.

On the other hand, using eval is almost never necessary in small standalone
utilities.

~~~
chrisseaton
> I don't see a use case for GraalVM in long-lived server applications

GraalVM also includes a better JIT compiler though, which makes long-lived
applications much faster. Twitter use it today to run their Scala code.

~~~
kjeetgill
From Twitter engineer Chris Thalinger's videos[0] it seems like they're using
JDK 9 or 10 and graal via JVMCI. Is there more to GraalVM than just using
graal with a particular JDK release?

[0]:
[https://www.youtube.com/watch?v=_7yIUkP5LiQ](https://www.youtube.com/watch?v=_7yIUkP5LiQ)

~~~
chrisseaton
> Is there more to GraalVM than just using graal with a particular JDK
> release?

Yeah there's a whole world of different ways you can use Graal.

[https://medium.com/graalvm/graalvm-ten-
things-12d9111f307d](https://medium.com/graalvm/graalvm-ten-
things-12d9111f307d)

They're choosing to use the JIT from CE Graal (which they've built
themselves), via the released version of JVMCI in a released JDK.

------
jgalt212
some immediately useful and practical applications of Clojure/GraalVM. nice
work!

------
amelius
I'm still concerned about the license and the fact that this comes from
Oracle.

~~~
bgorman
What concerns you over the JVM versus say, GCC? Both are GPL licensed. Oracle
has committed to openJDK being the reference implementation.

~~~
shakna
Oracle vs Google over Android having the same interfaces comes to mind. [0]

[0]
[https://www.techdirt.com/articles/20180327/10431439512/insan...](https://www.techdirt.com/articles/20180327/10431439512/insanity-
wins-as-appeals-court-overturns-googles-fair-use-victory-java-apis.shtml)

~~~
pjmlp
Neither Sun, nor Oracle ever had any issue with Java vendors that play by the
rules and there are plenty of them.

~~~
shakna
... And Google isn't a vendor here.

The API was made the same, but with Google's own implementation. Several
juries and courts have heard the case and said that an API isn't
copyrightable. CAFC dismissed the juries' findings without reasoning. It's
been punted back to a new jury and court for a final hearing.

~~~
pjmlp
Google admited several times that they haven't done a clean room reverse
engineering and their emails prove they were consciously trying to work around
Java licensing issues.

If Google cared so much, they could have bought Sun, but they were expecting
it would just crash and burn, while the company would get away with it.

Sadly for them Sun actually got a buyer.

~~~
shakna
> Google admited several times that they haven't done a clean room reverse
> engineering

> It is undisputed that Google copied verbatim the declaring code of the 37
> Java API packages—11,500 lines of Oracle’s copyrighted code. It also copied
> the SSO of the Java API packages. Google then wrote its own implementing
> code.

The only problem with Google's implementation is the copying of the API.

\---

> If Google cared so much, they could have bought Sun, but they were expecting
> it would just crash and burn, while the company would get away with it.

> The parties were unable to reach an agreement, in part because Google wanted
> device manufacturers to be able to use Oracle’s APIs in Android for free
> with no limits on modifying the code, which would jeopardize the “write
> once, run anywhere” philosophy.

> in any event that the jury must have found that Google did not act in bad
> faith

Google tried to get a reasonable license.

\---

Even CAFC has said that if Google had not received advertising revenue from
Android, their use of the APIs would have fallen under fair use. They are not
a Java vendor.

~~~
pjmlp
> They are not a Java vendor.

Last time I checked
[https://developer.android.com/](https://developer.android.com/) and
[https://developer.android.com/guide/platform/](https://developer.android.com/guide/platform/)
has the word _Java_ written all over the place.

So apparently they license an operating system, that makes use of Java, the
language, and a subset of its standard library, to the point that it affects
the sales of other Java vendors.

On my naivety it makes them a Java vendor to me.

~~~
shakna
Strangely I can only find 'Java API'.

> The entire feature-set of the Android OS is available to you through APIs
> written in the Java language.

> Build toolchains, such as Jack, compile Java sources into DEX bytecode,
> which can run on the Android platform.

Seems they make no use of the JVM... Which would be required to vend it, no?

~~~
pjmlp
A JVM is only one possible implementation of the Java language.

A few Java vendors on the embedded space also provide their own
implementations, where .class files are converted either into their special VM
format or straight into native code, before generating the firmware image for
deployment.

Android uses Java the language, alongside a partial implementation of Java the
standard library. The way it is implemented, is like any other programming
language, a detail.

The fact that I can pick any Java library that compiles under that subset and
use it on Android is expected by any Java developer.

Likewise embedded vendors that sell C compilers, even if they aren't fully
ANSI C compliant, still acknowledge they are selling C compilers.

~~~
shakna
You seem to be confused on a few points.

The court case is that Android infringes on Java SE, not the Java language.
The question is if it infringes on the platform, not the language.

> Android uses Java the language, alongside a partial implementation of Java
> the standard library

That's not what is being disputed. They use an API written in Java, afterall.

> Likewise embedded vendors that sell C compilers, even if they aren't fully
> ANSI C compliant, still acknowledge they are selling C compilers.

And Android has a compiler for Dalvik and AR. That's not up for dispute
either. That doesn't make them a vendor for Java SE. No more than the compiler
in GCC makes the GNU project a vendor.

> A few Java vendors on the embedded space also provide their own
> implementations, where .class files are converted either into their special
> VM format or straight into native code, before generating the firmware image
> for deployment.

Usage of the Java brand requires any platform you ensure compatibility between
your implementation and all other implementations [0]. The Android SDK is not
compatible to the letter of that trademark license, as the Android SDK is both
a subset, and also extends the Java API, so Google followed their license by
not claiming it.

\---

The only thing being disputed, is if their Java-written API is allowed to
reflect Java SE's API.

Google is a library vendor for a library that reflects a subset of the host
language. They also have their own compiler for a subset of the language.

> Likewise embedded vendors that sell C compilers, even if they aren't fully
> ANSI C compliant, still acknowledge they are selling C compilers.

This is more akin to claiming that a C++ compiler is infringing on a C
compiler by both being compatible with a subset of the C language.

[0] > This resulted in a legal dispute with Microsoft after Sun claimed that
the Microsoft implementation did not support RMI or JNI and had added
platform-specific features of their own. Sun sued in 1997, and, in 2001, won a
settlement of US$20 million, as well as a court order enforcing the terms of
the license from Sun. As a result, Microsoft no longer ships Java with
Windows.

~~~
pjmlp
Fact, Google ships an operating system with the userspace written in Java the
language, making use of a subset of Java standard library.

Fact, Google created a schism on the Java compatibility story by only
providing a subset, thus forcing Java developers to write Android specific
libraries.

Fact, if Google actually cared about Java they would have bought the Java
assets from Sun, after helping driving them to the ground, as they were aware
Sun was short on cash and would never sue them.

Now we can all enjoy a broken compatibility story up to Java 8, while Java 10
is out there and the distance will only increase.

Android is just as bad for Java portability as J++ was.

But hey, it is the nice "do no evil" corporation against the big bad lawyer
corporation.

~~~
shakna
I don't know what your problem is, and I don't know why you believe certain
'facts' that have never been presented at trial, but would clinch the case
against Google.

I'm tired of reading legal documents to answer your complaints. You can read
yourself, or continue ignoring the court case. Adios.

~~~
pjmlp
My problem is that Google just played a Microsoft, forked the Java eco-system,
but because it is the beloved "Do no Evil " company of SV, it gets love
support like yours instead of the hate Microsoft did exactly for the same
result, while we Java developers have to workaround the fragmentation issues
Google has brought into the Java world.

My problem is that I cannot pick any random Java library out of Maven and be
100% assured that it will run at all on Android.

My problem is that Android most likely will never move beyond its partial
implementation of Java 8, as per Android P.

If it was for Google's wishes, Sun would have closed doors, hopefully no one
would have bought the Java assets, they would get away with it, and we could
all enjoy a Java language stuck at what was Java 6's subset.

~~~
shakna
> My problem is that I cannot pick any random Java library out of Maven and be
> 100% assured that it will run at all on Android.

You need to stop thinking of the Android SDK as Java, because it isn't. It has
Objective-C to C similarities.

It doesn't have API compatibility, or bytecode compatibility or even the same
class constructors.

Thinking they're pretending to be the same is going to cause nothing but
frustration, and hurt you. It'll irritate and chafe more every time you have
to touch that god-awful ecosystem.

> it gets love support like yours instead of the hate Microsoft

No Google does not get my love, I have ranted against their practices for
years. This conversation has been about legalities, not ethics.

They suck as a company - but we have ecosystems built around compatible APIs,
a legal precedent here would be awful for everyone. (Firefox's new extension
API, the entire JS ecosystem, etc.)

~~~
pjmlp
> You need to stop thinking of the Android SDK as Java, because it isn't.

That is exactly my point, Google has broken Java's compatibility story,
regardless if they have found a legal loophole to get away with it or not.

Objective-C and C are two completely different programming languages, where
Objective-C is a superset of C. Any C compliant code is compilable by an
Objective-C compiler.

It is not the same as what Google has done to Java.

------
truth_seeker
How efficient is it compared to Azul Zing JVM ?

------
cup-of-tea
I cannot wait for emojis to go out of fashion.

~~~
aisyx
I'm alright with emoji as ideograms. I'm not okay with it in communication
though.

~~~
chrisseaton
What is an ideogram if it isn’t communication?

~~~
aisyx
In this instance I was referring to dialogue. A standard set of pictographs
for use in websites and signage is fine, but when someone I'm talking to over
text uses emoji I find it jarring and irritating at best.

------
abc_lisper
Does graal run on arm

~~~
cdrtz
A Graal backend for AArch64 is currently under development. See for example
these PRs at
[https://github.com/oracle/graal/pulls?utf8=%E2%9C%93&q=is%3A...](https://github.com/oracle/graal/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+aarch64+in%3Aname).

------
latenightcoding
Sorry for pointing the obvious and not adding anything useful to the technical
discussion, but after the recent events I would not touch anything coming from
oracle with a ten-foot pole

~~~
walkingolof
I do not understand the rationals for this, its licensed under GPL2, care to
elaborate a bit ?

~~~
TAForObvReasons
Parts are licensed under GPLv2+Classpath and other components like the js /
python layers are licensed under UPL. And based on
[https://www.graalvm.org/downloads/](https://www.graalvm.org/downloads/), it
would seem that Mac use is only supported by their "enterprise edition"

~~~
cdrtz
"The reason why we don't build CE on Mac OS is purely technical. Its because
there was no OpenJDK 8 build for Mac that we could use. We hope we can change
that soon. OpenJDK builds got a lot more regular with Java version >= 10."

(Source:
[https://news.ycombinator.com/item?id=16859559](https://news.ycombinator.com/item?id=16859559))

