Du C ou du Java dans les systèmes embarqués automobile ?

Gabriel Dos Reis

03/07/2009 à 19:22

rp writes:

| Il se trouve que Erwan David a formulé :
| >>> ça c'est poarcequ'il ets fait pour les nostalgiques du minitel.
| >> mini quoi ?
|
| > Un truc lent et lourd que les petits jeunes n'ont pas connu.
|
| Balivernes, ma fille de 3 ans 1/2 a joué en classe toute l'année
| avec...

Ah, c'est le truc que le MEN m'a demandé d'utiliser pour m'inscrire à un
certain concours, alors qu'il me demandait d'utiliser internet pour
fournir des informations pour un autre concours? gosh.

-- Gaby

Gabriel Dos Reis

03/07/2009 à 19:26

JKB writes:

| Le 03-07-2009, ? propos de
| Re: Du C ou du Java dans les systèmes embarqués automobile ?,
| Erwan David ?crivait dans fr.comp.lang.c :
| > JKB écrivait :
| >
| >> Le problème, c'est surtout quel'esprit fantassin n'existe plus. Plus
| >> il y a de couches d'abstraction (objet ou autres, je ne suis pas
| >> raciste !) plus il y a de bugs potentiels. J'en ai encore un exemple récent.
| >> La fonction astar de la libbost demande en moyenne 2s pour calculer un
| >> itinéraire sur un département français (et 600 Mo de mémoire,
| >> passons...). En réécrivant le truc en Fortran95, non seulement la
| >> vitesse d'exécution a été multipliée par 7, mais l'occupation mémoire
| >> n'est plus que de 65 Mo ! Bref, Java, C++ et les autres, ce sont
| >> vraiment des usines à gaz. Si encore il n'y avait pas de fuites...
| >
| > Là c'est plus un problème d'empilement de frameworks que de langage.
|
| Pas que. Lorsqu'on programme directement en C ou en Fortran, on
| attaque directement le problème frontalement. L'avantage, c'est qu'on
| sait exactement ce que le code va faire. Lorsqu'on attaque avec du C++
| ou du Java (ou tout autre langage objet), on ne sait plus exactement ce
| qui se passe.

uniquement si on ne sait pas ce c'est le problème. Dans ce cas, c'est
pas le langage. C'est le programmeur.

http://www.research.att.com/~bs/abstraction-and-machine.pdf

-- Gaby

Gabriel Dos Reis

03/07/2009 à 19:32

Hamiral writes:

