Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Java Applet error "invalid bytecode"

0 views
Skip to first unread message

John Zoetebier

unread,
Feb 11, 2004, 5:41:00 AM2/11/04
to
Opera 7.23

When I load page http://www.oyoaha.com/lookandfeel/applet/index.html
it shows a short message "loading pplet"
Next error messahe "invalid bytecode"

I have tested my Java settings under Opera and they are right.
Netscape and FireBird handle applet fine.
Any ideas ?

--
John Zoetebier
Web site: http://www.transparent.co.nz

Eirik Byrkjeflot Anonsen

unread,
Feb 11, 2004, 6:24:33 AM2/11/04
to
John Zoetebier <john.zoeteb...@transparent.co.nz> writes:

> Opera 7.23
>
> When I load page http://www.oyoaha.com/lookandfeel/applet/index.html
> it shows a short message "loading pplet"
> Next error messahe "invalid bytecode"
>
> I have tested my Java settings under Opera and they are right.
> Netscape and FireBird handle applet fine.
> Any ideas ?
>


Try starting opera from a command line with '-debugjava'.
I believe it should say something about a 'plugin.jar' or
something like that...


eirik

Robert Blaut

unread,
Feb 11, 2004, 7:55:12 AM2/11/04
to
On Wed, 11 Feb 2004 12:24:33 +0100, Eirik Byrkjeflot Anonsen
<ei...@opera.com> wrote:

> Try starting opera from a command line with '-debugjava'.
> I believe it should say something about a 'plugin.jar' or
> something like that...

The same problem exists in Opera 7.50p1 for Windows. Java Console report:

-- Opera Java Console --

Java vendor: Sun Microsystems Inc.
Java version: 1.5.0-beta

type 'h' for help

--
java.lang.ClassFormatError: Incompatible magic value 1013478509 in class
file OaLnFApplet
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access+100(Unknown Source)
at java.net.URLClassLoader+1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at com.opera.PluginPanel.run(PluginPanel.java:412)
at java.lang.Thread.run(Unknown Source)

--
Best Regards
Robert Błaut
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Eirik Byrkjeflot Anonsen

unread,
Feb 11, 2004, 8:50:06 AM2/11/04
to
"Robert Blaut" <qui...@despammed.com> writes:


If it works with the same JRE with another browser, I'm still
suspecting that plugin.jar doesn't get loaded. I don't think
there's any debug information about that on windows, but I'm
pretty sure I added it to the linux version (when running with
'-debugjava')


eirik

John Zoetebier

unread,
Feb 12, 2004, 3:57:56 PM2/12/04
to
On Wed, 11 Feb 2004 12:24:33 +0100, Eirik Byrkjeflot Anonsen
<ei...@opera.com> wrote:

No, get a completely different message:
==>
johnz@tsl010:~> opera -debugjava
opera: [java] There seems to be a preloaded version of Xt.
Typical causes for this are the LD_PRELOAD environment
variable or that Opera indirectly depends on libXt.so
There is a workaround for this problem in the opera startup
script that unfortunately triggers this error message.
Most likely this message is harmless, and the next message
printed is that java is not disabled after all (because of
"OPERA_FORCE_JAVA_ENABLED"). If the workaround has failed
opera will most likely crash every time it tries to use Java.

opera: [java] The Java enable flag will not be reset
because the OPERA_FORCE_JAVA_ENABLED environment
variable has been defined.

johnz@tsl010:~>
==>

When I search for libXt.so I get this:
tsl010:/home/johnz # find / -iname libXt.so
/usr/X11R6/lib/libXt.so

This is a standard X library.
None of the other browser seem to have problems with libXt.so.

Robt. W. Fletcher Jr.

unread,
Feb 12, 2004, 5:45:24 PM2/12/04
to

7.50p1 (static version) GNU/Linux; RedHat 7.1.

-- Opera Java Console --

Java vendor: Sun Microsystems Inc.

Java version: 1.4.2_01

type 'h' for help

java.lang.ClassFormatError: OaLnFApplet (Bad magic number)
at java.lang.ClassLoader.defineClass0(Native Method)


at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)

at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)


at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at com.opera.PluginPanel.run(PluginPanel.java:412)
at java.lang.Thread.run(Unknown Source)


And the debug output

% opera --debugjava &
[1] 8067


opera: [java] There seems to be a preloaded version of Xt.

There is a workaround for this problem in the opera

startup script. If that workaround fails, opera will


most likely crash every time it tries to use Java.

The workaround seems to be working.
Technical explanation:
There is a problem with the order of loading Xt and
Java. If Xt is loaded before libawt (part of Java),
Java will crash when it tries to access the screen.
The workaround is based on using LD_PRELOAD to load
libawt.so first.

opera: [java] The Java enable flag will not be reset
because the OPERA_FORCE_JAVA_ENABLED environment
variable has been defined.

opera: Could not initialize spell check. Error code -7
opera: Could not initialize M2
opera: [Java] Adding '/usr/java/j2re1.4.2_01/lib/plugin.jar' to classpath.


-rwf

Eirik Byrkjeflot Anonsen

unread,
Feb 13, 2004, 3:26:31 AM2/13/04
to
John Zoetebier <john.zoeteb...@transparent.co.nz> writes:


The messages are harmless in this case, since opera didn't
crash when starting java... (Opera doesn't have a problem
with libXt. Opera doesn't use it. Java, on the other hand,
has a nasty dependency on it that can't be resolved by the
usual, automatic library loader...)

But no message about plugin.jar. Seems I didn't add that
message until after 7.23.


It seems I've got the same problem, though, and the Java
console reports "Bad magic number". This typically means
that the file we handed to Java wasn't a class file at all...

Hmm, it seems the jar file is pretty broken after downloading
it with wget... jar just hangs on it, while unzip reports:

Archive: oalnf.jar
error [oalnf.jar]: missing 1 bytes in zipfile
(attempting to process anyway)
error [oalnf.jar]: reported length of central directory is
1 bytes too long (Atari STZip zipfile? J.H.Holm ZIPSPLIT 1.1
zipfile?). Compensating...
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
4694 Defl:N 2301 51% 02-09-04 01:42 1dc48967 com/oyoaha/swing/plaf/oalnf/ui/OaInternalFrameUI.class
760 Defl:N 432 43% 02-09-04 01:42 072e9af4 com/oyoaha/swing/plaf/oalnf/ui/OaCheckBoxUI.class
709 Defl:N 393 45% 02-09-04 01:42 80483f81 com/oyoaha/swing/plaf/oalnf/ui/OaComboBoxUI.class
2149 Defl:N 1091 49% 02-09-04 01:42 78123f47 om/oyoaha/swing/plaf/oalnf/ui/OaScrollBarUI.classP
error: expected central file header signature not found (file #5).
(please check that you have transferred or created the zipfile in the
appropriate BINARY mode and that you have compiled UnZip properly)


And the class file is not directly available, either. How on
earth can anything manage to handle this applet?


eirik

Tullio Chersi

unread,
Feb 13, 2004, 4:13:33 AM2/13/04
to
My Mozilla1.6 handles it with Sun Java Plugin 1.4.2_b28. Opera 7.5 does not.
Tullio
0 new messages