(6. Which MPEG-4 Profile does the decoder support?
The decoder fully supports the MPEG-4 Visual Simple Profile (ISO/IEC 14496-2), with the exception of RVLC. )
La question: "et un encodeur pour Linux ?" a une reponse dans le forum:
"As for support for Linux, that may be interesting mainly because we have some other encoders written for AIX (unix). At this point it is an issue if someone realy wants it and is ready to pay. Otherwise, it will be done if we feel there is a good market for that."
et c'est pas un Logiciel Libre, au cas ou vous en doutiez encore.
Aller plus loin
- le codec (10 clics)
- Presentation du MPEG4 (13 clics)
- un peu plus de blabla sur le MPEG4 (1 clic)
- Java Media Framework (3 clics)
- D I V X (1 clic)
# un décodeur mpeg-4 en java ?
Posté par Troy McClure (site web personnel) . Évalué à 1.
combien l'ont-ils acheté à i2bp ? (en milliards de dollars, pas la peine de me donner les centimes, je connais le prix d'une telle technologie)
est-ce qu'il fait vraiment 50 octets ?
comme c'est excitant !!
[^] # Re: un décodeur mpeg-4 en java ?
Posté par Nelis (site web personnel) . Évalué à 1.
Enfin ... c'est ce qui fait tout le charme de Linuxfr ;-)
[^] # C'est toujours mieux qu'une blague belge !
Posté par TSelek . Évalué à 1.
c'est achement mieux que de relire pour la 100ème fois la même fortune !
pour les gens sérieux, je leur conseille ZDNet, le JDN ou même CNet :p) (tient donc, que des 'net')
[^] # LE TROLL DE LA SEMAINE
Posté par Anonyme . Évalué à -1.
chuis hyper fier de mon troll ->90commentaires
Je vous remercie tous!
A mort java!!!
# Bonne nouvelle :-)
Posté par Nelis (site web personnel) . Évalué à 1.
Et que personne ne vienne me sortir "oui mais c'est lent" sinon il se prend une claque ;-) Je peux vous dire que chez moi, j'écoute mes MP3 sur un player Java et que ça n'est PAS lent :p
[^] # Re: Bonne nouvelle :-)
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Bonne nouvelle :-)
Posté par Nelis (site web personnel) . Évalué à 1.
[^] # Re: Bonne nouvelle :-)
Posté par Anonyme . Évalué à 0.
[^] # Re: Bonne nouvelle :-)
Posté par Dugland Bob . Évalué à 1.
[^] # Re: Bonne nouvelle :-)
Posté par Nelis (site web personnel) . Évalué à 1.
# en JAVA????
Posté par Anonyme . Évalué à 0.
trucs en java??!
Ce langage est mort-né: c'est lent,
c'est complexe, c'est pas portable(et oui..)
C'est pas pour rien qu'Oracle, ex grand
partenaire de Sun vient de dire stop a la
version 8i java-izé et pleine de bugs...
Y'a que i2bp pour y croire...
[^] # Re: en JAVA????
Posté par Dugland Bob . Évalué à 1.
Il a mis "I2bp", "mort-né" et "stop" dans le même post.
[^] # Re: en JAVA????
Posté par Troy McClure (site web personnel) . Évalué à 1.
bon alors, c'est qui qui trolle, hein ?
[^] # Re: en JAVA????
Posté par Nelis (site web personnel) . Évalué à 1.
[^] # Re: en JAVA????
Posté par Dugland Bob . Évalué à 1.
Ils ont quelle tête les investisseurs d'i2bp maintenant ?
[^] # Re: en JAVA????
Posté par Troy McClure (site web personnel) . Évalué à 1.
[^] # Pathétique ...
Posté par Nelis (site web personnel) . Évalué à 1.
[^] # Re: Pathétique ...
Posté par Anonyme . Évalué à 0.
Je n'essaye pas de te dissuader d'utiliser java.
On vera dans 2ans ou java en est...
Bon courage a tous les developpeur java du
monde, vive vous! ;-)
[^] # A propos d'Oracle ...
Posté par Nelis (site web personnel) . Évalué à 1.
Oracle9iAS stands out because it offers maturity and expansive Java capabilities with the proven technology of Oracle9i Enterprise Java Engine (Oracle9i EJE - formerly Oracle8i JVM). In addition, Oracle9iAS offers full support for standard application development and deployment using Java. Oracle9iAS has adopted Java's application development model and fully supports Java 2 Enterprise Edition APIs. So, Oracle9iAS lets you use Java in the intended way. From simple to complex, from small intranets to large enterprises requiring tens of thousands of concurrent internet connections, you are ready.
[...]
http://www.oracle.com/ip/deploy/ias/index.html?java.html(...)
No comment ...
[^] # Re: Pathétique ...
Posté par BeN . Évalué à 1.
minimun et java ne sera plus lent ! :))
[^] # Re: Pathétique ...
Posté par patrick . Évalué à 1.
[^] # Re: Pathétique ...
Posté par Anonyme . Évalué à 0.
Autant programmer en assembleur ca sera toujours plus rapide qu'en C++ quelque soit la frequence du processeur ...
[^] # Re: Pathétique ...
Posté par patrick . Évalué à 1.
[^] # Re: Pathétique ...
Posté par Anonyme . Évalué à 0.
Sauf ke lui cé le contraire, il pense ke cé les soft ki ne demenderaont pas tjrs + de CPU, cé ridicule de dire ke son soft il tournera tres bien ds 3ans, parce k'il sera depasse ! ;))
[^] # Re: Pathétique ...
Posté par Pat Le Nain . Évalué à 1.
Il a dit "640 Ko suffiront pour tout le monde"
[^] # Re: Pathétique ...
Posté par Anonyme . Évalué à 0.
[^] # Re: Pathétique ...
Posté par NebuchadnezzaR . Évalué à 1.
[^] # Re: Pathétique ...
Posté par Anonyme . Évalué à 0.
Resultat, t'as bô avoir un proc a 2Ghz, ton java te bouffe toujours trop de ressource par rapport a autre chose.
Pis pas la peine de lancer un troll la dessus. C'est juste mon avis :-)
David Jobet
--
Toujours pas logge. A pu password.
[^] # Quel avenir pour JAVA
Posté par gui_ . Évalué à 1.
Il y a déjà qq temps, Java était à la mode. On ne parlait que de ce langage "révolutionnaire" qui allait tout changer.
Avec le recule, on a du mal a trouver l'utilité de Java...
Qu'en pensez vous? (Ce n'est vraiment pas un troll, même si ça en a un peu l'air ;-)
[^] # Re: Quel avenir pour JAVA
Posté par Nelis (site web personnel) . Évalué à 1.
Un nombre sans cesse croissant d'applications Web, B2B, ... sont développées avec des technologies telles que JSP/Servlet, EJB, JMX, JMS, JDBC, ...
Il est vrai que pour le desktop, le Java a un peu de mal à décoller, mais c'est plus à cause du très mauvais marketing de Sun à ce niveau qu'à cause du langage...
Il existe qd meme de très bons logiciels : LimeWire (client GNUtella http://www.limewire.com(...) ), Jext (Editeur de texte libre http://www.jext.org(...) ), de très bons jeux en applets sur : http://www.minatrix.com(...) , ...
Si tu as encore des questions, n'hésite pas à me contacter...
[^] # Re: Quel avenir pour JAVA
Posté par gui_ . Évalué à 1.
Si te peux me convaincre de l'intérêt de Java, cela me motivera certainement plus pour l'apprendre et je dirais sans doute moins de bêtises ;-)
[^] # Re: Quel avenir pour JAVA
Posté par Nelis (site web personnel) . Évalué à 1.
C'est là où tu te trompes ... Il faut arrêter les idées reçues comme quoi Java est lent ... Il est vrai que Swing est encore lent et gourmant en ressources mais le langage en lui même est très rapide ! Parfois autant et meme plus que le C ...
Et ce que tu gagnes en utilisant Java côté serveur, c'est une plateforme de haut niveau, avec un design très propre, très portable, extensible facilement et avec une maintenance aisée ...
Une application Web ce n'est pas seulement un CGI qui lit ou ecrit des données dans une base...
Ca peut etre une application recevant des données du browser, qui evoit ces données sur un bus (style message queue) pour que des objets distribués manipulent ces données, renvoie les résultats qui doivent etre sotckés dans une base et enfin générer la réponse pour l'utilisateur ...
Tu comprends ce que je veux dire ? Java te fournit les outils pour faire tout ça et integrer facilement d'autre choses dans ton applications ...
[^] # Re: Quel avenir pour JAVA
Posté par Anonyme . Évalué à 0.
C'est vrai que çà peut être aussi rapide qu'en C++ (pour une programmation de qualité équivalente), mais plus rapide qu'en C, faut peut-être pas pousser...
Sinon, c'est vrai que Java c'est le pied : simple et efficace, pleins d'API, ...
Manquerait plus qu'un typage fort (cast vérifié à la compilation, à la CAML), un boxing plus souple (à la C#, désolé ;-) et quelques autres trucs et çà serait parfait.
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . Évalué à 1.
Si tu sait l'utiliser, c'est aussi rapide que du C (vu que ton C++ est traduit en C avant compilation).
Par contre pour l'apprentissage, c'est la misère (gérer le inline, le volatile).
J'ai été obligé d'arrêter le trip quand je me suis noyé dans les templates (un jour j'y arriverais).
[^] # Re: Quel avenir pour JAVA
Posté par boubou (site web personnel) . Évalué à 1.
Trop puissant, cet argument...
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . Évalué à 1.
Il faut voir le C++ comme une série de Macro évoluées au dessus du C.
<ma vie>
Personellement, j'ai du inline asm (deconnectable) au milieu de C++ (pour certains opérateur MMX) et ça marche très vite.
</ma vie>
Il ne faut pas oublier que le C atteint ses limites avec les architectures superscalaire et les instructions SIMD. Le gros problème : il n'a pas de remplaçant.
[^] # Re: Quel avenir pour JAVA
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Oh la belle fortune pour le bas de page de linuxfr :-).
[^] # Re: Quel avenir pour JAVA
Posté par MetalX . Évalué à 1.
> compilation).
Loin de moi l'idee de casser ton argument, mais tu peux traduire n'importe quel langage en C.
Savoir l'utiliser, c'est forcement programmer en objet, et je doute que le dynamic binding puisse etre aussi rapide que le static binding.
Maintenant, si tu veux vraiment faire du C++ en enlevant tout ce qui peut ralentir, tu finiras avec du C.
inline: Encore un truc qui ne devrait etre que l'affaire du compilateur plutot que d'un programmeur qui va l'utiliser plus mal dans 99% des cas.
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . Évalué à 1.
Mais le polymorphisme est vachement pratique en C!
Le problème du inline vient du C, je te le rappelle. Quand tu a du code dans un .h, tu le compile où ? Le même problème se pose avec les templates.
Le problème est résolu en JAVA (un seul fichier par classe) et dans les trucs monolythiques (genre SmallTalk) où tout le code est en vrac dans le fichier.
[^] # Re: Quel avenir pour JAVA
Posté par MetalX . Évalué à 1.
Je ne savais pas. Peux tu me donner une reference qui developpe cela? Je ne vois pas ce que tu veux dire.
Le code du .h est compile avec le fichier qui l'inclut.
En Java, les inlines sont geres a la compilation.
Je crois que je ne vois pas ou tu veux en venir exactement... (?_?)
[^] # Re: Quel avenir pour JAVA
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Tu peux faire de l'objet avec du static binding (mais pas du polymorphisme), et C++ sait tres bien faire ca (de tout les langages OO c'est meme lui qui sait le mieux le faire).
Par ailleurs, un appel a une methode virtuelle c'est juste un dereferencement de plus. Negligeable dans 99% des cas.
> inline: Encore un truc qui ne devrait etre que l'affaire du compilateur plutot que d'un programmeur
Vieux debat. Ca ne fait pas tres longtemps qu'on sait faire des compilos qui savent bien quand inliner, et c'est pas du tout facile a faire. Alors deja qu'un compilo C++ c'est complexe, si en plus il fallait rajouter ca... Quoique il me semble que certains le font plus ou moins (je crois que rien n'oblige le compilo a effectivement inliner ce que tu specifies "inline", c'est juste un indice, pas un ordre).
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . Évalué à 1.
Je doit me planter de terme, je parle de 2 classes ayant une fonction portant le même nom mais une implémentation différente, ça y'a beaucoup de cas ou c'est faisable à la compilation (entre autre pour les feuilles de l'arbre d'héritage).
J'évite de faire générer des pointeurs sur les fonctions membres dans mes champs de pixels.
[^] # Re: Quel avenir pour JAVA
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Et tout ca n'a rien a voir avec un pointeur sur une fonction membre, ca c'est encore autre chose :-).
[^] # Re: Quel avenir pour JAVA
Posté par MetalX . Évalué à 1.
> Negligeable dans 99% des cas.
Je ne disais pas la difference etait sensible. Je disais juste qu'il y en avait une. Les fonctionnalites interessantes d'un langage objet ont tjs un prix, meme si il est parfois si infime qu'on y attache aucune importance.
Si je ne me trompe pas, inline est juste une directive au compilo (comme register). Le compilo n'est pas oblige de le faire. Certes, ca demande un bon compilateur pour gerer les inlines, mais je pense que quand le programme devient complexe, le programmeur aura bien du mal a faire les inlines qu'il faut. Le programmeur se limitera alors aux inlines evidents qu'un compilateur peut trouver avec des algos de inlining simple.
(mais bon, j'ai travaille plus sur des compilos experimentaux que sur les compilos du commerce, alors je ne sais pas ou ils en sont).
J'analyserai le comportement de g++ avec les inlines quand j'aurai le temps. J'aimerai bien savoir justement comment il gere le probleme.
[^] # Re: Quel avenir pour JAVA
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Pour autant que je sache, c'est exact. Et je suis d'accord, un programmeur fait le plus souvent de mauvais inlines. D'ailleurs la plupart du temps on recommande de n'inliner qu'apres profiling (sauf evidemment, comme tu le dis, les trucs triviaux genre accesseurs).
[^] # Re: Quel avenir pour JAVA
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Toi aussi :-).
> (vu que ton C++ est traduit en C avant compilation).
Ca fait bien quelques siecles que ce genre de compilos n'existe plus. Tous les compilos actuels generent directement de l'assembleur.
> Par contre pour l'apprentissage, c'est la misère (gérer le inline, le volatile).
Le volatile ? Tu veux parler des methodes virtuelles peut-etre ?
[^] # Je peux avoir un justificatif ?
Posté par TSelek . Évalué à 1.
ou alors verifie ta RTC, tu as du bugger au 01/01/01...
[^] # Re: Je peux avoir un justificatif ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Sinon oui, compiler du C++ en passant par C, c'est completement obsolete.
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . Évalué à 1.
T'inquiète pas, je relis régulièrement !
surtout en ce moment.
[^] # Arrête de fumer la moquette...(je déconne)
Posté par TSelek . Évalué à 1.
Le langage en lui-même n'est pas rapide, ni lent d'ailleurs. la JVM oui (lente). un core Java comme PicoJavaII oui (rapide).
Java coté serveur, ok mais ca ne suit pas le principe optimisation output/ressources. d'ailleurs c'est promu par des fabriquants de hardware...
ensuite Java n'a pas inventé les semaphores ou Corba, et ce n'est pas la seule plateforme qui les supporte, d'autres langages/API le faisant encore mieux.
ensuite pour le portage, certes le langage l'est. mais connais-tu la notion de profiles ? J2EE, J2ME, J2SE, CLDC, etc, c'est pas de la fragmentation ? autrement dit chaque implémentation supporte son set de classes...
[^] # Re: Arrête de fumer la moquette...(je déconne)
Posté par Anonyme . Évalué à 0.
Désolé pour tes idées reçues mais sur un serveur Web, il vaut mieux utiliser des servlets que des CGI en C (tout du moins pour les serveurs très solicités) tout simplement parceque là ou en C, chaque ouverture d'un CGI cré un processus, sur des servlets chaque accès à un servlets cré une thread d'où une utilisation mémoir nettement moins important et une disponibilité accrue.
Ditent moi si je me trompe
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . Évalué à 1.
1 fichier par classe
la notion (explicite) de package
pas de pointeur (ça ne résout pas tout, mais ça aide)
la notion d'INTERFACE
la notion de SYNCHRONISATION (implémentez un monitor en C++, vous m'en direz des nouvelles)
Y'en a d'autres mais ça fait longtemps ...
Actuellement je suis au C (plus ou moins ++)... pour la vitesse (traitement de l'image en temps réel).
[^] # Re: Quel avenir pour JAVA
Posté par Anonyme . Évalué à 0.
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . Évalué à 1.
En plus tu vire la partie problématique de l'héritage multiple (j'ai un vieux souvenir de Eiffel qui me reviens en tête à ce propos).
[^] # Re: Quel avenir pour JAVA
Posté par patrick . Évalué à 1.
[^] # Re: Quel avenir pour JAVA
Posté par ufoot (site web personnel) . Évalué à 1.
Bon, je pousse un peu mais à peine (quand même)
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . Évalué à 1.
Comme je suis en recherche, je suis indépendant (donc sous linux).
J'ai du faire une démo sous win pour un salon :
la misère. J'ai développé sous Linux avec 3 #ifdef
et j'ai porté au dernier moment.
Le débugger de mémoire (Purify de Rationnal) :5000F, le profiler : pareil, pour la couverture ils ont pas ! Evidemment, ils m'ont pas filé de license temporaire (c'est la misère à désinstaller parraît-il)
Le MsDEV ne suit pas les pointeurs sur fonction (dommage, j'utilise GLUT)
J'ai utilisé gcc, gdb, gprof,gmake,gcov et electric fence (gdb bloque le sigsegv et rend la main). Moyenne en quoi pour 0 francs j'avais mieux qu'eux.
C'était la première fois que je faisait une couverture, j'incite tout le mond à en faire, ontrouve des bugs insoupsonnables avec ça !
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . Évalué à -1.
J'ai bon ?
Je peux faire consultant à une brique la journée maintenant?
Bouge pas :
start-up
Internet
Architecture logicielle
B2B
B2P
CRM
intranet
extranet
bob Ricard (oops!)
workgrouping (en ing ça marke plus de points)
www.kitetoa.com
[^] # Re: Quel avenir pour JAVA
Posté par Anonyme . Évalué à 0.
(pour le mélange interface-synchro, tu peux aussi faire ta remarque sur le post du dessus)
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . Évalué à 1.
Je crois me souvenir (j'ai juste lu une intro y'a 1 ou 2 ans) que lors d'un héritage en diamant (c'est de ça qu'on parle depuis tout-à-l'heure) tu choisi pour chaque symbole l'implémentation que tu veux (classe de gauche ou classe de droite).
[^] # Re: Quel avenir pour JAVA
Posté par Anonyme . Évalué à 0.
[^] # c'etait quoi ton probleme avec Eiffel?
Posté par reno . Évalué à 1.
Mais je crois qu'en Eiffel justement la "partie problématique de l'héritage multiple" n'etait pas problematique justement.
Alors, la question reste: pourquoi remplacer l'heritage multiple par les interfaces?
[^] # Re: c'etait quoi ton probleme avec Eiffel?
Posté par Dugland Bob . Évalué à 1.
Je parlais d'héritage multiple, en y pensant, j'ai pensé à ce vieux bout d'article lu. Je ne veux PAS dire qu'il y a un problème avec Eiffel, je me souvenais que Eiffel avait traité le problème d'une manière ou d'une autre, sans jugement de valeur.
Je ne veux pas tuer Eiffel (pas avant d'avoir fait connaissance du moins ... on verra après).
[^] # Re: Quel avenir pour JAVA
Posté par Anonyme . Évalué à 0.
Héritage simple : léger, pas de pb
Héritage simple + interfaces : aussi léger que l'héritage simple, et presque aussi fonctionnel que l'héritage multiple
[^] # Re: Quel avenir pour JAVA
Posté par Anonyme . Évalué à 0.
Pas forcément indispensable? si tu utilises java, dis-toi qu'à chaque fois que tu implémentes deux interfaces dans une classe, tu aurais pu hériter de 2 classes abstraites dont tu n'aurais eu à définir que 2 ou 3 routines d'accès (tout le reste du code étant déjà fait)...
[^] # Bof.
Posté par reno . Évalué à 1.
(Enfin ca c'est mon impression d'apres ce que j'ai lu sur Internet).
Lourd dans quel sens?
[^] # Re: Quel avenir pour JAVA
Posté par patrick . Évalué à 1.
[^] # Re: Quel avenir pour JAVA
Posté par Pat Le Nain . Évalué à 1.
[^] # Re: Quel avenir pour JAVA
Posté par boubou (site web personnel) . Évalué à 1.
1 fichier par classe public !!! Tu peux définir plusieurs classes dans un même fichier.
"la notion (explicite) de package"
Les namespaces, jamais entendu parler ?
"pas de pointeur (ça ne résout pas tout, mais ça aide) "
Argh !!! Java est bourré de pointeurs, mais pour ne pas faire peur, on appelle ça des références. Ce qui fait la force de Java par rapport au C++, c'est qu'il n'y a pas d'ariuthmétique sur les pointeurs et surtout qu'il y a un garbage collector.
"la notion d'INTERFACE"
Et les classes abstraites du C++ ? Le problème ici est plutôt que la sémantique de virtual du C++ est naze...
"la notion de SYNCHRONISATION"
Ouai, une bibliothèque quelconque, et ça roule. Franchement, c'est pas la mer à boir, d'autant plus que le modèle de parallelisme de Java est assez contre-intuitif par rapport aux threads posix, par exemple.
Bref, n'importe quoi...
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . Évalué à 1.
Simplement, si tu veux programmer proprement (définition libre), y'a des langages qui t'aident plus que d'autres.
Consernant la synchro, la notion de "monitor" est TRES loin d'un mutex posix.
[^] # Re: Quel avenir pour JAVA
Posté par Anonyme . Évalué à 0.
Contrairement à ce que tu dis, Sun est trés bon au niveau marketing parce qu'ils ont réussi à imposer java malgré toutes ses lacunes (opinion propre à moi-même). A la seule évocation du mot EJB, les marketings et les investisseurs sont aux anges et les développeurs pleurent leurs méres!
La où ils sont forts, c'est qu'ils sont arrivés à faire croire aux développeurs qu'un seul language est bon pour toutes les situations. Il n'y a qu'à voire la percée de java dans le monde du web. Dernier arrivé mais premier dans les coeurs même si les temps de dév et le nombre de devs sont multipliés par 2, sans parler des serveurs qui sont sur les rotules.....
Grâce à java, aprés les applis qui plantent, voici les sites web qui plantent (tm)(Internal server error chéri!)
[^] # Re: Quel avenir pour JAVA
Posté par Nelis (site web personnel) . Évalué à 1.
[^] # Re: Quel avenir pour JAVA
Posté par Anonyme . Évalué à 0.
[^] # Re: Quel avenir pour JAVA
Posté par Anonyme . Évalué à 0.
Je ne me considère certainement pas comme un guru mais j'apprends tous les jours :-) Ce que je ne supporte pas c'est les gens qui disent "c'est de la merde" sans connaitre ...
Et ne t'inquiète pas, je ne suis pas un intégriste, je suis ouvert à tout ... J'adore le C, le C++ (même si je n'aime pas sa syntaxe), le Java, Linux, Amiga, ... Et je ne demande qu'à essayer les technologies que je ne connais pas encore, j'essaie de ne pas juger sans connaitre ...
Le fait est que mon métier, c'est Java, d'où ça m'énerve encore plus quand les gens le descendent sans arguments ...
Enfin soit, j'espère que tu comprends mon point de vue ;-)
Nelis (pas authentitié)
[^] # Re: en JAVA????
Posté par Sohphie de Montmirail . Évalué à 1.
Il faudrait le faire savoir parce que de plus en plus de développements se font en JAVA.
Pauvres développeurs... Il vont devoir tout jeter et recommencer en C# (le langage de l'avenir).
[^] # Re: en JAVA????
Posté par Anonyme . Évalué à 0.
[^] # Re: en JAVA????
Posté par Anonyme . Évalué à 0.
[^] # Et Ruby, hein ?
Posté par TSelek . Évalué à 1.
tout comme le C, qui a entendu parlé du C-Ansi-99 ?
et Eiffel ? ça fait toujours plaisir de lire les travaux d'un français exclusivement en anglais...
Java c'est de la daube, c'est entendu...enfin on a vu des daubes bien pires !
Et le vainqueur est...tintintin... Ruby ! c'est pas compliqué, son géniteur a pris ce qu'il considérait comme le meilleur dans chaque langage.
moralité: le meilleur langage, c'est le plus récent qui a réussi ses multiples héritages.
mais qui se fatiguerait à pondre quelque chose de moins bon que l'existant ? après, l'adoption par le marché, c'est une autre histoire...
excellente doc sur Ruby http://www.rubycentral.com/(...) (par The Pragmatic Programmers...)
[^] # Re: Et Ruby, hein ?
Posté par Dugland Bob . Évalué à 1.
Je vais m'intéresser à eiffel, ruby et python bientôt, le problème c'est qu'on passe sa vie à apprendre des languages (et souvent les bibliothèque qui vont avec) mais : on fout rien de sa vie, on repasse au C au moindre problème, aucun n'est satisfaisant.
Récement, j'ai repris un truc en Smalltalk, c'est sympa (y'a rien comme syntaxe, super objet, packages), un peu déroutant au début (expression exécutées de gauche à droite, 3 niveaux de priorité) mais c'est super lent, et c'est limite monolythique (ça c'est une impression).
[^] # Ruby, c'est bien. si c'est vrai d'abord !
Posté par TSelek . Évalué à 1.
moi aussi je cherchais, et après un rapide survol de Perl et PHP, je suis tombé sur Ruby, pas par hasard mais après une longue recherche.
et puis au final: asm pour bootstraper le runtime-C, C pour coder l'interpreteur, interpreteur Ruby (à la place de Java et PHP et Perl, zou tous virés en même temps...), ca me semble bien, simple et radical.
pour le petit dernier, un mot de Matz, son créateur:
"Eh bien, Ruby est né le 24 février 1993. Je discutais avec mon collègue de la possibilité d'un langage de script orienté objet. Je connaissais Perl (Perl4, pas Perl5), mais je ne l'aimais pas vraiment, parce qu'il avait l'air d'un langage jouet (c'est toujours le cas).
Le langage de script orienté objet semblait très prometteur.
Je connaissais Python à l'époque, mais je ne l'aimais pas, parce que je ne pensais pas qu'il fut un véritable langage orienté objet --- les fonctionnalités orientées objet donnaient l'impression d'avoir été rajoutées au langage.
En tant que maniaque des langages et fan de l'orienté objet depuis 15 ans, je désirais vraiment un langage de script véritablement orienté objet et simple à utiliser.
J'ai donc décidé de le créer. Cela a pris plusieurs mois pour faire tourner l'interprète. J'y ai mis les fonctionnalités que j'aime avoir dans un langage, comme les itérateurs, la gestion des exceptions, le ramasse-miettes.
Ensuite, j'ai réorganisé les fonctionnalités de Perl dans une bibliothèque de classes, et les ai implémentées. J'ai posté Ruby 0.95 sur les groupes de discussion japonais en décembre 1995.
Depuis lors, des listes de diffusions très actives ont été mises en place et des pages web ont été créées."
(extrait de la FAQ, en cours de traduc par Pierre-Charles David, merci à lui)
[^] # Re: Ruby, c'est bien. si c'est vrai d'abord !
Posté par Dugland Bob . Évalué à 1.
Je suis ETUDINAT à la fac !
j'ai encore plus de temps libre qu'eux !
[^] # Re: Ruby, c'est bien. si c'est vrai d'abord !
Posté par Dugland Bob . Évalué à 1.
[^] # Re: Et Ruby, hein ?
Posté par Anonyme . Évalué à 0.
Justement, je viens de regarder la FAQ Ruby, ce n'est qu'un langage à héritage simple ! Même le modèle objet dynamique de GTK+ (qui sera séparé pour être mis dans la GLib 2.0 pour que des projets comme Gstreamer puissent l'utiliser sans nécessiter GTK+) autorise ça. Et franchement, quand on a gouté à l'héritage multiple, on ne peut plus s'en passer (sauf en C++ pour lequel la lourdeur de la syntaxe est telle qu'on préfère faire comme si cette possibilité n'était pas offerte).
[^] # y'a héritage et héritage, espèce de mono-maniaque !
Posté par TSelek . Évalué à 1.
Par contre moi je m'en fous éperdumment de n'avoir qu'un héritage simple (j'aime pas les trucs compliqués, ça défavorise les faibles d'esprits comme moi), surtout qu'un bon mixin ça le fait bien (mieux ;p). Il fait les mixins, le Gtk ?
Surtout qu'en fait, ce n'était pas de ces héritages auxquels je faisais allusion, mais le fait de s'INSPIRER d'autres langages...
Enfin chacun voit midi à sa porte.
[^] # Re: y'a héritage et héritage, espèce de mono-maniaque !
Posté par Anonyme . Évalué à 0.
Je voudrais pas trop m'avancer, mais je crois qu'il avait compris, une manière de rebondir sur les mots et non sur la sémantique ;-)
Quant au débat héritage simple/multiple, il est CAPITAL à mon goût, et la seule raison qui a poussé SUN à faire de l'héritage simple, c'est parce qu'ils réglent un problème en l'ignorant («la démocratie est un modèle théoriquement imparfait et qui semble non fonctionnel, retournons à une bonne vieille tyrannie !»). D'ailleurs, dans le bouquin le plus connu de Bertrand meyer (conception et programmation orienté objet), il est très bien expliqué (et de manière difficilement contestable) que l'héritage multiple est très pratique, que les difficultés qu'il soulève ont été résolu au niveau théorique et pratique, et que s'en passer est terriblement dommageable (en fait, il va personnellement plus loin en laissant sous-entendre qu'un langage sans héritage multiple n'est pas un un langage OO). Bref, rien à voir avec un problème d'ordre psychanalitique, c'est juste un débat de design pour la programmation, et j'ai personnellement choisi mon camp !
[^] # D'accord: les templates, les bugs
Posté par reno . Évalué à 1.
On est en 2001, j'attends toujours: j'appelle ca un language bacle! Les casts dans tous les coins, c'est pas beau.
L'environement Java a ete bugge jusqu'a l'os avec une duree de correction de bugs tres rapide: 2 ans et plus pour des bugs pour lesquels plein de gens avaient votes..
Ca c'est de la reactivite!
Ceci dit depuis le JDK 1.3 ca a l'air d'aller mieux..
Conclusion: si tu veux des raisons objective de taper sur Java, pas de problemes: il y en a plein!
C'est un language pas mal mais sans plus, sa force c'est l'environement qui commence a ne plus etre trop buggee.
[^] # Re: y'a héritage et héritage, espèce de mono-maniaque !
Posté par Anonyme . Évalué à 0.
[^] # Re: Et Ocaml, hein ?
Posté par Vivi (site web personnel) . Évalué à 1.
Ça c'est un langage cool : typage statique, inférence de types, programmation impérative, fonctionnelle et objet, GC performant, compilable en byte-code et en natif.
Et la vitesse est vraiment proche du C (et c'est vrai pour le coup).
[^] # Faudrait que je regarde..
Posté par reno . Évalué à 1.
C'est surtout ca la force de Java et de Perl..
[^] # Re: Il faut que tu regardes..
Posté par Vivi (site web personnel) . Évalué à 1.
C'est pas démentiel, c'est sûr. Mais il y en a de + en +. Et c'est assez facile à interfacer avec le C.
[^] # Re: Il faut que tu regardes..
Posté par Larry Cow . Évalué à -1.
Et en plus ils ont meme porté GTK(GtkML), alors que demander de plus ?
/begin{troll_prevention}
QT?
/end{troll_prevention}
[^] # Re: Il faut que tu regardes..
Posté par Vivi (site web personnel) . Évalué à 1.
Y'a même deux wrappers : GtkML et LablGtk
QT?
QT c'est écrit en C++, alors c'est moins simple à interfacer
[^] # Re: en JAVA????
Posté par Anonyme . Évalué à 0.
[^] # Re: en JAVA????
Posté par Anonyme . Évalué à 0.
Je suis un programmeur C#
j'écris meme un livre sur ce langage
J'ai aussi programmé bcp en Java.
Certes Sun exagère tout le temps la succés de son langage, mais si il y'a quelque chose de sur, c'est que le Java est très loin d'être mort
[^] # Re: en JAVA????
Posté par TSelek . Évalué à 1.
sinon c'est vrai que C# a des qualités intrinseques indéniables, et c'est pas un troll.
de toute façon, si C# n'avait pas d'avantages sur Java, il n'existerait pas.
alors comme ça tu fais du prosélytisme pro-crosoft ?
[^] # Re: en JAVA????
Posté par Tony Gencyl . Évalué à 1.
[^] # Re: en JAVA????
Posté par Romain Guy . Évalué à 1.
Lent ? Non, Java n'est lent que si l'on fait n'importe quoi dans son code. C'est le problème, des petits malins comme toi pensent q'un GC et une syntaxe plutôt claire épargnent tout effort au programmeur. C'est faux. Le programmeur Java doit faire attention à son code pour produire quelque chose d'efficace. Ce n'est pas très difficile souvent (exemple classique: une boucle s'exécutant en 17s avec des String ne s'exécute plus qu'en 170ms avec StringBuffer). Il faut juste savoir faire...
Complexe ? Quels langages utilise-tu ? Klik n' Play ? Java possède deux ou trois aspects un peu hardus à appréhender lorsque l'on débute (cf threads et deadlocks), mais ce n'est pas un langage complexe.
Par portable ? Mouarf... alors là mon pauvre. Ici encore, la tâche en incombe au développeur. Evidemment si ton code est bourré d'appels à des commandes shells ou si tu passe ton temps à appeler des fonctions de librairies externes, alors oui ton code à peu de chances d'être portable. Néanmoins, ce n'est pas très compliqué si on prend le temps de réfléchir à ce que l'on fait.
Java a ses défauts, comme tous les langages. Mais son plus grand défaut est d'avoir mal été compris par des crétins dans ton genre qui balancent des conneries sans même avancer de preuves. A cause de gens comme toi (à moins que tu n'en sois victime), Java a une sale réputation.
Je concède que Java n'est pas aujourd'hui très présent en matière de desktop. Mais ose jeter un oeil à des outils comme jDiskReport, jEdit, ArgoUML, Forté For Java et révise ton jugement.
[^] # Re: en JAVA????
Posté par Anonyme . Évalué à 0.
jDiskReport, c'est quoi, on peut le trouver où ?
[^] # Re: en JAVA????
Posté par Anonyme . Évalué à -1.
Simplement hautain. C'est vrai qu'il a été insultant ...
Et un -1 pour éviter la censure ...
[^] # Re: en JAVA????
Posté par Nelis (site web personnel) . Évalué à -1.
[^] # Re: en JAVA????
Posté par Anonyme . Évalué à -1.
Un peu plus qu'ailleurs, le moi-je-sais castrateur est roi ...
Constatation simple et quotidienne d'un vocabulaire qui n'interpelle plus personne ...
[^] # Re: en JAVA????
Posté par Anonyme . Évalué à 0.
Et puis ce qu'on considère comme des réussites en Java comme Jext ou Borland JBuilder, c'est LENT. Jext me bouffe 5MO de RAM, pour un éditeur de texte, c'est pas normal !! JBuilder, j'en parle même pas. Delphi est 10 fois plus rapide et moins bouffeur de RAM.
On dit souvent à propos de Java que l'avantage c'est les classes de base. OK toujours, mais les classes de base sont horriblement lentes. On doit donc réécrire autre chose, mais tu perds la portabilité, car tu dois linker avec les librairies systèmes.
Autre chose, javac n'optimise RIEN !! Si tu désassemble ton bytecode, tu verras que c'est affreux !! Tout est traduit litéralement, sans aucun effort d'optimisation, et pourtant javac est long à la compilation.
Le problème essentiel de Java va être que tu as deux possibilités pour programmer : la débutante où tu utilises les classes de bases et les types String et autres. Alors c'est facile, mais lent, et tu fait taper sur les doigts. Deuxième solution, tu bidouilles ton code à la main, t'optimises, tu désassemble pour corriger, bref tu bosses. Mais ou est la simplicité de Java à ce moment là ? On se croirait revenu en asm : si tu décrémente ta boucle au lieu de l'incrémenter, tu économise une instruction, et donc ... Je m'arrêtes là, mais je croyais que le but des langages de haut niveau était justement d'éviter ce genre de trucs, en les mettant au niveau du compilateur.
Le pense donc que Java n'est pas un mauvais langage en soi, mais qu'il s'embrouille avec des trucs imbuvables, comme sa volonté d'adopter à peu près la syntaxe de C++, ce qui compléxifie inutilement la chose. Java est jouable pour des mainframes ou la vitesse n'est pas génante, vu la puissance qui est sous le capot. Pour moi, dans l'état actuel des choses, programmer un Java rapide est très dur, bien plus que du C, et très contraignant.
[^] # Re: en JAVA????
Posté par Nelis (site web personnel) . Évalué à 1.
Là, je suis mort de rire :-) Les conneries qu'il ne faut pas entendre ici !!!! :-)))
[^] # Re: en JAVA????
Posté par djrom . Évalué à 1.
> là je suis mort de rire :-) ...
T'es mort de rire pour quoi ? Parce que oui, en asm, décrementer une boucle est mieux que de l'incrémenter car le flag Zéro du proc est activé quand tu atteint zéro en décrementant, ce qui t'économise une instruction CMP, car tu peux directement mettre une instruction JZ après pour sortir de ta boucle. Je sais, c'est du chipotage, mais les habitudes, hein :-)
[^] # Re: en JAVA????
Posté par Dugland Bob . Évalué à 1.
MMMMMmmmmmh le tueur, pour gagner un demi (peut-être même moins) cycle d'horloge tu programme tes boucles vers zéro.
On t'a pas parlé d'architecture superscalaire où que ton proc il aurait rien foutu de toute manière (d'où le moins d'un demi) ?
On t'as pas non plus dit que x86 est un des derniers jeu d'instruction cisc (et encore, l'architecture en dessous est de plus en plus risc)?
Commence par travailler sur la complexité, vire tes accès mémoire (1cache miss=200 cmp), tes divisions et modulos (40cmp).
Là tu auras du gain. mais les boucles à l'envers ... j'ai du mal !
</troll>
[^] # Re: en JAVA????
Posté par djrom . Évalué à 1.
Pi, zut, laisse-moi optimiser sur mon Z80, merde, ... :-))
[^] # Re: en JAVA????
Posté par Anonyme . Évalué à 0.
[^] # Re: en JAVA????
Posté par Anonyme . Évalué à 0.
[^] # Re: en JAVA????
Posté par Dugland Bob . Évalué à 1.
Tous les jours je découvre une instruction !
Pour le café, ils ont rien chez Intel ?
[^] # C'est pas du chipotage
Posté par TSelek . Évalué à 1.
1 bit.
un seul.
mais après tu trouveras toujours un bobo en z3, ah non j'arrete là, jcroyai kjetais sur vakooler...
hop en we...
[^] # Re: en JAVA????
Posté par Wawet76 (site web personnel) . Évalué à 1.
Exemple : Pour parcourir un tableau, au lieu de demander la taille du tableau et de faire un for, tu peux faire une boucle infinie et attraper l'evenement qui est lancé quand tu dépasses la taille du tableau.
Ca va plus vite, mais l'experience montre un certain étonnement chez les collègues qui passent derrière toi...
[^] # Re: en JAVA????
Posté par Romain Guy . Évalué à 1.
[^] # Re: en JAVA????
Posté par Wawet76 (site web personnel) . Évalué à 1.
Si la vitesse est critique, la "solution de porc" est plus rapide à partir d'un certain nombre d'éléments dans ton tableau. Le gain de temps augmente ensuite avec la taille du tableau vu que l'exception n'est lancée qu'une fois alors que le test que tu évites est effectué à chaque itération.
La valeur critique va changer selon les JVM, mais il y aura toujours cet effet de seuil.
Sur http://www.protomatter.com/nate/java-optimization/(...) l'auteur l'estime à 40 éléments sur sa machine.
Par contre, je suis d'accord que c'est un peu porcif...
--
Thomas Walraet
Developpeur Java non-pigiste mais qui lit les articles sur l'utilisation de son langage dans d'autre magasine que Login depuis un épisode déjà décrit ici et qui l'a fait passer pour un débile moyen auprès de ses voisins de TGV. (Le coup du tableau, c'était dans "Programmez!")
[^] # Re: en JAVA????
Posté par Anonyme . Évalué à 0.
Le fait de vérifier deux fois le dépassement de l'index (une fois dans le client, une foisdans la méthode) n'est pas très propre non plus.
Parfois il vaut faire un peu porcin ...
[^] # Re: en JAVA????
Posté par Anonyme . Évalué à -1.
En effet, car moi je suis un gourou.
> Figure toi que décrémenter une boucle ira plus vite que ta solution de porc...
En effet, car moi j'ai la solution.
> eh oui, il semblerait que la création d'un objet soit coûteuse en temps machine...
> or ta super astuce entraîne la création d'un objet ArrayOutOfBoundException.
En effet, car moi j'ai l'Astuce
> Arrêtez de dire n'importe quoi.
En effet, fermez là, c'est moi qui parle.
Merci et encore bravo. L'égo large fera toujours vomir.
[^] # Re: en JAVA????
Posté par Wawet76 (site web personnel) . Évalué à 1.
[^] # Re: en JAVA????
Posté par Romain Guy . Évalué à 1.
Je suis toujours aussi dégoûté par le nombre de débiles qui traînent ici.
[^] # Re: en JAVA????
Posté par Anonyme . Évalué à 0.
... le nombre de débiles qui traînent ici.
Ce n'est même plus du niveau du lapsus. A rajouter à la liste des "neuneu", "crétin", "naze", "imbécile", ...
Bel exemple du castrateur-insulteur en action.
[^] # Re: en JAVA????
Posté par Anonyme . Évalué à 0.
> présentée comme un truc de tueur alors que
> c pas très catholique...
Hmmm, pourquoi ne pas commencer par optimiser la clareté de tes post?
Cela permettra à tous ceux que tu traites de "débiles" d'éviter les erreurs d'interprétation de tes <ironique>paroles divines</ironique>.
[^] # Re: en JAVA????
Posté par Dugland Bob . Évalué à 1.
avec la méthode Electric fence (sous UNIX)
tu réserve un truc plus long que nécessaire, tu le mmap(1) dans un fichier, tu vire l'accès en lecture au fichier, tu catche le signal SIGSEGV (signal(1)) et tu parcours le truc j'usqu'au signal.
2 petits problèmes :
BSD et Linux n'ont pas le même comportement de signal(1)
Certains proc ne peuvent accéder qu'a des frontières de mot.
Trop facile !
[^] # Re: en JAVA????
Posté par Anonyme . Évalué à 0.
[^] # Re: en JAVA????
Posté par MetalX . Évalué à 1.
Si on part comme ca, ca va devenir /. assez vite
[^] # Re: en JAVA????
Posté par Dugland Bob . Évalué à -1.
Java ça pue, c'est indiscutable, un point c'est tout !
# Vraiment impressionant ... (explication sur java A LIRE!)
Posté par Anonyme . Évalué à 0.
Je veux bien que l'ai machine ait changé aussi, mais au debut il etait tout simplement impenssable de pouvoir faire un tel truc ... ou alors en reve ;)
Comme quoi quand on optimise les choses il y a une différence ... et meme si Java est la meilleure chose qu'il soit arrivé aux programmeurs depuis longtemps, il n'empeche que savoir programmé et optimiser les choses, c'est toujours le mieux ;)
Une petite recations aux trolls qui circulent sur Java :
Je suis decut de plus en plus par les integristes de l'opensource qui confondent ouverture d'esprit et du code avec totalitarisme. Ceux-ci n'hesite jamais à brocarder sans aucun fondement (ni preuve) sur la place publique une technologie sur laquelle il ne connaissent rien.
Et meme si Sun est parano sur les bords (à tord ou a raison), propager des affirmations comme quoi "Java n'est pas opensource" est purement simplificateur voire simpliste :
- Oui on peut faire avec Java des programmes en opensource Jext ou Jedit en sont des bons exemples ...
- Oui des VM son en opensource (kaffe, blackdown, ...) certaines (Sun, IBM) sont en community source seulement seul celle de MS (à ma connaissance) est en close-source.
- Non la specification Java est pas en opensource mais en community source:
Un rappel, dans une license community source on a access INTEGRALEMENT au code source du produit, qu'on peut modifier MAIS qu'on à pas le droit de diffuser sa modif sous le meme-nom (en laissant le nom de Java dessus). Pour intégrer la modif, il faut soumetre à la communauté du produit modifié la modif. Cette modif sera soumise à un vote des délégués (elus au suffrage universel : oui n'importe qui peut voter pour leur election).
Si votre soumission est un patch ou un bug fix, l'approuvation de la modif se fera rapidement... si c'est un ajout de fonctionalité, alors les délégués entament une procedure demande d'amélioration qui à pour but de verifier :
-l'unicité (ca n'existe pas deja)
-l'utilité (il y a un besoin avéré)
-les effets sur l'architecture
-la non-regression
La plateforme Java supposant la compatibilité ascendante totale, il est bien sur evidant que toute remise en cause de ces dogmes conduit à la non-validation de la demande (cf demande de MS concernant les invocations natives, s'en suivit les demélés en justice ...)
On a donc bien ici un processur ouvert dont la seule restriction à pour but d'eviter l'eclatement et le morcellement de la specification. D'ailleur il n'est pas dit que bientot la community source license ne franchira pas le cap de l'opensource ...
Si il y qqch dont je suis sur c'est bien que Java sera la dans 5 ou 10 ans .... quel part aucupera-t-il à cette date ... nul ne peut le dire.
Mais la perénité des applicatifs est quand meme le choix #1 de tout informaticien (meme si certains nouveaux venus ont tendance à l'oublier)
A+
3klr
[^] # Re: Vraiment impressionant ... (explication sur java A LIRE!)
Posté par Sohphie de Montmirail . Évalué à 1.
[^] # Re: Vraiment impressionant ... (explication sur java A LIRE!)
Posté par Romain Guy . Évalué à 1.
[^] # Re: Vraiment impressionant ... (explication sur java A LIRE!)
Posté par ufoot (site web personnel) . Évalué à 1.
Désolé, je peux pas laisser passer ça.
Je veux bien qu'on prétende que le WORA marche a un instant t. Mais pour ce qui est de la compatibilité dans le temps, c'est justement ce qui m'a détourné définitivement de Java. Concrètement, va faire tourner une appli JDK 1.0 avec un JDK 1.1, ben bon courage, tu vas en avoir besoin.
Evidemment on me répondra "oui mais depuis la 1.2 ca va beaucoup mieux patati patata". A cela je répond qu'aujourd'hui l'aspect de Java dont j'aurais besoin c'est tout ce qui est composants serveurs (EJB et tout le tremblement) et "Oh quelle surprise" on s'aperçoit que les vendeurs de serveurs d'application s'empressent de proposer des extensions propriétaires (adieu WORA) et d'une manière générale implémenter des serveurs J2EE avant que tout ait été spécifié par SUN (ex IBM et WebSphere 3 qui était a mon sens un peu en avance sur son temps...). Et hop on est ramené au cas précédent - le même qu'avec C++ - à savoir que la compatibilité reste un problème intordable.
Le langage Java est pas mauvais en soi mais je pense qu'on cherche trop à en faire une solution universelle. Et puis dans la catégorie portable, y'a quand même tous les langages de script (Perl, Python, Ruby, Tcl...) qui tiennent la route. Et pour la performance, un bon ch'tit composant en C et roule ma poule 8-)
[^] # Re: Vraiment impressionant ... (explication sur java A LIRE!)
Posté par François B. . Évalué à 1.
En revanche, des projets comme Kaffe, Classpath ou Gcj reconstruisent from scratch selon les spécifications, ce qui fait qu'ils sont totalement libres.
[^] # Re: Vraiment impressionant ... (explication sur java A LIRE!)
Posté par Anonyme . Évalué à 0.
par ex :
méthode java.io.File.isFile() :
"Tests whether the file denoted by this abstract pathname is a normal file. A file is normal if it is not a directory and, in addition, satisfies other system-dependent criteria."
J'aimerais savoir quels sont ces critères (device, tube nommé, lien symbolique, ... ???) mais dans les sources fournies par Sun (et qui m'ont bien souvent aidées), la méthode est déclarée "native" => et m****
PS : je poste cette question de manière exceptionnelle et oportuniste : je sais qu'on est pas sur le SAV de sun ;-)
[^] # Re: Vraiment impressionant ... (explication sur java A LIRE!)
Posté par Dugland Bob . Évalué à 1.
Natif->JVM (ou JNI, mais pas dans les classes natives)
Sun ne donne pas les source de sa JVM
[^] # Re: Vraiment impressionant ... (explication sur java A LIRE!)
Posté par Anonyme . Évalué à 0.
Sinon pour ceux qui trouvent que Java est un langage mort né. Il devrait se demander pourquoi tous les serveurs d'application en C++ sont maintenant porté en Java (Oracle, BAS, iPlanet) mais aussi pourquoi des universités comme Orsay (XI) et Versailles ont inclus Java à leurs programmes (il y en a d'autres).
--
Cyrille Morvan
Elève à la maison de l'ingénieur d'Orsay (FiiFo)
[^] # Re: Vraiment impressionant ... (explication sur java A LIRE!)
Posté par Dugland Bob . Évalué à 1.
Pourquoi tout le monde utilise Windows ?
Pourquoi IBM parle de Linux ?
Pourquoi on parle de l'UMTS ?
Parce-que c'est la mode.
# Java ça reste lent, mais c'est simple comme les lego.
Posté par Anonyme . Évalué à 0.
-Comme on utilise les librairies standard sun, c'est trés portable (enfin entre solaris, linux et windows, les 3 OS supporté par sun, ça marcherait peut être sous des JDK sous d'autres OS mais on s'en fout, il faut être honnête).
-Il y a bcp de librairies standard, on a pas besoin de reinventer la roue, et on gagne bcp de temps en développement.
-Comme on fait toujours le même type d'applis, on a un squelette déjà fait ce qui nous évite de repartir de zéro à chaque fois.
-On ne se fait pas chier comme en C a gérer la mémoire, ça fait gagner bcp de temps aussi. Bon le fait aussi de faire moins de boulot en aval (programmation) fait que la jvm sera plus chargée en amont.
-avec le jdbc, un accés à une base de donnée c'est "finger in the noize", et tu peux standardiser ton code pour n'importe quelle type de base, il suffit de changer le driver.
Non java est trés agréable à programmer, tu fais trés rapidement du code sale portable et qui reste lisible et maintenable. Surtout la jvm permet d'avoir une certaine stabilité, et en truffant le code de try, catch, tu es sur d'avoir une appli qui ne plantera pas (c'est pas pour autant qu'elle va reagir comme on le voulait :-).
Je compare Java a des lego, c'est facile à monter, c'est amusant, c'est robuste, mais une voiture en lego ne sera pas trés aérodynamique (je parle des briques classiques, pas avec des piéces moulées profilées des nouvelles boîtes).
Le C++ serait un mécano, en théorie plus puissant, mais les boulons se deserent tout le temps. Et tu n'obtiens jamais un montage robuste (c'est pour ça que c'est chiant).
Mais Java reste lent quand même, on ne peut pas comparer une émulation software avec du hardware.
On a quand même des problèmes de perfs de temps en temps.
Mais pour une entreprise ce n'est pas trop grave, ça coute moins cher d'acheter un gros serveur que de developper du code C ou C++ que personne n'arrivera à maintenir et qui sera plus fragile.
Par contre à titre personnel, ça me fait un peu chier de devoir me contenter d'un jeu en 256x256 au lieu de l'avoir en 1024x768.
C'est comme UAE, sur mon duron 650, il arrive enfin a faire tourner des jeux amiga500 à la frame rate. C'est marrant, c'est nostalgique, mais je ça me gonfle de jouer à un jeu "récent" comme si le jeu avait 10 ans avec une machine a 10000FF. Déjà qu'on se plaint que les OS modernes sont gros et bouffeurs de ressources, si tu rajoute une couche java dessus.
Java est dans une niche, et il est trés bien adapté, vouloir le rendre universel serait une erreur. Personnellement, je prefere programmer en C sur mes petits programmes personnels (en général c'est plûtot du calcul math) parce que c'est plus simple.
Mais des qu'il faut faire "moulte" malloc et free, il vaut mieux passer à autre chose, on perd trop de temps à se prendre la tête sur un dépassement de pointeur, sans parler de faire une fonction de sortie propre alors qu'en Java le boulot est maché au détriment de la performance.
Quand a swing, et bien, ça devient vite lourd a programmer, mais ça c'est le problème de tout ihm moderne. Quand a sa rapidité, ben à part Jbuilder qui répond bien, je n'ai pas vu un seul prog java agréable à utiliser en ihm. ça répond pas au quart de tour, et ça devient enervant.
Les applets, c'est un autre problème, ie5.5(d'accord c'est du crosoft, mais dans la philo java, il faut faire des applets qui tournent sur le plus de navigateurs possible) est toujours en 1.0, donc ça reste limité. Mais c'est la solution la plus simple pour faire un programme java qui pourra être lancé sur 80% des ordis de la planéte sans rien connaître aux lignes de commandes et sans faire un .bat ou un .sh en fonction du système.
Il n'y a pas de solutions miracle, la ou sun a vraiment été trés con, c'est qu'ils ont crées un proc virtuels qui étaient un peu trop compliqué à créer dans la réalité. Parce que si on avait des procs bytecode java a 500mhz, le langage aurait pu servir de base solide a un vrai os "multimedia". Ou alors faire du code morphing sur un proc style "transmeta", mais comme il n'y a pas de vai os java, ça ne sera jamais fait (enfin pas tout de suite).
Le plus simple c'est d'utiliser l'OS et le langage adapté à une utilisation particulière et éviter de s'enfermer dans une solution unique, même si à titre personnele, il faut quand même se spécialiser un peu plus dans peu de langages si on veut évoluer et arrêter de butiner à droite ou à gauche sans rien faire de concret.
C'est un peu comme le tunning du systéme, a force de vouloir choisir on ne fait rien.
DARKLEON
[^] # Re: Java ça reste lent, mais c'est simple comme les lego.
Posté par Anonyme . Évalué à 0.
- Grâce à ses classes standard, tu n'as pas à réinventer la roue, et te retrouver avec des algos de tri ou de recherche sub-optimaux. Les gains au niveau macroscopique dépassent largement ce qu'on perd au niveau microscopique.
- Ton appli tourne sur la quasi-totalité des architectures. Pas de portage. Tu peux développer sous Windows ou Linux (pas cher) et déployer sur des clusters de Suns sans inquiétude.
- Le code est plus lisible et maintenable, surtout avec un peu de méthodologie (genre design patterns).
- Le temps de développement est plus court et contient moins de bugs. Et quand ça plante, tu as un vrai stack-trace, pas un segfault 1000 instructions plus loin.
De toute façons, il est temps que les gens comprennent que si un langage est effectivement 10% plus lent qu'un autre, on en a rien à cirer car il suffit de prendre un serveur 10% plus puissant. L'achat du matériel, c'est peanuts comparé aux coûts de développemnt et de maintenance. Les clients veulent un programme qui marche *maintenant*, pas un super module en C optimisé bourré de bugs livré dans 1 an, même si ça va un peu plus vite.
PS: SVP, ne faites pas repartir le troll.
# off topic
Posté par Pierre Tramo (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.