Jaka wersja javac zbudowała mój słoik?

Skąd mam wiedzieć, która wersja kompilatora Java została użyta do zbudowania jar? Mam plik jar i mógł on zostać zbudowany w jednym z trzech JDK. Musimy dokładnie wiedzieć, który z nich, abyśmy mogli poświadczyć zgodność. Czy wersja kompilatora jest osadzona gdzieś w plikach klasy lub jar?

Nie można tego stwierdzić na podstawie samego pliku JAR.

Pobierz edytor szesnastkowy i otwórz jeden z plików klas w pliku JAR i spójrz na przesunięcia bajtów od 4 do 7. Informacje o wersji są wbudowane.

http://en.wikipedia.org/wiki/Java_class_file

Uwaga: jak wspomniano w komentarzu poniżej,

bajty te informują o wersji, dla której klasa została skompilowana, a nie w jakiej wersji.

A jarto tylko pojemnik. Jest to archiwum plików la tar. Chociaż jarmoże zawierać interesujące informacje zawarte w hierarchii META-INF , nie ma obowiązku określania rocznika klas w swojej treści. W tym celu należy sprawdzić zawarte w classnim pliki.

Jak wspomniał Peter Lawrey w komentarzu do pierwotnego pytania, niekoniecznie musisz wiedzieć, która wersja JDK zbudowała dany classplik, ale możesz znaleźć wersję klasy bajtowej classpliku zawartego w pliku jar.

Tak, to trochę do bani, ale pierwszym krokiem jest wyodrębnienie jednej lub więcej klas z jar. Na przykład:

$ jar xf log4j-1.2.15.jar

W systemie Linux, Mac OS X lub Windows z zainstalowanym Cygwin polecenie file (1) zna wersję klasy.

$ file ./org/apache/log4j/Appender.class
./org/apache/log4j/Appender.class: compiled Java class data, version 45.3

Lub alternatywnie, używając javapz JDK jako @ jikes.thunderbolt trafnie wskazuje:

$ javap -v ./org/apache/log4j/Appender.class | grep major
 major version: 45

A jeśli zostaniesz przeniesiony do Windowsśrodowiska bez jednego filelubgrep

> javap -v ./org/apache/log4j/Appender.class | findstr major
 major version: 45

FWIW, zgodzę się, że javappowie o wiele więcej o danym classpliku niż pierwotne pytanie.

W każdym razie inna wersja klasy, na przykład:

$ file ~/bin/classes/P.class
/home/dave/bin/classes/P.class: compiled Java class data, version 50.0

Numer główny wersji klasy odpowiada następującym wersjom JDK Java:

• 45,3 = Java 1.1
• 46 = Java 1.2
• 47 = Java 1.3
• 48 = Java 1.4
• 49 = Java 5
• 50 = Java 6
• 51 = Java 7
• 52 = Java 8
• 53 = Java 9

Oto sposób, w jaki Java może znaleźć te informacje.

Windows: javap -v <class> | findstr major
Unix:javap -v <class> | grep major

Na przykład:
> javap -v Application | findstr major   major version: 51

Nie ma potrzeby rozpakowywania pliku JAR (jeśli jedna z nazw klas jest znana lub jest sprawdzana, np. Za pomocą 7zip), więc w systemie Windows wystarczające byłyby:

javap -cp log4j-core-2.5.jar -verbose org.apache.logging.log4j.core.Logger | findstr major

Kompilator Java ( javac) nie buduje słoików, tłumaczy pliki Java na pliki klas. Narzędzie Jar ( jar) tworzy rzeczywiste słoiki. Jeśli nie określono żadnego niestandardowego manifestu, domyślny manifest określa, która wersja JDK została użyta do utworzenia jar.

