If you are interested in a deep dive into the Truffle technology and are interested in why it makes sense to implement a language on top ofTruffle checkout my recent Rebase talk for a really long answer:
https://youtu.be/O4icaN9khp4
Hey, I absolutely love Graal and where it is going. Big problem for me has been the license: GPLv2+CPE. On its own this is not a problem but coming from Oracle it makes people nervous.
I think if there's ever room to move towards Apache 2 or similar license it would be really welcome.
There's no reason to think that you're safe even if it were Apache-licensed. One of the things that was made clear in Oracle v. Google is that Oracle effectively treats litigation as an essential expense for exploring all revenue sources, leaving others susceptible to suits whether they have merit or not. Compounding this latter concern was that another thing made clear is that the terms of the respective licenses is something that Oracle doesn't consider important. Refer to McNealy testifying for example that commercial use of even GPL-licensed work is prohibited (despite the terms of the license not supporting this stance).
Oracle v. Google has nothing to do with it (Java’s licence at the time explicitly disallowed mobile usage)
Do you have an examples that give rise to any sort of concern about the usage of GPL-licenced code (regardless of code owner)?
It's like we're not even having the same conversation. McNealy, founder of Sun, testified under oath that GPL doesn't permit commercial use. What was unclear about this the first time it was stated?
Question for you, but first I just want to say thanks! The technology is awesome.
That Tetris game is that a command line thing? If so what library are you using to manipulate the console? I've wanted to create interactive command line utilities with the JVM for a long time and it's always been not supported.
It is true that you can write a compiler frontend targeting a generic backend (like GCC), and take advantage of existing optimizations. Truffle's somewhat unique value prop is that you can write a basic interpreter (not compiler) and get performance approaching that of a top-end JIT.
A question: how does a company allegedly so lawyer-first, tech-second manage to develop such cutting edge software? Oracle isn't normally a name that comes to mind when people think of programming language research.
> Oracle isn't normally a name that comes to mind when people think of programming language research.
Oracle has a very large, well-funded, and long-term PL research lab that consistently produces top-tier papers, and funds and collaborates with many academics.
If it doesn't come to mind when thinking about PL research then I can't think you're reading much PL research.
>so lawyer-first, tech-second manage to develop such cutting edge software?
Most DBA I met would not argue against Oracle having the best Database. Whether they would choose to use it for their projects is entirely different though. Something that is objectively good has zero to do with whether you like or dislike the company.
The amount of work that is going into JVM and VM research is absolutely insane. One VM to Rule them All, [1], that was submitted to HN in 2013.
This is fascinating. Combined with all the other languages that are now supported, along with its incredible capabilities, GraalVM is shaping up to be a truly modern “common language runtime” — what the .NET CLR and DLR once promised to be but so far have failed to deliver.
And for what it’s worth, TruffleRuby on Truffle/GraalVM (reportedly derived from JRuby) is supposed to be incredibly fast.
Plenty of languages (commercially) target the CLR, however given its Windows focus, many UNIX FOSS based researchers never cared about it, even in the presence of mono.
I'm well aware :) just wanted to clarify since this comes up a lot.
I spent most of last year maintaining a Web Forms app. It's no fun. Ironically, there used to be many more CLR languages, because Microsoft paid for their development. IronPython and IronRuby stand out. I wish ClojureCLR weren't dead too.
As I wrote below, I misjudged the project because of the low activity in its issues. Clearly the projects are not managed through GitHub, which is what I am used to. I made a mistake.
No, it was miserable as f and no way comparable. Getting WAS to run locally could take a day or two of configuring. And since everything was manually done and had to be tweaked when loading in new stuff. And if you broke something (or it broke by itself) it was easier to just wipe it and reinstall everything from scratch, again wasting a few days of work.
And if you tried running your own EAR files, it could take an hour from a code change to actually test it. Building it, installing it, reloading the server, and then getting to the correct state of testing. If you discovered a bug, you had to patch the code, build the file again and start over, wasting another hour. Some of it was evaded by using JRebel, but if the changes couldn't be swapped you were SOL.
No way WAS+EAR can be compared to running stand-alone images. It was a clusterfuck of dependencies and dependent configuration.
Absolutely. It was hellish. Very few people understood how intricate this was, how bad the logging/messages were when you got it wrong, and paid little or no mind to being able to be portable between application server implementations from the word go.
Just to be clear, I was talking about J2EE deployments of the time in general, not WebSphere in particular. I was mainly stuck on JBOSS 2.x/3.x and I was keen on using Resin instead.
Without regard to the merit of each tech, I've made the J2EE to K8S comparison before and am glad to see here I am not the only one who saw the resemblance.
It mostly goes to show that containerizing application code for execution in a managed environment in nothing new. I'm sure this was also done somehow in the mainframe world.
As to whether K8S is a superior embodiment of the concept, I'd say that the problem is rather that a large majority of adopters are just cargo-culting without having a real need for what it actually provides, externalizing the costs of complexity it brings. I have nothing against K8S itself, but its adoption curve is telling of CV-driven architecture at it's worst. Mind you, the same might have been said of J2EE back in the day.
If you follow NEWP manual from Unisys (nowadays still selling Burroughs as ClearPath), you will see UNSAFE code blocks and how its use tainted binaries, which requires admin permission for execution.
> It mostly goes to show that containerizing application code for execution in a managed environment in nothing new. I'm sure this was also done somehow in the mainframe world.
My experience with running images on k8s is way worse than what you describe. It is a clusterfuck of dependencies and configuration when in reality people just want to run java -jar.
Personally I disagree, but even if that was true, why add more unnecessary complexity to the mix? Deploying a jar vs deploying jar packaged as a docker image brings little benefits at a non negligible cost.
I did not have any problems getting WAS to run locallly and I was very Java newbie at that time. I guess I was just lucky. It was literally the first thing I did on my first Java work: I installed WAS and started writing some servlets.
For just getting something simple/singular up and running it was passable.
The problem was when it was used for multiple services (as his comparison with EAR and docker implies). Lets say you had a service for something packaged as EAR. You would then have to log in to the dashboard, add the package and configure it manually. If something changed with the package, you would probably have to reinstall it in WAS, you couldn't just pull the newest from git in your repo and be done. And if that needed any config changes, everyone on the team had to do the same locally and manually in the control panel. When you got multiple moving parts, you would spend more time bringing them in and configuring everything correctly than actually developing whatever you were supposed to.
But what I wasted most time on was certificates. Everything had to be signed and stuff, mostly self signed by randoms and more theater than security. Sooo many times stopped working because the certificate for some module expired, or the CAS was unknown and had to be manually loaded into everyone's local install etc.
Regarding performance: "Note that current raw performance of Java on Truffle isn’t representative of what it will be capable of in the near future. The peak performance is several times lower than running the same code in the usual JIT mode. The warmup also hasn’t been optimized yet. We focused in this initial release entirely on the functionality, compatibility, and making Java on Truffle open source available for a broader community. ... Expect performance, both warmup and peak performance to increase rapidly in each of our upcoming 21.x releases."
Who cares what it's written in? While I find lots of XML configs often to be verbose, translating it to JSON would be exactly the same mess. It's often what has to be configured that's the problem, and not how or the syntax of it.
If anything, XML with schema works out of the box in most IDEs with autocomplete, validation etc.,
The problem with XML is mostly syntactical: it's not always clear if something should be a node or an attribute, and it doesn't have actual lists, maps, or scalar types.
JSON has more structural issues: it can be too terse, so if you're not careful with naming fields, it can be really hard to tell what type of object something is, and for polymorphic lists, you're out of luck.
And I'm impressed that JSON still does not have an official, standards-body-sanctionned Schema specification. Nor does it have a thousand other little things that make XML still so solid when coding for the future.
I'm not super familiar with the ecosystem, but does the GraalVM compiler provide a way to "tree shake" dependencies?
This past year I wrote a rather simple desktop app (JavaFX) for work using Clojure. But Java by default uses RTTI - and Clojure by extension does as well - the dependency tree would balloon my final executable. For instance, I'd bring in some CV library like BoofCV to do some very basic image manipulation, but all of BoofCV and its dependencies would get dragged in. Hundreds of megabytes of junk.. So you either have to just accept you have a gargantuan executable or you have to use some smaller subpar libraries to do what you want. But it seems unfortunate the ecosystem pushes you to use less/smaller dependencies instead of using robust large ones.
I understand the reason behind it. The java compiler has no way to ensure which classes will be used and which won't be b/c crazy things can happen at run time. Maybe with all the work on GraalVM people will move their libraries to not use RTTI as much? I haven't had a chance to hook up Graal yet (I think it doesn't play nice with JavaFX.. or maybe that's old news) - but it's unclear if it'll slim down the final binary. If it does - then this potentially a game changer for "deliverable" executables :)
PS: You can manually go in and disable sub-dependencies.. but it's ugly and incomplete. I got Clojure/JFX/Java to compile down to something like 60MB - but my app is simple and it really should be more like 2MB.
> I'm not super familiar with the ecosystem, but does the GraalVM compiler provide a way to "tree shake" dependencies?
Yes it does whole-world analysis and only compiles in classes, methods, and fields, which are actually used.
The executables do have a minimum size, because the GC code for example doesn't get any smaller, but I think 2 MB is around the area of what can be achieved, yes.
Is there more terminology that means "to tree-shake"?
I understand javascript does tree-shaking, mainly in the context of code-minifiers, and certain languages do "path optimisation" usually at runtime - but I'm not sure how to describe the removal, and modification[0] of code (say, interpreted code) outside JS.
I'd like to "tree-shake" python in order to see what % of code in it's deps is actually used.
[0] e.g removing static parameters, replacing fns with lots of cases into multiple fns etc.
Ah okay. To me "tree shaking" was implicitly talking about the dependency tree and removing unused library dependencies. While "dead code elimination" would be a "deep" clean done by a linker when making a static binary (mostly C/C++ land..). There you're looking at a finer granularity than libraries/compilation-units. That's necessarily a bit trickier and I wasn't even thinking that far. But it seems the GraalVM compiler work on this level.
That page describes "dynamic" elimination, but let's say I call sqrt(x) in my module, but for a fixed value of x - in that case I can just replace the whole fn with a fixed value, but it would require me to detect that the fn is deterministic. Would that still count?
This is cool for former Smalltalkers: "Advanced class redefinition" (there was previous attempt at http://dcevm.github.io/ to bring this to HotSpot, but Sun/Oracle decided not to increase HotSpot complexity - see https://openjdk.java.net/jeps/159). So it seems JVM is one step closer to the Smalltalk VM...
This kind of stuff used to work in Objective-C too, but it was removed step by step for performance reasons. If you allow it, for every call you do to such an object you have to first check if the method exits on it or somewhere up the inheritance chain. You can cache of course, but adding or removing a method to an object invalidates the cache for the object itself and everything that inherits from it's class.
In a modern JIT with dynamic decompilation you can do these things in place, because the compiler essentially has global knowledge. The only real issue is to define the semantics (and then implement it of course). Objective-C is AOT compiled so the runtime checks are needed all the time.
I'm not sure why you think it's been removed? The entire runtime is still there…the cache you're talking about still exists and is hit for every method call.
First thing, I think Graal/Truffle is really cool tech. Second thing... what's the story when it comes to Truffle licensing? :-)
Would Oracle control the implementation of a particular language that used Truffle? Could they decide to "deplatform" that language? ("we don't authorize the use of Truffle in language implementation X for Y reasons") Or charge for licenses for users of that language? Or other somber scenarios... according to current licensing or in a hypothetical future ...
Compare with, say, LLVM infrastructure, were it seems more certain that a language can be implemented as free software and with less restrictions or caveats.
This seems like FUD. Truffle is licensed under the permissive UPL[0]. Even if they decided to make newer versions of it closed-source the opensource versions would still be available, and their licenses would continue to hold.
This happened with solaris: oracle decided to make new ‘official’ development closed, but the last opensource version continued to be used and developed by the community.
"FUD" is a concerted effort to outsell a competitor or something like that... I'm just an individual with real questions about implications of the licenses involved. I bet others have similar questions.
Graal licensing seems pretty complicated to me, and if I get it right Truffle only makes sense when used together with Graal.
From what I could find in the FAQ [1]:
* "GraalVM Community is free to use for any purpose and comes with no strings attached, but also no guarantees or support."
* "GraalVM Enterprise includes Improved performance and security over GraalVM Community"
In general it seems pretty good, but I think it is a bit painful to have to pay for certain optimizations... again, imagine if projects had to pay to, say, "clang -O3". Also could be painful to get stuck in Graal/Truffle version N if version N+1 switches to different licensing terms.
In general commercial compilers are a bit of a drag to work with... I use Saxon from time to time and sometimes I need to check the matrix to see if a feature is available or not [2]. For instance, until version 10.0, higher order functions (!) was a feature one had to pay for, for whatever reason.
As far as I know, full, profile-guided optimizations are the only paid features. Also, if Graal is instead used in place of Hotspot as a JIT compiler, there is no need for that so you get the “whole package”.
Java wasn’t open-source at the time Google copied it. In fact, the only thing that was prohibited by Sun’s license was mobile usage - they wanted to make money on Java with it.
So Google should get sued to hell for blatantly copying it (and they are really bad at shepharding, just look at the state of android java vs openjdk)
This comment is playing fast and loose with the facts. No part of Oracle's suit against Google relied on the claim that "Java wasn't open-source at the time Google copied it" (for good reason).
> they are really bad at shepharding, just look at the state of android java vs openjdk
This has nothing to do with copyright law―the thing that Google was sued for. There is no legal argument in this remark (which is the problem with about half the comments that appear saying that Google was in the wrong), just an assertion based on an appeal to emotion that Google deserved to be sued, and then working backwards from there to present a half-formed argument.
> No part of Oracle's suit against Google relied on the claim that "Java wasn't open-source at the time Google copied it"
It had a specific license explicitly disallowing mobile use. Everything else is irrelevant - google knowingly broke the license, didn’t they?
This is copyright infringement.
As for whether their copy of Java’s API at the time could constitute fair use and thus not subject to copyright law is up to debate and my personal opinion doesn’t matter on it.
> It had a specific license explicitly disallowing mobile use. Everything else is irrelevant...
The Java Specification explicitly allows people to re-implement the Java Language as long as they follow a few guidelines (which google allegedly did not, hence the lawsuit) -- even if they decide to target a mobile platform.
This is a perplexing response. Oracle's case against Google is about copyright infringement. On that point, you are correct, but that's where your comments part from reality.
Oracle in its case against Google is not arguing that "Java wasn't open-source at the time Google copied it". Oracle in its case against Google is not arguing that there was "a specific license explicitly disallowing mobile use". You on the other hand are arguing these things. That's where the problem lies: you're asserting infringement based on two fact claims that don't even match what Oracle's legal team presented to the courts.
(For that reason, your remark that "Everything else is irrelevant" is just bizarre and ironic—it's your comments here that are irrelevant... _None_ of the things you're saying are what the case is actually about.)
Here are some simple questions: to what extent does your knowledge of Oracle v. Google originate from secondary analysis and commentary about the case vs. direct knowledge (e.g. the briefs and testimony provided by Oracle and those who testified)? Do you have any firsthand experience reviewing the material that was presented in/to the courts? This is the problem with Internet peanut galleries. The answer to the last question can be solid "no", and yet commenters are undeterred from spewing nonsense from their gut that has no basis in reality.
About your last paragraph, I did try to get as close to primary sources as possible, without digging into the actual briefs, and I am no lawyer, so my understanding on these topics have a shaky foundation.
But if you have done so, at least you as a presumably secondhand information source, could you give me a rebuttal on why am I wrong?
Just like your last message[1], the answer is "but why male models?" (in other words, I just answered that[2]; do you want me to repeat it[3] or something?)
Google could have bought Sun, decided not to take the opportunity.
They also made a clusterfuck job copying Java APIs for their Android Java (aka Google's J++) dialect, where Java library authors have to hunt down what works exactly in each Android version.
It would be helpful to include a short description of what this Truffle is, or at least a link to here https://www.graalvm.org/graalvm-as-a-platform/language-imple... to disambiguate vs the probably better known smart contract development framework with the same name.
Note that Oracle were using the name for their language framework for years before the blockchain people also started using it, and also had peer reviewed publications using it... do people not Google potential names before picking one?
Truffle works by taking your interpreter and generating a compiler by partial evaluation [1]. So I believe they have written a JVM bytecode interpreter and Truffle makes the JIT.
I'm super impressed by how the Truffle/GraalVM team has been able to turn this theoretical concept into a system that yields production grade compilers (although this Java on Java is not there yet).
"A very important detail of this implementation is that it’s implemented in Java. Java on Truffle is Java on Java! Self-hosting is the holy grail of Java virtual machine research and development." - now if you chuckled and imagined this as xkcd, I'm with you. Regardless I think this is really not some ultimate geek olympics fantasy, but that truffle and graal will be equally if not more transformative to PL reseaech than LLVM has been.
High-performance JITs via partial evaluation of interpreters is the impressive part.
Self-hosting Java isn't a huge deal. IBM's Jalapeno/JikesRVM has been a JVM implemented almost entirely in Java for decades. It self-compiles by using the highest tier of its JIT on itself and then dumps the native code in memory to disk as an executable. Though, as far as I know, JikesRVM doesn't keep around its own bytecode (or an SSA representation of itself) for later dynamically re-optimizing itself or inlining parts of the JVM in user code hot spots. Hopefully a Truffle/Graal-based production JVM would be able to dynamically re-optimize/inline almost all of the JVM into hot spots in user code.
Java on Truffle is a normal Java application, it can run on a vanilla OpenJDK, doesn't need the bootstrap step.
Currently Graal/Truffle implements the first Futamura projection: you give it an interpreter written in Java,
it automatically generates a compiler (JIT). In this mode we have to keep the interpreter IR graphs (blueprints) around for partial evaluation.
With the first Futamura projection: Partial evaluator + interpreter + user code.
There's active work on implementing the second Futamura projection, where you partial evaluate the partial evaluator with respect to the interpreter,
generating a specialized partial evaluator for that interpreter.
With the second Futamura projection: (Specialized partial evaluator + interpreter) + user code.
This is truly fascinating and beautiful and the fact that it works for Java and not just a toy academic prototype is mind-blowing.
> Java on Truffle is a normal Java application, it can run on a vanilla OpenJDK, doesn't need the bootstrap step.
Okay, but if you're not bootstrapping, then you still need to keep OpenJDK around, and you're still hugely dependent upon big chunks of C++ code in OpenJDK, particularly in the garbage collector, unless they've added a crazy in-memory bootstrapping hook to OpenJDK to switch garbage collectors without shutting down the JVM.
Maybe there are some rapid development advantages to not requiring bootstrapping, but that means huge amounts of complexity around allowing re-definition of classes at runtime, particularly key JVM internals. Changing a tire without stopping the car is going to be very tricky.
Substrate is the key component that enables Ahead-of-Time compiled Native Images [1] on GraalVM. Java on Truffle enables bytecode to be dynamically loaded in a Native Image. Before Java on Truffle, you had to choose either pure compiled or pure dynamic.
Which is completely amazing considering how much dynamic and reflective code there is floating around in the Java ecosystem. I've never been able to compile anything beyond a trivial app with native-image because there is always something dynamic being used somewhere. I'm really looking forward to seeing where espresso goes.
Yes but it's extremely difficult to know them before hand. Trust me I've tried. It's not a trivial thing to do. The only success I've had is with quarkus [0] and thats only if you don't go outside of what the framework provides.
I wonder which use cases Espresso has. Until now, it looks like a very tech-focus project. That's fine, no doubt about that. But I guess there are business use-cases, too. Any ideas?
I agree! Our work on TruffleSqueak [1] and on Polyglot Live Programming [2] has shown that it's possible to build language-agnostic live programming tools with GraalVM. If Espresso implements the required Truffle APIs correctly, our tools should also just work for Java. :)
Very impressive, good news for programming language research.
On the other hand, it seems to me that these efforts and its resources would be better used developing a Webasm JVM implementation. Or at least kick-start the project.
We are missing a major platform in the JVM ecosystem and nobody seems to care.
I assume the GP was referring to wasm running on top of graal, not graal running on top of wasm.
I don't think graal atop wasm would be a particularly interesting use case. Wasm purports to be a portable, secure, performant application runtime. Graal purports to be a portable, secure , performant application runtime. The latter, however, has had many more engineer-hours thrown at its implementation, and is thus both more heavyweight (so it needs all the resources it can get) and more performant (so it makes sense to use it as the backing runtime).
Wasm is build as an efficient target for C/C++ like languages. It's mostly a striped down portable CPU intruction set. Graal/Truffle is intended to be an efficient target for everything. It's a toolbox of crazy magic for building your own JIT.
There are not equivalent.
What if somebody will build a GraalVM-based browser? That would be something. Anyway, W3C recommends WebAssembly but does not impose it. It is not too late in the game because WASM doesn't even have DOM access, yet. And also people are still using browsers that are not WASM-ready. How many people actually compile their libraries to WASM today? Aside to early adopters scattered around Rust and Emscripten.
I don't see which actor in the industry (outside of browser makers) has the human resources to make such an experiment.
Mozilla were the one lobbying for wasm... and chromium has abandoned pnacl because of them. The only hope might be microsoft.
Oracle could do it in theory but I don't expect them to do it anytime soon.
GraalVM can output LLVM, which can go to WASM. In the past it also used to be able to output JavaScript. It should be easy enough to make it output WASM directly.
The GC is written in Java, so if you have the translation to WASM that's covered as well.
JVM has first class objects, exceptions and managed memory. WASM doesn't. This does not make one better than the other, just indicates their intended uses.
It is basically just a portable cpu architecture with everything it entails (manual memory management, etc). While there are plans for a gc, it seems hard to fit into this model (but I’m sure the team can pull it off).
It is basically made so c/cpp and other low level languages could be run inside browsers, and I don’t really see the point of it? Like, it is probably good for a video editor running inside a browser, but it will probably mostly entail all sort of mining, unnecessarily usage of cpu and the like. And it won’t magically improve performance, since at the boundary , calling javascript is really expensive, usually much more than writing the whole thing in js. Unless of course if someone does plenty of numerical computations.
It's dynamically compiled to machine code - it's not 'interpreted' as you are probably thinking of it.
For example there is also a Truffle implementation of C running on the JVM that runs some benchmarks faster than native C (due to runtime optimisations being better than static optimisations.)
Running on HotSpot is an advantage for the development of Java on Truffle itself; the tooling is amazing, debugger, inspectability, you can debug the VM as a normal Java application...
GraalVM can compile an AOT version of Java on Truffle, then no JVM is needed.
> but if (!) you use JVM you are using an interpreter
You're using an interpreter to start with, but then it dynamically compiles machine code to run instead of using the interpreter.
But these terms are very fluid. I'd call HotSpot an interpreter, and a compiler, and both at the same time. It depends how you're looking at it at that moment.
This is wonderful news, but Graal is sadly behind the times there.
Android had AOT compilation of Java bytecode (well, technically Dalvik bytecode) since 2013. It was upgraded to hybrid AOT/JIT mode in 2016. All of it was open-sourced, unlike Graal, where many key optimizations (such as auto-vectorization) remained proprietary.
Unlike GraalVM's AOT mode, Android VM can run existing Java libraries without any code changes — you don't have to painstakingly look for static variables and mark them for late loading, and reflection just works.
You are the one behind the times, Java has had support for AOT compilation since around 2000, just not as free beer.
Most 3rd party commercial JDKs have offered it, specially for embedded deployment scenarios.
Besides Android Java isn't Java, rather a Google dialect with cherry picked packages from (nowadays) OpenJDK, most likely to die frozen in its current state as they embrace Kotlin über alles.
AOT is not by itself anything good/fancy. As others mentioned, java could be AOT compiled since ancient times.
Graal is state of the art/interesting, because it uses a different compilation technique than usual, looking at the program to be compiled incorporated with the interpreter for that compilation - which result in superior results for AOT compilation, and in the case of a replacement of JIT compilers, it looks promising (but not yet surpassing Hotspot).
Android’s java is pretty terrible in comparison, just saying.
If you can read Java code and you are interested in how it is implemented start reading here: https://github.com/oracle/graal/blob/espresso/espresso/src/c...
If you are interested in a deep dive into the Truffle technology and are interested in why it makes sense to implement a language on top ofTruffle checkout my recent Rebase talk for a really long answer: https://youtu.be/O4icaN9khp4
If you don't have enough time for an 1h talk checkout my summary tweet: https://twitter.com/grashalm_/status/1212763944043139072