3
votes

Existe-t-il un raisonnement pratique pour appliquer la version JDK pour la construction?

Il existe plug-in maven enforcer qui peut forcer build à être ne fonctionne que sur une version JDK spécifique.

Je me demande s'il existe un raisonnement pratique pour avoir cela? Nous avons déjà une configuration de construction pour spécifier les versions source et cible. Pour autant que je sache, cela devrait être plus que suffisant, car Java est rétrocompatible. Par exemple à quoi il ressemble dans gradle:

  <properties>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
  </properties>

Voilà à quoi il ressemble dans maven:

compileJava   {
  sourceCompatibility = '1.8'
  targetCompatibility = '1.8'
}

Si vous en avez vu raison d'exiger la version exacte de jdk - pourriez-vous s'il vous plaît également l'écrire.

UPD. La question est plus de savoir s'il y a une différence pratique pour compiler un projet de source / cible java de la version 8 avec des JDK de 8,9,10 ou 11 ...

java maven gradle

1 commentaires

Eh bien, par exemple, je ne peux pas compiler les flux JDK 8 avec JDK 7.

3 Réponses :

3
votes

Pas du tout. Source concerne principalement la syntaxe. La cible concerne le nombre magique et les capacités spécifiques du code d'octet.

Mais vous pourriez très bien écrire du code conforme à Java 7 qui utilise une seule classe X que seul jdk 8 ou plus récent fournit. Lorsque vous utilisez ensuite un jdk Java 8, ce compilateur trouvera cette classe X et construira correctement. Mais lors de l'exécution de ce code sur un jvm Java 7, la classe X de Java 8 est manquante, ce qui entraîne une exception d'exécution.

Donc: forcer le jdk vous empêche d'utiliser des classes qui ont été ajoutées à Java après votre version cible.

3 commentaires

ma question n'est pas de compiler un nouveau code avec d'anciennes versions mais vice versa - compiler l'ancien code avec les jdk les plus récents

En ce qui concerne cette réponse, il convient de mentionner le javac --release flag du JDK 9+, qui empêche d'utiliser les API des nouveaux JDK.

@TomaszLinkowski Je suggère d'inclure cette information de drapeau --release dans une réponse.

4
votes

La raison principale en est peut-être de meilleures optimisations dans le compilateur du nouveau JDK. Ainsi, même si le niveau de bytecode cible est le même que celui de l'ancien compilateur, le bytecode cible lui-même pourrait être amélioré.

Selon Brian Goetz , cela tire son poids:

Il y a des moments où une meilleure traduction du code source en bytecode est rendue possible par les améliorations de la JVM. Par exemple, avant la version 5, Foo.class était traduit en appel réfléchissant; après, à LDC.

Par conséquent, vous pouvez raisonnablement vouloir vous en tenir à un niveau de langue donné dans une organisation (en raison du code partagé), mais des applications spécifiques peuvent toujours profiter des améliorations de VM.

Modifier : Désolé! Le tweet cité concerne la compilation avec la source inférieure à la cible (par exemple -source 8 -target 11 ), donc c'est différent de ce que l'OP a demandé. Pourtant, peut-être que le nouveau compilateur peut produire un meilleur bytecode même lorsque la cible reste inchangée.

PS. Comme conseillé par Basil , permettez-moi de mentionner le javac --release flag du JDK 9+, qui empêche d'utiliser les API des nouveaux JDK tout en conservant les anciens niveaux de langue.

0 commentaires

1
votes

Eh bien, il y a plusieurs raisons. Celui que je voudrais souligner est le déploiement dans un environnement d'entreprise.

Disons que vous avez des milliers de machines maintenues en cours d'exécution dans une entreprise, vous ne pouvez tout simplement pas installer chaque version de java sur chaque ordinateur. De plus, la sécurité ne permet généralement pas le téléchargement (souvent pas d'accès direct à Internet) et chaque version de Java disponible doit être maintenue en ce qui concerne la sécurité - avec beaucoup de paperasse et de discussions (par exemple, la sécurité).

Botomline est: Dans une entreprise, vous disposez d'un ensemble très limité de versions Java disponibles et souvent pas à la pointe de la technologie.

Maintenant, disons que la version disponible est Java 8. Maintenant, si vous voulez que l'application s'exécute dans l'environnement, vous devez vous assurer qu'elle fonctionne réellement sur la version disponible (comme Java 8). S'il utilise quelque chose qui n'est pas disponible dans cette version, il ne fonctionnera tout simplement pas ou ne plantera pas. En substance, une telle application ne serait tout simplement pas utilisable dans l'entreprise. Ce qui signifie que l'entreprise chercherait une solution différente, qu'elle peut réellement utiliser dans son environnement.

Donc, être capable de dire au compilateur la version cible aide beaucoup à créer une application qui peut et sera réellement utilisée (et ne plante pas sur la machine d'un utilisateur).

0 commentaires