Discussion :

[Bktero]

Le géant du semi-conducteur STMicroelectronics a annoncé il y a quelques jours la sortie d'outils de développement et d'une gamme de micro-contrôleurs associée pour pouvoir développer des applications en Java. STMicroelectronics propose ainsi une solution pour créer des interfaces utilisateurs complexes, graphiquement évoluées, à la manière des smartphones mais pour des appareils bien moins puissants. Les processeurs cibles sont en effet ceux de la gamme STM32, des micro-contrôleurs 32 bits utilisant les architectures Cortex-M d'ARM.

Le produit s'appelle STM32Java et propose un environnement de développement, un compilateur Java, des plateformes Java optimisées pour les micro-contrôleurs STM32, des bibliothèques et des outils pour construire vos applications. Il est possible d'interfacer de manière simple du code en C et du code en Java. Un simulateur permet de tester sur PC l'application telle qu'elle sera compilée et déployée sur la cible matérielle.

La licence annuelle est de 2600USD pour un poste.

STMicroelectronics a crée un site dédié à ce produit. On peut y acheter des licences et des kits d'évaluation, la liste des références des puces compatibles est consultable et STMicroelectronics fournit des ressources pour prendre en main le produit (manuel, notes d'applications, spécifications...). Des vidéos montrent que l'environnement de développement est basé sur Eclipse et montrent l'exécution en parallèle de la même application sur le simulateur et une carte d'évaluation. On peut y voir le rendu des applications façon smartphone promis par STMicroelectronics.

Sources :

Communiqué de presse de STMicroelectronics
Le site dédié à STM32Java
Page produit dans le catalogue


Et vous ?

Seriez-vous intéressés pour faire vos développements embarqués en Java ?

[Bluedeep]

La licence annuelle est de 2600USD pour un poste.

Je suis un peu surpris qu'une firme franco-italienne, avec un actionnariat partiellement étatique de surcroit, donne un prix en USD et pas en EUR.

[Bktero]

Je ne trouve pas particulièrement étonnant qu'une firme internationale s'adressant en anglais à ces clients du monde entier donne ses prix en USD, la monnaie de référence des échanges mondiaux

[ManusDei]

Seriez-vous intéressés pour faire vos développements embarqués en Java ?

Pas sûr. Est-ce qu'on a un bon contrôle de la mémoire ? Parce que si c'est pour embarquer un Garbage Collector, je ne suis pas certain des performances finales.

[transgohan]

Pas sûr. Est-ce qu'on a un bon contrôle de la mémoire ? Parce que si c'est pour embarquer un Garbage Collector, je ne suis pas certain des performances finales.

Si tu poses la question c'est que visiblement tu ne sais pas comment on gère la mémoire avec Java autrement que par le fait de dire "le GB il est là laissons le faire".
Je te recommande cet article : http://schmitt.developpez.com/tutoriel/java/memoire/
Le GB n'est pas une taupe, c'est juste une autre façon de programmer et de gérer la mémoire.
La mauvaise image de Java qu'on a vient surtout de la tonne de développeurs qui ne savent pas programmer (oui j'utiliserai plutôt le terme de bidouiller pour eux) et l'énorme demande en développeur Java/JEE demandée par les SSII(qu'on ne parte pas dans le troll je ne cible pas toutes les SSII) qui ne sont au final pas très regardantes sur la qualité.

C'est intéressant cependant de voir que ST s'est penché sur le Java.
Car effectivement ce langage ramené directement à un niveau processeur (ou microprocesseur dans ce cas là) est loin d'être une bouse. J'ai actuellement un collègue qui fait mumuse sur un ARM Cortex A8 avec du Java. Et pour vous donner de la suite dans les idées, il fait du développement temps réel.
Il a encore de nombreuses choses à tester, mais pour le moment il a retourné le bouzin dans tous les sens et n'a pas un seul point en défaveur de java.

[MiaowZedong]

Si tu poses la question c'est que visiblement tu ne sais pas comment on gère la mémoire avec Java autrement que par le fait de dire "le GB il est là laissons le faire".
Je te recommande cet article : http://schmitt.developpez.com/tutoriel/java/memoire/
Le GB n'est pas une taupe, c'est juste une autre façon de programmer et de gérer la mémoire.
La mauvaise image de Java qu'on a vient surtout de la tonne de développeurs qui ne savent pas programmer (oui j'utiliserai plutôt le terme de bidouiller pour eux) et l'énorme demande en développeur Java/JEE demandée par les SSII(qu'on ne parte pas dans le troll je ne cible pas toutes les SSII) qui ne sont au final pas très regardantes sur la qualité.

C'est intéressant cependant de voir que ST s'est penché sur le Java.
Car effectivement ce langage ramené directement à un niveau processeur (ou microprocesseur dans ce cas là) est loin d'être une bouse. J'ai actuellement un collègue qui fait mumuse sur un ARM Cortex A8 avec du Java. Et pour vous donner de la suite dans les idées, il fait du développement temps réel.
Il a encore de nombreuses choses à tester, mais pour le moment il a retourné le bouzin dans tous les sens et n'a pas un seul point en défaveur de java.