| Erwan David a Ã©crit :
| > Terminaux de paiement (bancaire) et middleware sÃ©curisÃ© sur
| > tÃ©lÃ©phones mobiles.
| >
| > Avec une VM java (STIP,
| > http://www.globalplatform.org/specificationsdevice.asp) Ã l'intÃ ©rieur.
|
| Je pense qu'il faut un peu relativiser. Ãa, c'est juste un peu moins
| critique que du guidage de missile ou la gestion des commandes
| Ã©lectroniques d'une voiture.

Est-ce tu considÃ¨res qu'un vÃ©hicule Ã une place qui coÃ» te des centaines
de millions de dollars, qui peut causer des dÃ©gats catastrophiques s'il
fonctionne mal cours d'opÃ©ration est critique ?

| Pour ma part, j'ai une fois discutÃ© avec un type qui Ã©tait sur les
| systÃ¨mes de navigation des avions de lignes. Il m'a assurÃ© que cela se
| faisait en assembleur, sur PC... Les choses ont sans doute changÃ©
| depuis, car c'Ã©tait il y a une bonne huitaine d'annÃ©es, mais le
| constat est le mÃªme : plus l'application est critique, plus on cherc he
| Ã Ãªtre proche de la machine.

Le systÃ¨me d'exploitation qui pilote le Mars Rover est Ã©crit en C ++.
Le logiciel de capture et traitement d'images du Mars Rover est du C++.
Le CERN utilise du C++ pour les logiciels impliquÃ©s dans le LHC.

-- Gaby

Gabriel Dos Reis

03/07/2009 à 19:40

Marc Boyer writes:

[...]

| Nous travaillons avec le CEA sur des outils d'analyse statique, donc pour
| l'embarqué avion mais potentiellement aussi le nucléaire. Le langage cible
| est C. Java n'est pas à ma connaissance sur les écrans radards.

Si tu es familier avec les Joint Strike Fighters[1] et des compagnies qui
en fabriquent, tu trouvera ceci interessant :

http://www.research.att.com/~bs/JSF-AV-rules.pdf

[1] http://www.jsf.mil/

-- Gaby

JKB

03/07/2009 à 20:11

Le 03-07-2009, ? propos de
Re: Du C ou du Java dans les systèmes embarqués automobile ?,
Gabriel Dos Reis ?crivait dans fr.comp.lang.c :

JKB writes:

| Le 03-07-2009, ? propos de
| Re: Du C ou du Java dans les systèmes embarqués automobile ?,
| Erwan David ?crivait dans fr.comp.lang.c :
| > JKB écrivait :
| >
| >> Le problème, c'est surtout quel'esprit fantassin n'existe plus. Plus
| >> il y a de couches d'abstraction (objet ou autres, je ne suis pas
| >> raciste !) plus il y a de bugs potentiels. J'en ai encore un exemple récent.
| >> La fonction astar de la libbost demande en moyenne 2s pour calculer un
| >> itinéraire sur un département français (et 600 Mo de mémoire,
| >> passons...). En réécrivant le truc en Fortran95, non seulement la
| >> vitesse d'exécution a été multipliée par 7, mais l'occupation mémoire
| >> n'est plus que de 65 Mo ! Bref, Java, C++ et les autres, ce sont
| >> vraiment des usines à gaz. Si encore il n'y avait pas de fuites...
| >
| > Là c'est plus un problème d'empilement de frameworks que de langage.
|
| Pas que. Lorsqu'on programme directement en C ou en Fortran, on
| attaque directement le problème frontalement. L'avantage, c'est qu'on
| sait exactement ce que le code va faire. Lorsqu'on attaque avec du C++
| ou du Java (ou tout autre langage objet), on ne sait plus exactement ce
| qui se passe.

uniquement si on ne sait pas ce c'est le problème. Dans ce cas, c'est
pas le langage. C'est le programmeur.

Non. Tu peux dire tout ce que tu veux, mais lorsque tu écris un
malloc() en C, tu sais exactement ce que tu fais (hors problème
d'implantation du malloc sur l'OS en question). Lorsque tu crées des
objects en C++ ou en Java, tu ne sais plus ce que tu fais _exactement_.
Tu sais exactement ce que tu cherches à faire, mais tu ne sais pas
exactement ce que le compilateur va générer comme code. C'est exactement
pour cela qu'on se retrouve avec des logiciels style usine à gaz qui
utilisent les ressources des machines comme des gorets. Par contre,
c'est certainement plus rapide en terme de développement.
C'est aussi comme ça qu'on se retrouve avec des bugs sournois quasiment
impossible à trouver parce qu'on ne sait plus qui incriminer entre le
compilo java, le code source et la JVM (parce la sacro-sainte
portabilité java, elle me fait souvent rigoler, un code C, ADA ou
Fortran bien écrit étant généralement bien plus portable que du java.
J'ai un souvenir ému du passage d'un programme Java d'une jkd Sun sous
Linux à la même version sous Windows. Déjà, ce n'était pas simple. Mais
on a touché le sublime le jour où on a utilisé une J9 sous Linux/ppc ou
une JVM Sun sous Solaris et l'absurde avec une JVM HP sous OpenVMS parce
que Java a été pensé pour des chemins du type Unix et absolument pas
pour des chemins à la VMS node::disk:[directory]file.extension;version !).
Bref, plus il y a de couches, plus on fait dans l'à-peu-près et plus on
a des trucs qui merdoient joyeusement sans qu'on puisse trouver le bug
(déjà dans les compilo C il y a des surprises, alors dans ce qui est
plus complexe...) au moins de façon simple.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 03-07-2009, ? propos de
Re: Du C ou du Java dans les systèmes embarqués automobile ?,
Gabriel Dos Reis ?crivait dans fr.comp.lang.c :

