# Probleme beim Klassen-Import von sun.misc. ...



## AndyFFW (1. Jan 2013)

Hallo,
Ich habe in einer Klasse 2 Importe: - sun.misc.Resource und sun.misc.URLClassPath - Bei diesen erhalte ich die Fehlermeldung: " Zugriffseinschränkung: Der Typ (Import) ist nicht zugänglich aufgrund einer Beschränkung in der erforderlichen Bibliothek - Java\lib\rt.jar - "

Nach na weile googlen habe ich diesen Problem nicht gefunden. Ich habe auch in dem Pfad nachgeschaut und die Klassen befinden sich auch dort. Ein 
	
	
	
	





```
import sun.misc.*;
```
 hat natürlich auch keine Abhilfe geschaffen.

Hoffe jmnd hat die Lösung. Danke


----------



## tfa (1. Jan 2013)

Ganz einfach: Importiere diese Klassen nicht! Die gehören nicht zur veröffentlichten API und sollten nicht direkt verwendet werden.


----------



## AndyFFW (1. Jan 2013)

tfa hat gesagt.:


> Ganz einfach: Importiere diese Klassen nicht! Die gehören nicht zur veröffentlichten API und sollten nicht direkt verwendet werden.



Hm das macht die Sache natürlich kompliziert. Das Projekt ist nämlich ein Importierter Quellcode eines Open Source Programms. Also gibs keine andere Lösung?
Danke


----------



## tröööt (1. Jan 2013)

alles was man nicht auf Java Platform SE 7 gehört nicht zur offiziellen API sondern ist teil der jeweiligen propiertären implementierung des VM-entwicklers ...

das ist ein grundsatz in der java-entwicklung ... entwickler die dagegen "verstoßen" und dies dann so auch noch publizieren sollten sich nicht wundern wenn ihre user probleme bekommen ...

wenn also der verwendete code eine oracle VM einer bestimmten version verlangt musst du dieser verwenden um den code lauffähig zu bekommen ... oder du schreibst den code soweit um das er SE-konform ist ...

aus erfahrung kenne ich die beiden genannten klassen nur aus reflection-codes die irgendwas mit classloadern zu tun haben ... vieles davon kann man auch anders lösen ...

ansonsten wäre es , um dir zu helfen , auch sinnvoll wenn du mal linkst was du nutzen willst ...


----------



## maki (1. Jan 2013)

AndyFFW hat gesagt.:


> Hm das macht die Sache natürlich kompliziert. Das Projekt ist nämlich ein Importierter Quellcode eines Open Source Programms. Also gibs keine andere Lösung?


Das lässt sich in Eclipse abstellen oder zu einer Warnung machen:
[Eclipse] Access restriction: Class is not accessible due to restriction on required library @Digizol


----------



## AndyFFW (2. Jan 2013)

tröööt hat gesagt.:


> alles was man nicht auf Java Platform SE 7 gehört nicht zur offiziellen API sondern ist teil der jeweiligen propiertären implementierung des VM-entwicklers ...
> 
> das ist ein grundsatz in der java-entwicklung ... entwickler die dagegen "verstoßen" und dies dann so auch noch publizieren sollten sich nicht wundern wenn ihre user probleme bekommen ...
> 
> ...



Ah ok. Am liebsten wäre es mir auf SE umzucoden. Für die Klasse 
	
	
	
	





```
import sun.misc.URLClassPath;
```
 hab ich den ersatz 
	
	
	
	





```
import java.net.URLClassLoader;
```
 gefunden. Ehrlich gesagt hab ich nichts kontrolliert aber nach der Namensänderung hatte ich für das Objekt keine Fehler mehr aber für die Klasse 
	
	
	
	





```
import sun.misc.Resource;
```
 hab ich nichts auf die schnelle gefunden. Da ich gleich zur arbeit muss poste ich mal die gesamte Klassendatei


