A vous lire, c'est déjà le cas...

donc un sdk limité par rapport a la version business.. esperons qu'il ne bride que des fonctions bien pro, peu utile pour un programmeur standart...

mmmm ... rien n'est encore sur pour le moment! donc ...

Pour clore ce faux débat, regardez ça (3ème post en partant du bas) :
http://www.developpez.net/forums/d [...] lector-g1/

Sun précise que le G1 n'est utilisable que sous "Java support contract" (donc support technique) et qu'il est désactivé par défaut uniquement parce qu'il n'a pas encore été testé sur le terrain.
Sun ajoute que n'importe qui peut l'activer (En indiquant même la commande !) et que le G1 sera fourni et utilisé par défaut dans le JDK7 gratuitement et sans condition.

En outre c'était déjà un projet de SUN de faire payer, pour contrer sur le marché pro (celui qui paie car il a besoin de du support) jrockit qui est bien meilleure niveau GC et qui est payant

Mais c'est bien connu, Oracle est "le grand méchant" comme Microsoft est le satan ....

Oui, enfin comme je l'ai écrit, rien n'indique que cela soit la conséquence du rachat par Sun. Et à dire vrai, je pense même que ça n'a rien à voir

@Kador

Maintenant que BEA appartient aussi à Oracle, on n'est pas dans la merde : ils contrôlent le marché et feront la politique qu'ils souhaitent.

Ca fait quand même un peu MS à force : on rachète tous les acteurs d'un marché et on le verrouille à sa sauce.

Enfin bon, business is business !

De toute facon le java est bien parce qu'il est multiplateforme mais c'est un langage lourd au possible à éxécuter et impossible à optimiser pour économiser de la puissance.
Malheureusement aucun autre langage n'est aussi universel.

Troll poilu repéré.

De quel marche parles-tu?

Et OpenOffice ... c'est pour quand ?

Car c'est aussi Sun qui le distribut, du moins d'après ce que j'ai vu à son installation. Alors, je me demande si une fois bien ou mieux implanter ... il font faire pareil.

et bah y'en a du troll et du bien poilu, ainsi que de l'information non vérifié par ici...

enfin debat clos, Sun c'est fendu d'un communiqué pour couper court a la rumeur...
c'est rigolo que ca parte a partir du GC car justement durant la keynote d'hier a la javaone un des intervenants a charié la dessus

et attilavv, pour info, OpenOffice est derivé de StarOffice qui est aussi un produit Sun.... les deux sont tres tres proches, sauf que StarOffice est vendu avec du support derriere...
donc non OpenOffice deviendra pas payant, puisque il est au contraire issu d'un produit payant...

Non ce n'est malheureusement pas un troll mais un des point faible du langage, mais tout ce qui tourne avec une machine virtuelle pour interprété le langage en temps réel est forcément moins optimisé et donc moins performant ou moins économique qu'un programme compilé pour une architecture donnée.
Certes, c'est plus facile à gérer pour celui qui développe, mais c'est plus efficace de compiler pour chacune des architectures visées.
C'est justement parce que le java est un langage qui se distance totalement des architectures qu'il est très enseigné, à mon grand désespoir.

C'était ce que je pensais également "intuitivement", mais il me semble avoir lu je-ne-sais-où (et forcement, impossible de retrouver cet article) que ce n'était pas forcement le cas... Un spécialiste dans la salle ?

C'est quand même plus compliqué que trancher directement en déclarant que la jvm implique nécessairement des performances plus faibles. Il faut tout de même se souvenir que quelque soit le langage mis en place (pour le web en tout cas), il n'existe techniquement pas d'environnement dénué de "machine virtuelle" (sauf si le site est full html...).

Après, soyons clairs: Java est un "bon" produit, sauf qu'il est utilisé à tort et à travers. selon l'ampleur du boulot à mener, java peut être recommandé ou au contraire proscrit, simplement de par sa relative complexité de mise en place. Concernant les performances brutes, à fonctionnalités égales, s'il s'agit d'un exécutable, un programme pondu avec un langage proche de la machine (C++ par exemple) sera potentiellement plus performant. En revanche, il sera plus difficile de porter le dit programme sur un OS différent de celui d'origine.

De là, deux constats:
- Avoir une surcouche logicielle type JVM réduit les performances
MAIS
- Il permet une portabilité accrue.

Ceci étant, cette dernière notion est hypocrite dans les faits puisque l'on ne réinvente pas le monde tous les matins. Une politique de changement dans une grande entreprise prend du temps, et d'ici à ce que le parc change d'OS (abandon des serveurs Web sous Linux pour passer sous Windows par exemple), il en coulera de l'eau sous les ponts.

Il y aura toujours une partie de la puissance utilisée par la machine virtuelle (overhead). Cecidit, un code très étudié et le plus léger possible peut être performant, même avec une machine virtuelle.

Coder une application en language machine reviendrait un peu trop cher à l'heure actuelle... Heureusement que des langages tels que le Java, l'infrastructure .NET ou le Perl existent

Pour info, je suis admin de systèmes Java, pas les plus simples: Portails SAP J2EE... Et c'est vrai qu'un Garbage collector un peu mieux foutu ne serait pas du luxe... (Enfin, SAP hors pour les dernières versions, on est toujours en JDK 1.4.2.22 obligatoire).

