Plusieurs questions concernant Java

Bonjour,

Bonjour

J'ai plusieurs question concernant Java:

-Est-ce que Java est viable pour des applications très grandes, j'ai
lu quelque part que l'on ne pouvait pas faire des programmes de plus
de 64ko ?
Java est actuellement utilise pour les grosses applications. Dans ma

societe, on l utilise sur des projets avec plus de 1000 classes
C'est très limitant non ?
en effet :-)

Peut-on envisager l'utilisation de Java sur des aplications lourdes ?
Oui

Des exemples ?

-La rapidité et Java:
J'ai vu qu'il y avait une utilisation JIT (just in time), qui permet
une amélioration importante des performances. Mais je me demandais
s'il existait un moyen, lors de l'execution d'un programme java, que
la console java le traduise enièrement en code natif de la machine
avant son utlisation, et non pas seulement que de certaines parties du
programmes les plus souvent utilisées (je ne parle pas de faire un
exécutable)
programme source java-> traduction totale en code natif sur la machine
cible->utlisation du programme
Cela ne permetrait-il pas, après un certain temps(dû à la compliation
en code natif) d'avoir une application totalement fluide ?
Il y a eu des essais, mais pas tres pertinents a mon avis. Pas mal d

applications client serveur fonctionnent en java (swing cote client) et
ont des perfs excellentes ( le principal pb etant souvent situe entre le
clavier et la chaise...). J ai vu pas mal de perfs entre des pg natifs (
codes en c) et java. Mis a part le lancement de la jvm qui peut etre
assez long selon les config, l execution d un prg ou d un algorithme est
sensiblement le meme au bout de qq executions.

Par avance merci

J espere t avoir apporte qq eclaircissements

Fred

Alexandre

xfredox <xfredox@free.fr> wrote:

-Est-ce que Java est viable pour des applications très grandes, j'ai
lu quelque part que l'on ne pouvait pas faire des programmes de plus
de 64ko ? C'est très limitant non ?

C'est totalement faux surtout...

--
Christophe Franco

xfredox wrote:

J'ai plusieurs question concernant Java:
-Est-ce que Java est viable pour des applications très grandes,

Oui. Plus que "tres grandes" même.

Bonjour,

J'ai plusieurs question concernant Java:

-Est-ce que Java est viable pour des applications très grandes, j'ai
lu quelque part que l'on ne pouvait pas faire des programmes de plus
de 64ko ? C'est très limitant non ?
Peut-on envisager l'utilisation de Java sur des aplications lourdes ?
Des exemples ?

Bonjour,

Un ancien exemple en tête, une application swing dont la conception à
débutée il y a plus de 7 ans (!!) et qui n'est rien d'autre que l'IHM de
gestion de marché de produits dérivés d'une grande banque mondiale
présente à la défense.

Il y a 4 ans de celà la taille de son JAR d'exécution était déjà de plus
de 60Mo en compréssé et elle consomait plus de 300Mo de mémoire pour
afficher via les 6 écrans de sorties les différents graphiques
temps-réel et IHM d'aide à la décisions.

Une application super performante disposant de fonctionalités "aux
petits oignons" à faire palir tout courtier ;-)

-La rapidité et Java:
J'ai vu qu'il y avait une utilisation JIT (just in time), qui permet
une amélioration importante des performances. Mais je me demandais
s'il existait un moyen, lors de l'execution d'un programme java, que
la console java le traduise enièrement en code natif de la machine
avant son utlisation, et non pas seulement que de certaines parties du
programmes les plus souvent utilisées (je ne parle pas de faire un
exécutable)
programme source java-> traduction totale en code natif sur la machine
cible->utlisation du programme
Cela ne permetrait-il pas, après un certain temps(dû à la compliation
en code natif) d'avoir une application totalement fluide ?

Pour les taches complexes, une optimisation JIT sera toujours plus
performante qu'une "compilation native". Tout simplement, car le JIT a
une vison dynamique des choses.

Si ton application effectue tout le temps une unique chose (genre calcul
matriciel), par contre ton JIT plafonera en optimisation alors qu'une
compilation native serait plus efficace.