JKB <knatschke@koenigsberg.fr> writes:

| Le 03-07-2009, ? propos de
| Re: Du C ou du Java dans les systèmes embarqués automobile ?,
| Erwan David ?crivait dans fr.comp.lang.c :
| > JKB <knatschke@koenigsberg.fr> écrivait :
| >
| >> Le problème, c'est surtout quel'esprit fantassin n'existe plus. Plus
| >> il y a de couches d'abstraction (objet ou autres, je ne suis pas
| >> raciste !) plus il y a de bugs potentiels. J'en ai encore un exemple récent.
| >> La fonction astar de la libbost demande en moyenne 2s pour calculer un
| >> itinéraire sur un département français (et 600 Mo de mémoire,
| >> passons...). En réécrivant le truc en Fortran95, non seulement la
| >> vitesse d'exécution a été multipliée par 7, mais l'occupation mémoire
| >> n'est plus que de 65 Mo ! Bref, Java, C++ et les autres, ce sont
| >> vraiment des usines à gaz. Si encore il n'y avait pas de fuites...
| >
| > Là c'est plus un problème d'empilement de frameworks que de langage.
|
| Pas que. Lorsqu'on programme directement en C ou en Fortran, on
| attaque directement le problème frontalement. L'avantage, c'est qu'on
| sait exactement ce que le code va faire. Lorsqu'on attaque avec du C++
| ou du Java (ou tout autre langage objet), on ne sait plus exactement ce
| qui se passe.

uniquement si on ne sait pas ce c'est le problème. Dans ce cas, c'est
pas le langage. C'est le programmeur.

Non. Tu peux dire tout ce que tu veux, mais lorsque tu écris un
malloc() en C, tu sais exactement ce que tu fais (hors problème
d'implantation du malloc sur l'OS en question). Lorsque tu crées des
objects en C++ ou en Java, tu ne sais plus ce que tu fais _exactement_.
Tu sais exactement ce que tu cherches à faire, mais tu ne sais pas
exactement ce que le compilateur va générer comme code. C'est exactement
pour cela qu'on se retrouve avec des logiciels style usine à gaz qui
utilisent les ressources des machines comme des gorets. Par contre,
c'est certainement plus rapide en terme de développement.
C'est aussi comme ça qu'on se retrouve avec des bugs sournois quasiment
impossible à trouver parce qu'on ne sait plus qui incriminer entre le
compilo java, le code source et la JVM (parce la sacro-sainte
portabilité java, elle me fait souvent rigoler, un code C, ADA ou
Fortran bien écrit étant généralement bien plus portable que du java.
J'ai un souvenir ému du passage d'un programme Java d'une jkd Sun sous
Linux à la même version sous Windows. Déjà, ce n'était pas simple. Mais
on a touché le sublime le jour où on a utilisé une J9 sous Linux/ppc ou
une JVM Sun sous Solaris et l'absurde avec une JVM HP sous OpenVMS parce
que Java a été pensé pour des chemins du type Unix et absolument pas
pour des chemins à la VMS node::disk:[directory]file.extension;version !).
Bref, plus il y a de couches, plus on fait dans l'à-peu-près et plus on
a des trucs qui merdoient joyeusement sans qu'on puisse trouver le bug
(déjà dans les compilo C il y a des surprises, alors dans ce qui est
plus complexe...) au moins de façon simple.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Vous avez filtré cet utilisateur ! Consultez son message

Le 03-07-2009, ? propos de
Re: Du C ou du Java dans les systèmes embarqués automobile ?,
Gabriel Dos Reis ?crivait dans fr.comp.lang.c :

