Problemi e limitazioni noti

Problemi noti o limitazioni che potresti riscontrare in determinati ambienti di sistema o configurazioni.

Alcuni dei problemi qui descritti potrebbero non costituire dei limiti della versione, poiché vengono fornite istruzioni per aggirarli, ove possibile.

Novità di questa versione

__MAP_64 il flag non è supportato
Java 25 su z/OS non abilita il __MAP_64 flag per le operazioni di mappatura della memoria. Di conseguenza, non è in grado di mappare in modo affidabile file di grandi dimensioni (≥ 2 GB) in intervalli di indirizzi altamente contigui. Per ulteriori dettagli su questo comportamento, consultare mmap() — Mappatura delle pagine di memoria. A causa di questa limitazione, le operazioni che richiedono la mappatura di più di Integer.MAX_VALUE byte e che materializzano oggetti Java sono destinate a fallire.

Ad esempio, MemorySegment.getString(long) è soggetto ai limiti di dimensione imposti dal tipo int di Java. Se si chiama getString(100) su un segmento di memoria la cui dimensione mappata è size(long) Integer.MAX_VALUE + 100, l'operazione potrebbe fallire con IllegalArgumentException o IndexOutOfBoundsException. Si tratta di un comportamento previsto.

Impatto : questo problema riguarda le applicazioni che utilizzano l'API Foreign Function & Memory o FileChannel.map() altre operazioni su file mappati in memoria che superano il Integer.MAX_VALUE limite. A causa di questi vincoli, le operazioni di mappatura della memoria sono di fatto limitate a circa 1.5 GB – 2 GB, a seconda della configurazione del sistema (in particolare, il MAXASHARE parametro in BPXPRMxx ).

Soluzione alternativa: suddividere i file di grandi dimensioni in parti più piccole (ciascuna di dimensioni inferiori a 2 GB) e mapparli separatamente, anziché caricare l'intero file in memoria come un unico oggetto Java. In alternativa, utilizzare le tradizionali operazioni di I/O sui file invece della mappatura in memoria.

Requisiti di sistema: assicurarsi che i parametri di sistema z/OSMAXASHARE e MAXMMAPAREA siano configurati in modo da supportare almeno un intervallo indirizzabile di 2 GB. Contatta l'amministratore di sistema per verificare e modificare queste impostazioni, se necessario.

L'analisi dei certificati non è supportata in modalità COMPAT con la codifica EBCDIC ( IBM‑1047 )
In Java 25 su z/OS, l'analisi dei certificati X.509 richiede un input codificato UTF‑8. L'analisi del certificato non va a buon fine quando si esegue il programma in modalità COMPAT o FIPS con codific IBM‑1047 a (EBCDIC). A livello interno, il X509Factory.parseX509orPKCS7Cert() metodo (utilizzato da CertificateFactory) applica l' UTF‑8 come parte della logica di rilevamento della codifica post-JEP 400. Di conseguenza, i dati dei certificati codificati utilizzando l' IBM‑1047 e non possono essere analizzati e ciò comporta CertificateException: No certificate data found.
Configurazione supportata:
  • Modalità predefinita di Java 25 ( UTF‑8 )
Configurazioni non supportate:
  • Modalità Java 25 COMPAT ( IBM‑1047 )
Questo comportamento è conforme alle specifiche e riflette le modifiche alla codifica della piattaforma introdotte dai seguenti JEP.
  • JEP 400 : " UTF‑8 " come impostazione predefinita
  • JEP 470 (Anteprima) : Miglioramento del rilevamento della codifica e del comportamento di elaborazione
z/OS limite relativo alla data e all'ora del file
In « z/OS », i valori di data e ora dei file forniti dal sistema operativo hanno una risoluzione solo al secondo. Di conseguenza, le seguenti API restituiscono o aggiornano i timestamp con una precisione al secondo, indipendentemente dai valori in millisecondi forniti:
  • File.setLastModified()
  • File.lastModified()
  • ZipEntry.setTime()
  • ZipEntry.getTime()
Nota: questa limitazione è intrinseca alla piattaforma z/OS ed era già presente nelle versioni precedenti. Le applicazioni che richiedono timestamp con una precisione al millisecondo su z/OS dovrebbero implementare meccanismi di temporizzazione alternativi.
Ridotti i limiti di dimensione delle entità JAXP
A partire da Java 24, i limiti di sicurezza JAXP sono stati ridotti (ad esempio, jdk.xml.totalEntitySizeLimit da 50.000.000 a 100.000), il che potrebbe causare errori di elaborazione XML nelle applicazioni che gestiscono documenti XML di grandi dimensioni. Per ulteriori informazioni sulle modifiche e sulle opzioni di mitigazione, consultare la sezione "Migrazione dalle versioni precedenti".

Elementi delle versioni precedenti che sono ancora validi

La funzione "Prospettiva della memoria nativa" nello strumento Health Center non funziona