Ponieważ musiałem przeanalizować grube słoiki, byłem zainteresowany wersją każdej klasy w pliku jar. Dlatego podjąłem podejście Joe Liversedge https://stackoverflow.com/a/27877215/1497139 i połączyłem je z https://stackoverflow.com/a/3313839/1497139 tabelą wersji klas klasy Davida J. Liszewskiego, aby utworzyć skrypt bash jarv, aby wyświetlić wersje wszystkich plików klas w pliku jar.

stosowanie

usage: ./jarv jarfile
 -h|--help: show this usage

Przykład

jarv $Home/.m2/repository/log4j/log4j/1.2.17/log4j-1.2.17.jar

java 1.4 org.apache.log4j.Appender
java 1.4 org.apache.log4j.AppenderSkeleton
java 1.4 org.apache.log4j.AsyncAppender$DiscardSummary
java 1.4 org.apache.log4j.AsyncAppender$Dispatcher
...

Skrypt Bash jarv

#!/bin/bash
# WF 2018-07-12
# find out the class versions with in jar file
# see https://stackoverflow.com/questions/3313532/what-version-of-javac-built-my-jar

# uncomment do debug
# set -x

#ansi colors
#http://www.csc.uvic.ca/~sae/seng265/fall04/tips/s265s047-tips/bash-using-colors.html
blue='\033[0;34m'  
red='\033[0;31m'  
green='\033[0;32m' # '\e[1;32m' is too bright for white bg.
endColor='\033[0m'

#
# a colored message 
#   params:
#     1: l_color - the color of the message
#     2: l_msg - the message to display
#
color_msg() {
  local l_color="$1"
  local l_msg="$2"
  echo -e "${l_color}$l_msg${endColor}"
}

#
# error
#
#   show an error message and exit
#
#   params:
#     1: l_msg - the message to display
error() {
  local l_msg="$1"
  # use ansi red for error
  color_msg $red "Error: $l_msg" 1>&2
  exit 1
}

#
# show the usage
#
usage() {
  echo "usage: $0 jarfile"
  # -h|--help|usage|show this usage
  echo " -h|--help: show this usage"
  exit 1 
}

#
# showclassversions
#
showclassversions() {
  local l_jar="$1"
  jar -tf "$l_jar" | grep '.class' | while read classname
  do
    class=$(echo $classname | sed -e 's/\.class$//')
    class_version=$(javap -classpath "$l_jar" -verbose $class | grep 'major version' | cut -f2 -d ":" | cut -c2-)
    class_pretty=$(echo $class | sed -e 's#/#.#g')
    case $class_version in
      45.3) java_version="java 1.1";;
      46) java_version="java 1.2";;
      47) java_version="java 1.3";;
      48) java_version="java 1.4";;
      49) java_version="java5";;
      50) java_version="java6";;
      51) java_version="java7";;
      52) java_version="java8";;
      53) java_version="java9";;
      54) java_version="java10";;
      *) java_version="x${class_version}x";;
    esac
    echo $java_version $class_pretty
  done
}

# check the number of parameters
if [ $# -lt 1 ]
then
  usage
fi

# start of script
# check arguments
while test $# -gt 0
do
  case $1 in
    # -h|--help|usage|show this usage
    -h|--help) 
      usage
      exit 1
      ;;
    *)
     showclassversions "$1"
  esac
  shift
done 

wersję kompilatora Java można znaleźć w plikach .class za pomocą edytora heksadecymalnego.

Krok 1: Wyodrębnij pliki .class z pliku jar za pomocą ekstraktora zip

krok 2: otwórz plik .class w edytorze szesnastkowym. (Użyłem wtyczki edytora szesnastkowego notatnika ++. Ta wtyczka odczytuje plik jako plik binarny i pokazuje go w postaci szesnastkowej). Możesz zobaczyć poniżej.

Indeks 6 i 7 podaje główny numer wersji używanego formatu pliku klasy. https://en.wikipedia.org/wiki/Java_class_file

Java SE 11 = 55 (0x37 hex)

Java SE 10 = 54 (0x36 hex)

Java SE 9 = 53 (0x35 hex)