JKB writes:

| Le 03-07-2009, ? propos de
| Re: Du C ou du Java dans les systèmes embarqués automobile ?,
| Erwan David ?crivait dans fr.comp.lang.c :
| > JKB écrivait :
| >
| >> Le problème, c'est surtout quel'esprit fantassin n'existe plus. Plus
| >> il y a de couches d'abstraction (objet ou autres, je ne suis pas
| >> raciste !) plus il y a de bugs potentiels. J'en ai encore un exemple récent.
| >> La fonction astar de la libbost demande en moyenne 2s pour calculer un
| >> itinéraire sur un département français (et 600 Mo de mémoire,
| >> passons...). En réécrivant le truc en Fortran95, non seulement la
| >> vitesse d'exécution a été multipliée par 7, mais l'occupation mémoire
| >> n'est plus que de 65 Mo ! Bref, Java, C++ et les autres, ce sont
| >> vraiment des usines à gaz. Si encore il n'y avait pas de fuites...
| >
| > Là c'est plus un problème d'empilement de frameworks que de langage.
|
| Pas que. Lorsqu'on programme directement en C ou en Fortran, on
| attaque directement le problème frontalement. L'avantage, c'est qu'on
| sait exactement ce que le code va faire. Lorsqu'on attaque avec du C++
| ou du Java (ou tout autre langage objet), on ne sait plus exactement ce
| qui se passe.

uniquement si on ne sait pas ce c'est le problème. Dans ce cas, c'est
pas le langage. C'est le programmeur.

Non. Tu peux dire tout ce que tu veux, mais lorsque tu écris un
malloc() en C, tu sais exactement ce que tu fais (hors problème
d'implantation du malloc sur l'OS en question). Lorsque tu crées des
objects en C++ ou en Java, tu ne sais plus ce que tu fais _exactement_.
Tu sais exactement ce que tu cherches à faire, mais tu ne sais pas
exactement ce que le compilateur va générer comme code. C'est exactement
pour cela qu'on se retrouve avec des logiciels style usine à gaz qui
utilisent les ressources des machines comme des gorets. Par contre,
c'est certainement plus rapide en terme de développement.
C'est aussi comme ça qu'on se retrouve avec des bugs sournois quasiment
impossible à trouver parce qu'on ne sait plus qui incriminer entre le
compilo java, le code source et la JVM (parce la sacro-sainte
portabilité java, elle me fait souvent rigoler, un code C, ADA ou
Fortran bien écrit étant généralement bien plus portable que du java.
J'ai un souvenir ému du passage d'un programme Java d'une jkd Sun sous
Linux à la même version sous Windows. Déjà, ce n'était pas simple. Mais
on a touché le sublime le jour où on a utilisé une J9 sous Linux/ppc ou
une JVM Sun sous Solaris et l'absurde avec une JVM HP sous OpenVMS parce
que Java a été pensé pour des chemins du type Unix et absolument pas
pour des chemins à la VMS node::disk:[directory]file.extension;version !).
Bref, plus il y a de couches, plus on fait dans l'à-peu-près et plus on
a des trucs qui merdoient joyeusement sans qu'on puisse trouver le bug
(déjà dans les compilo C il y a des surprises, alors dans ce qui est
plus complexe...) au moins de façon simple.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

espie

03/07/2009 à 20:30

In article ,
JKB wrote:

Non. Tu peux dire tout ce que tu veux, mais lorsque tu Ã©cris un
malloc() en C, tu sais exactement ce que tu fais (hors problÃ¨me
d'implantation du malloc sur l'OS en question). Lorsque tu crÃ©es des
objects en C++ ou en Java, tu ne sais plus ce que tu fais _exactement_.
Tu sais exactement ce que tu cherches Ã faire, mais tu ne sais pas
exactement ce que le compilateur va gÃ©nÃ©rer comme code. C'est exactement
pour cela qu'on se retrouve avec des logiciels style usine Ã gaz qui
utilisent les ressources des machines comme des gorets. Par contre,