Il Total Physical Memory campo nella tabella Native memory table è vuoto. Il campo viene compilato sulla base dei dati recuperati dall'API getTotalPhysicalMemorySize, che è ormai obsoleta. L'impossibilità di recuperare i dati dalla memoria fisica provoca la generazione di un messaggio di eccezione com.ibm.lang.management.OperatingSystemMXBean.getTotalPhysicalMemory() nel flusso di output stdout standard ogni 5 secondi (intervallo di lettura della memoria). Il problema è in fase di risoluzione e verrà risolto in una versione futura di Java 21. Fino ad allora, come soluzione alternativa, imposta l'opzione « JVM » -Dcom.ibm.diagnostics.healthcenter.data.memory su off«», in modo da disabilitare la raccolta dei dati relativi alla memoria nell'Health Center.

Problema con il comando `keytool` di Java 21
Quando si utilizza lo strumento zseckeytool -exportcert, si consiglia di utilizzare -file l'opzione insieme a un nome di file. Ciò contribuisce a garantire che il certificato esportato sia privo di tag e codificato in formato « DER ». Per preservare la codifica « DER », è fondamentale che il file rimanga senza tag ed evitare di convertirlo involontariamente in un formato diverso.

Se preferisci l' PEM, puoi utilizzare -rfc l'opzione insieme -file all'opzione. Il certificato esportato PEM è codificato in formato ISO8859-1. Per leggere il file, utilizzare il comando chtag -tc ISO8859-1 per contrassegnare il certificato e impostare le variabili d'ambiente appropriate per la conversione automatica di z/OS.

Per i file di certificati in formato DER, si consiglia di utilizzare keytool di Java 17 o versioni precedenti per la stampa. In Java 21 è presente un keytool problema noto per cui alcune informazioni potrebbero non essere stampate correttamente.

Quando si stampano i file dei certificati in formato « PEM », è possibile avvalersi anche dello OpenSSL strumento per ricevere assistenza.

In sintesi, prestate attenzione alle opzioni di codifica e di etichettatura quando utilizzate lo zseckeytool -exportcert strumento, per garantire una stampa accurata e coerente del certificato.

Limiti delle applicazioni che utilizzano le API Foreign Function e Memory

Quando il codice Java chiamato da una funzione esterna genera un'eccezione, l'applicazione potrebbe chiudersi in modo imprevisto.

La classe non java.awt.Robot è supportata
La java.awt.Robot classe non è supportata sui sistemi z/OS. I programmi Java che utilizzano la classe Robot potrebbero non funzionare correttamente sui sistemi d z/OS.
jlink Lo strumento cerca di impostare l'attributo "APF-authorized" su libj9ifa29.so per soddisfare i requisiti di idoneità di zIIP
Quando si utilizza lo jlink strumento per creare un'immagine di runtime nativa, lo strumento tenta di impostare l'attributo "APF-authorized" sulla libj9ifa29.so libreria per garantire che l'applicazione Java rimanga idonea all'elaborazione da parte del System z Integrated Information Processor di IBM ( zIIP ). Se non si dispone dell'autorizzazione necessaria per eseguire l'operazione APF, viene visualizzato un messaggio di avviso:
Warning: APF authorization failed for lib/default/libj9ifa29.so
Per informazioni sui permessi necessari per impostare l'attributo "APF-authorized", consultare la documentazione relativa alla propria versione di z/OS. Ad esempio, gestire chi può impostare l'attributo "Autorizzato da APF".
Limitazione della lunghezza del percorso di classe

Se il percorso delle classi supera i 2031 caratteri, la shell lo tronca a 2031 caratteri. Se hai bisogno di un percorso di classe più lungo di 2031 caratteri, utilizza un file di opzioni. Per ulteriori dettagli, consultare @argfile nella sezione dedicata al comando java.

I messaggi generati tramite `stout` o `stderr` potrebbero non essere reindirizzati quando freopen() si utilizza
I messaggi che l' JVM e scrive su stdout o stderr potrebbero non essere reindirizzati al nuovo file se l'applicazione Java™ utilizza la funzione freopen() C/C++ per reindirizzare stdout o stderr i flussi da un file di un tipo a quello di un altro. Per risolvere questo problema, imposta la proprietà com.ibm.writeToStandardOutputsUsingStreams di sistema su true all'avvio di JVM Questa proprietà specifica che l'output viene scritto utilizzando flussi di file, che supportano il reindirizzamento dei dati tra i set di dati di MVS e i file del file system Z di Unified Storage Server (USS) ( zFS ).
Nota: questa impostazione modifica anche il comportamento predefinito del buffering da no buffering a line buffering, e l'output potrebbe non essere generato immediatamente. Per risolvere questo problema, disattiva il buffering utilizzando le funzioni setbuf() setvbuf() o dopo aver chiamato la freopen() funzione.

Altre questioni

Se riscontri un problema che non riesci a risolvere, consulta la sezione "Risoluzione dei problemi dell'SDK Java" per consigli e informazioni su come segnalare il problema.