Temurin-build: Comment mettre à jour les données de fuseau horaire avec AdoptOpenJDK

Cela se produit-il avec un binaire Adopt en dehors de Docker? Quel message d'erreur voyez-vous?

Oui, je suis capable de recréer ce problème sur ma machine en dehors de docker, la sortie de la commande (avec l'indicateur de verbosité activé) est la suivante:

$ java -jar resources/tzupdater.jar --location --force -v
Using https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz as source for tzdata bundle.
java.home: /Library/Java/JavaVirtualMachines/adoptopenjdk-12.jdk/Contents/Home
java.vendor: AdoptOpenJDK
java.version: 12
tzupdater version 2.2.0-b01
JRE tzdata version: tzdata2018g
Downloaded file to /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/tz.tmp/tzdata.tar.gz
java.lang.NullPointerException
Exception in thread "main" com.sun.tools.tzupdater.TzRuntimeException: java.lang.NullPointerException
    at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:653)
Caused by: java.lang.NullPointerException
    at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:215)
    at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:634)

Je ne sais pas pourquoi il prend ma version Java comme étant 12 comme:

$ java -version
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.2+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.2+9, mixed mode)
$ echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home

@keirlawson Ah, on dirait que vous utilisez un Mac. Apple dispose d'un outil interne spécial qui définit le JAVA_HOME par défaut, etc.

J'utilise un script shell pour permuter entre eux:

# List all of the Java's that are available
alias java_ls='/usr/libexec/java_home -V 2>&1 | grep -E "\d.\d.\d[,_]" | cut -d , -f 1 | colrm 1 4 | grep -v Home'

# Swap between Java's
function use_java() {
    export JAVA_HOME=$(/usr/libexec/java_home -v $1)
    export PATH=$JAVA_HOME/bin:$PATH
    java -version
}

Mais oui, le NPE est ennuyeux - nous devrons creuser là-dedans - pas un problème de docker alors je vais changer cela.

En creusant un peu là-dedans, j'ai découvert deux choses à noter;

Oracle TZ Updater a les informations suivantes sur sa page de téléchargement;

Configuration requise

L'outil TZUpdater prend en charge toutes les versions actuellement prises en charge d'Oracle JDK et JRE, sur toutes les plates-formes prises en charge. La valeur de la propriété java.vendor doit être Sun Microsystems Inc. ou Oracle Corporation ou BEA Systems, Inc.

Ce qui me fait penser que cela ne fonctionnera pas de toute façon.

Il existe également un autre outil d'Azul Systems (disponible sur https://www.azul.com/products/open-source-tools/ziupdater-time-zone-tool/), qui est publié sous GPLv2 mais ne s'exécute pas sous jdk11 avec un texte de [ziupdater]unsupported Java version 11.0.3 .

Si je ne manque aucune information, je pense que nous devons discuter de nos options ici.

Intéressant - avons-nous accès à la source Azuls? Espérons que nous pourrons fork / patch
que pour travailler avec Adopt

Le samedi 27 avril 2019 à 12h13, Ali Ince [email protected] a écrit:

En creusant un peu là-dedans, j'ai découvert deux choses à noter;

Oracle TZ Updater a les informations suivantes sur sa page de téléchargement;

Configuration requise

L'outil TZUpdater prend en charge toutes les versions actuellement prises en charge de Oracle
JDK et JRE, sur toutes les plates-formes prises en charge. La valeur de la propriété java.vendor
doit être Sun Microsystems Inc. ou Oracle Corporation ou BEA Systems, Inc.

Ce qui me fait penser que cela ne fonctionnera pas de toute façon.

Il y a aussi un autre outil d'Azul Systems, qui est publié sous GPLv2
mais ne parvient pas à s'exécuter sous jdk11 avec un texte de version non prise en charge.

Si je ne manque aucune information, je pense que nous devons discuter de nos options
ici.

-
Vous recevez ceci parce que vous êtes abonné à ce fil de discussion.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/AdoptOpenJDK/openjdk-build/issues/1057#issuecomment-487277125 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AABME2D2GVKBSNWHNGDOXOLPSQYNFANCNFSM4HIV2ISA
.

>

Cheers, Martijn (Envoyé de Gmail Mobile)

Oui, j'ai trouvé celui d'Azul, mais je n'ai trouvé la source nulle part bien qu'il soit censé être open source. Peut-être que si quelqu'un a un contact chez Azul, il pourra peut-être le lui retirer?

Je ne sais toujours pas si ZIUpdater d'Azul est publié avec le code source ou non, car il contient cette information en bas de la page que j'ai liée auparavant.

Veuillez nous envoyer vos questions / problèmes / demandes d'instantanés source à [email protected]

Mais théoriquement, nous pouvons demander les codes sources. Avons-nous des contacts chez Azul @karianna?

Oui, je vais leur envoyer un ping maintenant.

