Salut  
 
est il interressant d'utiliser java (plutot que c# ou c++ )pour dévellopper une application (non web) qui ne va tourné que sur un poste ?
 
c la meme chose ?  
c mal ?
c bien ?
on s'en fou ?

 
Tout dépend de l'application et si elle comporte des parties spécifiques à l'OS choisis ... Tu peux pas formuler une vraie question, à savoir une question technique en donnant l'environnement tecnhique. Parce que dans l'absolu ca n'a pas vraiment de sens

pour faire quoi ?

en fait je veux savoir si c con d'utiliser java pour par exemple faire un notepad qui ne fonctionnera que sur une machine
 
en réalité c pas un notepad mais une application qui permet de commander un robot depuis une interface graphique, avec camera, synchro entre l'appli et la video(tu clique sur l'ecran et le robot y va ( en 2D biensur ),...

Te prends pas la tête avec ça, de toutes façon si tu as des appels natifs ils devront être encapsulés proprement, donc fais ton application en java "normal", fais tes appels-natif normalement et si portage il doit y avoir, tu le fera à ce moment là. Si ton application est bien conçue d'un point de vue objet, les appels natif seront ségrégués du code objet et plus ou moins isolés.

 
en pensant java n'est pas devenu aussi populaire grace à sa portabilité mais plutôt à sa facilité de programmation

la portabilité joue aussi beaucoup : pouvoir développer sur son poste de travail sous windows et passer les classes sur le site de prod sous unix ou linux c'est quand même super pratique et très courant en entreprise

 
c'est quand même pas ça qui à fait démarré java dans les années 90

Je pense que si l'outils est prévu pour ne tourner que sous Windows, alors la question se pose vraiment.
En effet, sous Windows, plus que sous X-like, le Java offre des performances assez dégradées par rapport aux autres langages cités.
 
