Blocco OSX JNLP Avvia Java1.8U40 - Qualcuno sa perché?

Distribuiamo la nostra applicazione come file di avvio JNLP e/o come applet per pagine Web.Blocco OSX JNLP Avvia Java1.8U40 - Qualcuno sa perché?

Ho un cliente che ha aggiornato il suo sistema MAC OSX all'ultima versione Java 1.8_40. Dopo l'aggiornamento, il lancio di JNLP ha smesso di funzionare. Sembra avviare Java (lampeggia il logo java blu) e poi si ferma. Nessuna eccezione viene lanciata. Sospetto ancora un altro ostacolo alla sicurezza OSX.

Abbiamo regolato le sue impostazioni di sicurezza OSX per fidarci della nostra applicazione.
Abbiamo regolato la sua sicurezza Java per fidarci del nostro sito.
Abbiamo anche regolato le preferenze di Safari per consentire all'applicazione di funzionare senza restrizioni ("modalità non sicura").
L'applicazione è firmata con un certificato di firma del codice.
Il cliente può utilizzare il metodo di lancio dell'applet utilizzando il plug-in Java Safari.
Tutti gli altri clienti (OSX & Windows) sono generalmente soddisfacenti. Se si tratta di un nuovo problema MAC Java, vorrei anticiparlo.

Qualcun altro là fuori lo vede? Eventuali indizi su ciò che sta causando il problema?

fonte

2015-03-04 Punisher

@AndrewThompson Quali applet? Questo sembra riguardare il webstart. –

@ MaartenBodewes Oh, mio male. BTW - Qualcosa potrebbe essere sia un'applet *** che *** lanciata da JWS, anche se sembra che * non * sia il caso qui. –

Sì, supportiamo il lancio come applet e come lancio JWS .jnlp. Questo ci dà alternative nei casi in cui un metodo non funziona. – Punisher

La nostra ipotesi è che la causa di this bug sia stata trasferita a 8u40. Scopriamo che l'applicazione non può essere messa a fuoco quando viene visualizzata la nuova schermata iniziale blu Java. Possiamo anche riprodurlo su tutte le app demo webstart sul proprio sito Oracle, quindi non è il nostro codice.

È possibile confermare questo errore eseguendo l'istanza webstart con -Xnosplash per saltare la schermata iniziale. Sfortunatamente non è possibile aggiungere quel parametro al file jnlp.

Possiamo solo riprodurre questo problema su OSX 10.10 (Yosemite).

Una soluzione alternativa (se è possibile controllare le impostazioni Java del client) è aggiungere "-Xdebug" nel Pannello di controllo Java -> Java -> Visualizza ... -> Parametri di runtime.

Aggiornamento: il bug è stato corretto e backported to 1.8u40. Oracle ha anche aggiornato silenziosamente i propri download alla nuova build (1.8u40b27) come può essere seen here Non so che le persone che già utilizzano 1.8u40 riceveranno automaticamente un aggiornamento.

fonte

2015-03-06 01:12:36

Ari che sembra azzeccato con la mia esperienza. Anche se potrei provare a ottenere -Xnosplash nel mio file JNLP per vedere se questo aiuta. Complimenti a te. – Punisher

Ok dopo alcuni tentativi e la ricerca che passa in "-noSplash" ha eliminato Java Splash. Non ho ancora provato con il cliente. Aggiornerà la prossima settimana. – Punisher

@Punisher purtroppo non mi ha aiutato. Ho provato sia il tuo approccio a java-vm-args, sia inserendo -nosplash.Nessun problema risolto nella mia app. –

Quando aggiungo '-Xdebug' nel Pannello di controllo Java come parametro di runtime, funziona per me.

fonte

2015-03-06 16:14:16 Guenze

Confermo che -Xdebug è una buona soluzione quando viene inserito nel Pannello di controllo Java -> Java -> Visualizza ... - > Parametri di runtime, ma ovviamente non possiamo controllarlo dal server, quindi non è una buona soluzione a lungo termine. –

Blocco OSX JNLP Avvia Java1.8U40 - Qualcuno sa perché?

risposta

Problemi correlati