Quelques renseignements sur l'avenir du Java.

J’y faisais tourner mon Subsonic sans aucun soucis.

Je ne connais pas, mais cela ne semble pas être une appli Java (c’est ca https://en.wikipedia.org/wiki/SubSonic_(software) ?)

C’est ceci.

C’est un logiciel qui passe son temps à attendre le réseau et l’entrée utilisateur, donc les performances ne sont pas critiques.

Comme la majorité des logiciels, en vrai.

Question idiote : c’est viable de faire du Java sur RPi ? (Performances, mémoire ?)

Pas idiote du tout.

J’ai constaté que la Raspberry arrivait très bien à faire fonctionner des programmes d’une taille correcte et avec quelques traitements supplémentaires derrière. J’ai même été surpris sur le nombre de données qu’elle pouvait traiter en un très court délai. Malheureusement, je n’ai pas de programme pour faire la comparaison (c’est celui de l’entreprise).

Et de ce que j’ai lu, le Java n’est pas aussi lent qu’on pourrait le croire. Apparemment, de gros efforts ont été fait pour optimiser la Java Virtual Machine (je pense au Just In Time).

Après, si d’autres personnes plus calées sur le sujet auraient des sources pour vérifier ce que je dis, je ne serai pas contre. Ça m’intéresse aussi.

Voici un lien très intéressant en attendant.

Ma question n’est pas sur le Java en général, mais le cas spécifique du Java sur RPi. C’est pas de l’embarqué, mais c’est pas non plus très performant.

Surtout, ta question n’a pas vraiment de sens. Ça dépend de ce que tu veux y faire tourner, pas de la technologie elle-même.

On en sait pas plus. Et il parlait aussi de site web. Je ne sais pas s’il veut une JVM plus un serveur Apache, mais dès qu’on parle de RPi, je me pose forcement la question des performances. Les premiers n’étaient pas franchement des bêtes de course. (Les applis tournaient mieux sur mon telephone). Je n’ai pas testé le dernier RPi, et peut être que ça supportera ce qu’il veut faire. Mais je ferais des tests avant, histoire de ne pas développer toute une application en Java (ou autre environnement) et m’apercevoir après que ça n’est pas utilisable a cause des performances ou de la mémoire.

(Je me poserais la même question de performances en C++/Qt. Mais je sais que je pourrais faire sauter la partie Qt et conserver le code métier en C++. Avec le Java, s’il y a un problème de performances, quelle sera l’alternative et qu’est-ce qu’on pourra garder de ce qu’on a déjà fait ? C’est une vraie question, je ne connais pas assez le Java pour savoir les solutions en cas de problème de performances)

Bonjour,

Pour revenir sur le sujet de Java, une question:

Ils disent que le JDK commercial et l’OpenJDK seront fonctionnellement identiques. Est-ce que c’est vraiment sûr ?

J’ai une mauvaise expérience datant de quelques années dans laquelle l’OpenJDK est 3 fois plus lent que le JDK normal et ne fonctionne pas avec certaines bibliothèques. A l’époque j’avais eu des problèmes avec le driver MySQL. En d’autres termes l’OpenJDK c’était vraiment pourri.

S’ils font deux builds différents, c’est bien parce qu’il y a une différence fonctionnelle quelque part, et que la différence n’est pas uniquement la présence ou l’absence de support non ? Sinon ils ne se casseraient pas la tête à faire deux builds différents.

Du coup j’ai du mal à les croire… je fais tourner un jeu gratuit avec 16000 utilisateurs et parfois 500 utilisateurs connectés simultanément; et je me demande du coup si je ne devrais pas envisager de switcher vers autre chose pendant qu’il en est encore temps avant que mon jeu ne cesse totalement de fonctionner.

Il n’y a pas « un » mais « des » JDK commerciaux, celui d’Oracle n’en est qu’un parmi d’autres (Azul, IBM, Oracle, Red Hat font du support commercial de JDK). Il y a même plusieurs JDK libres utilisables en production depuis qu’IBM a refilé son J9 à la fondation Eclipse.

Le premier OpenJDK utilisable était le 7, le 6 a existé mais c’était un rétroportage du 7, avec plein de problèmes. Les différences entre le JDK Oracle et OpenJDK sur les versions 8, c’est surtout de la gestion graphique (ce qui a poussé Jetbrains à diffuser son propre fork pour faire tourner leurs IDE), une poignée de détails dans la crypto, et surtout l’absence des classes « internes SUN » dans l’OpenJDK (les fameuses sun.xxxxxxx que personne n’était censé utiliser mais qu’on retrouvait souvent).

Depuis Java 11, Oracle JDK et OpenJDK sont la même chose à la licence près.

Le premier OpenJDK utilisable était le 7

JE crois que c’est avec celui-là que j’ai fait ma mauvaise expérience… à la migration de Java 6 vers Java 7 et à la réinstall du système c’était le JDK fourni par défaut par debian. Une catastrophe ce truc.

et surtout l’absence des classes « internes SUN » dans l’OpenJDK (les fameuses sun.xxxxxxx que personne n’était censé utiliser mais qu’on retrouvait souvent).

C’est une bonne raison de plus pour les abandonner définitivement… il faut que je regarde si je n’en utilise pas encore dans un coin perdu du code, parce que je me souviens en avoir utilisé à l’époque de Java 5, 6 et peut-être encore 7.

Depuis Java 11, Oracle JDK et OpenJDK sont la même chose à la licence près.

OK, mais alors quel est l’intérêt de faire deux téléchargement différents, si techniquement c’est exactement la même chose ?

Merci.

OK, mais alors quel est l’intérêt de faire deux téléchargement différents, si techniquement c’est exactement la même chose ?

Oracle. C’est très, très souvent significatif de « pas logique »…

C’est super toutes ces réponses ! La Raspberry, pour sa petite taille est très performante. Avec 1.2GHz, j’imagine qu’on peut faire un tas de choses. En tout cas, c’est vrai qu’Oracle est super flou sur les licences, les différences, etc… Mais bizarrement, l’utilisation d’OpenJDK ne semble véritablement pas poser de soucis pour une utilisation commerciale.