Java SE 8 = 52 (0x34 hex),

Java SE 7 = 51 (0x33 hex),

Java SE 6.0 = 50 (0x32 hex),

Java SE 5.0 = 49 (0x31 hex),

JDK 1.4 = 48 (0x30 hex),

JDK 1.3 = 47 (0x2F hex),

JDK 1.2 = 46 (0x2E hex),

JDK 1.1 = 45 (0x2D hex).

Możesz poznać wersję binarną Java, sprawdzając pierwsze 8 bajtów (lub używając aplikacji, która potrafi).

Sam kompilator, zgodnie z moją najlepszą wiedzą, nie wstawia żadnego podpisu identyfikującego. I tak nie widzę czegoś takiego w formacie klasy specyfikacji pliku VM .

Kod wysłane przez Owena można powiedzieć informacje wymienione przez szereg innych odpowiedzi tutaj:

public void simpleExample ()
{
    FileInputStream fis = new FileInputStream ("mytest.class");
    parseJavaClassFile ( fis );
}
protected void parseJavaClassFile ( InputStream classByteStream ) throws Exception
{
    DataInputStream dataInputStream = new DataInputStream ( classByteStream );
    magicNumber = dataInputStream.readInt();
    if ( magicNumber == 0xCAFEBABE )
    {
        int minorVer = dataInputStream.readUnsignedShort();
        int majorVer = dataInputStream.readUnsignedShort();
        // do something here with major & minor numbers
    }
}

Zobacz także tę i tę stronę. Skończyło się na szybkim modyfikowaniu kodu produktów umysłowych, aby sprawdzić, do czego została skompilowana każda z moich zależności.

Programiści i administratorzy używający Bash mogą uznać te funkcje wygody za pomocne:

jar_jdk_version() {
  [[ -n "$1" && -x "`command -v javap`" ]] && javap -classpath "$1" -verbose $(jar -tf "$1" | grep '.class' | head -n1 | sed -e 's/\.class$//') | grep 'major version' | sed -e 's/[^0-9]\{1,\}//'
}

print_jar_jdk_version() {
  local version
  version=$(jar_jdk_version "$1")
  case $version in 49) version=1.5;; 50) version=1.6;; 51) version=1.7;; 52) version=1.8;; esac
  [[ -n "$version" ]] && echo "`basename "$1"` contains classes compiled with JDK version $version."
}

Możesz je wkleić do jednorazowego użytku lub dodać do ~/.bash_aliaseslub ~/.bashrc. Wyniki wyglądają mniej więcej tak:

$ jar_jdk_version poi-ooxml-3.5-FINAL.jar
49

i

$ print_jar_jdk_version poi-ooxml-3.5-FINAL.jar
poi-ooxml-3.5-FINAL.jar contains classes compiled with JDK version 1.5.

EDYCJA Jak wskazuje jackrabbit , nie możesz w 100% polegać na manifeście, aby powiedzieć ci coś pożytecznego. Jeśli tak, to możesz wyciągnąć go w swojej ulubionej powłoce UNIX za pomocą unzip:

$ unzip -pa poi-ooxml-3.5-FINAL.jar META-INF/MANIFEST.MF
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 11.3-b02 (Sun Microsystems Inc.)
Built-By: yegor
Specification-Title: Apache POI
Specification-Version: 3.5-FINAL-20090928
Specification-Vendor: Apache
Implementation-Title: Apache POI
Implementation-Version: 3.5-FINAL-20090928
Implementation-Vendor: Apache

Ten .jar nie ma nic użytecznego w manifeście na temat zawartych klas.

Jeden liner (Linux)

unzip -p mylib.jar META-INF/MANIFEST.MF

Spowoduje to wydrukowanie zawartości MANIFEST.MFpliku na standardowe wyjście (mam nadzieję, że plik znajduje się w pliku jar :)

