@Pavel Right, I forgot about that. Do you know how compatible Java 8 and 9 are? Would I have to offer both Java 8 and Java 9 or could I just replace it?
@Dennis A program written for Java 8 will perform identically under Java 9 (unless it requires the use of the Java 8 default garbage collector, which is highly unlikely).
Unlike Python 2/3, Java 8/9 adds new features without changing any existing behaviour, except for switching to a more efficient garbage collector. Theoretically, someone's code might rely on the old garbage collector, and it will perform differently, but that's incredibly unlikely and probably wouldn't work under TIO anyway.
@Dennis tl;dr, feel free to replace Java 8, nothing should break.
When I save and go to copy one of the preset outputs to my clipboard it's a little jarring to have to go all the way to the right of the screen. I don't think that the textarea needs to be as wide as it is. "Less is more" may apply to the screen real-estate used on that pane. (just my opinion)
Hey @Dennis a new language got added to the big polyglot that's not in Tio yet. Has anyone talked to you about added it? This is the source code link in the post: esolangs.org/wiki/User:Marinus/Minimal-2D_interpreter
Java 8 : 2.144 s
Java 8 w/Apache Commons: 2.432 s
Java 9 : 3.364 s
Java 9 w/Apache Commons: 4.166 s
The extra CLASSPATH for Apache Commons doesn't seem to be a huge issue for Java 8, but it makes Java 9 even slower, and it's already a lot slower than Java 8.
I can try compiling 9 from source instead of using the packaged version from copr, but if that doesn't make a difference, I think we should wait until 9 gets a little more polished.
That's a fair point. I wish I knew if some existing permalinks are using Apache Commons though. Removing it at this point from the wrapper would break those links...
I grep'd for X11 to find a way to disable it. This is what I found.
# Check if X11 is needed
if test "x$OPENJDK_TARGET_OS" = xwindows || test "x$OPENJDK_TARGET_OS" = xmacosx; then
# No X11 support on windows or macosx
NEEDS_LIB_X11=false
else
# All other instances need X11, even if building headless only, libawt still
# needs X11 headers.
NEEDS_LIB_X11=true
fi
OK, bash configure finally ran without errors. Wish me luck.
Building target 'default (exploded-image)' in configuration 'linux-x86_64-normal-server-release'
gmake[2]: *** No rule to make target 'java.base-libs', needed by 'exploded-image-optimize'. Stop.
ERROR: Build failed for target 'default (exploded-image)' in configuration 'linux-x86_64-normal-server-release' (exit code 2)
No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: If caused by a warning, try configure --disable-warnings-as-errors.
/opt/jdk9/make/Init.gmk:286: recipe for target 'main' failed
So hg clone doesn't actually download the source code, only a Bash script that can be used to download it. Why configure would check for a gazillion dependencies but not the actual source needed for compilation is beyond me.
arena:jdk9# make
Building target 'default (exploded-image)' in configuration 'linux-x86_64-normal-server-release'
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Compiling 17 properties into resource bundles for jdk.compiler
Parsing 1 properties into enum-like class for jdk.compiler
Compiling 19 properties into resource bundles for jdk.javadoc
Compiling 10 properties into resource bundles for jdk.jdeps
Compiling 7 properties into resource bundles for jdk.jshell
Compiling 115 files for BUILD_INTERIM_java.compiler
I'll just use the version from copr (the least of three evils) and add Java 9 instead of replacing Java 8. When it gets a bit more polished, I'll replace it and set up some redirects.
There are ways to remove internet access completely from the arena server and tunnel all outside traffic though the main server, but that's not implemented yet and far from a priority as long as there is only one arena.
@Pavel I'm sorry, but JShell will have to wait until then.
java.version is a standard property which exists in every VM.
There is just a tiny trick which might make your life easier: Search for the second dot and cut the string there. Then convert it to double. Now, you can check the version much more comfortably:
if (version >= 1.5) ...
You can put ...
Alright, this is my best guess regarding what happened.
I modified the wrapper script while mbomb007 was running their submission, which caused it to glitch. I fail to see how java.version could have printed /srv/wrappers/java-openjdk9 in the first place. It shouldn't even be aware of the name of the script that calls the compiler.
It'd be nice if hovering the mouse over a language (in the selection list) in v2 would display the full language name. I can't see the difference between some items in the list that have long names.
For example, I see three entries of Assembly (x..
That, or give the list flexible columns like Nexus has
java.version is a standard property which exists in every VM.
There is just a tiny trick which might make your life easier: Search for the second dot and cut the string there. Then convert it to double. Now, you can check the version much more comfortably:
if (version >= 1.5) ...
You can put ...
talk.tryitonline.net
talk.tryitonline.net