Le Java est peut-ête tout-à-fait utilisable, mais n'est-t-on pas en pleine illustration de "When all you have is a hammer, all problems look like a nail"?

[transgohan]

Le Java est peut-ête tout-à-fait utilisable, mais n'est-t-on pas en pleine illustration de "When all you have is a hammer, all problems look like a nail"?

Cette tirade est tirée par les cheveux.
J'ai des collègues qui te répondront que c'est du n'importe quoi d'utiliser du C à la place du C++ (et ce quelque soit le type de système), ou inversement.
Pour aller encore plus dans le ridicule j'en connais deux qui préférerons faire certaines applications simples en assembleur plutôt qu'en C.

Bref selon moi quand on maîtrise une technologie c'est pas la peine de s'emmerder à aller faire autre chose parce que c'est la mode.

Et encore une fois... Java n'est pas un marteau, je ne parle absolument pas de l'immondice de JVM que vous avez sur vos ordinateurs. Je parle du bytecode intermédiaire interprété par le CPU comme instruction machine...
Java ne se limite pas à sa JVM, Java est un langage avant tout et non une plateforme.

[Bktero]

Je me suis souvenu que je n'avais jamais donné mon avis sur le sujet ^^

transgohan a une bonne vision de la chose. Java ne se limite pas à la tasse à café qui apparaît des fois en bas de votre écran et fait (faisait car ce n'est plus tout à fait vrai) ramer votre PC. Java est comme C : il y a des spécifications qu'un éditeur logiciel peut choisir d'implémenter. Le monde ne se limite pas à la JVM Oracle.

MiaowZedong : non, on est en illustration du problème : si j'ai un clou, il me faut un marteau; si j'ai une vis, il me faut un tournevis. Java n'est pas fait pour remplacer C, comme C n'est pas fait pour remplacer l'assembleur. Selon les problèmes posés, on utilise le bon outil.

ManusDei : tu n'es pas certain et tu as sûrement tord et raison à la fois. C'est justement parce que tu dois utiliser Java quand c'est pertinent. Si tu veux faire une gestion à l'octet près, alors oui, ce n'est pas Java qu'il te fait puisse que la gestion de la mémoire est assurée par le GC. Avoir un GC et le laisser faire ne veut pas pour autant dire que tu dois coder n'importe comment, on reste dans un contexte embarqué avec des ressources limitées.

Il faut prendre du recul sur l'évolution des micro-contrôleurs et des applications qui tournent sur ces puces. Il est aujourd'hui devenu (presque) courant d'avoir 1Mo de flash et 128ko de RAM et les STM32F4 (Cortex M4) sont des gros machins ! On peut voir les tailles de puces compatibles ici. C'était inimaginable il y a quelques années. La complexité des applications qui rentrent désormais sur un micro-contrôleur a donc forcément explosé. La POO donne de nombreux outils pour gérer la complexité, je pense que c'est assez indéniable. Il devient donc pertinent d'avoir des langages OO sur embarqué, Java par exemple. STM32Java est tourné vers les IHM, l'apport de l'OO avec un design pattern tel que MVC est pertinent.

Pour ce qui est des performances, un système embarqué a de nombreux points pouvant le ralentir comme absence de contrôleur d'écran ou lecture et écriture sur des mémoires externes. Il y a énormément de points d'attention et l'utilisation de Java n'est vraiment pas le point bloquant. Les vidéos montrent bien que le rendu de l'IHM est bon

[ManusDei]

Je sais être dans un domaine particulier, mais là où je bosse on utilise du C, avec des macro assembleur inline pour des questions de performance. Et c'est pas pour la frime, c'est nécesssaire pour respecter les contraintes du système.

J'imagine pas vraiment la même chose en Java, mais je suis peut-être dans un domaine un peu trop particulier (je suis jeune diplômé donc je connais pas tout, loin de là).

Faudrait que je regarde, j'ignore totalement si l'utilisation de la POO a un impact sur la taille du code.

[Bktero]

Tu as raison de ne pas l'imaginer : ce n'est pas fait pour ^^

Java n'est de base pas fait pour l’algorithmie pure. Prend le cas d'un calcul matriciel : Java vérifie si tu ne dépasses pas d'un tableau quand tu essayes d'accéder à une case. Chaque accès à chaque case sera donc bien plus lent que le même code en C puisque C ne fait pas de vérification des bornes. Si tu veux encore optimiser certains temps de calcul, tu fais ce que tu fais : tu passes en assembleur. Dans ton cas, Java ne convient pas.

En revanche, si tu veux faire une IHM complexe sans calcul compliqué derrière, tu ne le feras pas en assembleur. Tu auras besoin de mécanismes haut niveau pour la gestion des widgets graphiques. Java est alors pertinent. A titre d'exemple, ce produit est fait avec en grande partie avec du Java et la puce est un micro-contrôleur type Cortex M. Ils cherchent là à faire une interface complète, complexe, modulable.

Au passage, Java est portable donc tout ce qui a été écrit en Java pourra être réutilisé sur un autre appareil qui fournit une JVM et les bibliothèques utilisées. Toujours chez Deltadore, tu pourras regarder ce produit qui a la même interface graphique. Ce n'est pas dû au hasard

A chaque problème une solution. Je ressors ma vis et mon marteau.