W zależności od tego, co zbudowało twój pakiet, znajdziesz wersję JDK w Created-Bylub Build-Jdkkey.

Każdy plik klasy ma numer wersji osadzony na poziomie kodu bajtowego, którego JVM używa, aby sprawdzić, czy podoba mu się ten konkretny fragment kodu bajtowego, czy nie. To 48 dla Java 1.4, 49 dla Java 1.5 i 50 dla Java 6.

Istnieje wiele kompilatorów, które mogą generować kod bajtowy na każdym poziomie, javac używa opcji „-target”, aby wskazać, który poziom kodu bajtowego ma zostać wygenerowany, a javac Java 6 może generować kod bajtowy dla przynajmniej 1.4, 1.5 i 6. Nie wierzę, że kompilator wstawia wszystko, co może zidentyfikować sam kompilator, i myślę, że o to prosisz. Coraz częściej stosuje się także kompilator Eclipse, ponieważ jest to pojedynczy słoik, który może działać tylko z JRE.

W pliku jar znajduje się zwykle wiele klas, a każda z nich jest niezależna, dlatego musisz sprawdzić wszystkie klasy w słoiku, aby mieć pewność co do właściwości zawartości.

W odpowiedzi na odpowiedź Davida J. Liszewskiego uruchomiłem następujące polecenia, aby wyodrębnić manifest pliku jar na Ubuntu:

# Determine the manifest file name:
$ jar tf LuceneSearch.jar | grep -i manifest
META-INF/MANIFEST.MF

# Extract the file:
$ sudo jar xf LuceneSearch.jar META-INF/MANIFEST.MF

# Print the file's contents:
$ more META-INF/MANIFEST.MF
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.2
Created-By: 1.7.0_25-b30 (Oracle Corporation)
Main-Class: org.wikimedia.lsearch.config.StartupManager

Wiele razy możesz patrzeć na całe pliki jar lub pliki wojenne zawierające wiele plików jar oprócz siebie.

Ponieważ nie chciałem ręcznie sprawdzać każdej klasy, napisałem program Java, aby to zrobić:

https://github.com/Nthalk/WhatJDK

./whatjdk some.war
some.war:WEB-INF/lib/xml-apis-1.4.01.jar contains classes compatible with Java1.1
some.war contains classes compatible with Java1.6

Chociaż nie mówi to o tym, z czym klasa została skompilowana, określa, jakie JDK będą mogły ZAŁADOWAĆ klasy, co prawdopodobnie jest tym, od czego chciałeś zacząć.

Aby rozwinąć odpowiedzi Jonathona Fausta i McDowell : Jeśli korzystasz z systemu opartego na * nix, możesz użyć od(jednego z pierwszych programów uniksowych ^1, który powinien być dostępny praktycznie wszędzie), aby wysłać zapytanie do .classpliku na poziomie binarnym:

od -An -j7 -N1 -t dC SomeClassFile.class

Spowoduje to wyświetlenie znanych wartości całkowitych, np. 50For Java 5, 51for Java 6i tak dalej.

¹ Cytat z https://en.wikipedia.org/wiki/Od_(Unix)

Napisałem również własny skrypt bash, aby zrzucić wersję Java wymaganą przez wszystkie słoiki przekazane w wierszu poleceń ... Mój jest trochę szorstki, ale dla mnie działa ;-)

przykładowe użycie

$ jar_dump_version_of_jvm_required.sh *.jar
JVM VERSION REQUIRED: 46.0, /private/tmp/jars/WEB-INF/lib/json-simple-1.1.jar
JVM VERSION REQUIRED: 49.0, /private/tmp/jars/WEB-INF/lib/json-smart-1.1.1.jar
JVM VERSION REQUIRED: 50.0, /private/tmp/jars/WEB-INF/lib/jsontoken-1.0.jar
JVM VERSION REQUIRED: 50.0, /private/tmp/jars/WEB-INF/lib/jsr166y-1.7.0.jar

