This section deals with problems you may experience while using or installing jEdit. Problems that aren't OS specific are listed under “General Problems”.
1. General Problems | |
| |
Q: | jEdit won't start. What should I do? |
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. Begin by finding the
Java application loader you are using:
Next, find where you have installed jEdit. You should look
for the file
Once you have both files, run the Java loader with the
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
On Windows, if you are using a batch script to run jEdit, the
same points (other than file permissions) apply to examining
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. |
Q: | After jEdit starts, I can't see all of the plugins I have downloaded. How can I make them appear? |
A: |
If you use jEdit's Plugin Manager to download and install plugins, your
plugins will be found in the
The default location of the settings directory depends on your operating
system. You can find out its location during a jEdit session by
evaluating
The settings directory can be changed by using the
|
Q: | During an editing session I get an error message about an “OutOfMemoryError” while working with a large file or performing a lengthy operation. The message reappears every time I retry the operation. How can I prevent this? |
A: |
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 the command line option
If you are using the 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. |
Q: | Why is jEdit's window movement and resizing so buggy? |
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. |
Q: | What should I do when the installer displays the message, No such file or directory ? |
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. |
Q: |
After downloading Exception in main(), NoClassDefFoundError: jeditXXXinstall/jar. What am I doing wrong? |
A: |
You need to specify the |
Q: | jEdit crashed the JVM, what gives? |
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). Some recent problems with Java 1.4.x and Windows were the result of a bug in the JVM and certain graphics card drivers. |
Q: | Why is jEdit so slow to start up? |
A: | The most likely cause is one or more plugins that are installed. jEdit 4.1 displays loading times for plugins in the activity log.
You should be able to see which (if any) plugins are causing an excesively long delay. |
Q: | Why is jEdit so slow? |
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, SpeedJava 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. NoteIf you are experiencing slow downs when switching and saving buffers (up to 20 second delays) and you have the TaskList plugin installed, check that the version is greater than 0.4. Versions after 0.4 fix the problem.
|
Q: | Go to left/top/bottom/right docking area does not work for some plugins? |
A: |
The plugin is missing a |
2. Mac OS Problems | |
Q: | Why are the tabs for docked windows blurry under OS X 10.2? |
A: |
In Mac OS X 10.2 Apple enabled Hardware Acceleration for Java by default.
Unfortunately it had some bugs. This is the result of one of these bugs.
The only way to avoid this problem is to disable hardware acceleration for
jEdit or your whole system.
To disable it in jEdit you will need to edit
the following file:
jEdit/jEdit.app/Contents/Resources/MRJApp.properties
You will need to add the line |
Q: | Why are the menus not in the menubar? |
A: | You can enable the use of OS X's menubar in the Mac OS Plugin settings. You should note that the reason this is off by default is because of numerous problems with using the Mac OS X menubar. For example dynamic menus, shortcuts and check box menu items do not work correctly or at all. All bar the shortcut issue is resolved in Java 1.4.1 (currently in beta). |
Q: | Why does jEdit freeze when I hide the application while it is starting up? |
A: | This appears to be a bug in Java 1.3.1. Once the splash screen has gone it should be safe to hide the application. |
Q: | Why does jEdit freeze my whole system? |
A: | Under some hardware configurations this can happen. It is only known to happen with Rage 128 Pro graphics cards. There appears to be a bug relating to the graphics card drivers that cause any carbon applications using the card to freeze. Since java 1.3.1 is carbon based, it suffers from this problem. Follow the instructions here to disable hardware acceleration. Java 1.4.x does not suffer from this problem (in beta at this time). |
3. Unix/Linux Problems | |
| |
Q: |
After installing jEdit on Linux, running the Warning: JAVA_HOME environment variable not set How can I fix this? |
A: |
Your |
Q: | How can I get jEdit to run on Mandrake Linux 8.1? When I try to start the program, I keep getting an error which begins as follows: java/lang/NoClassDefFoundError: Ljavax/swing/text/Document; at java.lang.reflect.Method.invoke(Method.java:native) at kaffe.jar.ExecJarName.main
|
A: | This version of Mandrake Linux uses the Open Source Kaffe package as its default Java virtual machine. Kaffe is compliant with version 1.1 (and to a limited extent, version 1.2) of the Java platform. However, the latest version of jEdit, version 4.1, requires at least version 1.3. You will need to install another Java package for Linux (either Blackdown, IBM or Sun) that complies with at least version 1.3. |
Q: | I installed jEdit 3.2.2 from the RPM on Mandrake 8.1 and I am unable to send any keyboard inputs to jEdit. But the mouse interacts with the program just fine. I have tried running it on Sun's JDK 1.3.1 and Blackdown's latest JDK (Dec. 2001) without any luck. |
A: | This problem has been reported with various combinations of window managers and desktop environments. The IBM JDK has not been reported to have this problem. In addition, there have not been reported problems with the Sun and Blackdown JDK's when running under the Sawfish window manager. |
4. Windows Problems | |
| |
Q: |
When I try to run
The JEditLauncher component does not appear to be installed.
|
A: |
The dialog presenting this message asks if you would like to install the
launcher. Select |
Q: | When I try to run the jEdit installation package in Windows, I get an error message, Error opening registration key "software\javasoft\java runtime environment". How can I fix this? |
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 ( |
Q: |
When trying to install jEdit on Windows Me with an MS-DOS prompt, after entering
|
A: |
You should confirm that you have a Java runtime environment installed, which
will include |
Q: | When I run jEdit on Windows, it flashes, blinks, and doesn't display correctly! Why is your program so buggy? |
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 |