Je ne suis pas du tout d'accord sur la confusion joyeuse que tu
entretiens ici entre C++ et Java. En C++, sur une implementation sans
garbage-collector (ce qui est le cas habituel), tu peux savoir exactement
ce qui va se passer en termes d'allocation memoire (hormi la suppression
par le compilateur de certaines copies d'objets, ce qui veut juste dire
que le code genere est plus simple que ce que tu vois). Ca n'est pas
simple, mais c'est bien defini et extremement precis (et il y a dans le
langage tout ce qu'il faut pour gerer des cas plus tordus, en particulier,
tu peux allouer des choses de facon tres specifique si necessaire, ca a ete
explicitement concu pour pouvoir faire de l'embarque).

Des que tu rajoutes un GC, ca devient la merde. Je ne sais pas s'il existe
des implementations de java prevues pour de l'embarque, sans GC (j'espere
qu'il y en a) et je ne sais pas a quel point les bibliotheques susceptibles
d'etre utilisees savent dans quel environnement elles evoluent).

Pour moi, c'est une difference assez fondamentale: tu as d'un cote un langage
extremement precis, ou tu peux controler les choses avec le meme niveau de
precision que le C (mais C++ est beaucoup, beaucoup plus gros et complexe
a maitriser que le C), et de l'autre cote un langage de relativement haut
niveau, avec une gestion memoire et une gestion de threads qui est censee
marcher, et que tu controles assez peu. Ce sont les modeles de fonctionnement
"par defaut" des deux langages. Je suis sur que tu peux trouver des exceptions,
mais ca ne laisse pas bien presager vis-a-vis des programmeurs que tu pourras
trouver pour faire de l'embarque.

Tiens, m'etonnes que JP Bourguignon ne se soit pas encore pointe pour nous
dire qu'on avait tous faux et qu'il fallait faire de l'embarque en
common-lisp :-P

In article <slrnh4sif8.tkq.knatschke@rayleigh.systella.fr>,
JKB <wilhelm-siegfried.knatschke-koenigsberg@chezmoi.com> wrote:

Non. Tu peux dire tout ce que tu veux, mais lorsque tu Ã©cris un
malloc() en C, tu sais exactement ce que tu fais (hors problÃ¨me
d'implantation du malloc sur l'OS en question). Lorsque tu crÃ©es des
objects en C++ ou en Java, tu ne sais plus ce que tu fais _exactement_.
Tu sais exactement ce que tu cherches Ã faire, mais tu ne sais pas
exactement ce que le compilateur va gÃ©nÃ©rer comme code. C'est exactement
pour cela qu'on se retrouve avec des logiciels style usine Ã gaz qui
utilisent les ressources des machines comme des gorets. Par contre,

Je ne suis pas du tout d'accord sur la confusion joyeuse que tu
entretiens ici entre C++ et Java. En C++, sur une implementation sans
garbage-collector (ce qui est le cas habituel), tu peux savoir exactement
ce qui va se passer en termes d'allocation memoire (hormi la suppression
par le compilateur de certaines copies d'objets, ce qui veut juste dire
que le code genere est plus simple que ce que tu vois). Ca n'est pas
simple, mais c'est bien defini et extremement precis (et il y a dans le
langage tout ce qu'il faut pour gerer des cas plus tordus, en particulier,
tu peux allouer des choses de facon tres specifique si necessaire, ca a ete
explicitement concu pour pouvoir faire de l'embarque).

Des que tu rajoutes un GC, ca devient la merde. Je ne sais pas s'il existe
des implementations de java prevues pour de l'embarque, sans GC (j'espere
qu'il y en a) et je ne sais pas a quel point les bibliotheques susceptibles
d'etre utilisees savent dans quel environnement elles evoluent).