Il semble qu'OpenJDK dispose déjà d'un utilitaire pour résoudre une partie du problème, bien qu'il ne soit pas largement diffusé: https://github.com/akashche/tzdbgen

IBM a un TZUpdater. Parlé brièvement à Tim sur les options pour l'open source. Nous enquêtons.

Azul en discute également

Bonjour, y a-t-il du nouveau à propos de ce problème?

Merci

@SueChaplain Des nouvelles de votre part? Je chasserai officiellement Azul.

Avoir envoyé une demande formelle à Azul

J'ai aussi essayé l'autre outil proposé par @keirlawso. J'utilise adoptopenjdk 12 et cela semble fonctionner mais on ne sait pas comment transmettre les fichiers tz supplémentaires liés à la version openjdk. Ainsi, l'outil n'utilise que les fichiers standard, il a donc une documentation ou des fonctionnalités incomplètes. J'ai également ouvert un problème github pour cet outil.

@karianna - discussions toujours en cours ici pour confirmer l'originalité du code. Sera prod.

J'espère qu'un tzupdater sera bientôt disponible, nous avons une plate-forme cloud de fuseau horaire critique, avec des paiements et des factures, le fuseau horaire est une partie vitale de nos microservices.

Juste pour informer la communauté:
Azul tzupdater fonctionne uniquement avec adoptopenjdk 8.
Je l'ai essayé avec nos conteneurs docker avec le dernier iana db: 2019a avec cette version:

https://web.cs.ucla.edu/~eggert/tz/release

Les bases de données officielles de l'IANA tar.gz contiennent des bogues, nous utilisons donc celui-ci.
Donc pour l'instant, pour résoudre ce problème, nous devons rétrograder vers java 8. (le fuseau horaire est plus important que la version java elle-même dans notre cas).

Peut-être qu'Azul peut vérifier la prise en charge de java 11 et 12, afin que l'outil puisse fonctionner correctement avec adoptopenjdk, sans faire de gros changements ou écraser beaucoup de code.

Il semble qu'OpenJDK dispose déjà d'un utilitaire pour résoudre une partie du problème, bien qu'il ne soit pas largement diffusé: https://github.com/akashche/tzdbgen

voir aussi: ZoneRulesBuilder.java dans le chemin /make/src/classes/build/tools/tzdb/ de jdk8

Existe-t-il des mises à jour sur les solutions Azul ou IBM?

@karianna - discussions toujours en cours ici pour confirmer l'originalité du code. Sera prod.

Salut Sue,

Avez-vous eu plus de chance?

Cela semble fonctionner sur zulu, openjdk et corretto (ou du moins il ne lance pas, n'a pas testé les dates, ni les fuseaux horaires).

https://bell-sw.com/pages/iana-updater/

Il utilise cependant le format «arrière-garde»; vous devez donc créer vous-même le tzdata.tar.gz.

git clone https://github.com/eggert/tz
git checkout 2019b
make tarballs

java -jar IANAUpdater.jar -t ${JAVA_HOME} -z  tzdata2019b-rearguard.tar.tz

La dernière version d'oracle tzupdater fonctionne avec openjdk, mais pas avec zulu ni corretto.
https://github.com/akashche/tzdbgen semble abandonné, et ça jette.
ziupdater d'azul jette également.
Mais copier / coller build.tools.tzdb de java.net/openjdk dans un projet semble fonctionner.

Tous les java "tz-parser" utilisent le format "Rearguard". Mais l'IANA ne publie que le format «avant-garde».

@paulocesarcuneo

Veuillez exécuter make rearguard_tarballs au lieu de make dans le dossier tzdb-xxx (IANA Time Zone Database Complete Distribution) pour générer une entrée valide pour tzdbgen , TZUpdater ou IANAUpdater

@karianna - @ andrew-m-leonard et son équipe ont jeté un coup d'œil et peuvent vous dire comment cela se passe.

Salut Sue,

Avez-vous eu plus de chance?

IBM Timezone Updater ne prend actuellement en charge que les mises à jour apportées à IBM Java 1.4.2, 5.0, 6, 7 et 8. Il ne prend pas en charge les mises à jour apportées à OpenJDK8 ou OpenJDK9 + (pour les variantes Hotspot ou OpenJ9). Nous étudions actuellement ce qui doit être fait pour que le programme de mise à jour du fuseau horaire fonctionne avec ces versions. Vous tiendrons au courant de l'avancement de ce travail.

Salut, il semble que le jar Azul ziupdater version 1.0.2.2 semble maintenant mettre à jour correctement les données de fuseau horaire, lors de l'utilisation d'un fichier de fuseau horaire 2019b formaté par l'arrière, avec Java 11

@djphillyp Le programme de mise à jour Azul fonctionne-t-il également pour jdk8?

Lisez simplement la doc! il prend en charge jdk8 :-)

