99

How can I restart a Java AWT application? I have a button to which I have attached an event handler. What code should I use to restart the application?

I want to do the same thing that Application.Restart() do in a C# application.

Jonas
  • 97,987
  • 90
  • 271
  • 355
Azfar Niaz
  • 1,396
  • 3
  • 12
  • 18
  • 2
    Maybe I don't understand your question. You want your application to have a button that restarts the application? So, after the app is no longer running, it should be able to restart itself? That sounds impossible to me. – Jay Nov 11 '10 at 22:23
  • I m not asking that after JVM stops, i m asking that how can i respawn my main java frame? – Azfar Niaz Nov 11 '10 at 22:30
  • 2
    Not impossible. I see the eclipse workbench frequently restart, even windows does this trick after updates. The false assumption is that the application is the only thing running with nothing underneath it. We will need a restart capable launcher, turtles all the way down. – whatnick Nov 11 '10 at 22:33
  • just the same way as in C# application, where u can write System.restart() to do so ? – Azfar Niaz Nov 11 '10 at 22:35
  • @aniaz then you should update the question to point out you want to show/hide the frame. The application is NOT the Frame. – whatnick Nov 11 '10 at 22:36
  • If you properly used OSGI you might not need to restart. – djangofan Aug 15 '13 at 20:48

13 Answers13

110

Of course it is possible to restart a Java application.

The following method shows a way to restart a Java application:

public void restartApplication()
{
  final String javaBin = System.getProperty("java.home") + File.separator + "bin" + File.separator + "java";
  final File currentJar = new File(MyClassInTheJar.class.getProtectionDomain().getCodeSource().getLocation().toURI());

  /* is it a jar file? */
  if(!currentJar.getName().endsWith(".jar"))
    return;

  /* Build command: java -jar application.jar */
  final ArrayList<String> command = new ArrayList<String>();
  command.add(javaBin);
  command.add("-jar");
  command.add(currentJar.getPath());

  final ProcessBuilder builder = new ProcessBuilder(command);
  builder.start();
  System.exit(0);
}

Basically it does the following:

  1. Find the java executable (I used the java binary here, but that depends on your requirements)
  2. Find the application (a jar in my case, using the MyClassInTheJar class to find the jar location itself)
  3. Build a command to restart the jar (using the java binary in this case)
  4. Execute it! (and thus terminating the current application and starting it again)