jar_dump_version_of_jvm_required.sh

#!/bin/bash

DIR=$(PWD)
function show_help()
{
  ME=$(basename $0)
  IT=$(cat <<EOF

  Dumps the version of the JVM required to run the classes in a jar file

  usage: $ME JAR_FILE

  e.g. 

  $ME myFile.jar    ->  VERSION: 50.0     myFile.jar

  Java versions are:
  54 = Java 10
  53 = Java 9
  52 = Java 8
  51 = Java 7
  50 = Java 6
  49 = Java 5
  48 = Java 1.4
  47 = Java 1.3
  46 = Java 1.2
  45.3 = Java 1.1

EOF
  )
  echo "$IT"
  exit
}

if [ "$1" == "help" ]
then
  show_help
fi
if [ -z "$1" ]
then
  show_help
fi

function unzipJarToTmp()
{
  JAR=$1
  CLASS_FILE=$(jar -tf "$JAR" | grep \.class$ | grep -v '\$' | head -n1 | awk '{print $NF}')
  OUT_FILE="$CLASS_FILE"
  #echo "J=$JAR C=$CLASS_FILE O=$OUT_FILE"
  jar xf "$JAR" "$CLASS_FILE"

  MAJOR=$(javap -v "$OUT_FILE" 2>&1 | grep major | awk -F' ' '{print $3'})
  MINOR=$(javap -v "$OUT_FILE" 2>&1 | grep minor | awk -F' ' '{print $3'})
  if [ -z "$MAJOR" ]
  then
    echo "JVM VERSION REQUIRED: NA as no classes in $JAR"
  else
    echo "JVM VERSION REQUIRED: $MAJOR.$MINOR, $JAR"
  fi
}

# loop over cmd line args
for JAR in "$@"
do
  cd "$DIR"
  JAR_UID=$(basename "$JAR" | sed s/.jar//g)
  TMPDIR=/tmp/jar_dump/$JAR_UID/
  mkdir -p "$TMPDIR"
  JAR_ABS_PATH=$(realpath $JAR)

  cd "$TMPDIR"

  #echo "$JAR_ABS_PATH"
  unzipJarToTmp "$JAR_ABS_PATH"
  #sleep 2
done

Możesz to łatwo zrobić w wierszu poleceń, wykonując następujący proces:

Jeśli znasz dowolną nazwę klasy w słoiku, możesz użyć następującego polecenia:

javap -cp jarname.jar -verbose packagename.classname | findstr major

przykład:

    C:\pathwherejarlocated> javap -cp jackson-databind-2.8.6.jar -verbose com.fasterxml.jackson.databind.JsonMappingException | findstr major

Wynik :

    major version: 51

Krótki przegląd:

JDK 1.0 — major version 45 
DK 1.1 — major version 45 
JDK 1.2 — major version 46 
JDK 1.3 — major version 47 
JDK 1.4 — major version 48 
JDK 1.5 — major version 49 
JDK 1.6 — major version 50 
JDK 1.7 — major version 51 
JDK 1.8 — major version 52 
JDK 1.9 — major version 53 

PS: jeśli nie znasz żadnej z nazw klas, możesz to łatwo zrobić za pomocą dowolnego dekompilatora jar lub po prostu używając następującego polecenia, aby wyodrębnić plik jar:

jar xf myFile.jar

Sprawdzasz w pliku manifestu przykład słoika:

Wersja manifestu: 1.0 Utworzono: 1.6.0 (IBM Corporation)

W systemie Windows wykonaj następujące czynności:

1. Rozpakuj lub rozpakuj plik JAR za pomocą komendy JAR WinZip / Java.
2. Przeciągnij i upuść jeden z plików klas do projektu Java Eclipse.
3. Otwórz plik klasy.

Teraz Eclipse wyświetli dokładną wersję główną i dodatkową.

Buduję mały skrypt bash (na github) w oparciu o sugestię Davidsa za pomocą filepolecenia