Nous avons une application utilitaire simple qui lit toutes les données du fuseau horaire utilisé dans une JRE et l'affiche tout dans une table simple. Nous devons utiliser une version plus ancienne du JRE (6_24) pour une version de produit à venir (en raison d'autres problèmes apparemment), mais nous devons également inclure des mises à jour de fuseaux de temps plus récentes dans cette version (qui serait autrement incluse, disons, 6_29 ). Nous emballons déjà un JRE privé qui sera installé, d'obtenir des mises à jour du fuseau horaire dans ce JRE privé à l'aide du TZUPDater Tool n'est pas le problème - le problème est la lecture / la vérification de la version du tzdata (par exemple, tzdata2010o, tzdata2011k) est en cours de lecture avec l'application utilitaire (c'est-à-dire quelle version est utilisée dans le JRE L'application est en cours d'exécution) . L'application affiche actuellement la version jre dans la barre de titre, mais avec les mises à jour du fuseau horaire, cela ne suffit plus pour déterminer quelle version la version est utilisée.
5 Réponses :
Dans l'un de mes JRES, il y a un fichier dans Je vais chercher une manière moindre pirate, mettra à jour la réponse si je trouve quelque chose.
mise à jour:
Semble qu'il n'y a pas d'API pour obtenir ces données. Cependant, le code dans la classe jre_path \ lib \ zi nommé ZoneInfomapings . Dans la première ligne, il affiche les données que vous recherchez.
sun.util.calendar.zoneInfofile montre comment analyser.
Ouais, c'est le dossier qui est remplacé par Tzupdater et j'ai remarqué (après avoir posté la question (après avoir posté la question) que ZoneInfomapings contient cette ligne, mais NotePad ++ affiche d'autres données / caractères qui l'entouraient dans cette première ligne qui m'a fait penser que cela nécessiterait un piraté Des trucs pour y arriver ..., espérons-le, il y a une meilleure façon de vous y rendre à partir de la JRE ou que quelqu'un pourrait poster du code pour lire ce fichier / ligne ...
Code utilisé ici comme exemple pour analyser cette sortie: Docjar .com / html / API / Sun / Util / Calendrier / ZoneInfofile.java.html
Si vous utilisez Linux, vous pouvez le faire à partir de la ligne de commande: Cordes ZoneInfomappings | tête -2
Dans Java 8, vous pouvez utiliser zonerulesprovider.geversions ("utc") .
@Andreas Veuillez poster votre commentaire comme une réponse séparée. Important et distinct des autres réponses.
Voici une chose pirate qui a fonctionné pour moi dans IBM et Oracle Jres:
public static void main(String args[]) throws Exception {
File f = new File(System.getProperty("java.home") + File.separator + "lib" + File.separator + "zi" + File.separator + "ZoneInfoMappings");
if (f.exists()) {
FileInputStream fis = new FileInputStream(f);
byte[] buf = new byte[11];
try {
fis.skip(11);
fis.read(buf);
System.out.print("Olson Database version is ");
System.out.println(new String(buf));
} finally {
fis.close();
}
}
}
zonerulesProvider.geversions code> en Java 8, vous pouvez utiliser zonerulesprovider.geversions (" utc ") code> : p>
La signification et le format exact de la version sont spécifiques au fournisseur. La version doit suivre l'ordre lexicographique, la carte renvoyée sera donc commandée à partir des règles connues les plus anciennes aux dernières règles disponibles. Le groupe "TZDB" par défaut utilise la numérotation de version constituée de l'année suivie d'une lettre, telle que "2009E" ou "2012F". P>
blockQquote>
Exemple: P>
System.out.println(
java.time.zone.ZoneRulesProvider
.getVersions("UTC")
.lastEntry()
.getKey()
);
dans Windows, utilisez
findstr tzdata <java-home>\lib\zi\ZoneInfoMappings
La solution upvote fonctionne, mais au lieu d'écrire et d'exécuter du code, on peut également demander à l'outil TZ Updater lui-même pour chaque JRE installé: sortie d'échantillon: p> tzupdater version 2.3.2-b02
JRE tzdata version: tzdata2018g
tzupdater tool would update with tzdata version: tzdata2021a