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.
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?
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.
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.
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?
agree but also, ClojureScript didn’t have runtime eval for a long time (because the compiler is bootstrapped on jvm) and that didn’t stop anyone. Even today, runtime eval costs sending all of clojurescript over the wire and no dead-code-elimination; cljs users are quite used to not having runtime eval in prod
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
> 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.)
> 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.
> The Java language was released to the public in 1995, under the Sun Community Source License, making the source freely available but requiring that products using the code were maintained to the Java standard, and that any commercial derivative works were licensed by Sun.
> Over 2006 and 2007, due to pressure from developers, Sun changed the license of the various Java packages to use the GNU General Public License with a "classpath exception", allowing developers the needed access to make derivative works and with the ability to release applications with a different license. This led to the OpenJDK (Open Java Development Kit), first released in 2007.
> Android, Inc. was founded in 2003 by Andy Rubin, Rich Miner, Nick Sears, and Chris White to develop a mobile phone platform.[7][8] Google purchased Android in 2005 and continued developing the Android operating system.[8] During development of Android, Google wanted to incorporate the Java Standard Edition libraries. Google's executive chairman Eric Schmidt had approached Sun's president Jonathan I. Schwartz about licensing the Java libraries for use in Android. Sun offered a licensing deal of between US$30 and 50 million.
> The compiler was never the problem; the API was.
I'm aware, that's the crux of the case. I was asking you to prove the statement:
> This happened before Java went open-source.
Which you have disproved now. We have no argument there - Java was open source at the time.
> Sun offered a licensing deal of between US$30 and 50 million.
> 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.
They also required Google not extend the API, which is where the deal failed.
> In other words, API were not exactly free (for an outwardly noble purpose), and Google reused them before they were GPL-ed.
So far, all juries and all but one court case has found that an API is not copyright-able. We'll see, but a compatible interface doesn't appear to be something you can license.
The problem stays: the licensing terms were not clear at the time, so while the source was available for looking ("open source"), it was not free enough (required licensing). Such was the understanding of both sides, because they talked about obtaining a license.
I should have said "before Java the platform had a permissive enough license".
If I say how nasty Oracle and Ellison have been in general, people will require me to provide references. I don't feel like researching it. But you can, if you want to answer your own question.
GraalVM (and OpenJDK on which it's based) are 100% open source, on a GPLv2 license.
It doesn't matter much what Oracle and/or Ellison do, the sources are all out there.
My biggest concern is that there's an Enterprise Edition of GraalVM. I'm a little suspicious that the Community Edition will end up crippled and EE will cost more money than I'll ever want to spend.
Let's play your fantasy out for a minute. Imagine I hire a large and good enough team of engineers to duplicate any feature in the enterprise edition and contribute it within a day of being released, to the community edition.
Do you believe Oracle or anyone will accept that?
Because if not, that's a clear problem.
(FWIW I strongly doubt they would be okay with this)
You still gain the benefit from having a nice faster GraalVM, and given it's open source, you could create a fork and encourage the community to use it as an alternative.
I'm sure if you were producing a much faster GraalVM, you'd soon get people to move away from Oracle's one to yours (MariaDB vs MySQL springs to mind as a comparison)
The problem here is what loophole a big company like Oracle can find, if they don't like you. They can't prevent you from doing a fork, but can easily sue you for not keeping copyright visible enough in project page README file.
Taking into account amount of resources they have, this will be enough to shut you down ;)
Do you mean corporate communication? The only way symbols are not used for communication are if they're immediately deleted/destroyed/only written to write-only media/etc. Even your personal diary and notes are communications with your future self.
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.
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
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/, it would seem that Mac use is only supported by their "enterprise edition"
"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."
And most importantly, there's this - https://news.ycombinator.com/item?id=16919776 ( Java SE 8 business users must buy a licence from Jan 2019 to receive updates)