# WebStart Java 6 liefert "Illegal field modifiers"



## vfl_freak (22. Januar 2010)

*WebStart Java 6 liefert "Illegal field modifiers"*

Hallo zusammen,

ich versuche seit zwei Tagen mein Projekt auf Java6 umzustellen.
Nach anfänglichen Problemchen mit einigen LIBs klappt es jetzt sehr gut. Ich kann das Programm im JBuilder2007 mittels ANT (build.xml) problemlos compilieren und auf direkt aus der Umgebung heraus aufrufen. Es ist sogar richtig schnell geworden 

Nun habe ich vorhin die jar-Datei auf den Webserver überspielt und versucht, das Programm von dort aus zu installieren.
Leider bekomme ich nun permanent folgende Fehlermeldung, mit der ich nichts anfangen kann:


```
java.lang.ClassFormatError: Illegal field modifiers in class XXX/Protokoll_lokal: 0xA
    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$000(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 com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClassInternal(Unknown Source)
    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$000(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 com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
    at com.sun.javaws.Launcher.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
```

_*Protokoll_lokal*_ ist 'lediglich' ein Interface, in dem div. Konstanten definiert sind!

Meine aktuelle Java-Version scheint JDK 1.6.0_12 und JRE 1.6.0_17 zu sein ...
Ich habe alle Pfade etc. kontrolliert und sind IMHO korrekt.

Was mich stark irritiert, ist die Tatsache, dass dies erst beim Download mit Webstart auftritt!
Dies ist die zugehörige JNLP-Datei:

```
<?xml version="1.0" encoding="utf-8"?>
<!-- JNLP File Created by KBr - XXX@zyx  -->
<jnlp spec="1.0+"
 codebase="http://www.XXX.zzz/xxx/" href="xxx_vision.jnlp">
 <information>
  <title>XXX (Vision-Version)</title>
  <vendor>XXX</vendor>
  <homepage href="xxx.html"/>
  <description>XXX (Vision-Version)</description>
  <description kind="short">XXX (Vision-Version)</description>
  <icon href="pics/w32g.gif"/>
  <offline-allowed />
  <shortcut online="true">
    <desktop/>
  </shortcut>
 </information>
 <security>
  <all-permissions/>
 </security>
 <resources>
  <j2se version="1.6.0*" href="http://java.sun.com/products/autodl/j2se" initial-heap-size="128m" max-heap-size="512m" />
  <jar href="XXX.jar"/>
  <jar href="Serialio.jar"/>
  <jar href="jspComm.jar"/>
  <jar href="log4j-1.2.8.jar"/>
  <jar href="jco.jar"/>
  <jar href="edtftpj.jar"/>
  <nativelib href="Win_x86_EtherAddr.jar"/>
  <nativelib href="libSolaris_sparc_EtherAddr.jar"/>
  <nativelib href="libLinux_x86_EtherAddr.jar"/>
  <nativelib href="mawin.jar"/>
  <nativelib href="win32com.jar"/>
  <nativelib href="JSkype.jar"/>
  <!--nativelib href="MSVCRTD.jar"/-->
 </resources>
 <application-desc main-class="XXX.mainApp"/>
</jnlp>
```

Ich hoffe, dass mit irgendwer weiterhelfen kann ..... 

Danke und Gruß
Klaus


----------



## hansmueller (25. Januar 2010)

Hallo Klaus,

das ein Programm in der IDE-Umgebung funktioniert, aber außerhalb nicht, ist nach meiner Erfahrung nichts ungewöhnliches. In den IDEs kann man inzwischen alles mögliche einstellen und diese nehmen dem Programmierer viel Arbeit ab. Aber wenige Menschen können diesen Funktionsumfang auch fehlerfrei benutzen. (Ich gehöre leider nicht dazu).

Die Fehlermeldung spricht von einem


> Illegal field modifiers



Dies könnte ein falsch gesetzes
final
static
transient
oder
volatile
sein.

Normalerweise sollte dies aber die IDE bereits als Fehler anzeigen.

Setze doch mal den ganzen Code von "Protokoll_local" ins Forum.

MfG
hansmueller


----------



## vfl_freak (25. Januar 2010)

hansmueller hat gesagt.:


> Die Fehlermeldung spricht von einem "Illegal field modifiers"
> Dies könnte ein falsch gesetzes
> final
> static
> ...


Letzteres wundert mich ja auch .... von daher gehe ich ganz stark davon aus, dass der Fehler bei WebStart oder der jnlp-Datei liegt !



hansmueller hat gesagt.:


> Setze doch mal den ganzen Code von "Protokoll_local" ins Forum.