En clair, pour le commun des mortels, le JIT sera toujours meilleur, car
une application actuelle n'est que difficilement linéarisable non
monolithique et disposant d'E/S (IHM ou interface avec système tiers)
qui rendent son exécution difficilement prédictible a priori.

Par avance merci

Enfin, pour ce qui est de la limitation des 64ko, il s'agit de la limite
historique de la taille du code d'une méthode (et non d'une classe, ni
encore moins d'un programme) ... ce qui en fait déjà une trés (trés
trés) grosse méthode que je n'ai jamais rencontrée (considérant, qu'il
faut toujours mieux découper le code pour mieux le structurer et éviter
les blocs de code-poubelle, mais c'est un avis trés perso). Donc rien à
craindre coté limitation technique de Java !


Pour résumer, si tu peux pas le faire en Java, c'est que tu es limité
par les capacité de ta machine :o)

A+
TM

Bonsoir,

Et bien je me suis longuement posé la même question que toi.

Lorsqu'on arrive a se poser ce genre de question cela signifie, je
crois, que l'on est plus tourné vers Windows et les technologies qui lui
sont propres... je ne dois pas être très loin.

Je me suis aussi posé la question de savoir pourquoi, comme dans la
boîte pour laquelle je travaille, on développe les applications sous
Java au lieu de les développer sous, par exemple, dotnet.

Personnellement je n'ai toujours pas la réponse.

Sinon oui il est possible de développer des applications très grandes en
Java... par contre reprendre le projet d'un externe/indépendant expert
en Java n'est pas chose simple... enfin pour moi.

Bonjour,

J'ai plusieurs question concernant Java:

-Est-ce que Java est viable pour des applications très grandes,
...
Fred

khnoum wrote:

Je me suis aussi posé la question de savoir pourquoi, comme dans la
boîte pour laquelle je travaille, on développe les applications sous
Java au lieu de les développer sous, par exemple, dotnet.

Qu'est-ce que "dotnet" a et que Java n'a pas?

--
"Beaucoup de gens achètent des choses dont ils n'ont pas besoin
avec de l'argent qu'il n'ont pas (crédits & emprunts)
pour impressionner des gens qu'ils n'aiment pas."
Inconnu

Bonjour,

Tout d'abord je tiens a préciser que je ne fais aucune comparaison entre
Java & Dotnet. Donc

Voilà. Tout comme je développe en Java mais pour WinXP je me dis
pourquoi ne pas avoir opté pour une technologie directement liée et
intégrée à l'OS car le côté portabilité n'a jamais fait partie du/des
cahier/s des charges.

khnoum wrote:

Je me suis aussi posé la question de savoir pourquoi, comme dans la
boîte pour laquelle je travaille, on développe les applications sous
Java au lieu de les développer sous, par exemple, dotnet.

Qu'est-ce que "dotnet" a et que Java n'a pas?

khnoum wrote:

Je me suis aussi posé la question de savoir pourquoi, comme dans la
boîte pour laquelle je travaille, on développe les applications sous
Java au lieu de les développer sous, par exemple, dotnet.

Qu'est-ce que "dotnet" a et que Java n'a pas?

Emmm..... le nom :o)

Plus sérieusement, .net est une game produit de MS et Java une technologie.

Donc seul une comparaison produit/produit est pertinente (ou plutôt
solution/solution), par exemple les solutions Java de IBM par exemple
avec la gamme de Microsoft (y comprit le framework .net).

.net est artefact de MS en réponse à l'échec de la prise de control de
Java de 1999, car la vrai plateforme de cet éditeur reste sans conteste
Windows. Ceux sont ce SE et ces API qui contraingnent les développement
et assurent in-fine une certaine portabilité d'un PPC à une console ...
D'ailleur, il n'y a qu'à regarder comment les suffixes .net on disparut
de bon nombre de produit ou encore l'utilisation limité du mode
"managed" dans les applis et API des derniers produits de l'éditeur pour
pour comprendre, que même en interne il y a du mou dans le fil ;-)

Pour comprendre la différence, je dirais qu'il faut se poser la question
inverse :