Je développe en Java, C++, et de nombreux autres langages. Et "locheloche" a effectivement raison. Java consomme beaucoup plus de ressources mémoire et cpu puisque la machine virtuelle doit faire le travail d'interprétation. Et le résultat est forcément plus lent. Certains diront qu'on peut compiler le java, ce qui est faut ou plutôt un abus de langage. En fait on peut précompiler le java (bytecode). C'est plus rapide pour la machine virtuelle mais ça reste moins rapide qu'un programme compilé (il y a toujours une interpretation).
Par contre, l'avantage de Java est de pouvoir fonctionner sur toute plateforme pour laquelle une machine virtuelle java a été développée. Donc l'avantage, c'est qu'un ancien programme java pourrait (en théorie car il reste quelques librairies propriètaires parfois, notamment quand on regarde le développement sur téléphone portable) fonctionner sur une nouvelle plateforme où une machine virtuelle est disponible, sans que l'on est rien d'autre à faire.

non mais sans dec, vous avez déjà vu un soft java qui soit rapide ou qui ne soit pas moche au possible ?
Et quand ça ressemble plus ou moins à qq chose, généralement c'est bien bugué à souhait (ex : SQLDeveloper)
Moi je dis, Oracle devrait carrément tuer dans l'oeuf ce pseudo langage tout pourri et son framework daubifique...
Surtout quand on le compare au framework .NET...

Bien que je sois d'accord avec toi dans l'idée, Java a énormément de traction, que ce soit en entreprise ou dans les écoles d'info.
Le tuer alors que le marché ne jure que par ça, c'est stupide. Java est une mine d'or, s'ils continuent à l'améliorer y'a moyen d'en faire quelque chose pour contrer l'émergence de .NET.

pas bon tout ça

Tuer le java... non, mais tuer les mauvaises pratiques: oui et mille fois oui!

Avec l'esprit "open source" qui est faussement véhiculé par le java (librairies gratuites, mais compétences vendues au prix du platine), on se retrouve avec des quantités stupides de concurrents pour faire la même chose: rien que pour les lectures écritures XML il y a des dizaines de solutions... et je ne parle pas des "pseudo" librairies complémentaires qui se sont disséminées sur le web.

Java n'est pas, dans le principe, un mauvais produit, d'autant qu'il est transverse aux plate formes (depuis le téléphone portable jusqu'aux serveurs d'entreprise, qui dit mieux?), mais il pâtit d'une part de son mode de fonctionnement, et d'autre part du boulot de sagouin fait par les développeurs!

Et puis ... n'oublions pas que .NET est propriétaire, et que pour développer dessus il faut rester sous Windows (alors que Eclipse par exemple, est multi plateforme). J'ajoute enfin que, pour avoir bossé avec les deux, je préfère, et de loin l'environnement dev de Eclipse, et la partie serveur IIS de .NET...

il ne faut pas oublier qu'apres, on peut avoir des procs qui savent "lire" le bytecode directement... ce qui permet de gagner encore en temps d'excecution ce qui peut etre interessant dans certains cas

et pour reprendre un des exemples qui est/etait visible en ce moment a la javaone, le Chicago Board Options Exchange utilise un systeme full Java depuis 2001 et autant dire que ca a besoin d'etre performant et rapide ^^ (bien qu'il ait fait une joke sur le garbage collector ^^ )



a noter l'annonce cette semaine de pas mal de gros poids lourd du secteur (orange/sony/nokia/...) pour enfin allez vers une plateforme commune pour le dev sur appareil mobile et arrêter de faire des lib proprio a droit et gauche...

Pour répondre à e-TE_iut qui confirme plus ou moins ce que je disais en apportant des nuances, et peut-être pour corriger ses erreurs de jeunesse (enfin je pense, d'ailleurs je ne suis pas bien vieux non plus avec mes 30 ans, mais depuis tout jeune je programme, j'ai donc suivi un peu les évolutions des langages de programmation, langage machine directement en entrant les codes en mémoire sans mnémonique, BASIC, C++, Java, ... enfin je ne suis pas là pour faire la liste de tous les langages ...), le fait d'avoir un processeur qui exécute directement du bytecode Java ne signifie pas qu'il sera vraiment performant (en tout cas plus qu'un processeur exécutant du code machine bien pensé ou du code C compilé s'il n'utilise pas trop de librairies bidons).
En effet, pour comprendre plus facilement il suffit de revenir au langage basic. Ce langage a une commande très intéressante qui fait plein de chose : la commande PRINT.
En mémoire sur nos vieux ordinateurs 8 bits qui avaient un "BASIC" en ROM, il suffisait d'un octet pour coder la fonction PRINT suivi bien entendu des arguments. Cela ne signifie pas pour autant que la machine exécutait très rapidement un PRINT car cette commande pouvait faire une multitude de chose donc pour une tâche donnée, le code machine correspondant était beaucoup plus lourd avec beaucoup plus d'opérations à effectuer que si ce qu'on souhaitait faire avec la commande PRINT avait été directement programmé en code machine (le code serait ainsi beaucoup plus épuré, il irait à l'essentiel et ne ferai pas des opérations sur les registres pour rien). C'est pareil pour un processeur qui exécute du bytecode Java. Combien lui faut-il de cycles pour réaliser réellement la commande ? Il doit faire un enchainement d'opérations qui ne sont peut-être (et même certainement) pas toutes nécessaires pour le résultat escompté. C'est le prix à payer pour utiliser des langages dit de HAUT NIVEAU (même si le JAVA ne fait pas spécialement partie de ceux-là, mais il a tendance à le devenir avec l'utilisation de librairies parfois douteuses comme pour le C++ d'ailleurs).
Bon ce post est déjà assez long comme ça et je pense que tout le monde a perçu l'idée. Désolé si je n'ai pas été assez clair mais j'ai la flegme de me relire.

Pour ce qui concerne la plateforme commune pour les téléphones portables ça serait vraiment une bonne chose mais j'attends de voir (pour 2019 ?? quand les téléphones n'existeront plus ... Bon j'arrête, ça c'est vraiment une remarque pour rien).

Bon désolé d'avoir tant diverger, cela ne concerne plus le sujet de départ.