A:

If you don't have a clue as to why you cannot run jEdit, it's best to perform a step-by-step diagnosis. If it never worked before, begin by finding the Java application loader you are using: java.exe, javaw.exe or java. Make sure it is running by entering its full path with the -h parameter in a terminal or console window. If you can't find the Java application loader, your Java runtime environment package may be missing or incomplete.

Next, find where you have installed jEdit. You should look for the file jedit.jar which contains all of the application's Java class files in a compressed archive.

Once you have both files, run the Java loader with the -jar option and with jedit.jar as the target. Make sure that you either specify full paths for both files or that the directories for the files are part of your PATH environment variable. If jEdit does not load at this point, the likely problem is a corrupt jedit.jar file. Try downloading the application again.

If jEdit does load using this procedure, you need to examine the “shortcut” loading mechanism you wish to use.

On Linux and MacOS X, you need to find and examine the jedit shell script provided by the installation routine to confirm that the script's commands target the correct files and locations, and that variables like JAVA_HOME are either defined in the script or elsewhere in your shell's environment. Don't forget to make sure that the script's file permissions allow you to execute it as a shell script.

On Windows, if you are using a batch script to run jEdit, the same points (other than file permissions) apply to examining jedit.bat. If you are using jEditLauncher, run jedit /p in jEdit's installation directory from a command line to get the custom loader's setup dialog. Here you can check the paths for both the Java application loader and jEdit as well as any command line parameters for both programs. Make sure that you have placed Java and jEdit options in the correct input fields. If the parameters seems correct but jEdit will not load with the Windows launcher, try uninstalling and reinstalling the launcher by running jedit /u followed by jedit /i.

But it worked before! It just stopped working after an upgrade. What should I do?

If it used to work for an older version and no longer works, it could be that you have some old crud (bad settings, unsupported plugins) in your jEdit settings directory (~/.jedit on Linux, %APPDATA%\jEdit on Windows, or ~/Library/jEdit on MacOS). You may want to try renaming the offending directory to something else, and restarting jEdit with fresh settings. You can later copy things from your old settings back if you find you are missing things.

If at this point you're still stuck, ask for help on the jedit-users mailing list, the jEdit Community “Installation” message board or on IRC. You're bound to find someone quickly.

A:

If you use jEdit's Plugin Manager to download and install plugins, your plugins will be found in the jars subdirectory of one of two directories: either the directory in which jEdit is installed, or the current user's settings directory. These are the only location jEdit examines when it loads plugins at startup.

The default location of the settings directory depends on your operating system. You can find out its location during a jEdit session by evaluating jedit.getSettingsDirectory() in BeanShell.

The settings directory can be changed by using the -settings command line parameter. If you change the location of the settings directory with this parameter, jEdit will not be able to find plugin archive files in the old location. If you use or change the -settings parameter, make sure your plugins don't get left behind.

A:

The memory requirements of jEdit vary greatly depending on how many files are in use, and what plugins you are using. You can see how much it is using in the status bar.

One solution that often works is to set or increase the allocation of memory to the heap for Java objects created by the Java Virtual Machine in which jEdit is running. Add a command line option -mx640m to the options passed to the version of the Java application loader you are using (such as java, java.exe or javaw.exe). In place of the 640 in the option, use a number of megabytes you think is appropriate for the maximum heap size. If you already are using the option, try doubling it.

For more information about JVM options, see the page on JVM options in the users guide.

On Windows, if you are using the jedit.exe launcher, you can add or change the JVM arguments by editing a file called jEdit.l4j.ini in the same directory as the jedit.exe. Place one JVM argument (e.g. -mx640m) on each line by itself.

If out of memory errors occur while running a build or compilation operation from within jEdit, you can also have the operation run in an external process rather than inside the same Java Virtual Machine running jEdit. The AntFarm plugin, for example, lets you select this approach as a configuration option. In other cases, you can run an external program using the command line interface of the Console plugin, which will capture and display the output of the external process and in many cases parse the output for error information.

A:

Before jEdit 5.0, it happened to me quite a bit too. I use this macro to help avoid the need to restart jEdit.

/** Reset_TextArea.bsh */
view.splitVertically();
view.unsplitCurrent();

Run this, and jEdit creates a new TextArea for you, one that is in a valid state.