Das wird sich kaum lohnen, da es wie gesagt ca. 500 Konstanten sind, die allesamt als _*"public static final"*_ deklariert sind! "_transient_" und "_volatile_" nutze ich in der Datei gar nicht. Die jeweiligen Datentypen gehen von _int_, _long_, _String_ und _boolean_ bis zu _char[]_ und _String[]_ ....

Ich will gleich noch alle Einträge der jnlp-Datei prüfen und ggf. auch das Java-JDK neu installieren ....

Gruß
Klaus


----------



## deepthroat (25. Januar 2010)

Hi.

Schau dir mal die Ausgabe von javap -private an.

Du hast dort vermutlich ein privates, statisches Attribut drin. (JVM_ACC_PRIVATE | JVM_ACC_STATIC == Code 0xA)

Gruß


----------



## vfl_freak (25. Januar 2010)

Moin deepthroat,

erstmal Danke für Deine Antwort!
Es sind wirklich nur Kosntanten mit _*"public static final"*_ ... hatte vorhin auch schon mal spaßeshalber ohne _*"Static final"*_ versucht, aber kam der gleiche Fehler.

Was mich ja auch so stark irritiert, dass ich problemlos compilieren kann! Und ich kann die Anwendung ja auch direrkt aus der Entwicklungsumgebung heraus starten .....  

*Leider ist mir nicht klar, was Du mit " javap -a" meinst. Soll dass ja im CMD ausgeführt werden?  Dort bekomme ich nur den Hinweis,  dass der Befehl "entweder falsch geschrieben sei oder nicht gefunden werden konnte" ....
*
Gruß Klaus


----------



## deepthroat (25. Januar 2010)

vfl_freak hat gesagt.:


> *Leider ist mir nicht klar, was Du mit " javap -a" meinst. Soll dass ja im CMD ausgeführt werden?  Dort bekomme ich nur den Hinweis,  dass der Befehl "entweder falsch geschrieben sei oder nicht gefunden werden konnte" ....
> *


javap ist ein Disassembler für .class Dateien vom Java SDK.

Wenn der Befehl nicht gefunden wird, dann hast du das bin Verzeichnis deines SDKs nicht im %PATH%. Du kannst den Pfad ja komplett eintippen. Und du müßtest halt vorher aus dem Jar welches auf dem Webserver liegt die .class Datei des com/gselectronic/worker/config/Protokoll_lokal Interface extrahieren:

```
c:\programme\java\jdk6\bin\javap -private Protokoll_lokal > ausgabe.txt
```
Gruß


----------



## vfl_freak (25. Januar 2010)

deepthroat hat gesagt.:


> javap ist ein Disassembler für .class Dateien vom Java SDK.


Ah, Danke, habe mich gerade mal im Web schlau gemacht ...



deepthroat hat gesagt.:


> Wenn der Befehl nicht gefunden wird, dann hast du das bin Verzeichnis deines SDKs nicht im %PATH%.


Das kann sein, hatte das JDK 1.6.0_12 heute mal neu installiert, darf aber hier Umgebungsvariablen nicht ändern (keine Admin-Rechte)




deepthroat hat gesagt.:


> Du kannst den Pfad ja komplett eintippen. Und du müßtest halt vorher aus dem Jar welches auf dem Webserver liegt die .class Datei des xxx/Protokoll_lokal Interface extrahieren:
> 
> ```
> c:\programme\java\jdk6\bin\javap -private Protokoll_lokal > ausgabe.txt
> ...


Ok, klar, da hätte ich selbst drauf kommen können :-(
Ich habe es jetzt zunächst mal mit der lokalen class-Datei, die beim Compilieren erzeugt wurde, versucht. Habe sie nach C:\ kopiert, allerdings sagt mir das javap, dass der diese Datei nicht finden kann ...

Hier mein kompletter Aufruf:

```
c:\programme\java\jdk1.6.0_12\bin\javap -private c:\Protokoll_lokal Interface > C:\OUT.TXT
```
Gruß
Klaus


----------



## deepthroat (25. Januar 2010)

vfl_freak hat gesagt.:


> Ich habe es jetzt zunächst mal mit der lokalen class-Datei, die beim Compilieren erzeugt wurde, versucht. Habe sie nach C:\ kopiert, allerdings sagt mir das javap, dass der diese Datei nicht finden kann ...
> 
> Hier mein kompletter Aufruf:
> 
> ...


Mit Pfaden kommt javap nicht gut zurecht. Wechsle doch das Verzeichnis wo sich die Datei befindet und das "Interface" mußt du weglassen - das war nur ein copy'n'paste Fehler von mir... 

Gruß


----------



## vfl_freak (25. Januar 2010)

Ah, ok ... jetzt ... 

tja, wie erwartet alles nur "public static final ...", bis auf ein seltsames "static {};" am Ende 


```
Compiled from "Protokoll_lokal.java"
public interface xxx.Protokoll_lokal
{
...
    static {};
}
```

Gruß
Klaus


----------



## deepthroat (25. Januar 2010)

vfl_freak hat gesagt.:


> Ah, ok ... jetzt ...
> 
> tja, wie erwartet alles nur "public static final ...", bis auf ein seltsames "static {};" am Ende


Hm. Die statische Methode sollte eigentlich Ok sein... Wie sieht die Datei aus dem Webserver jar aus? Genauso?

Ansonsten, mach doch einfach aus deinem Interface eine [final] class. Implementieren willst du doch dieses "Interface" sowieso nicht, oder?!

Gruß


----------



## vfl_freak (25. Januar 2010)

Hmmm .. jetzt bin ich endgültig verwirrt :-(

Habe gerade mal die jar.Datei entpackt und das Ganze dann wiederholt.
Mal ganz davon abgesehen, das die class-Datei erheblich  kleiner ist (nur 2 statt 19 kB):

```
public interface xxx.Protokoll_lokal{
    public static final char[] cKey;
    public static final java.lang.String[] SERVERLISTE;
    public static final java.lang.String[] DATAEDITDIALOGOPTIONSLIST;
    public static final java.lang.String[] DATAEDITDIALOGOPTIONS;
    private static java.lang.String USERHOME;
    public static final java.lang.String DRUCKAUSGABE_ORDNER;
    public static final java.lang.String[] MSGDIALOGMESSAGETYPES;
    public static final java.lang.String[] EXTENDEDALSTSTATSDIALOGTEXTE;
    static {};
}
```

In den Sourcen ist USERHOME aber immer noch public 

Jetzt verstehe ich gar nichts mehr


----------



## vfl_freak (25. Januar 2010)

deepthroat hat gesagt.:


> Ansonsten, mach doch einfach aus deinem Interface eine [final] class. Implementieren willst du doch dieses "Interface" sowieso nicht, oder?!



Doch doch, da dies die Standardkonstanten der Applikation sind, wird dieses Interface an rund 130 Stellen verwendet ..... 
Und das auch schon seit vor meiner Zeit .    :-(

Gruß
Klaus


----------



## deepthroat (25. Januar 2010)

vfl_freak hat gesagt.:


> Hmmm .. jetzt bin ich endgültig verwirrt :-(
> 
> Habe gerade mal die jar.Datei entpackt und das Ganze dann wiederholt.
> Mal ganz davon abgesehen, das die class-Datei erheblich  kleiner ist (nur 2 statt 19 kB):
> ...


Aus der neuesten (beta) ProGuard ChangeLog:


> Version 4.5
> 
> * *Avoiding making fields in interfaces private*.


^^

Gruß


----------



## vfl_freak (25. Januar 2010)

nochmals hmmm - mal davon abgesehen, dass ich ProGuard 4.*4* nutze:
und ist der Rest geblieben 

gruß
Klaus


----------



## deepthroat (25. Januar 2010)

vfl_freak hat gesagt.:


> nochmals hmmm - mal davon abgesehen, dass ich ProGuard 4.*4* nutze


Eben, da ist der Bug ja noch drin. Erst in 4.5 ist er behoben.


vfl_freak hat gesagt.:


> und ist der Rest geblieben


Anscheinend wurde USERHOME nicht extern verwendet... ? \edit: bzw. beim Kompilieren direkt durch Literale bzw. Verweise auf den Stringpool ersetzt, so das keine Referenz mehr darauf zeigte.

Gruß


----------



## vfl_freak (25. Januar 2010)

deepthroat hat gesagt.:


> Anscheinend wurde USERHOME nicht extern verwendet... ?


Jau, genau das isses  
Die Konstante wurde nur einmal in der darunterliegenden Zeile verwendet ....
Vermutlich hat meine Vorgänger sie als "*public*" deklariert, um sie auch anderswo verwenden zu können, dies dann aber nie getan . ein Sch... ist das 

Na, dann werde ich das mal anpassen, ggf. auch noch mal schnell ProGuard updaten und dann alles nochmal versuchen!
Melde mich wieder, ob es geklappt hat!

Erst mal _*Dankeschön*_ für die tolle Unterstützung!
Gruß
Klaus


*EDIT:*  jau, hat alles wunderbar geklappt !!


----------