Pour moi, c'est une difference assez fondamentale: tu as d'un cote un langage
extremement precis, ou tu peux controler les choses avec le meme niveau de
precision que le C (mais C++ est beaucoup, beaucoup plus gros et complexe
a maitriser que le C), et de l'autre cote un langage de relativement haut
niveau, avec une gestion memoire et une gestion de threads qui est censee
marcher, et que tu controles assez peu. Ce sont les modeles de fonctionnement
"par defaut" des deux langages. Je suis sur que tu peux trouver des exceptions,
mais ca ne laisse pas bien presager vis-a-vis des programmeurs que tu pourras
trouver pour faire de l'embarque.

Tiens, m'etonnes que JP Bourguignon ne se soit pas encore pointe pour nous
dire qu'on avait tous faux et qu'il fallait faire de l'embarque en
common-lisp :-P

Vous avez filtré cet utilisateur ! Consultez son message

In article ,
JKB wrote:

Non. Tu peux dire tout ce que tu veux, mais lorsque tu Ã©cris un
malloc() en C, tu sais exactement ce que tu fais (hors problÃ¨me
d'implantation du malloc sur l'OS en question). Lorsque tu crÃ©es des
objects en C++ ou en Java, tu ne sais plus ce que tu fais _exactement_.
Tu sais exactement ce que tu cherches Ã faire, mais tu ne sais pas
exactement ce que le compilateur va gÃ©nÃ©rer comme code. C'est exactement
pour cela qu'on se retrouve avec des logiciels style usine Ã gaz qui
utilisent les ressources des machines comme des gorets. Par contre,

Je ne suis pas du tout d'accord sur la confusion joyeuse que tu
entretiens ici entre C++ et Java. En C++, sur une implementation sans
garbage-collector (ce qui est le cas habituel), tu peux savoir exactement
ce qui va se passer en termes d'allocation memoire (hormi la suppression
par le compilateur de certaines copies d'objets, ce qui veut juste dire
que le code genere est plus simple que ce que tu vois). Ca n'est pas
simple, mais c'est bien defini et extremement precis (et il y a dans le
langage tout ce qu'il faut pour gerer des cas plus tordus, en particulier,
tu peux allouer des choses de facon tres specifique si necessaire, ca a ete
explicitement concu pour pouvoir faire de l'embarque).

Des que tu rajoutes un GC, ca devient la merde. Je ne sais pas s'il existe
des implementations de java prevues pour de l'embarque, sans GC (j'espere
qu'il y en a) et je ne sais pas a quel point les bibliotheques susceptibles
d'etre utilisees savent dans quel environnement elles evoluent).

Pour moi, c'est une difference assez fondamentale: tu as d'un cote un langage
extremement precis, ou tu peux controler les choses avec le meme niveau de
precision que le C (mais C++ est beaucoup, beaucoup plus gros et complexe
a maitriser que le C), et de l'autre cote un langage de relativement haut
niveau, avec une gestion memoire et une gestion de threads qui est censee
marcher, et que tu controles assez peu. Ce sont les modeles de fonctionnement
"par defaut" des deux langages. Je suis sur que tu peux trouver des exceptions,
mais ca ne laisse pas bien presager vis-a-vis des programmeurs que tu pourras
trouver pour faire de l'embarque.

Tiens, m'etonnes que JP Bourguignon ne se soit pas encore pointe pour nous
dire qu'on avait tous faux et qu'il fallait faire de l'embarque en
common-lisp :-P

Erwan David

03/07/2009 à 20:49

(Marc Espie) écrivait :

Des que tu rajoutes un GC, ca devient la merde. Je ne sais pas s'il existe
des implementations de java prevues pour de l'embarque, sans GC (j'espere
qu'il y en a) et je ne sais pas a quel point les bibliotheques susceptibles
d'etre utilisees savent dans quel environnement elles evoluent).

Javacard jusqu'à la v2 n'a pas forcément de GC. Javacard3 en a
obligatoirement un...

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé

Gabriel Dos Reis

