2010-10-30 5 views
10

Quelqu'un peut-il me dire que l'option jsr14 sera toujours disponible avec JDK7/8?La version cible du compilateur java "jsr14" avec JDK7/8

Say,

$ javac -source 1.5 -target jsr14 Hello.java 
+0

Lequel a raison? "sera toujours" ou "sera toujours". Pardon. Je ne parle pas anglais quand je suis réveillé. :) –

+0

Quelle est la version cible de "jsr14"? Voulez-vous dire -target 1.4? – EJP

+0

vérifier cela sur EJP. http://www.ibm.com/developerworks/java/library/j-jtp02277.html –

Répondre

4

Le dernier paquet source OpenJDK (openjdk-7-ea-src-b130-18_feb_2011.zip) contient encore le drapeau dans la source (langtools/src/share/classes/com/sun/tools/javac/jvm/Target.java), mais il n'a jamais été pris en charge, donc compter sur elle est une mauvaise idée.

Pourquoi en avez-vous besoin?

+0

Parce que j'avais l'habitude d'écrire 1.5 codes et de compiler pour 1.4 cible pour mes STBoxes Java ME. –

+4

@Jin: J'utiliserais l'une des cibles prises en charge et j'utiliserais quelque chose comme [Retroweaver] (http://retroweaver.sourceforge.net/) ou [Retrotranslator] (http://retrotranslator.sourceforge.net/) pour poster -process le résultat. –

+0

Mais jsr14 était parfait pour cela ... –

4

Ce drapeau a été abandonné depuis les étapes béta de 1.5. Il était uniquement inclus pour permettre au compilateur 1.5 beta de contourner la vérification/l'analyse générique par défaut alors que la spécification générique n'était pas finalisée. Une fois que la version 1.5 a été libérée, ce drapeau n'a plus aucun sens. Les nouvelles versions du compilateur peuvent ne pas donner d'erreurs lors de la rencontre, mais il est fort probable qu'elles l'ignorent silencieusement.

12

Nous utilisons beaucoup -jsr14 dans OSGi car cela nous permet d'utiliser des génériques dans notre API mais de les déployer sur des environnements 1.4, qui sont toujours populaires dans les environnements embarqués. Malheureusement, ils ont fait JDK 7 pas rétrocompatible avec Java 6 et 5. Javac 1.7 ignore les informations génériques qui sont réellement présentes dans les fichiers JAR. Il n'y a heureusement pas de problème au moment de l'exécution car cette information est ignorée quand même. Et ce n'est pas comme si c'était une fonctionnalité non documentée ...

Malheureusement, les gens à l'avant ont souvent très peu de respect pour les personnes qui ne peuvent pas simplement mettre à jour au plus tard et le plus grand. Devinez Oracle ne se soucie plus vraiment des marchés embarqués.

Nous allons probablement devoir expédier deux JAR, un pour l'embarqué et un pour JDK 7. Sucks.

Voici le rapport de bogue, nous avons déposé: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7078419

+0

Eclipse P2 utilise la cible jsr14 pour une raison similaire. Malheureusement, il n'est pas vrai qu'il n'y a pas de problème à l'exécution. OpenJDK explose lors de l'utilisation de la réflexion sur les types compilés avec la cible jsr14. Cela est particulièrement problématique lorsque vous utilisez Spring DM ou Blueprint comme vu ici: https://gist.github.com/1251497 – mpilquist

+1

J'ai couru dans ce problème OSGi. Existe-t-il un rapport de bogue OSGi pour lequel je peux voter? Note: la résolution pour le rapport de bogue JDK est: Pas un défaut Il doit être corrigé sur le côté OSGi alors. – Puce

+0

J'ai soumis un problème ici: https://issues.apache.org/jira/browse/FELIX-3455 S'il vous plaît voter pour cela. – Puce

Questions connexes