Q : Qu'est-ce que Java a et que MS .net n'a pas ?
R : Le choix de la solution

Car en .net, lorsqu'il y a un soucis on finit toujours par dire qu'il
faut choisir la solution MS alors qu'en Java, il y a toujours plusieurs
solutions pour faire face à tout problème.

Solution choisie contre solution intégrée en clair !

A+
TM

Bonjour,

J'ai plusieurs question concernant Java:

-Est-ce que Java est viable pour des applications très grandes, j'ai
lu quelque part que l'on ne pouvait pas faire des programmes de plus
de 64ko ? C'est très limitant non ?

a une époque on était limité à des méthode de 64 ko de byte code...
il faut coder comme un porc pour faire ca...
a une époque seuls les générateur de code type JSP y arrivaient.

Peut-on envisager l'utilisation de Java sur des aplications lourdes ?
Des exemples ?

actuellement on fait tourner des JVM avec 4Go de ram

-La rapidité et Java:
J'ai vu qu'il y avait une utilisation JIT (just in time), qui permet
une amélioration importante des performances. Mais je me demandais
s'il existait un moyen, lors de l'execution d'un programme java, que
la console java le traduise enièrement en code natif de la machine
avant son utlisation, et non pas seulement que de certaines parties du
programmes les plus souvent utilisées (je ne parle pas de faire un
exécutable)

programme source java-> traduction totale en code natif sur la machine
cible->utlisation du programme
Cela ne permetrait-il pas, après un certain temps(dû à la compliation
en code natif) d'avoir une application totalement fluide ?
il y a des compilo sur linux, mais c'est contre productif.

l'expérience (les bench) ont montré que la méthode du hotspot compiler
est bien plus efficace.
en effet le compilo optimise le code en fonction de ce qu'il fait
vraiement, et non pas en fonction de ce qu'il pourrait faire...

actuellement sur pas mal d'applications réelles et complexes le code
java talone ou précède C/C++.
une des raison principales est d'ailleurs le garbage collecteur qui est
bien plus efficace que le malloc/free du C/C++

en effet en java une allocation mémoire est quasiment gratuite et seule
coute la copie des objets survivants au premier garbage (5% du total).
en plus la compatction qui en résulte améliore les perf...

d'ailleurs pas mal de conseils d'optimisation java n'ont plus lieu
d'être... genre éviter la création d'objets temporaires, faire des
allocateurs spécialisés, éviter les synchronize, évioter les
concaténation de String...

regarder:
http://www.ibm.com/developerworks/java/library/j-jtp09275.html
http://www.ibm.com/developerworks/java/library/j-jtp04223.html
http://arsenalist.com/2007/03/26/tss-java-symposium-best-talk-brian-goetz-tackles-java-performance-myths/


la meilleur manière de coder est actuellement de faire simple, direct et
de travailler sur les algorithme de haut niveau et pas sur le codage.
par exemple
http://www.ibm.com/developerworks/library/j-dcl.html

au pire on utilise des bibliothèques... mais JNI est de moins en moins
utile...

regarder pour le calcul scientifique:
http://jscience.org/

j'utilise actuellement une lib en JNI, et même si ca me coutait un
facteur 2 ou 4 de perfe je préfèrerais avoir du pure-java qui ne me
cause pas un crash JVM à chaque null-pointer.

dans une entreprise, la complexité et la difficulté font exploser le
cout du projet (des centaines de kE) mais surtout ses risques (des ME),
et aussi font effondrer les performances..
ca fait aussi effondres la maintenabilité et exploser les couts de
maintenances...

les problèmes de perf augmentent la puissance des machines, des dizaine
de kE,avec il est vrai des couts d'administration qui augmentent
(centaine de kE)...

Par avance merci

Fred

Tout à fait d'accord.

Nous développons une application d'analyse de données de contrôle non
destructif. C'est une application desktop standalone.
Historiquement, elle était développée en C++ et nous avons commencé à
utiliser java pour l'UI basée sur swing (initialement avec des objectifs de
portabilité). Je n'ai pas les métriques mais il y a plusieurs centaines de
milliers de loc.

