We made a fork of the Rust Playground(java-playground.com)
java-playground.com
We made a fork of the Rust Playground
https://java-playground.com/?runtime=latest&release=21&preview=enabled&gist=27cf9e5152d902d19e3be500c072f66c
40 comments
The biggest differences that I can think of right now are
- 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.
- 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.
> Its not using the whole orchestrator...thing
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.
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.
Noob-ish here:
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?
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?
I think that yes, it's technically possible with a good amount of work at all layers of the stack. The bigger worry I'd have is purely about time. The Docker images for the Rust playground clock in close to 2 GiB, and there's 3-6 of those. No one is going to wait to download that to run a small program.
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
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
For Rust, the issue is that LLVM is very difficult to compile for wasm, but cranelift can't generate wasm. I'm not sure if codegen-gcc can help here.
Off-topic, but I'd like to thank you for your numerous amazing stackoverflow answers about Rust.
Wow I've been out of the Java game too long it seems. This barely looks like Java.
yeah. The snapshot of Java in my head still needs main() to be defined in a class.
Looks quite nice.
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.
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.
Set a timer for a few days for me to clean up the documentation and whatnot then I am down.
Thanks for working on this. I'd love to see those new features and if I can I'd like to help.
[Shameless plug]
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.
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.
That is still Java 8, right?
(I do really like CheerpJ if only because it enables software preservation.)
(I do really like CheerpJ if only because it enables software preservation.)
Correct, but the new CheerpJ 3 archicture will let us move quite quickly to modern Java versions.
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.
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.
A big mistake about all these Playgrounds is that it forces the "Source Code Pro" monospace font (or any specific font) rather than respecting user's monospace font choice in the browser. Programmers tend to be picky about the font choice, which you can easily judging by just how many these fonts are out there competing. There is really no aesthetic reason to do such a forcing, and even you do have political or financial reason to do so, it's extremely easy to block remote font anyway. So stop doing it please, or at least provide a checkbox to disable it.
Sorry, this is a field I have not thought about maybe ever.
What is the thing you want me to do?
What is the thing you want me to do?
github link here: https://github.com/McCue-Software-Solutions/java-playground
huh, Java can just do "void main" now? or is the playground omitting some boilerplate? that was one of my main reason for never touching Java/C#, too much ceremony just to write a basic program.
C# allowed to write main-less applications for quite some time: https://dotnetfiddle.net/oGnV4m
I wouldn't say two years is "quite some time", but yeah that's cool
It is a preview feature right now, so the playground is adding --enable-preview. (there is a toggle for that.)
java --enable-preview Main.java
Things generally exit preview after ~2 releases.
java --enable-preview Main.java
Things generally exit preview after ~2 releases.
I'm guessing this is the fork https://github.com/bowbahdoe/java-playground
Actually the one on McCue-Software-Solutions is the right one. I might move it there soon-ish though.
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.)
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.)
[deleted]
So for people (like me) who were surprised by how modern the Java code looked like… here are the following features/JEPs involved in the Java code:
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
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
I'm happy that JEP 441 was added to Java.
// 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
}
[deleted]
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.