```
import java.io.IOException;
import java.lang.reflect.Field;
import java.net.URL;
import java.net.URLClassLoader;
import java.net.URLStreamHandlerFactory;
import java.nio.ByteBuffer;
import java.security.CodeSource;
import java.security.cert.Certificate;
import java.util.jar.Manifest;
import java.util.logging.Logger;
import sun.misc.Resource;
import java.net.URLClassLoader;//import sun.misc.URLClassPath;

/**
 * This class loader disables sealed package checking and certificate
 * checking. It requires access to two restricted sun.* packages however.
 * 
 * @author sk89q
 */
@SuppressWarnings("restriction")
public class RogueClassLoader extends URLClassLoader {
    
    private static final Logger logger = Logger.getLogger(RogueClassLoader.class.getCanonicalName());
    private URLClassLoader urlClassPath;

    public RogueClassLoader(URL[] urls, ClassLoader parent,
            URLStreamHandlerFactory factory) {
        super(urls, parent, factory);
        install();
    }

    public RogueClassLoader(URL[] urls, ClassLoader parent) {
        super(urls, parent);
        install();
    }

    public RogueClassLoader(URL[] urls) {
        super(urls);
        install();
    }
    
    private void install()  {
        try {
            Field field = URLClassLoader.class.getDeclaredField("ucp");
            field.setAccessible(true);
            this.urlClassPath = (URLClassLoader) field.get(this);
            //field.set(this, new RogueURLClassPath(urlClassPath.getURLs()));
        } catch (SecurityException e) {
            throw new RuntimeException("Failed to find 'ucp'", e);
        } catch (NoSuchFieldException e) {
            throw new RuntimeException("Failed to find 'ucp'", e);
        } catch (IllegalArgumentException e) {
            throw new RuntimeException("Failed to find 'ucp'", e);
        } catch (IllegalAccessException e) {
            throw new RuntimeException("Failed to find 'ucp'", e);
        }
    }

    @Override
    protected Class<?> findClass(final String name)
            throws ClassNotFoundException {
        String path = name.replace('.', '/').concat(".class");
        Resource res = urlClassPath.getResource(path, false);
        if (res != null) {
            try {
                return defineClass(name, res, true);
            } catch (IOException e) {
                throw new ClassNotFoundException(name, e);
            }
        } else {
            if (name.equals("BaseModMp")) {
                logger.info("(!!) Something requested ModLoaderMP, but you don't have it.");
            } else if (name.equals("BaseMod")) {
                logger.info("(!!) Something requested ModLoader, but you don't have it.");
            }
            throw new ClassNotFoundException(name);
        }
    }

    private Class<?> defineClass(String name, Resource res, boolean verify)
            throws IOException {
        int i = name.lastIndexOf('.');
        URL url = res.getCodeSourceURL();
        if (i != -1) {
            String pkgName = name.substring(0, i);
            Package pkg = getPackage(pkgName);
            Manifest manifest = res.getManifest();
            if (pkg == null) {
                if (manifest != null) {
                    definePackage(pkgName, manifest, url);
                } else {
                    definePackage(pkgName, null, null, null, null, null, null,
                            null);
                }
            }
        }
        ByteBuffer buffer = res.getByteBuffer();
        byte[] bytes = (buffer == null) ? res.getBytes() : null;
        CodeSource cs = new CodeSource(url, (Certificate[]) null);
        return (buffer != null ? defineClass(name, buffer, cs) : defineClass(name,
                bytes, 0, bytes.length, cs));
    }*/
    /*
    private class RogueURLClassPath extends URLClassPath {

        public RogueURLClassPath(URL[] urls, URLStreamHandlerFactory urlStreamHandlerFactory) {
            super(urls, urlStreamHandlerFactory);
        }

        public RogueURLClassPath(URL[] urls) {
            super(urls);
        }
        
        public Manifest getManifest() {
            return null;
            
        }
        
    }*/

}
```

Das ist die .java Datei nach der einen Änderung


----------



## AndyFFW (2. Jan 2013)

maki hat gesagt.:


> Das lässt sich in Eclipse abstellen oder zu einer Warnung machen:
> [Eclipse] Access restriction: Class is not accessible due to restriction on required library @Digizol



Hm danke nich die schönste Lösung aber ne schöne Notlösung.


----------



## tröööt (2. Jan 2013)

tja ... erfahrung zahlt sich aus ... wusste ich doch das es um classloader-manipulation geht ... dafür ist es mir einfach zu vertraut ...

auch war mir schon in zeile 18 klar worum es geht als ich den "namen" gelesen habe ... denn dieser ist in diesem umfeld einfach zu bekannt als das man es erst in zeile 71-74 rallt um was es hier eigentlich mal wieder geht ...