Contrairement à nos craintes initiales, les performances sont tres bonnes.
Nous utilisons de moins en moins jni et le C++ même pour du calcul
scientifique. L'expérience montre que les différences de perf pures ne sont
pas significatives. Par contre les couts des appels avec de gros transferts
de données entre java et C++ est important. La souplesse du gc et du
multithread en java font la différence.

Le seul point négatif concernant java est le pb des perf d'affichage
graphique. Il semble que java/swing/awt n'utilise que partiellement les
possibilités matérielles d'accélération graphique. Cela évolue dans le bon
sens, mais ce n'est pas encore comparable à une application native.

"Alain" <alain@no.ne.org> a écrit dans le message de news:
467bae19$0$27375$ba4acef3@news.orange.fr...

Bonjour,

J'ai plusieurs question concernant Java:

-Est-ce que Java est viable pour des applications très grandes, j'ai
lu quelque part que l'on ne pouvait pas faire des programmes de plus
de 64ko ? C'est très limitant non ?

a une époque on était limité à des méthode de 64 ko de byte code...
il faut coder comme un porc pour faire ca...
a une époque seuls les générateur de code type JSP y arrivaient.

Peut-on envisager l'utilisation de Java sur des aplications lourdes ?
Des exemples ?

actuellement on fait tourner des JVM avec 4Go de ram

-La rapidité et Java:
J'ai vu qu'il y avait une utilisation JIT (just in time), qui permet
une amélioration importante des performances. Mais je me demandais
s'il existait un moyen, lors de l'execution d'un programme java, que
la console java le traduise enièrement en code natif de la machine
avant son utlisation, et non pas seulement que de certaines parties du
programmes les plus souvent utilisées (je ne parle pas de faire un
exécutable)

programme source java-> traduction totale en code natif sur la machine
cible->utlisation du programme
Cela ne permetrait-il pas, après un certain temps(dû à la compliation
en code natif) d'avoir une application totalement fluide ?
il y a des compilo sur linux, mais c'est contre productif.

l'expérience (les bench) ont montré que la méthode du hotspot compiler est
bien plus efficace.
en effet le compilo optimise le code en fonction de ce qu'il fait
vraiement, et non pas en fonction de ce qu'il pourrait faire...

actuellement sur pas mal d'applications réelles et complexes le code java
talone ou précède C/C++.
une des raison principales est d'ailleurs le garbage collecteur qui est
bien plus efficace que le malloc/free du C/C++

en effet en java une allocation mémoire est quasiment gratuite et seule
coute la copie des objets survivants au premier garbage (5% du total).
en plus la compatction qui en résulte améliore les perf...

d'ailleurs pas mal de conseils d'optimisation java n'ont plus lieu
d'être... genre éviter la création d'objets temporaires, faire des
allocateurs spécialisés, éviter les synchronize, évioter les concaténation
de String...

regarder:
http://www.ibm.com/developerworks/java/library/j-jtp09275.html
http://www.ibm.com/developerworks/java/library/j-jtp04223.html
http://arsenalist.com/2007/03/26/tss-java-symposium-best-talk-brian-goetz-tackles-java-performance-myths/


la meilleur manière de coder est actuellement de faire simple, direct et
de travailler sur les algorithme de haut niveau et pas sur le codage.
par exemple
http://www.ibm.com/developerworks/library/j-dcl.html

au pire on utilise des bibliothèques... mais JNI est de moins en moins
utile...

regarder pour le calcul scientifique:
http://jscience.org/

j'utilise actuellement une lib en JNI, et même si ca me coutait un facteur
2 ou 4 de perfe je préfèrerais avoir du pure-java qui ne me cause pas un
crash JVM à chaque null-pointer.

dans une entreprise, la complexité et la difficulté font exploser le cout
du projet (des centaines de kE) mais surtout ses risques (des ME), et
aussi font effondrer les performances..
ca fait aussi effondres la maintenabilité et exploser les couts de
maintenances...

les problèmes de perf augmentent la puissance des machines, des dizaine de
kE,avec il est vrai des couts d'administration qui augmentent (centaine de
kE)...

Par avance merci

Fred