[HN Gopher] We made a fork of the Rust Playground
___________________________________________________________________
We made a fork of the Rust Playground
Author : emccue
Score : 81 points
Date : 2023-10-09 12:44 UTC (10 hours ago)
(HTM) web link (java-playground.com)
(TXT) w3m dump (java-playground.com)
| [deleted]
| avgcorrection wrote:
| I'm guessing this is the fork https://github.com/bowbahdoe/java-
| playground
| emccue wrote:
| 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.)
| pjmlp wrote:
| 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.
| emccue wrote:
| Set a timer for a few days for me to clean up the documentation
| and whatnot then I am down.
| johntortugo wrote:
| Thanks for working on this. I'd love to see those new
| features and if I can I'd like to help.
| 0JzW wrote:
| github link here: https://github.com/McCue-Software-
| Solutions/java-playground
| junon wrote:
| Wow I've been out of the Java game too long it seems. This barely
| looks like Java.
| devnull3 wrote:
| yeah. The snapshot of Java in my head still needs main() to be
| defined in a class.
| signal11 wrote:
| 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.
| goranmoomin wrote:
| 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
| [deleted]
| wdroz wrote:
| 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 }
|
| 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.
| subarctic wrote:
| wait, is it actually called a JEP (like the Java version of a
| Python PEP)?
| emccue wrote:
| YEP
| [deleted]
| shepmaster wrote:
| Primary maintainer of the Rust Playground here. I'm glad to see
| open source doing the open source thing!
|
| 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.
| silenced_trope wrote:
| 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?
| pitaj wrote:
| 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.
| shepmaster wrote:
| 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
| emccue wrote:
| 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.
| shepmaster wrote:
| > 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.
| Macha wrote:
| > 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.
| apignotti wrote:
| [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.
| emccue wrote:
| That is still Java 8, right?
|
| (I do really like CheerpJ if only because it enables software
| preservation.)
| apignotti wrote:
| 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.
| dj_gitmo wrote:
| My corpo firewall is blocking because of what seems to be a TLS
| issue.
| emccue wrote:
| Oof. Hopefully its just because the cert was issued recently?
| loeg wrote:
| Issued by Let's Encrypt on Saturday.
| 38 wrote:
| 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.
| emccue wrote:
| 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.
| 38 wrote:
| so the example is misleading regarding the current non-
| preview release, got it.
| gbear605 wrote:
| Yeah, though it'll probably be non-preview in six months,
| so if that's what's holding you back you don't have long to
| wait.
| neonsunset wrote:
| C# allowed to write main-less applications for quite some time:
| https://dotnetfiddle.net/oGnV4m
| 38 wrote:
| I wouldn't say two years is "quite some time", but yeah
| that's cool
___________________________________________________________________
(page generated 2023-10-09 23:02 UTC)