auch wenn ich es eigentlich aus prinzip ablehne HIER auf solche fragen zu antworten braucht man sich darüber das es einen solche code überhaupt gibt auch nicht zu wundern ...

wenn man halt bewusst das security-system von java aushebeln will muss man natürlich mit VM-abhängigen klassen arbeiten ... da führt kein weg dran vorbei ...

das sich eine IDE hier natürlich mit gewissen grundsätzen weigert ... eben weil man es NICHT machen sollte ... ist völlig verständlich und hier auch völlig korrekt ...
natürlich erzeugt der compiler selbst nur eine warning ... keinen error ... aber auch dieser weist darauf hin das man es nicht machen sollte ...



Spoiler: OT



[ot]auch wenn ich keinen bock habe mich HIER mit minecraft zu befassen von mir ein rat : viele lehnen "sk89q" als mod-entwickler eben wegen solcher codes grundsätzlich ab ... auch ist es nicht mehr wirklich zeitgemäß nur direkt für ModLoader/MP zu arbeiten ...
konzentriere die dich lieber auf Forge ... denn das ist die zukunft der MC-modding-community[/ot]


----------



## AndyFFW (2. Jan 2013)

tröööt hat gesagt.:


> tja ... erfahrung zahlt sich aus ... wusste ich doch das es um classloader-manipulation geht ... dafür ist es mir einfach zu vertraut ...
> 
> auch war mir schon in zeile 18 klar worum es geht als ich den "namen" gelesen habe ... denn dieser ist in diesem umfeld einfach zu bekannt als das man es erst in zeile 71-74 rallt um was es hier eigentlich mal wieder geht ...
> 
> ...



Sehr Interessant. Die Sache zieht hier so weite Kreise das ich doch mal mein vorhaben bekannt gebe bevor mich noch iwer in irgendwelche dunklen ecken schiebt...

Ich will für unseren Server (Mod-Server) einen Launcher machen. Und das erste problem was sich auftat: Wie schreibt man den Login. Darum hab ich mir einen Quellcode eines OpenSource Launcher gedownloadet um mir einen solchen Login anzugucken. Da der Launcher noch weitere "Nice-Features" hat wollt ich den in Eclipse zum Laufen bringen um mir anzugucken wie was realisiert wurde. Die Klassenabhängigkeiten machen es natürlich sehr schwierig letzteres zu bewerkstelligen


----------



## tröööt (3. Jan 2013)

ich setzt das ganze lieber mal ein einen ot-spoiler ...


Spoiler: OT



[ot]wenn es um das modding von minecraft geht muss meist eh "META-INF" gelöscht werden ... da package-sealing aber nur durch das manifest-attribut angegeben wird fällt es bei entfernen des manifestes eh weg ... wesshalb man keinen classloader-hack braucht ... was dann auch wieder konform mit der regel geht das man auf direkte zugriffe auf klassen in sun.* und com.sun.* verzichten sollte ...[/ot]


----------



## AndyFFW (3. Jan 2013)

tröööt hat gesagt.:


> ich setzt das ganze lieber mal ein einen ot-spoiler ...
> 
> 
> Spoiler: OT
> ...



Nein es geht nicht ums modifizieren von Minecraft sondern darum einen Launcher zu schreiben. Primär hab ich mir den Quellcode eines Launchers geholt um zu erfahren wie der Login geschrieben wird. Um den Launcher gut kapieren zu können will ich ihn in Eclipse lauffähig machen und am besten ohne fehler zu warnungen zu machen. Aber ich glaube das ist jetz die beste lösung


----------



## maki (3. Jan 2013)

AndyFFW hat gesagt.:


> Hm danke nich die schönste Lösung aber ne schöne Notlösung.


Kommt darauf an was du vorhast.

Willst du den Code so wie er ist zum laufen bringen: Die einzige Lösung
Willst du den Code umschreiben/refaktoren: Keine so gute Lösung


----------



## AndyFFW (3. Jan 2013)

maki hat gesagt.:


> Kommt darauf an was du vorhast.
> 
> Willst du den Code so wie er ist zum laufen bringen: Die einzige Lösung
> Willst du den Code umschreiben/refaktoren: Keine so gute Lösung



Ich will den Code als anschauungs beispiel^^ daher werd ichs so machen


----------



## tröööt (4. Jan 2013)