03/07/2009 à 21:24

JKB writes:

[...]

| > uniquement si on ne sait pas ce c'est le problème. Dans ce cas, c'est
| > pas le langage. C'est le programmeur.
|
| Non. Tu peux dire tout ce que tu veux,

Non seulement je peux dire tout ce que je veux, mais je peux aussi
étayer mes allégations.

| mais lorsque tu écris un
| malloc() en C, tu sais exactement ce que tu fais

et comment peux-tu prouver cela ?

| (hors problème
| d'implantation du malloc sur l'OS en question). Lorsque tu crées des
| objects en C++ ou en Java, tu ne sais plus ce que tu fais _exactement_.

Erreur. Sit *tu* ne sais pas ce que tu fais, alors tu as un problème de
compréhension -- ce n'est pas le langage.

| Tu sais exactement ce que tu cherches à faire, mais tu ne sais pas
| exactement ce que le compilateur va générer comme code.

Huh? Et comment le sais-tu pour le C ?

| C'est exactement
| pour cela qu'on se retrouve avec des logiciels style usine à gaz qui
| utilisent les ressources des machines comme des gorets.

Encore une fois, tu confonds incompétence de programmeur avec outil --
mais je ne suis pas trop surpris, en lisant les lignes auxquelles je
réponds.

-- Gaby

Gabriel Dos Reis

03/07/2009 à 21:27

(Marc Espie) writes:

[...]

| Des que tu rajoutes un GC, ca devient la merde.

Il y a GC et GC, de la même façon qu'il y a framework et framework.
Il y a certains programmes que je trouve plus facile à écrire,
comprendre, évoluer, et maintenir lorsqu'un a un bon GC que sans GC dud
tout.

[...]

| Tiens, m'etonnes que JP Bourguignon ne se soit pas encore pointe pour nous
| dire qu'on avait tous faux et qu'il fallait faire de l'embarque en
| common-lisp :-P

Je suis aussi étonné :-)

-- Gaby

Zeldus

03/07/2009 à 22:53

"JKB" a écrit dans le message de
news:

compilo java, le code source et la JVM (parce la sacro-sainte
portabilité java, elle me fait souvent rigoler, un code C, ADA ou
Fortran bien écrit étant généralement bien plus portable que du java.
J'ai un souvenir ému du passage d'un programme Java d'une jkd Sun sous
Linux à la même version sous Windows. Déjà, ce n'était pas simple. Mais
on a touché le sublime le jour où on a utilisé une J9 sous Linux/ppc ou
une JVM Sun sous Solaris et l'absurde avec une JVM HP sous OpenVMS parce
que Java a été pensé pour des chemins du type Unix et absolument pas
pour des chemins à la VMS node::disk:[directory]file.extension;version !).

En même temps, tous les éditeurs d'applis mobiles téléphones / smartphones /
PDA (essentiellement les jeux mais pas seulement) sont bien contents d'avoir
JavaME à leur disposition car avec plus de 1000 modèles de téléphones dispo
utilisant des processeurs différents, une quantité de RAM différente, une
résolution d'écran différente et j'en passe, il y aurait de quoi s'arracher
les cheveux. Aujourd'hui, ce qui permet de distribuler le même code écrit
pour un Sony Ericsson sur un Nokia ou un Motorola, c'est bien Java, sachant
qu'on trouve un peu de tout dans les processeurs embarqués dans les
terminaux mobiles. Nokia a essayé le C++ avec Symbian, et bien, ils sont
toujours les seuls à proposer du C++ et ils ont dû se mettre à Java pour
pouvoir permettre à leurs utilisateurs d'utiliser les softs dispo sur les
portails wap.

Et le business des logiciels pour téléphones / smartphones est en très forte
expansion, y a qu'à voir tous les constructeurs qui lancent leurs boutiques
de vente en ligne.

Pierre

Du C ou du Java dans les systèmes embarqués automobile ?

10 réponses

Veuillez sélectionner un problème