C'est sympa, on va retrouver les vieilles traditions de pondre du code supplémentaire pour la portabilité.
Ile ne me semble pas que le langage soit adapté à l'utilisation de plusieurs vaiantes. En c/c++ on a un préprocesseur pour ça, mais en Java, comment va-t-on faire.
Des différences existeront à coup sûr entre le Java de GCJ et le Java de Sun. Il faudra se taper des appels à l'API de réflexivité pour voir quel compilo/interpréteur tourne et utiliser des paths différents dans le code pour ça.
Je préfère largement la formule avec préprocesseur, qui permet de voir du premier coup d'oeuil la différence entre le code de traitement et le code de portabilité.
Sinon, la communauté peut toujours créer un préprocesseur pour Java, qu'il faudrait utiliser pour générer des sources compatibles avec l'une ou l'autre des implémentations.
Ca serait comique, une innovation de la communauté qui permettrait d'améliorer la portabilité d'un langage marketé comme étant portable .
# Les vieilles traditions
Posté par iug . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 3.
Ile ne me semble pas que le langage soit adapté à l'utilisation de plusieurs vaiantes. En c/c++ on a un préprocesseur pour ça, mais en Java, comment va-t-on faire.
Des différences existeront à coup sûr entre le Java de GCJ et le Java de Sun. Il faudra se taper des appels à l'API de réflexivité pour voir quel compilo/interpréteur tourne et utiliser des paths différents dans le code pour ça.
Je préfère largement la formule avec préprocesseur, qui permet de voir du premier coup d'oeuil la différence entre le code de traitement et le code de portabilité.
Sinon, la communauté peut toujours créer un préprocesseur pour Java, qu'il faudrait utiliser pour générer des sources compatibles avec l'une ou l'autre des implémentations.
Ca serait comique, une innovation de la communauté qui permettrait d'améliorer la portabilité d'un langage marketé comme étant portable .