naja ... aber wie gesagt : bewusst java-mechaniken aushebeln ist ein absolutes NO-GO ...
da solltest du lieber wirklich einfach das package-sealing des minecraft.jar entfernen ... deutlich einfacher und die ganze kiste ist geklärt ...


----------



## AndyFFW (9. Jan 2013)

tröööt hat gesagt.:


> naja ... aber wie gesagt : bewusst java-mechaniken aushebeln ist ein absolutes NO-GO ...
> da solltest du lieber wirklich einfach das package-sealing des minecraft.jar entfernen ... deutlich einfacher und die ganze kiste ist geklärt ...





tröööt hat gesagt.:


> das package-sealing des minecraft.jar entfernen


was genau bedeutet das?


----------



## tröööt (9. Jan 2013)

kannst du ignorieren ... da ich nirgendswo package-sealing finde ... weder der launcher noch das eigentliche game ...

WRAUM dann also sk89q einen classlaoder schreibt der laut seiner doc das package-sealing umgehen soll weis ich nicht ... aber die meinung der community gegenüber diesem entwickler habe ich ja mal grob erwähnt ...

ich versteh das problem irgendwie immer noch nicht ...

du willst einen launcher schreiben ... dann guck dir an wie es andere machen und versuche bei solchen fehlern den code entsprechend umzuschreiben ...


----------



## AndyFFW (11. Jan 2013)

tröööt hat gesagt.:


> kannst du ignorieren ... da ich nirgendswo package-sealing finde ... weder der launcher noch das eigentliche game ...
> 
> WRAUM dann also sk89q einen classlaoder schreibt der laut seiner doc das package-sealing umgehen soll weis ich nicht ... aber die meinung der community gegenüber diesem entwickler habe ich ja mal grob erwähnt ...
> 
> ...





tröööt hat gesagt.:


> du willst einen launcher schreiben ... dann guck dir an wie es andere machen und versuche bei solchen fehlern den code entsprechend umzuschreiben ...



Genau das habe ich gemacht und genau deshalb kam ich auf das problem und genau deshalb ist dieser thread entstanden^^
aber ich habe meine vorgehensweise geändert und schreib komplett eigenen code da ich endlich auf informationen getroffen bin die ich benötigt habe. falls es jemanden interessiert: User:Oxguy3/Minecraft.net API - Minecraft Wiki

Dann noch ne andere frage zu dem thema: wie binde ich packages ein die nicht standardmäßig vorhanden sind? Die müssten ja in Java\lib\rt.jar reinkommen - bloß in welcher form? ordner mit enthaltenen klassen oder?


----------



## tröööt (11. Jan 2013)

HÄ ? was willst du mit "rt.jar" und extra packages ?

libs die du nutzen willst kommen in den classpath und gut is ... mehr dazu in der FAQ oder in der java-insel


----------



## AndyFFW (11. Jan 2013)

tröööt hat gesagt.:


> HÄ ? was willst du mit "rt.jar" und extra packages ?
> 
> libs die du nutzen willst kommen in den classpath und gut is ... mehr dazu in der FAQ oder in der java-insel



naja evtl erstellt man sich zB selber fertige klassen oder kriegt von woanders welche und man will sie nur mit import in seinem programm haben und die orginalen klassen liegen ja in der rt.jar - dort könnte man ja weitere hinzufügen


----------



## tröööt (12. Jan 2013)

AndyFFW hat gesagt.:


> naja evtl erstellt man sich zB selber fertige klassen oder kriegt von woanders welche und man will sie nur mit import in seinem programm haben und die orginalen klassen liegen ja in der rt.jar - dort könnte man ja weitere hinzufügen



*NEIN !* dafür gibt es den *CLASSPATH*

Klassenpfad ? Wikipedia
http://en.wikipedia.org/wiki/Classpath_(Java)
PATH and CLASSPATH (The Java™ Tutorials > Essential Classes > The Platform Environment)
Java ClassPath
http://www.java-forum.org/einfuehru...umgebungsvariable-einstellen-windows-7-a.html

sowie  : Let me google that for you

und ein ganz wichtiger tipp : FINGER WEG vom jdk/jre ordner .. damit kann man mehr kaputt machen als man denkt ... und das zu beheben ende bei den meisten in rätzel raten weil sie nicht klar ausdrücken können WAS sie getan haben ...


----------