@karianna Comme Azul a déjà un programme de mise à jour de fuseau horaire disponible publiquement qui fonctionne avec Java 11, y a-t-il une raison d'utiliser IBM Timezone Updater? La seule fonction de l'outil IBM qui ne figure pas dans le package Azul est la possibilité de mettre à jour un ensemble d'installations Java sur un disque dur à partir d'un fichier de paramètres et éventuellement de générer le fichier de paramètres à l'aide d'un ensemble de critères d'inclusion / exclusion.

Pour tous ceux qui souhaitent une version ultérieure du format «arrière-garde», vous pouvez créer le vôtre. Voir https://stackoverflow.com/questions/56908541/update-to-tzdata2019b-is-failing-tzupdater-version-2-2-0-b01

@karianna Comme Azul a déjà un programme de mise à jour de fuseau horaire disponible publiquement qui fonctionne avec Java 11, y a-t-il une raison d'utiliser IBM Timezone Updater? La seule fonction de l'outil IBM qui ne figure pas dans le package Azul est la possibilité de mettre à jour un ensemble d'installations Java sur un disque dur à partir d'un fichier de paramètres et éventuellement de générer le fichier de paramètres à l'aide d'un ensemble de critères d'inclusion / exclusion.

Je n'étais pas au courant que cela était accessible au public? J'ai dû leur demander manuellement le code source ...

Binaire accessible au public. Avons-nous besoin de la source?

Binaire accessible au public. Avons-nous besoin de la source?

Oui, nous avons besoin de la source :-) - Adoptez la politique de ne pas avoir de builds mystérieux.

Je me trompe peut-être, mais ce code ne pourrait-il pas être enveloppé pour fournir la fonctionnalité?

https://github.com/openjdk/jdk/tree/0c3f9c6012a5878bc9275a5abad6b3d044a30ba7/make/jdk/src/classes/build/tools/tzdb

J'ai également remarqué qu'il y avait un engagement récent à cela pour supporter le format "vanguard", ce qui simplifierait les choses aussi car les fichiers publiés par l'IANA pourraient être réutilisés directement!

@paulocesarcuneo

Veuillez exécuter make rearguard_tarballs au lieu de make dans le dossier tzdb-xxx (IANA Time Zone Database Complete Distribution) pour générer une entrée valide pour tzdbgen , TZUpdater ou IANAUpdater

Résultat:

make: * Aucune règle pour faire des cibles 'Rearguard_tarballs'. Arrêter.

@paulocesarcuneo
Résultat:
make: * Aucune règle pour faire des cibles 'Rearguard_tarballs'. Arrêter.

assurez-vous d'avoir téléchargé l'ensemble complet avec les sources. Next vient de travailler pour moi:

wget https://data.iana.org/time-zones/releases/tzdb-2019b.tar.lz
lzip -d tzdb-2019b.tar.lz
tar xf tzdb-2019b.tar
cd tzdb-2019b /
faire backguard_tarballs

@paulocesarcuneo
Résultat:
make: * Aucune règle pour faire des cibles 'Rearguard_tarballs'. Arrêter.

assurez-vous d'avoir téléchargé l'ensemble complet avec les sources. Next vient de travailler pour moi:

wget https://data.iana.org/time-zones/releases/tzdb-2019b.tar.lz
lzip -d tzdb-2019b.tar.lz
tar xf tzdb-2019b.tar
cd tzdb-2019b /
faire backguard_tarballs

Même erreur. :(

@paulocesarcuneo alors quelque chose est différent avec votre environnement. Essayez docker run ubuntu

@paulocesarcuneo @sgrinev Mon problème est Ubuntu 16.04, solution:

make AWK=gawk rearguard_tarballs

java -Djava.vendor="Oracle Corporation" -verbose:class -jar "${PWD}/tzupdater.jar" -v -l "file://${PWD}/${RGTZ}"

pour info, https://github.com/AdoptOpenJDK/TSC/issues/123

De cette façon, j'ai résolu mon problème:

sudo java -Djava.vendor="Oracle Corporation" -jar "${PWD}/tzupdater.jar" -l

une mise à jour ici?

Aujourd'hui, il a encore cassé les systèmes tzupdater d'Oracle à la version 2.3.1 n'aime pas cette nouvelle version de 2020b et échoue

https://stackoverflow.com/questions/64254417/tzupdate-failures-with-2020b

Peut-être que c'est le bon moment pour y arriver

@JigarJoshi Il semble qu'Oracle ait publié la version 2.3.2, qui étant donné que le bogue a maintenant été marqué comme résolu, j'espère qu'il corrige ce problème.

@keirlawson pouvez-vous également essayer?

@ andrew-m-leonard oui le problème est résolu avec 2.3.2.

Pensez-vous que c'est toujours une bonne idée d'ajouter la version OpenJDK de l'outil de mise à jour du fuseau horaire?

Pensez-vous que c'est toujours une bonne idée d'ajouter la version OpenJDK de l'outil de mise à jour du fuseau horaire?

Ce serait génial - je pense que la meilleure chose à faire serait de demander très poliment à Oracle s'il y réfléchirait.