Re: Ancienne Version Java 32 Bits
Mazie Wingeier
I cannot find an issue for updating Java, so I created one: Update Java version Issue #77 imagej/imagej-updater GitHub Read this about why I think Java currently does not get updated. And if someone knows more, please comment
The best for you would be to download a fresh fiji (and use it as it is ) or if you want to keep your original fiji, copy the folder Fiji.app\java\win64\jdk1.8.0_211 (or whatever version) from the fresh fiji and replace the jdk folder in your previous fiji with this new one.
Hi @ctrueden, I was also surprised to find that the latest Fiji was not bundled with a more recent Java. I was not expecting that this could be the cause of the https error, so I had tried many other things before reaching this solution. Indeed I think it would be great if a more recent Java version would come bundled with Fiji.
I followed the instructions provided in this link to run Fiji natively on my ARM-based Mac. I have successfully installed the latest Fiji and Temurin JRE 11.0.19 for macOS aarch64. However, when I attempted to perform an update, I encountered the following error in the console:
[WARNING] Your Java might be too old to handle updates via HTTPS. This is a security risk. Depending on your setup please download a recent version of this software or update your local Java installation.
Also, will the new version have any automatic restart functionally. I've had to manually restart MR ever morning for the last few... years... as for some reason or another the Task Scheduler wouldn't reliably start the server script after shutting the server down. Which is odd because I use TS at work for running scripts and that always works. *shrugs*
Having a proper restart functionality is a bit problematic: You can't properly restart an application from within the application. In case of Java (the new version still needs a JVM for the plugin API), this introduces a few additional issues, since the JVM is very restrictive in this regard (once a VM, which was originally started from a certain process, is terminated, it's impossible to create a new one in the same process).
It's always safer to have an external program or script which performs the restart. However, there are a few dirty and unsupported workarounds though to still restart an application. We did some experiments with that in the past (with the Java version), but it wasn't possible to reliably restart an application (resulting in undefined behaviour - sometimes it worked, sometimes it resulted in messed up "invisible" processes, depending on the OS). This may be different in the new version, we have to run a few tests before I can give any information about that.
Windows offers a specific API to handle restarts, but that seems to be mainly intended to perform restarts after driver updates (or at least to release shared resources). I haven't looked into this API yet, but this would be obviously a very platform-specific solution (and even on Windows, this wouldn't be available on all versions).
Maybe we could alternatively implement a "soft restart", without actually performing a fresh restart of the application (not an actual restart, instead this would be more like a "reset"). I'm not sure if this is sufficient - especially if something goes wrong, there may still be unreleased resources
The 'master' Java application launched new 'slave' JVMs for the server using a ProcessBuilder, the StreamGobbler then effectively Tee's off the Output Stream and pushed the results to the GUI's ServerMonitor.
But this isn't necessarily a major issue. Basically the main game faces the same issue (when returning to the main menu, which unloads the plugin API), so we make sure to have proper cleanup routines and we just reuse the old VM when loading another world (or joining another server). We could implement the same for the server itself (basically everything that's necessary for this is already in place [i.e. clean up network connections and release resources]), but I'm not sure if this is sufficient - if something goes wrong, this wouldn't work. Especially if any issues are related to the process (locks or issues with any connections), this wouldn't help at all (because it's still the same process).
Starting a separate process from within the application doesn't work either - at least it's not reliable. Basically the process API always run new processes as child processes, and terminating the main process also terminates childs. It is possible to run a detached process (which is still alive after killing the original process), but this sometimes results in strange situations (like invisible processes, and sometimes they can't even be killed), especially after doing this multiple times. But as mentioned, we have to tinker with that a bit - it was quite problematic in Java, but it might work better in C++.
Having a separate "launcher" which runs the game/server as child process is basically the proper way to do something like that (this is what our standalone is doing, but your RCON tool seems to be doing that as well?). In this case the "launcher" can always stop and restart the actual program at any time. But for our dedicated server, we don't have plans to introduce a separate launcher (since a launcher also introduces a few other issues - and it would also bloat the server).
That wouldn't help if it's still the same process. And in this case we need to find a way to communicate with the other JVM (that was started by the JVM), since all our native references and pointers wouldn't be valid anymore.
It could be either a bug in the JDK, or this behaviour is simply not supported (which is more likely). In most cases there is almost never a situation you actually have to recreate a VM after destroying it
This would add a massive degree of complexity The API already got a lot complexer in the new version due to the communication between Java and the native side (via JNI). Right now the native part alone is more than 10k lines of code (without taking any Java code like the actual API into account), and some API stuff is still missing
Passing data from Java to C#/C++ is quite easy, but receiving this data on the native side or passing data from native to Java (or vice versa) involves a lot of boilerplate code (especially if we're not only dealing with primitive datatypes, which is often the case in our API). If there was another bridge now this would make the API extremely bloated.
This would add a massive degree of complexity The API already got a lot complexer in the new version due to the communication between Java and the native side (via JNI). Right now the native part alone is more than 10k lines of code
Without any ale in my system, thinking more clearly about it, yes that would mean writing code - for - every - single - getter - setter - constructor- and his aunt. And then every time one was added or changed. I do like creating work but this now sounds ridiculous!
Yeah that's true, that would be way too much additional work and redundant code (which, in return, would be fairly error prone) Nevertheless, maybe we still find a way to offer a proper restart functionality. Maybe it's even sufficient to have something like that just for Windows: On Linux, it's fairly easy to set up a crontab via script, but on Windows, the TS seems to be a bit more problematic
a little late but i use restart on crash to reboot the server. as long as you can schedule it to close it should work well. i used it for 2 java rw servers and the unity server. only for the unity server in case of a crash/hang it will load it back up.
When typing the command into ingame console, you can also add a parameter which describes when the restart will be issued exactly (in seconds). I.e. restart 120 will issue a restart in 120 seconds (2 minutes). This automatically sends multiple messages to all players about the impending restart, and saves the world again before actually performing the restart.
You can also set up an automatic restart via scheduler. Just create a "scheduler.txt" file in the server folder (requires server restart) and add this line, for example: @+12h /restart -> this will restart the server 12 hours after the original start.
Is it possible to have both game versions installed on the same machine? I'm playing mostly single player and although I really want to explore the new features every time the unity version is getting updated I want to avoid uninstalling and reinstalling every time I switch between the two, if at all possible.
After years away started using Variax again. Had to download Work Bench old version not the HD. I've hit the JAVA wall. It will not install. Java Envoiromental blah blah. I have uninstalled Java and Workbench and reinstalled and still no joy. Which Java do I need as 1.75 Workbench will load load with the recommended Java Runtime Environment 1.6. Any help please?
I use an older Variax 300, an HD500, and both my computers (a desktop and a laptop) are Windows 10. I have no problems with Monkey, Workbench, and HD Edit. Everything does what it is suppose to, with the lowest level of Variax ever created.
I used to use the JAVA libraries for development, but haven't touched them in years. I don't know if those are what are making my Workbench/Variax run fine or not, but I'm not removing them just in case they are - LOL!
I attempted to install the Variax Workbench v1.75 on a clean Windows 10 64-bit OS computer. The Line 6 installer encountered a problem downloading the Java Runtime Environment (JRE). The problem is the Line 6 installer tries to download the 1.6.0 Java Runtime Environment Installer (32-bit) [Java version 6] from a URL location that no longer exists (the location is hard-coded in the installer). Since that location no longer exists, the Java download fails.
d3342ee215