I'll try to answer any questions from the Rust point of view, and it will be good to hear of any large differences between the two implementations.
- Its not using the whole orchestrator...thing. That was some complex code and we made a Practical Choice.
- No equivalents for a lot of the rust tools. Choices aren't as straightforward as for the cargo/rust world. I do intend to at least add JUnit testing as an option though.
- Its not building things from source, which means I need to manually update download urls every now and then.
- Might not be running on a big enough machine. Lets see if HN hugs it to death.
For further context, the "orchestrator" is a reimplementation of some of the backend.
The original version of the playground basically took the user input, dumped it into a file, then mounted that file into a Docker container and waited for it to be complete — a traditional batch process. This works great, but doesn't allow fun things like streaming input / output from the process, or having temporary files that persist over a short time period.
The new code has a shim program that lives inside the container and we can communicate with it via messages passed on stdin/stdout. Things are a lot more asynchronous and a bit more complicated.
I think it's a reasonable thing to avoid for now, but note that my plan is to eventually remove the current synchronous code eventually.
> I need to manually update download urls every now and then
I do much the same, roughly every 6 weeks or so.
> a big enough machine
The primary instance is a single c5a.large in EC2. I also run my own instance on a single t2.micro.
It looks like this playground requires a server connection instead of being purely front-end, which makes sense being Java.
But I'm familiar with SWC's playground (https://swc.rs/playground) and I believe it uses WASM and therefore doesn't require a back-end component.
Is it possible to do something similar with the Rust playground and Java playground?
Now, because no one has put in all the work to make it happen, I don't know if this would be a real problem or not, but I haven't yet heard a comprehensive counter argument.
Some related ideas:
- Client-side interactive terminal for WASM https://github.com/rust-lang/rust-playground/issues/374
- Compile Rust Language Server into WASM https://github.com/rust-lang/rust-playground/issues/357
java --enable-preview Main.java
Things generally exit preview after ~2 releases.
If we are already by feature requests,
- JVM bytecode view
- JIT machine code view
- Select between OpenJDK, OpenJ9, Azul, GraalVM,...
- Enable code generation specific features per selected JVM implementation
Anyway only brainstorming some ideas, it is already quite nice as it is.
We have just renewed our fully-client side take on the "Java playground" concept, powered by CheerpJ
https://javafiddle.leaningtech.com/
AWT and Swing apps work as well, which I believe to be quite unique.
(I do really like CheerpJ if only because it enables software preservation.)
3.0 will still be focused on Java 8, with a fully new JIT architecture that does not require any AOT compilation steps or preprocessing.
With 3.1+ will begin catching up with modern Java.
Finalized features:
- JEP 395: Records, finalized in Java 16: https://openjdk.org/jeps/395
- JEP 409: Sealed Classes, finalized in Java 17: https://openjdk.org/jeps/409
- JEP 441: Pattern Matching for switch, finalized in Java 21: https://openjdk.org/jeps/441
Preview Language Features:
- JEP 430: String Templates, preview language feature since Java 21: https://openjdk.org/jeps/430
- JEP 445: Unnamed Classes and Instance Main Methods, preview language feature since Java 21: https://openjdk.org/jeps/445
// As of Java 21
Integer i = ...
switch (i) {
case -1, 1 -> ... // Special cases
case Integer j when j > 0 -> ... // Positive integer cases
case Integer j -> ... // All the remaining integers
}
What is the thing you want me to do?
This was done as a senior project @ University of Central Florida. Using the github org made things simpler for the students to work on it. (Everyone has to learn git at some point.)