D'un autre côté, mise à part cas précis, je suis convaincu que la portabilité est un argument qui n'est pas si convinquant que ça. En effet, si on développe proprement en C++, et qu'on évite de jouer comme un tarré avec des pointeurs, et qu'on privilégie le modèle thread plutôt que le modèle multi-process, on atteindra d'excellentes performances, que ce soit sous Windows ou sous Linux. Et si c'est bien codé, la compilation d'un OS à l'autre ne nécessite que des modifications mineures et isolées (perso, tous les programmes que j'ai écrit en C - bon, ok, ils étaient très limités ) compilaient sous Linux et Windows sans en modifier une ligne. Faut juste recompiler pour chaque plateforme.
Sinon, pour finir avec le C#, ce dernier est bien plus rapide que le Java sur environement Microsoft. Et ça va devenir de plus en plus vrai avec l'évolution de Windows, qui suportera nativement l'architecture .NET
Deplus, je rappelle que le C# est prévu pour être portable. Actuellement, il n'y a pas encore de SDK très évolué pour Linux, mais ils sont déjà amplement suffisant pour faire pas mal de choses. Donc la question java-c# ne se pose pas vraiment à ce niveau. Si aujourd'hui c'est sous M$, alors il y a fort à parier que d'ici que tu aies besoin de le passer sous Linux, un SDK digne de ce nom soit disponible.
 
Par contre, si l'appli est prévue à l'origine sous Linux, Java reste une bonne option, car les perfs sont assez bonne sur cet environnement.
 
Compilateurs et SDK C# pour Linux : (et qu'on arrête de me prendre la tête avec ça maintenant hein )
 
http://www.go-mono.com/
http://www.southern-storm.com.au/portable_net.html (tourne sur la plupart des architectures de processeurs et OS du marché)
http://www.dotgnu.org/
http://sourceforge.net/projects/dotsquare/
http://sourceforge.net/projects/ocsdnet/

 
euh ca sert à qqch de filer des liens qui pointent vers un trou noir  

y'en a quand même 3 au dessus, qui donnent des liens vers des compilos déjà fonctionnels, dont notamment le 3° qui a été réalisé avec l'aide de M$ (c'est un des deux premiers à avoir commencé, et ont bénéfié de documents internes de M$ lors du développement de leur version pour windows)

 
et ... je n'ai pas parlé des 3 premiers liens que je sache  

vi, comme d'hab, je poste 3 vérités et 2 erreurs, et tu m'allume sur les deux erreurs
 
pis en plus, j'ai dis que ce sera pour un portage future, d'ici là, ces deux liens seront remplis

 
puisque c'est pas directement ms qui supporte les versions .net sur les autres os, ils seront toujours en retard, les performances d'être moins bonne et ça risque de ne pas être pleinement compatible
 
je doute que sur les millions de programme en c++ qu'il existe, qu'ils soit tous "malpropre"
porte un programme c++ vers linux, macos, unix, solaris ne se fait pas comme ça, surtout pour un gros projet...
encore pire si on a une couche graphique
 
"Sinon, pour finir avec le C#, ce dernier est bien plus rapide que le Java sur environement Microsoft."
plus que très exagéré

MagicBuzz > Aux dernières nouvelles, il me semblait que c'était la VM Windows qui marchait le mieux, dans le panel des VMs développées par Sun.

+1
 
mais faut pas oublier les autres machines virtuel aussi... il n'y a pas juste sun

pour le premier point :
- M$ a reçu l'interdiction de développer pour x-like. C'est ainsi qu'IE sous Unix n'existe plus depuis le 5.01, et que M$ a dépensé des dizaines de millions de dollard dans le vide pour encourager Mac à développer MacOS X (à la base, M$ espérait s'en servir de tremplin pour s'implanter sur les plateformes X-like
- Si M$ avait développé un framework pour X-like, il aurait été encore plus mal perçu que là où ils n'ont rien fait. Des tas de personnes n'auraient rien trouvé de mieu que de l'éplucher, ligne par ligne pour en trouver les moindres bugs et mauvaises optimisations, et ça aurait fait la une de tous les sites de nerdz, ce forum le premier.
- Ta critique va à l'encontre de la doctrine de la plupart des membres ici qui prétendent que le GNU/Libre c'est mieu que le proprio/soumis à licence, que ça évolue plus vite, que c'est plus performant et que le support est meilleur. donc faudrait qu'on se mette tous d'accord : GNU c'est de la merde ou un super truc ? et me répondez pas que vu que c'est M$ qui fixe les règles du jeu, que ce soit GNU ou pas ça change rien, c'est de la merde quand même, et que de toute façon M$ refuse de donner des docs pour que les développeurs GNU puissent bosser, puisque c'est faux.
 
La seconde critique, j'entends par "propre" le fait de prévoir la portabilité quand on développe un programme qui à pour but d'être compilé sur différentes plateformes. le c++ est suffisament vaste, librairies graphiques comprises, pour être capable de faire du code OS-indépendant. Evidement, c'est plus contraignant qu'en Java, et on aura toujours des routines qui seront forcément spécifiques. Ca nécessitera toujours une retouche, mais qui peut être minime si on y a pensé avant de se lancer comme un autiste dans le code.
 
Pour la troisième phrase, je maintient que sur plateforme Windows (du moins 2000 et +) l'environnement .NET est nettement plus rapide que Java, mise à part évidement certains cas particuliers (chuis sûr qu'en QBASIC on peut trouver des trucs plus rapides qu'en C# aussi...)

OK, je savais pas. La tendance se serait donc inversée ? Moi je suis resté à l'époque où la VM sous Windows était non seulement pas très stable, mais aussi très lente.

A la boite on utilise une version très particulière de la VM d'IBM, pour cause de produits IBM. D'après ce que j'ai entendu, l'offre IBM en matière de VM est très hétérogène et flirte parfois avec la bouse de vache.

 
il doit avoir des dinosaures près de chez toi

 
la vm d'ibm est reconnu pour être assez rapide mais $$$

bah vu ce qui se disait à l'époque pour la défense de la VM de Sun, on pouvait s'attendre à ce que ça n'ait pas évolué depuis :
Microsoft à l'époque aurait volantairement obstrué son système et falcifié les documentations de spécification de son OS pour que Sun aille dans le mur.
Microsoft étant propriétaire de son système et par conséquent de ces docs, s'il avait vraiment fait ça, il aurait été intouchable au niveau légal, donc y'a pas de raison pour que ça ait changé.
Vu qu'à l'époque, ces arguments, pas plus que java ne m'avaient convaincus, j'ai pas cherché à approfondir mes recherches, ni à suivre l'évolution de la chose...

 
depuis quand ms suit les règles  
 

 
ça reste fortement à prouver...
tu fais une petite recherche sur le web et tu trouves plusieurs exemples qui le démondre...
 
un petit exemenple trouvé en 2 secondes
http://www.freeroller.net/page/ceperez/20030520
 
pour ce que j'ai pu essayé et voir les performances se ressemble
tout est question d'optimisation quoi
on peut arriver en java à faire des truc aussi rapide qu'en c
d'ailleur un mec dans un de mes cours est arrivé 3 troisième nivea vitesse pour des tris et recherche

ils ont été en cours et sun à gagné il me semble
 
de toute façon il y aurait eu plainte pour monopole et tout le tralala

Le hic c'est qu'il n'y a pas qu'une VM. Il y a pléthore en vérité.

 
ça je sais mais j'ai jamais vu une vm de ibm qui était vraiment médiocre niveau performance

j'sais pas pourquoi, mais j'ai un peu du mal à croire que MS ait aidé un projet qui indique ceci en guise d'accueil sur son site:

J'en ai une qui est livrée avec un compilateur qui ne sait pas compiler, si tu veux.

 
quel version, quel compilo, quel année, quelle plateforme?

Je te donne les références demain si j'y pense. Si j'oublie, voici quand même ce que je sais :
 
C'est un compilo IBM que ma boite utilisait avant que j'arrive. Il générait du bytecode qui n'était pas exécutable. Pour info actuellement on utilise deux compilos IBM (d'autres que le précédent) un SDK 1.3 IBM qui date d'octobre 2002 et qui corrige la précédente version au niveau JIT et celui de WebSphere 5 qui fait aussi de la merde sur un ensemble de classes. Contournement : avant de déployer, on compile avec le premier compilo, on fait un jar de ces classes et on supprime les src et les class, pour que WS se contente d'utiliser nos classes.
 
C'est très mal expliqué.

 
Ca sert à quoi?
 
(NB: en fait ça veux rien dire)
 

Bah à rien justement
 
C'est comme si tu compiles un programme en C, et qu'au moment de le démarrer, tu à le sablier, puis plus rien

De mon point de vue, à rien. De celui d'IBM, à te vendre de la mise à jour, du support...

 
A quoi bon tester la compilation avec un compilo qui génère du bytecode pourri?  

Parcequ'avec websphere, t'as pas trop le choix. c'est du java à la sauce IBM. Je suis pas sûr qu'un programme compilé normalement avec un autre compilo tourne dessus. Et encore moins sûr qu'un programme écrit poru websphère soit compilable dans un autre compilo que ceux d'IBM

Non, écoute. Arrête de savoir tout sur tout. C'est n'importe quoi ce que tu viens d'écrire.
 
Il y a des specs sur la machine virtuelle en général. Les gens d'IBM même si je ne les porte pas dans mon coeur font un boulot correct. En général ça marche. On rencontre quelques problèmes avec leurs produits, comme avec tous ceux de nos fournisseurs.

 
c'était le post de trop. Tout est absolument faux dans ton post. Essaie de parler des choses que tu connais, surtout sur un forum public  

 
Je me souviens qu'il était impossible d'acceder directement a un conteneur EJB d'un websphere (3.5 je crois) avec une JVM non IBM. Depuis ca a été un peu amélioré...

j'avais ce genre de souvenirs aussi, d'où mon post.
mais bon, maintenant, je risque plus de parler de ce dont "je ne connais pas", vais faire l'impasse totale sur 90% des topics de ce forum, ça sera bien mieu. websphere s'est peut-être un peu normalisé depuis un an, mais j'ai de gros doutes à ce sujet (sinon je vois pas comment ils justifieraient un tel prix pour leur VM, vu qu'il y en a des plus performantes qui sont gratuites et plus officielles, celle de Sun par exemple). mais bon, à partir du moment où y'a marqué "java", c'est forcément 100% portable et 100% standard et de toute façon y'a que M$ pour se foutre des normes et des standard... n'oubliez pas que c'est IBM qui a lancé M$, comme on dit dans ma campagne, tel père tel fils.