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.
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.
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.
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.)
Some of these are preview features (main outside a class, string interpolation) and need a command line switch to enable, and can change. But they should be in Java by the next LTS release.
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.
// 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
}
I should stop to talk badly of Java based on my old memories of Java 6... Maybe they should do like C++ and call it 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.
40 comments
[ 3.1 ms ] story [ 56.2 ms ] threadI'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.
Wow, I would have assumed it would have required more than that.
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
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.)
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.
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.
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
What is the thing you want me to do?