Ich habe Code zum Durchlaufen der Ergebnisse von classLoader.getResources ("META-INF / MANIFEST.MF"), um die Liste der Jars im Klassenpfad zurückzugeben. Dies hat von 1.6.0_18 bis 1.7.0_40 problemlos funktioniert. Jetzt unterbricht 1.7.0_45 dies, indem ein Popup mit Sicherheitswarnungen über gemischten signierten / nicht signierten Code angezeigt wird.

Kleiner, in sich geschlossener Testfall zur Demonstration des Problems:

package testcase;
import java.io.*;
import java.net.*;
import java.util.Enumeration;
import java.util.logging.*;
public class TestCase {
    public static void main(String[] args) {
        getAllJarUrls();
    }

    public static void getAllJarUrls() {
        try {
            final Enumeration<URL> mfUrls = Thread.currentThread().getContextClassLoader().getResources("META-INF/MANIFEST.MF");
            while (mfUrls.hasMoreElements()) {
                URL jarUrl = mfUrls.nextElement();
                if (!jarUrl.getProtocol().equals("jar")) {
                    continue;
                }
                try {
                    System.out.println(jarUrl.toURI());
                } catch (URISyntaxException ex) {
                    Logger.getLogger("testcase").log(Level.SEVERE, null, ex);
                }
            }
        } catch (IOException e) {
            Logger.getLogger("testcase").log(Level.SEVERE, null, e);
        }
    }
}

Starten Sie dies mit einem jnlp (jar signiert mit einem gültigen Zertifikat) als:

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://localhost/test" href="test.jnlp">
    <information>
        <title>test</title>
        <vendor>test</vendor>
      </information>
    <security><all-permissions/></security>
    <resources>
        <jar href="testcase.jar" main="true" download="eager"/>
    </resources>
    <application-desc main-class="testcase.TestCase"/>
</jnlp>

Lassen Sie die Konsole beim Ausführen sichtbar und drücken Sie '5', um eine ausführliche Ausgabe zu erhalten. Klicken Sie anschließend in der Sicherheitsabfrage auf "Blockieren", um die Ausnahme anzuzeigen. Wenn Sie auf Zulassen klicken, wird der Code normal ausgeführt.Dies ist jedoch keine akzeptable Benutzererfahrung. Zumal unsere Anwendung ohne Benutzereingabe starten können muss.

Die Ausgabe unter 1.7.0_45 lautet wie folgt:

CacheEntry[http://localhost/test/testcase.jar]: updateAvailable=true,lastModified=Tue Oct 15 21:09:21 CDT 2013,length=6314
jar:file:/C:/jre32/1.7.0_45/lib/javaws.jar!/META-INF/MANIFEST.MF
jar:file:/C:/jre32/1.7.0_45/lib/deploy.jar!/META-INF/MANIFEST.MF
jar:file:/C:/jre32/1.7.0_45/lib/plugin.jar!/META-INF/MANIFEST.MF
jar:file:/C:/jre32/1.7.0_45/lib/deploy.jar!/META-INF/MANIFEST.MF
Trace level set to 5: all ... completed.Trace level set to 5: all ... completed.
security: resource name "META-INF/MANIFEST.MF" in http://localhost/test/testcase.jar : java.lang.SecurityException: trusted loader attempted to load sandboxed resource from http://localhost/test/testcase.jar

Die testcase.jar ist signiert. Es sind sogar alle neuen Manifestattribute enthalten: Anwendungsname: Testfall Berechtigungen: Alle Berechtigungen Codebasis: *

Ein Unterschied des dekompilierten CPCallBackHandlers von deploy.jar von 7u40 auf 7u45 zeigt signifikante Änderungen. Es sieht so aus, als hätten die Änderungen für LiveConnect die vorhandene Funktionalität beeinträchtigt. Und nein, hier ist kein LiveConnect beteiligt.

Ist noch jemand darauf gestoßen? Vorschläge für eine Problemumgehung? Fehler melden?

(Anmerkung: auch in den OTN Java-Foren gepostet, aber ich hoffe auf eine schnellere Antwort hier :).

Danke, Chris