If you can reproduce the steps you took to cause this, please submit a bug report that details what plugins/versions you were using, and how to reproduce it. It may be specific to a file you are editing, or a particular combination of settings you are using, or sequence of actions you performed.

A:

Perhaps the option to let Java draw window borders is enabled. This option can lead to strange behavior on some Java versions and operating systems. Disable it in the Appearance tab of the Utilities>Global Options dialog box.

A:

The full message that you may receive from the Java application launcher begins as follows:

Exception in thread "main" java.util.zip.ZipException: No such file or directory
...

This means that the Java application launcher cannot read the jar archive file that you specified on the command line. If your Java runtime environment otherwise runs properly, then either you have named the incorrect file name or the installation file is corrupt or incomplete. Check the file name, download the installer again if necessary, and be sure to follow any specific instructions for your operating system posted on the jEdit web site.

A:

You need to specify the -jar option for the Java application loader so that the loader will search the installation archive for the starting class file. Without the option, it treats the archive as a single class file (which it is not!), thus producing the error. The correct command line would be java -jar jeditXXXinstall.jar.

A:

It's important to realise that java applications should never do this. The problem is almost certainly a bug in the JVM. Problems of this nature are often tricky to solve. Depending on your platform, there should be information logged about what caused the crash to occur. For Unix type systems you will likely get an error in the console (and for Mac OS X you may also get a report in ~/Library/Logs/CrashReporter/JavaApplicationStub.crash.log).

A:

Sometimes, it can be due to a deadlock, or an infinite loop, or something else. You need to obtain a thread dump from the time of hang, and attach that as a textfile to your bug report, explaining what you were doing at the time.

One way to obtain a thread dump, is to run jEdit with java -jar jedit.jar from a command line shell in the foreground, wait for the hang or lockup, and type Ctrl+\ (or Ctrl+Break on Windows) into the shell window. You should see a thread dump printed immediately that will help diagnose the problem.

Another way to get a thread dump is to run jEdit as you normally would, then run visualvm. You can right click on the jEdit process from within visualvm and choose "thread dump".

A:

Install ShortcutDisplay plugin for help.

A:

Some plugins require a lot of setup - chances are if you disable one, you will be able to determine the culprit. jEdit normally starts up quite quickly without plugins.

You should be able to see which (if any) plugins are causing an excesively long delay.

A:

There may be many causes for this. Java by nature is more demanding on hardware than native applications. Modern computers should not have much problem with this.

The most likely cause is plugins that parse buffers or do other computationally expensive operations. These include XML, JavaSideKick, and CodeAid. If performance is important to you, installing a whole batch of plugins in one go is probably not a very good idea. Install them one at a time, so you can evaluate the effects of each.

A:

The plugin is missing a requestDefaultFocus() method. Check the jedit plugin bugs tracker to see if the ticket is already opened and you can open a ticket if it's not there.

A:

Make sure the version of Java you are running is Oracle Java 1.8 or higher. In debian/ubuntu, apt-get install openjdk-8-jdk

A:

Your jedit shell script should be modified to set the JAVA_HOME variable to the directory containing the executables of your desired Java runtime environment (JRE).

A:

The dialog presenting this message asks if you would like to install the launcher. Select Yes and supply further information as prompted. A file named install.log is generated in the same directory as jedit.exe that contains information on the launcher's installation. You can send this file along with jEdit's Activity Log if you continue to have problems running jEdit with the launcher package.

A:

The problem is not with jEdit but may be caused by your installation of the Java runtime environment. Under Windows, Sun's Java application loader relies on entries in the Windows registry to find the files that create the runtime environment and a Java virtual machine. The loader (java.exee or javaw.exe) is unable to find the necessary registration entry and therefore sends the error message. The best approach to fixing this is to uninstall and reinstall the JDK.

A:

You should confirm that you have a Java runtime environment installed, which will include java.exe and the version that omits a separate terminal window, javaw.exe. Make sure that the directory containing java.exe or javaw.exeis found in the value of your PATH environment variable. Otherwise you should give the full path to the chosen loader on your command line.

A:

A frequent cause of this problem is buggy video drivers and/or a buggy DirectDraw implementation. A workaround is to disable Java's use of DirectDraw by adding the following option to the Java virtual machine command line:

-Dsun.java2d.noddraw=true