Le marché que je décris c'est telephonie mobile (ok il n'y a pas de JVM dans tous les telephones portables) + TV num. Ce ne sont pas des petits marchés. A l'heure actuelle, ce sont deja des millions de machines. Je ne parle pas non plus des autres marchés.
Tous les equipements embarqués n'ont pas les memes contraintes, mais pour certains d'entre eux, le fait de pouvoir mettre a jour l'application sans se preoccuper de la plateforme materielle est clairement un avantage. Ceci est, a mon avis, quelque choses qui va continuer a se developper.
La JVM JamVM (J2SE) annonce un executable (compresse) de 140KB. La JVM MicroJVM (J2ME) annonce une empreinte memoire inferieure a 30 KB.
Le ByteCode est plus compact pour deux raisons:
- la premiere vient de sa conception : en ByteCode Java, si tu mets '0' sur la pile, c'est un seul octet ; sur une machine 32 bits, rien que le nombre tient sur 4 octets ; tout n'est pas comme ca, mais globalement, c'est plus compact
- la seconde raison est que les classes s'appuient beaucoup sur la bibliotheque et que tu peux eventuellement mettre a jour une seule classe ; c'est moins evident si tu veux faire ca avec un programme compilé, surtout sans bibliotheque partagée
Un des interets que le ByteCode soit compact est le temps de telechargement de la mise-a-jour. Le programme tient aussi moins de place en memoire.
Ceci dit, je ne vient pas ici pour dire que Java c'est genial pour l'embarque grace a son ByteCode, surtout que je suis plutot C. Je dis juste que c'est dans certains cas, cela a des avantages. Ceci est valable pour tous les langages generant du ByteCode.
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par crumpet . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
Tous les equipements embarqués n'ont pas les memes contraintes, mais pour certains d'entre eux, le fait de pouvoir mettre a jour l'application sans se preoccuper de la plateforme materielle est clairement un avantage. Ceci est, a mon avis, quelque choses qui va continuer a se developper.
La JVM JamVM (J2SE) annonce un executable (compresse) de 140KB. La JVM MicroJVM (J2ME) annonce une empreinte memoire inferieure a 30 KB.
Le ByteCode est plus compact pour deux raisons:
- la premiere vient de sa conception : en ByteCode Java, si tu mets '0' sur la pile, c'est un seul octet ; sur une machine 32 bits, rien que le nombre tient sur 4 octets ; tout n'est pas comme ca, mais globalement, c'est plus compact
- la seconde raison est que les classes s'appuient beaucoup sur la bibliotheque et que tu peux eventuellement mettre a jour une seule classe ; c'est moins evident si tu veux faire ca avec un programme compilé, surtout sans bibliotheque partagée
Un des interets que le ByteCode soit compact est le temps de telechargement de la mise-a-jour. Le programme tient aussi moins de place en memoire.
Ceci dit, je ne vient pas ici pour dire que Java c'est genial pour l'embarque grace a son ByteCode, surtout que je suis plutot C. Je dis juste que c'est dans certains cas, cela a des avantages. Ceci est valable pour tous les langages generant du ByteCode.