Eu tenho código para iterar sobre os resultados de classLoader.getResources ("META-INF / MANIFEST.MF") para retornar a lista de jars no caminho de classe. Isso funcionou bem de 1.6.0_18 até 1.7.0_40. Agora 1.7.0_45 quebra isso, mostrando um pop-up de aviso de segurança sobre código misto assinado / não assinado.

Pequeno testcase independente para demonstrar o problema:

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);
        }
    }
}

Lançar isto com um jnlp (jar assinado com um certificado válido) como:

<?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>

Quando executar, tenha o console visível e pressione '5' para saída detalhada. em seguida, clique em 'bloquear' no aviso de segurança para ver a exceção. Clicar em permitir permitirá que o código seja executado normalmentemas esta não é uma experiência de usuário aceitável. especialmente desde que nosso aplicativo tem que ser capaz de iniciar sem entrada do usuário.

A saída sob 1.7.0_45 é a seguinte:

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

O testcase.jar é assinado. Ele ainda tem todos os novos atributos de manifesto incluídos: Nome do aplicativo: testcase Permissões: todas as permissões Codebase: *

Um diff do CPCallBackHandler descompilado do deploy.jar de 7u40 para 7u45 mostra mudanças significativas. Parece que as alterações para o LiveConnect borked a funcionalidade existente. E não, não há LiveConnect envolvido aqui.

Alguém mais caiu nessa? Sugestões para uma solução alternativa? Arquivar um bug?

(nota: também postada nos fóruns de java do OTN, mas estou esperando por uma resposta mais rápida aqui :).

Obrigado, chris