Sorry to bug you all with this, I've searched on this site and found many hits, but not anything addressing this specific problem:

Installed jedit from jedit_4.3pre11_all.deb. Install returned 0 meaning it installed correctly. Java on this system is jre1.6.0_03.

Invoking it from a console returns the following:


~$ jedit
Warning: $JAVA_HOME environment variable not set! Consider setting it.
Attempting to locate java...
Found a virtual machine at: /usr/bin/java...

~$ Exception in thread "main" java.lang.NoClassDefFoundError: org.gjt.sp.jedit.jEdit
at java.lang.Class.initializeClass(libgcj.so.70)
Caused by: java.lang.VerifyError: verification failed at PC 122 in org.gjt.sp.jedit.jEdit:reloadModes(()V): incompatible type on stack
at java.lang.Class.initializeClass(libgcj.so.70)

I did make sure my java/bin folder was on the path, and evidently jedit did find the vm, but choked later.

Any ideas? Anyone ever encounter this?

Many thanks in advance

Did you set JAVA_HOME as mentioned in the message?

Here's what I just entered:

~$ JAVA_HOME=/usr/java/jre1.6.0_03/bin/

~$ $JAVA_HOME
bash: /usr/java/jre1.6.0_03/bin/: is a directory

~$ jedit
Warning: $JAVA_HOME environment variable not set! Consider setting it.
Attempting to locate java...
Found a virtual machine at: /usr/bin/java...
~$ Exception in thread "main" java.lang.NoClassDefFoundError: org.gjt.sp.jedit.jEdit
at java.lang.Class.initializeClass(libgcj.so.70)
Caused by: java.lang.VerifyError: verification failed at PC 122 in org.gjt.sp.jedit.jEdit:reloadModes(()V): incompatible type on stack
at java.lang.Class.initializeClass(libgcj.so.70)

So I entered it, checked that it was set, and ran jedit, with the same result. I did the same the first time too.

OR-- did I enter the JAVA_HOME variable incorrectly above? If so, I'd appreciate a pointer on how to do it right.

Thanks again

JAVA_HOME should probaly not point to the path where the VM is located, but where the entire environment is.

In my case, JAVA_HOME is set to /usr/lib/java - one directory level ABOVE bin/.

I assume yours to be /usr/java/jre1.6.0_03/ - without ¨bin".

Thanks Su-Shee, I set it as you suggested:

JAVA_HOME=/usr/java/jre1.6.0_03/

But still got the same result.

I checked on the SUN web site to confirm that my jre was installed correctly. Their system confirmed it. I can only suspect the package, because this was marked as "latest" and not "stable" on the jedit.org site. Problem is, I'm still new at this, can't yet figure out how to install a non-deb package, and they don't have a .deb for the (older) stable jedit.

Wait, I use jedit either, let me check.

Nope, works perfectly fine, as usal.

I got the platform independent installer,
did sudo java -jar <theinstaller.jar>, said yes, yes, yes and got a jedit in /usr/local/bin which I just called with jedit someperlcode.pl.

This is how I'm used to it since.. for several years I guess.

But I didn't use a distribution's package.

I _did_ use "latest" and not stable.

And set "export JAVA_HOME=<yourpath>", not just "JAVA_HOME=<yourpath>" because you would have to call it each time before starting something java-ish probably.

Thanks so much, again

Followed your instructions:

# export JAVA_HOME=/usr/java/jre1.6.0_03/

Then verified:

$JAVA_HOME
bash: /usr/java/jre1.6.0_03/: is a directory

Then attempted to install from the platform-independent installer:

# java -jar jedit4.3pre11install.jar

Got the following response:

Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified


(.:15061): Gtk-WARNING **: cannot open display:

not too big a deal I suppose, I can still use Nedit which has most of the features I'm looking for. If you (or anyone) have any other ideas, that would be great. In any case, thanks so much for your help.

You started X as user, but the installer as root, I guess.

Do

sudo java -jar theinstaller.jar

and start jedit yourfile as usal.

I assume here a configured sudo. (You as user included in /etc/sudoers.)

Otherwise, set as root

export DISPLAY=:0

and as user:

xhost + localhost

but prefer "sudo" over this solution.

The thing with graphical installers under Linux is that you usally install new stuff with root permissions to write into directories like /usr, /etc and so on, but your GUI just runs as user.