Veger
  • 34,172
  • 10
  • 101
  • 111
  • in what package is UpdateReportElements? strangely, i can't find this via Google. – ericsoco Jun 12 '13 at 00:53
  • ah, never mind, that's @Veger's class. substitute for your own main class, i suppose? – ericsoco Jun 12 '13 at 00:54
  • @ericsoco Yes can be any class, it is used to find the location of the jar file. Which is used to restart the application. I will update the answer to make it more clear! – Veger Jun 12 '13 at 08:19
  • @Veger great stuff but how do I reset my variables to initial state? – Kamran Jul 04 '13 at 06:20
  • 6
    Isn't there a small time frame in which two versions of the same app are running at the same time? – Monir Oct 31 '14 at 16:27
  • Would this work is remote debugger is enabled? (server socket open by the JVM itself) – aalku Feb 20 '15 at 08:10
  • 5
    Will System.exit(0) not terminate the child process? – Horcrux7 Apr 21 '15 at 10:42
  • If you have a question please do not ask it in a comment, but open a new question, so you can be helped properly. – Veger Apr 21 '15 at 11:58
  • 6
    @Veger All the questions are **very** relevant to the answer. – Tomáš Zato - Reinstate Monica May 01 '15 at 01:30
  • 1
    @TomášZato SO does not work in this way, it is not a forum. For example the question whether `System.exit(0)` terminates the child process or not, has nothing to do with 'how to restart a Java application'. Hence it should be asked in a new question (although I suppose that it is already asked on SO). Same goes for (most) other questions in these comments. – Veger May 01 '15 at 14:51
  • 18
    @Veger Question whether `System.exit(0)` terminates the child process has the same answer as whether this answer really works and why. If you can't provide sensible explanation along with your answer, you did a bad job. Answer that provides more questions than it answers isn't an example of a thorough answer. Good answers do not just show the code but also explain how and why they work, that the drawbacks are and what are the alternatives. You didn't even try to cover these things. – Tomáš Zato - Reinstate Monica May 01 '15 at 15:09
  • @TomášZato I could give answers to these questions, but 1) They ask different things than the original question, so they deserve their own question and specific answers 2) The question (and answer) is 5 years old, starting a new question (again) makes more sense (to prevent the mess we just created). 3) The answer is accepted, so it works for the OP (and for lots of others as well, looking at the upvotes). Furthermore, the [answer by @Meinersbur](http://stackoverflow.com/a/4160543/246263) shows a working example which is the same/similar to the used technique of my answer. (to be continued) – Veger May 01 '15 at 20:53
  • (continuation) 4) It is ['official' policy](http://meta.stackexchange.com/q/19457/141775) to start a new question for follow-up questions. 5) The `System.exit(0)` question is already [answered](http://stackoverflow.com/a/269511/246263) on SO, but people tend to be asking before looking/trying (again see the [answer by @Meinersbur](http://stackoverflow.com/a/4160543/246263)). NB that this response took about 20 minutes, so me being lazy or unwillingly to spend time on this/SO has nothing to do with it. – Veger May 01 '15 at 20:53
  • 8
    So many comments debating whether to answer @Horcrux7's question or not. You guys could've just told him the answer from the beginning lol. Well I'll go ahead and do it (kinda late I know): no it doesn't. There. – Voldemort Jul 19 '15 at 09:38
  • 10
    To answer my questions self. The sample does not work !!! The System.exit(0) terminate the client process immediate. – Horcrux7 Jul 20 '15 at 09:14
  • I'm changing first sentence of the answer `Of course it is NOT possible to restart a Java application.` This is only a `workaround for limited scenarios`. Where are classpath variables jvm arguments and other variables. What if other process doesn't start and this ends? What if other instance try to use same resource `File/Port` whatever ? This is not the counterpart solution asked in the question. Aplication.Restart() for dotnet doen't exist in java. I would go for another app to handle this. – Davut Gürbüz Mar 04 '19 at 15:51
35
import java.io.File;
import java.io.IOException;
import java.lang.management.ManagementFactory;

public class Main {
    public static void main(String[] args) throws IOException, InterruptedException {
        StringBuilder cmd = new StringBuilder();
        cmd.append(System.getProperty("java.home") + File.separator + "bin" + File.separator + "java ");
        for (String jvmArg : ManagementFactory.getRuntimeMXBean().getInputArguments()) {
            cmd.append(jvmArg + " ");
        }
        cmd.append("-cp ").append(ManagementFactory.getRuntimeMXBean().getClassPath()).append(" ");
        cmd.append(Main.class.getName()).append(" ");
        for (String arg : args) {
            cmd.append(arg).append(" ");
        }
        Runtime.getRuntime().exec(cmd.toString());
        System.exit(0);
    }
}

Dedicated to all those who say it is impossible.

This program collects all information available to reconstruct the original commandline. Then, it launches it and since it is the very same command, your application starts a second time. Then we exit the original program, the child program remains running (even under Linux) and does the very same thing.

WARNING: If you run this, be aware that it never ends creating new processes, similar to a fork bomb.

Meinersbur
  • 7,391
  • 1
  • 25
  • 28
  • 1
    **Possible improvement** `ManagementFactory.getRuntimeMXBean().getInputArguments()` will only give you the input arguments passed to the JVM. It misses parameters passed to your application. e.g., `java -jar start.jar -MISSED_PARAM=true`. On an oracle jvm, you can retrieve those parameters using `System.getProperty("sun.java.command")`. – Chris2M Dec 12 '14 at 10:52
  • 3
    The parent VM could end if the child VM and the parent VM wouldn't be connected to each other with pipes, which is what happens the way the child VM is started. By using `ProcessBuilder` and `inheritIO()`, the child VM can be started in a way that the parent VM would end. – Christian Hujer Mar 11 '15 at 22:57
  • 1
    I got a version of this going. This comment is to tell you how to stop it: rename something in the path that contains the java.exe. – Dale May 16 '16 at 02:46
  • This is strictly speaking not restarting but launching a new JVM with the same arguments as this one. – Thorbjørn Ravn Andersen Jun 18 '17 at 12:39
  • 4
    What's the difference? Is there a difference between restarting a PC and shutting down the OS+booting it up again? – Meinersbur Jun 20 '17 at 00:36
31

Basically, you can't. At least not in a reliable way. However, you shouldn't need to.

The can't part

To restart a Java program, you need to restart the JVM. To restart the JVM you need to

  1. Locate the java launcher that was used. You may try with System.getProperty("java.home") but there's no guarantee that this will actually point to the launcher that was used to launch your application. (The value returned may not point to the JRE used to launch the application or it could have been overridden by -Djava.home.)

  2. You would presumably want to honor the original memory settings etc (-Xmx, -Xms, …) so you need to figure out which settings where used to start the first JVM. You could try using ManagementFactory.getRuntimeMXBean().getInputArguments() but there's no guarantee that this will reflect the settings used. This is even spelled out in the documentation of that method:

    Typically, not all command-line options to the 'java' command are passed to the Java virtual machine. Thus, the returned input arguments may not include all command-line options.

  3. If your program reads input from Standard.in the original stdin will be lost in the restart.

  4. Lots of these tricks and hacks will fail in the presence of a SecurityManager.

The shouldn't need part

I recommend you to design your application so that it is easy to clean every thing up and after that create a new instance of your "main" class.

Many applications are designed to do nothing but create an instance in the main-method:

public class MainClass {
    ...
    public static void main(String[] args) {
        new MainClass().launch();
    }
    ...
}

By using this pattern, it should be easy enough to do something like:

public class MainClass {
    ...
    public static void main(String[] args) {
        boolean restart;
        do {
            restart = new MainClass().launch();
        } while (restart);
    }
    ...
}

and let launch() return true if and only if the application was shut down in a way that it needs to be restarted.

Community
  • 1
  • 1
aioobe
  • 383,660
  • 99
  • 774
  • 796
  • 3
    +1 for better design advice; although, sometimes it's just not possible, especially if using JNI, for example. – maerics Nov 11 '10 at 22:25
  • Well, a native library could modify global state that can't be modified from the JNI interface, so there would be no way to "restart" the state of the program other than by restarting the process. Of course, the native library should be better designed but sometimes you depend on things you can't control. – maerics Nov 11 '10 at 22:50
  • Ok, but with that reasoning, you can just as well have a pure Java-library modifying some internal static variables. This would however be a design flaw and shouldn't occur in well written libraries. – aioobe Nov 11 '10 at 23:05
  • 2
    Your answer is incorrect, since it is perfectly possible even without external applications/daemons as shown by Meinersbur and my own answer. And for self-updating purposes restarting an application is a good solution, so there is actually a need for restarting applications as well. – Veger Nov 16 '10 at 12:55
  • 3
    But you *do* use an external application: `java`! You're forgetting that Java is a language specification, not a program. What if I run your program using some other jvm, such as [kaffe](http://www.kaffe.org/) for instance? Updated my answer anyway :-) – aioobe Nov 16 '10 at 13:01
  • I did this initially as well. The only problem with this method is that if you updated the code, you won't have the new code available on restart since you're only re&launching the previously compiled instance. – Lorenzo Nov 24 '20 at 09:00
  • 2
    @Lorenzo, that's correct. The original question here is basically if the application can _restart itself_. The answer is basically _no_, you need the cooperation from someone else (like the OS, or a wrapper script or something similar) that spawns the new instance. – aioobe Nov 24 '20 at 09:07
  • I'm in no way denying that you had answered the question hehe; just noting that if there's extra logic that needs to be done between restarts won't make this approach plausible. But for a simple restart like the OP asked then I would approve this solution since it's the fastest way to 'restart' (as compared to killing + starting a new jvm) – Lorenzo Nov 24 '20 at 09:10
  • Yep. I agree with you! And many people coming here probably want to update code as you suggest. – aioobe Nov 24 '20 at 10:00
12

Strictly speaking, a Java program cannot restart itself since to do so it must kill the JVM in which it is running and then start it again, but once the JVM is no longer running (killed) then no action can be taken.

You could do some tricks with custom classloaders to load, pack, and start the AWT components again but this will likely cause lots of headaches with regard to the GUI event loop.

Depending on how the application is launched, you could start the JVM in a wrapper script which contains a do/while loop, which continues while the JVM exits with a particular code, then the AWT app would have to call System.exit(RESTART_CODE). For example, in scripting pseudocode:

DO
  # Launch the awt program
  EXIT_CODE = # Get the exit code of the last process
WHILE (EXIT_CODE == RESTART_CODE)

The AWT app should exit the JVM with something other than the RESTART_CODE on "normal" termination which doesn't require restart.

maerics
  • 133,300
  • 39
  • 246
  • 273
  • very interesting solution. Problem on OSX is that, typically, Java apps are run from a compiled `JavaApplicationStub`... Not sure if there's an easy way around that. – Dan Rosenstark Feb 18 '12 at 22:35
  • I did this in windows and it works perfectly well, i have a batch script that initially runs my program by doing `java my-program.java` and the last line of the batch file is ```if "%ERRORLEVEL%" EQU "1" java my-program.java``` so if my program exits with ```System.exit(1)``` it will restart, otherwise ```System.exit(0)``` makes it shutdown. Although i was able to do it using pure java before (adding a shutdown hook + using processbuilder.inheritIO() to stdin/out gets passed to new process); this approach is much easier – Lorenzo Nov 24 '20 at 09:08
7

Eclipse typically restarts after a plugin is installed. They do this using a wrapper eclipse.exe (launcher app) for windows. This application execs the core eclipse runner jar and if the eclipse java application terminates with a relaunch code, eclipse.exe restarts the workbench. You can build a similar bit of native code, shell script or another java code wrapper to achieve the restart.

whatnick
  • 5,100
  • 2
  • 17
  • 35
5

Windows

public void restartApp(){

    // This launches a new instance of application dirctly, 
    // remember to add some sleep to the start of the cmd file to make sure current instance is
    // completely terminated, otherwise 2 instances of the application can overlap causing strange
    // things:)

    new ProcessBuilder("cmd","/c start /min c:/path/to/script/that/launches/my/application.cmd ^& exit").start();
    System.exit(0);
}

/min to start script in minimized window

^& exit to close cmd window after finish

a sample cmd script could be

@echo off
rem add some sleep (e.g. 10 seconds) to allow the preceding application instance to release any open resources (like ports) and exit gracefully, otherwise the new instance could fail to start
sleep 10   
set path=C:\someFolder\application_lib\libs;%path%
java -jar application.jar

sleep 10 sleep for 10 seconds

Amr Lotfy
  • 2,519
  • 4
  • 32
  • 47
5

Although this question is old and answered, I've stumbled across a problem with some of the solutions and decided to add my suggestion into the mix.

The problem with some of the solutions is that they build a single command string. This creates issues when some parameters contain spaces, especially java.home.

For example, on windows, the line

final String javaBin = System.getProperty("java.home") + File.separator + "bin" + File.separator + "java";

Might return something like this:C:\Program Files\Java\jre7\bin\java

This string has to be wrapped in quotes or escaped due to the space in Program Files. Not a huge problem, but somewhat annoying and error prone, especially in cross platform applications.

Therefore my solution builds the command as an array of commands:

public static void restart(String[] args) {

        ArrayList<String> commands = new ArrayList<String>(4 + jvmArgs.size() + args.length);
        List<String> jvmArgs = ManagementFactory.getRuntimeMXBean().getInputArguments();

        // Java
        commands.add(System.getProperty("java.home") + File.separator + "bin" + File.separator + "java");

        // Jvm arguments
        for (String jvmArg : jvmArgs) {
            commands.add(jvmArg);
        }

        // Classpath
        commands.add("-cp");
        commands.add(ManagementFactory.getRuntimeMXBean().getClassPath());

        // Class to be executed
        commands.add(BGAgent.class.getName());

        // Command line arguments
        for (String arg : args) {
            commands.add(arg);
        }

        File workingDir = null; // Null working dir means that the child uses the same working directory

        String[] env = null; // Null env means that the child uses the same environment

        String[] commandArray = new String[commands.size()];
        commandArray = commands.toArray(commandArray);

        try {
            Runtime.getRuntime().exec(commandArray, env, workingDir);
            System.exit(0);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
Malt
  • 25,324
  • 9
  • 56
  • 86
4

Just adding information which is not present in other answers.

If procfs /proc/self/cmdline is available

If you are running in an environment which provides procfs and therefore has the /proc file system available (which means this is not a portable solution), you can have Java read /proc/self/cmdline in order to restart itself, like this:

public static void restart() throws IOException {
    new ProcessBuilder(getMyOwnCmdLine()).inheritIO().start();
}
public static String[] getMyOwnCmdLine() throws IOException {
    return readFirstLine("/proc/self/cmdline").split("\u0000");
}
public static String readFirstLine(final String filename) throws IOException {
    try (final BufferedReader in = new BufferedReader(new FileReader(filename))) {
        return in.readLine();
    }
}

On systems with /proc/self/cmdline available, this probably is the most elegant way of how to "restart" the current Java process from Java. No JNI involved, and no guessing of paths and stuff required. This will also take care of all JVM options passed to the java binary. The command line will be exactly identical to the one of the current JVM process.

Many UNIX systems including GNU/Linux (including Android) nowadays have procfs However on some like FreeBSD, it is deprecated and being phased out. Mac OS X is an exception in the sense that it does not have procfs. Windows also does not have procfs. Cygwin has procfs but it's invisible to Java because it's only visible to applications using the Cygwin DLLs instead of Windows system calls, and Java is unaware of Cygwin.

Don't forget to use ProcessBuilder.inheritIO()

The default is that stdin / stdout / stderr (in Java called System.in / System.out / System.err) of the started Process are set to pipes which allow the currently running process to communicate with the newly started process. If you want to restart the current process, this is most likely not what you want. Instead you would want that stdin / stdout / stderr are the same as those of the current VM. This is called inherited. You can do so by calling inheritIO() of your ProcessBuilder instance.

Pitfall on Windows

A frequent use case of a restart() function is to restart the application after an update. The last time I tried this on Windows this was problematic. When overwrote the application's .jar file with the new version, the application started to misbehave and giving exceptions about the .jar file. I'm just telling, in case this is your use case. Back then I solved the issue by wrapping the application in a batch file and using a magic return value from System.exit() that I queried in the batch file and had the batch file restart the application instead.

Christian Hujer
  • 14,160
  • 5
  • 30
  • 40
  • 1
    My solution on windows for the pitfall was to copy over the newly generated `.jar` file from the build directory `build\libs\my.jar` to the current working directory and then running that instead. This avoids me overwriting the currently running jar (since i automatically re-compiles my jar between restarts); and this approach also helps to always have a runnable jar in case the update/compilation fails; where the restart will simply run the previously compiled jar. – Lorenzo Nov 24 '20 at 09:22
4

If you realy need to restart your app, you could write a separate app the start it...

This page provides many different examples for different scenarios:

http://www.rgagnon.com/javadetails/java-0014.html

Sean W.
  • 4,446
  • 6
  • 35
  • 61
3

Old question and all of that. But this is yet another way that offers some advantages.

On Windows, you could ask the task scheduler to start your app again for you. This has the advantage of waiting a specific amount of time before the app is restarted. You can go to task manager and delete the task and it stops repeating.

SimpleDateFormat hhmm = new SimpleDateFormat("kk:mm");    
Calendar aCal = Calendar.getInstance(); 
aCal.add(Calendar.SECOND, 65);
String nextMinute = hhmm.format(aCal.getTime()); //Task Scheduler Doesn't accept seconds and won't do current minute.
String[] create = {"c:\\windows\\system32\\schtasks.exe", "/CREATE", "/F", "/TN", "RestartMyProg", "/SC", "ONCE", "/ST", nextMinute, "/TR", "java -jar c:\\my\\dev\\RestartTest.jar"};  
Process proc = Runtime.getRuntime().exec(create, null, null);
System.out.println("Exit Now");
try {Thread.sleep(1000);} catch (Exception e){} // just so you can see it better
System.exit(0);
Dale
  • 4,421
  • 2
  • 37
  • 68
3

I was researching the subject myself when came across this question.

Regardless of the fact that the answer is already accepted, I would still like to offer an alternative approach for completeness. Specifically, Apache Ant served as a very flexible solution.

Basically, everything boils down to an Ant script file with a single Java execution task (refer here and here) invoked from a Java code (see here). This Java code, which can be a method launch, could be a part of the application that needs to be restarted. The application needs to have a dependency on the Apache Ant library (jar).

Whenever application needs to be restarted, it should call method launch and exit the VM. The Ant java task should have options fork and spawn set to true.

Here is an example of an Ant script:

<project name="applaucher" default="launch" basedir=".">
<target name="launch">
    <java classname="package.MasinClass" fork="true" spawn="true">
        <jvmarg value="-splash:splash.jpg"/>
        <jvmarg value="-D other VM params"/>
        <classpath>
            <pathelement location="lib-1.jar" />
            ...
            <pathelement location="lib-n.jar" />
        </classpath>
    </java>
</target>
</project>

The code for the launch method may look something like this:

public final void launch(final String antScriptFile) {
 /* configure Ant and execute the task */
   final File buildFile = new File(antScriptFile);
   final Project p = new Project();
   p.setUserProperty("ant.file", buildFile.getAbsolutePath());

   final DefaultLogger consoleLogger = new DefaultLogger();
   consoleLogger.setErrorPrintStream(System.err);
   consoleLogger.setOutputPrintStream(System.out);
   consoleLogger.setMessageOutputLevel(Project.MSG_INFO);
   p.addBuildListener(consoleLogger);

   try {
       p.fireBuildStarted();
       p.init();
       final ProjectHelper helper = ProjectHelper.getProjectHelper();
       p.addReference("ant.projectHelper", helper);
       helper.parse(p, buildFile);
       p.executeTarget(p.getDefaultTarget());
       p.fireBuildFinished(null);
   } catch (final BuildException e) {
       p.fireBuildFinished(e);
   }

   /* exit the current VM */
   System.exit(0);

}

A very convenient thing here is that the same script is used for initial application start up as well as for restarts.

01es
  • 5,052
  • 1
  • 29
  • 39
2

Similar to Yoda's 'improved' answer, but with further improvements (both functional, readability, and testability). It's now safe to run, and restarts for as as many times as the amount of program arguments given.

  • No accumulation of JAVA_TOOL_OPTIONS options.
  • Automatically finds main class.
  • Inherits current stdout/stderr.

public static void main(String[] args) throws Exception {
    if (args.length == 0)
        return;
    else
        args = Arrays.copyOf(args, args.length - 1);

    List<String> command = new ArrayList<>(32);
    appendJavaExecutable(command);
    appendVMArgs(command);
    appendClassPath(command);
    appendEntryPoint(command);
    appendArgs(command, args);

    System.out.println(command);
    try {
        new ProcessBuilder(command).inheritIO().start();
    } catch (IOException ex) {
        ex.printStackTrace();
    }
}

private static void appendJavaExecutable(List<String> cmd) {
    cmd.add(System.getProperty("java.home") + File.separator + "bin" + File.separator + "java");
}

private static void appendVMArgs(Collection<String> cmd) {
    Collection<String> vmArguments = ManagementFactory.getRuntimeMXBean().getInputArguments();

    String javaToolOptions = System.getenv("JAVA_TOOL_OPTIONS");
    if (javaToolOptions != null) {
        Collection<String> javaToolOptionsList = Arrays.asList(javaToolOptions.split(" "));
        vmArguments = new ArrayList<>(vmArguments);
        vmArguments.removeAll(javaToolOptionsList);
    }

    cmd.addAll(vmArguments);
}

private static void appendClassPath(List<String> cmd) {
    cmd.add("-cp");
    cmd.add(ManagementFactory.getRuntimeMXBean().getClassPath());
}

    private static void appendEntryPoint(List<String> cmd) {
    StackTraceElement[] stackTrace          = new Throwable().getStackTrace();
    StackTraceElement   stackTraceElement   = stackTrace[stackTrace.length - 1];
    String              fullyQualifiedClass = stackTraceElement.getClassName();
    String              entryMethod         = stackTraceElement.getMethodName();
    if (!entryMethod.equals("main"))
        throw new AssertionError("Entry point is not a 'main()': " + fullyQualifiedClass + '.' + entryMethod);

    cmd.add(fullyQualifiedClass);
}

private static void appendArgs(List<String> cmd, String[] args) {
    cmd.addAll(Arrays.asList(args));
}

V1.1 Bugfix: null pointer if JAVA_TOOL_OPTIONS is not set


Example:

$ java -cp Temp.jar Temp a b c d e
[/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java, -cp, Temp.jar, Temp, a, b, c, d]
[/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java, -cp, Temp.jar, Temp, a, b, c]
[/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java, -cp, Temp.jar, Temp, a, b]
[/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java, -cp, Temp.jar, Temp, a]
[/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java, -cp, Temp.jar, Temp]
$
Mark Jeronimus
  • 8,223
  • 2
  • 32
  • 44
-13
System.err.println("Someone is Restarting me...");
setVisible(false);
try {
    Thread.sleep(600);
} catch (InterruptedException e1) {
    e1.printStackTrace();
}
setVisible(true);

I guess you don't really want to stop the application, but to "Restart" it. For that, you could use this and add your "Reset" before the sleep and after the invisible window.

Jamal
  • 747
  • 7
  • 22
  • 31