Dans le monde des serveurs d'application, Jonas est mis en avant par Red Hat, quand Bea (Weblogic) semble vivre des heures difficiles.
Hors des grands serveurs d'application (Websphere, Weblogic, JBoss, Jonas,...) se sont développées des solutions spécialisées, plus ciblées, qui semblent moins ambitieuses au départ mais qui remplissent une attente.
À tel point qu'un mouvement mené par les développeurs - et relayé par les éditeurs de livres (O'Reilly, Manning) - pousse vers des solutions plus simples, mieux dimensionnées, plus flexibles et à terme souvent plus efficaces. Ces solutions sont d'autant plus vite menées et promues qu'elles sont toutes open source.
D'un côté Sun reconnaît l'apport du dialogue et de l'ouverture, et le besoin de fédérer des forces autour de Java, en engageant celui qui s'occupe du site de blogs jroller.
De l'autre l'open source se professionnalise: création de www.springframework.com pour soutenir le framework Spring et gagner sa vie sur les services - comme JBoss.
Pendant ce temps les discussions sur les EJB 3 font rage, et Google engage une armée de développeurs Java de très haut niveau... * Tiger : première RC de Java 5 (ou Java 1.5). Ce qui devait s'appeler Java 1.5 se nommera peut-être en fin de compte Java 5. (NdM : pour connaître la compatibilité de la plupart des JVM libres avec les différents JDK, voir GNU Classpath vs: JDK 1.0, JDK 1.1, JDK 1.2, JDK 1.3, JDK 1.4)
* RedHat propose depuis la fin du mois de juillet un serveur d'applications basé sur JOnAS. (serveur d'appli le 23/8)
* Sorties de deux versions de deux frameworks phares open source : Struts (version 1.2.2) et Spring (version 1.1).
* Première sortie de NetBeans 4.
* Version alpha de Hibernate 3.
* Rod Johnson, Juergen Hoeller, et Bruce Tate fondent springframework.com.
* Google engage des experts de Java à tour de bras : Josuah Bloch, Neal Gafter (Sun), Adam Bosworth, Cédric Beust (Bea),...
* Livres : sortie de "J2EE Development without EJB", "Better, faster, lighter Java" et de "Hibernate in Action".
* jdocs.com : les documentations des principales bibliothèques Java toutes accessibles.
* TestNG (de Cédric Beust), un framework permettant de tester, et qui utilise la programmation orientée aspect.
Aller plus loin
- Téléchargez Java 5 RC (7 clics)
- Struts 1.2.2 (2 clics)
- Spring 1.1 (1 clic)
- Bosworth quitte BEA pour google (1 clic)
- Site de référence (2 clics)
- Site de référence en français (3 clics)
# Java et l'OpenSource.....
Posté par kruskal . Évalué à 10.
Néanmoins, il semble que peu de monde s'intéresse a contribuer aux différentes implémentations libres de Java (gcj, kaffe,.....)
Je trouve ca dommage. Objectweb, Apache et autres Eclipse connaissent les Avantages de l'OpenSource, puisque c'est une part de leurs argumentaires.
Pourtant, ces grosses organisations semblent totalement les ignorer en ce qui concerne les Jvm.
Avec les moyens que ces organisations possèdent, il serait envisageable qu'ils offrent quelques contributions a gcj par exemple. Ecrire les classes qui leurs manquent pour faire tourner leurs softs, et les reverser. Cela permettrait d'obtenir rapidement un gcj bien plus abouti.
Faudra t'il un coup bas de Sun, ou un rachat de celui ci par MS, pour les faire réagir ?
[^] # Re: Java et l'OpenSource.....
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
Toujours est-il qu'il me semble également que pour un projet libre relativement essentiel, classpath bouge bien peu.
A tel point qu'aujourd'hui, la façon la plus simple executer du java de façon libre me semble encore être Mono
[^] # Re: Java et l'OpenSource.....
Posté par ndesmoul . Évalué à 3.
[^] # Re: Java et l'OpenSource.....
Posté par Stéphane Traumat (site web personnel) . Évalué à 8.
C'est comme si on disait aux utilisateurs de Linux de développer des firmwares libres avant de développer linux.
Il y a vraiment deux choses bien distinctes :
- ce qui se passe en dessous de la jvm
- ce qui se passe au dessus de la jvm
Et généralement, les gens sont soit d'un coté de la barrière soit de l'autre.
Donc les gens développent simplement sans se soucier de la JVM qui se retrouve être une abstraction...
Notons quand même que Redhat est en train de porter JOnAS sous gcj. donc il y a bien des contributions des grands groupes à GCJ même si elles ne se voient pas :)
http://about.me/straumat
[^] # Re: Java et l'OpenSource.....
Posté par kruskal . Évalué à 4.
Malheureusement, tout le monde n'est pas a cheval sur les principes comme l'est RedHat: Ces efforts ne sont pas suivis. RedHat a porté Eclipse sous gcj, mais Eclipse n'en fait toujours pas de builds officiels (je ne sais meme pas s'ils ont intégré les patchs de redhat)
Esperons que pour Jonas cela aille différement.
Pour ce qui est de contribuer a gcj, je l'aurais bien fait, mais ayant un jour accepté cette $*#!?&@ de licence de chez sun, je ne peut pas :(
[^] # Re: Java et l'OpenSource.....
Posté par Jiel (site web personnel) . Évalué à 0.
Une licence de non divulgation?
[^] # Re: Java et l'OpenSource.....
Posté par Jiel (site web personnel) . Évalué à 1.
http://linuxfr.org/comments/471067.html#471067(...)
[^] # Re: Java et l'OpenSource.....
Posté par Nicolas Delsaux (site web personnel) . Évalué à 6.
Néanmoins, il semble que peu de monde s'intéresse a contribuer aux différentes implémentations libres de Java (gcj, kaffe,.....)
Je trouve ca dommage. Objectweb, Apache et autres Eclipse connaissent les Avantages de l'OpenSource, puisque c'est une part de leurs argumentaires.
Je ne voudrais pas marcher dans le troll, mais ... pourquoi faire ?
Soyons pragmatiques : les consortiums J2EE sont pour la plupart le fait de grosses structures (même ObjectWeb en fait partie). Et ces structures, si elles voient un intérêt à développer telle ou telle couche applicative, le font. Redévelopper une machine virtuelle, ou participer au développement, ne les intéresse pas, car celles existant (IBM, Sun, BEA) sont suffisament performantes pour leurs besoins.
De plus, dans leur esprit, Java => JVM Sun. J'en veux pour preuve qu'à la SNCF, ils utilisent Weblogic, pourtant fourni avec JRockit (la meilleure JVM pour serveur J2EE), sur une JVM Sun (incompréhensible, mais vrai).
Avec les moyens que ces organisations possèdent, il serait envisageable qu'ils offrent quelques contributions a gcj par exemple. Ecrire les classes qui leurs manquent pour faire tourner leurs softs, et les reverser. Cela permettrait d'obtenir rapidement un gcj bien plus abouti.
C'est vrai que ce serait sympa, mais ça n'intéresse personne. par exemple, moi, réécrire les classes du JDK, je suis désolé, mais ça m'emmerde profondément.
Faudra t'il un coup bas de Sun, ou un rachat de celui ci par MS, pour les faire réagir ?
Tiens, un peu de paranoïa anti méga-corpo ?
[^] # Re: Java et l'OpenSource.....
Posté par bengali . Évalué à 4.
Je ne suis pas aussi enthousiaste que toi sur Jrockit.
Jrockit n'existe que sur Intel 32bits et 64Bits. Si Weblogic tourne sous SPARC(Solaris) ça me paraît logique d'utiliser la JVM de Sun. De plus, de part mon expérience en production de serveur Weblogic je n'ai pas trouvé la Jrockit très stable sous Windows (pas mal de bogues). Elle présente un intérêt que sous Linux car la JVM de SUN y est pas très stable et performante. De +, les outils de monitoring de la JVM existant avec Jrockit existent maintenant pour la JVM de Sun (JVMstat) et beaucoup d'autres arrivent pour Tiger (http://java.sun.com/j2se/1.5.0/docs/tooldocs/(...)).
[^] # Re: Java et l'OpenSource.....
Posté par Stéphane Brunner . Évalué à 3.
- Pour faire une distribution avec des applications Java on ne peut pas utiliser la JVM de Sun car Sun interdit ça redistribution.
- Pour une distribution conne Debian qui tourne sur 11 architectures différentes, ils ont besoin d'une JVM don ils ont le code source pour la compiler sur les différentes architectures (ceci sans parle du contrat social de Debian).
[^] # Re: Java et l'OpenSource.....
Posté par cumulus . Évalué à 2.
Tu en es sûr ?
D'après ce que je lis sur http://java.com/en/download/license.jsp(...) , on en a le droit sous certaines conditions (Paragraphe 2 dans SUPPLEMENTAL LICENSE TERMS).
[^] # Re: Java et l'OpenSource.....
Posté par Stéphane Brunner . Évalué à 2.
[^] # Re: Java et l'OpenSource.....
Posté par gabuzo . Évalué à 4.
C'est probable mais je n'en suis pas complètement sûr. Il existe, en effet, sur Debian des packages (msttcorefonts par exemple) qui n'incluent pas réellement le logiciel mais le télécharge lors de l'installation. Ce genre de manipulation serait probablement faisable avec le JDK/JRE de Sun. J'ai donc tendance à penser qu'il y a d'autres raisons.
[^] # Re: Java et l'OpenSource.....
Posté par Jiba (site web personnel) . Évalué à 3.
C'est une des raisons qui m'a fait abandonner Java (Je faisais des jeux, donc la disponibilité de paquet pour l'utlisateur final était assez importante).
[^] # Re: Java et l'OpenSource.....
Posté par Cook Captain . Évalué à 1.
Il est parfaitement possible et légal de distribuer une JRE avec ses softs.
[^] # Re: Java et l'OpenSource.....
Posté par Jiba (site web personnel) . Évalué à 1.
[^] # Re: Java et l'OpenSource.....
Posté par kruskal . Évalué à 3.
>Tiens, un peu de paranoïa anti méga-corpo ?
Peut tu nous garantir que cela n'arrivera pas ?
En tout cas, si ca arrive, les "grosses structures" en question elles seront les premieres a raler parce que les Jvm libres sont pas assez avancées (et ce jour la tout bougera vite.
Enfin, je rapelle qu'une grosse structure qui veut un java libre, il y en à, et elle s'apelle IBM. Pourtant je n'ai pas l'impression qu'Ibm contribue beaucoup a gcj/classpath
[^] # Re: Java et l'OpenSource.....
Posté par account . Évalué à 2.
http://www-124.ibm.com/developerworks/oss/jikes/(...)
http://www-124.ibm.com/developerworks/oss/jikesrvm/(...)
[^] # Re: Java et l'OpenSource.....
Posté par Pierre Jarillon (site web personnel) . Évalué à 0.
Le standard est défini par le fabricant alors que la norme est régie par un organisme indépendant (les angalis n'ont qu'un seul mot et ont des difficultés à comprendre).
Même si Sun joue bien le jeu et respecte les spécifications qu'il publie, cela constitue un risque potentiel important. Si un jour le conseil d'administration de SUN change de cap et adopte les règles déontologiques de Microsoft, beaucoup de personnes et d'applications seront très mal.
La solution serait de confier ces spécifications et la certification à un consortium comme OASIS.
[^] # Re: Java et l'OpenSource.....
Posté par Pierre Tramonson . Évalué à 3.
Sun donne le droit de faire des implémentations indépendantes de ces spécifications, sous certaines conditions : http://java.sun.com/j2se/1.4.2/docs/relnotes/license.html(...)
Il me semble que des implémentations Open-Source de certaines APIs Java sont reconnues comme implémentations officielles.
La certification J2EE par contre est restée chez Sun et je ne suis pas sur que ça change.
[^] # Re: Java et l'OpenSource.....
Posté par governator . Évalué à 1.
[^] # Quelques questions
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Ce serait sympa d'expliquer ça en détail.
Sans lancer de Troll, Mono est parait-il capable d'executer du java. Quelqu'un a-t-il essayé ?
Dernier petit détai (trollesque ?) tien, tien...le prochain java va s'appeler Tiger comme le prochain OS de chez apple ...
[^] # Re: Quelques questions
Posté par kruskal . Évalué à 5.
>>accepté cette $*#!?&@ de licence de chez sun, je ne peut pas :(
>Ce serait sympa d'expliquer ça en détail.
Ma foi, c'est simple. Quand tu télécharge les sources du j2sdk de Sun, tu a acces a des sources copyrightées de sun, sous une licence (SCSL) qui est tout sauf libre ni OpenSource.
Afin de limiter les risques légaux (genre l'affaire Sco) et sachant que Sun, ce ne sont pas des gens très gentils, les responsables de gcj/classpath ne permettent pas aux personnes ayant eu accès a ces sources de contribuer à leurs projets.
[^] # Re: Quelques questions
Posté par Romain Guy . Évalué à 1.
Pour Mono, ça se passe avec iKvm.
[^] # Re: Quelques questions
Posté par TImaniac (site web personnel) . Évalué à 2.
Oué j'ai essayé.
Ils ont tout simplement fait une machine virtuelle Java au dessus de Mono (IKVM comme indiqué dans le post précédent)
2 intérêts :
utiliser le langage Java avec les outils habituels mais avec les API de Mono par exemple.
lancer une application Java, les API ClassPath sont alors utilisés.
On peut bien entendu mixer le tout, et on peut alors utiliser ClassPath et les API Mono en même temps :)
[^] # Re: Quelques questions
Posté par Nicolas Delsaux (site web personnel) . Évalué à 0.
Et écrire du code qJava qui ne marche qu'avec Mono ? Génial !
A moins de rétroporter les APIs Mono en java, auquel cas ça pourrait être à peine plus générique ...
[^] # Re: Quelques questions
Posté par TImaniac (site web personnel) . Évalué à 3.
Donc ce n'est pas se limiter, c'est utiliser une autre plateforme.
coder en Java sur Mono, c'est avoir le choix entre les classpath ou l'ensemble des possibilité de Mono et de l'interopérabilité qui en découle avec d'autres langage de la plateforme. C'est une question de choix, je ne vois pas l'intérêt de tout backporté sur la machine officielle de Java.
# Hibernate
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: Hibernate
Posté par Gabriel . Évalué à 2.
Mis à part qu'ils tournent sur Jonas bien sûr ;-)
[^] # Re: Hibernate
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
EJB stateless -> pooling, transaction, exportable service web
et c simple ( avec Xdoclet ), je pense que c'est le meilleur endroit pour y placer la logique métier !
http://about.me/straumat
# Et encore, on est loin du compte ...
Posté par Nicolas Delsaux (site web personnel) . Évalué à 5.
Dans le monde des serveurs d'application, Jonas est mis en avant par Red Hat, quand Bea (Weblogic) semble vivre des heures difficiles.
BEA a quand même sorti une très belle nouveauté cette année : Weblogic Workshop, associé au framework Beehive (surcouche de Struts) tous deux très convaincants, comme je l'écris ici http://nicolas.delsaux.free.fr/web/Java/formation.php(...) et qui plus est Open-Source livré à la fondation Apache (qui n'en est plus à un framework web de plus) !
Hors des grands serveurs d'application (Websphere, Weblogic, JBoss, Jonas,...) se sont développées des solutions spécialisées, plus ciblées, qui semblent moins ambitieuses au départ mais qui remplissent une attente.
Tu penses à Spring, manifestement. N'oublions pas Tapestry, WebWork et autres qui montrent une seule chose : il n'existe pas actuellement de solution web réellement convaincante.
À tel point qu'un mouvement mené par les développeurs - et relayé par les éditeurs de livres (O'Reilly, Manning) - pousse vers des solutions plus simples, mieux dimensionnées, plus flexibles et à terme souvent plus efficaces. Ces solutions sont d'autant plus vite menées et promues qu'elles sont toutes open source.
Tu pourrais être plus explicite ? Pour ma part, sur le front du concept, ces derniers mois ont amené l'émergence d'une vraie révolution sémantique, l'IoC, d'un vrai buzzword (l'architecture orientée service ou SOA).
D'un côté Sun reconnaît l'apport du dialogue et de l'ouverture, et le besoin de fédérer des forces autour de Java, en engageant celui qui s'occupe du site de blogs jroller.
Kwé ? D'un autre côté, Sun demande la suppression de tous les API Sun (J2SE, J2EE et J2ME) du site jdocs. Dommage !
Pendant ce temps les discussions sur les EJB 3 font rage,
Ah ça, les EJB, c'est toujours pas gagné, surtout quand on voit qu'il faut environ un mois pour écrire un mapper O/R. La dernière fois que j'ai discuté avec des gens qui avaient écrit des EJB, je leur ai demandé ce que ça leur apportait. Difficile d'avoir une réponse claire sur le sujet, sauf de la part d'une personne bossant pour BEA ... Mais ça peut être une réponse orientée.
et Google engage une armée de développeurs Java de très haut niveau...
Et tout le monde se demande pourquoi : porter Google en Java ? Réécrire des interfaces web en J2EE qui sent, ou sortir son propre conteneur ?
[^] # Re: Et encore, on est loin du compte ...
Posté par Rossel Olivier . Évalué à 2.
Plutot des gens qui ont reflechi sur les agents ou les problemes de parallelisation massive.
[^] # Re: Et encore, on est loin du compte ...
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: Et encore, on est loin du compte ...
Posté par Nicolas Delsaux (site web personnel) . Évalué à 2.
Plutot des gens qui ont reflechi sur les agents ou les problemes de parallelisation massive.
Je vais parler pour celui que je connais par mail (Cedric Beust). Lui, il m'a surtout l'air d'être une brute en Java. Peut-être qu'il connaît ces problématiques, mais ce qu'il connaît surtout, c'est le Java. Et j'ai comme l'impression que pour les autres têtes, c'est pareil.
[^] # Re: Et encore, on est loin du compte ...
Posté par Stéphane Traumat (site web personnel) . Évalué à 4.
A mon avis, C'est pas Java par hasard :)
http://about.me/straumat
[^] # Re: Et encore, on est loin du compte ...
Posté par Romain Guy . Évalué à 2.
On trouve ça tous dommage mais ce que faisait JDocs.com avec la doc de J2SE allait à l'encontre de la licence que tu acceptes lors du téléchargement de cette doc. Rick Ross et Matt Schmidt modifiait ainsi le contenu de la documentation sans permission. Heureusement il y a aujourd'hui une parade : la doc est affichée dans une frame en haut et les notes en bas. C'est moins pratique que pour les autres APIs mais c'est mieux que rien. Et ils continuent à faire pression sur Sun :)
[^] # Hasta la revolucion..
Posté par Gabriel . Évalué à 3.
Tu pourrais être plus explicite ? Pour ma part, sur le front du concept, ces derniers mois ont amené l'émergence d'une vraie révolution sémantique, l'IoC, d'un vrai buzzword (l'architecture orientée service ou SOA).
J'ai l'impression qu'on reprend les mêmes problèmes mais au lieu de construire une grande solution toute faite et qui se voudrait tout terrain (à la EJB), on reprend avec les bases du langage (POJO) et on construit de petites solutions ciblées : jdo/Hibernate pour la persistence, Struts/webwork/tapestry pour les vues... et un framework d'application (pico Container, Spring) pour relier le tout.
ça amène d'un part à des solutions plus simples à construire et à appréhender. Deuxio, ça pousse (toujours plus) vers les modèles Model-View-Controller. On a donc une séparation des tâches qui devient nette, entre les controllers, le model et les vues.
Et dans ce sens je trouve aussi que IoC est un achèvement : cela revient à découper ses classes de manière très strictes, à bien les tester. Chacun fait une seule chose mais la fait bien.
Puis seulement après à les re-cabler , à les relier avec le framework Spring ou Pico.
Le tout est assez cohérent dans la démarche. De plus cela amène une plus grande solidité : si JDO ne suffit pas tu le remplaces dans ton cablage (IoC) par Hibernate ou par une solution jdbc, sans toucher au reste. Ce qui implique naturellement de coder par interface, afin de rendre le code remplaçable facilement: la classe qui utilise hibernate peut être remplacée par la classe qui utilise ojb (ou ejb) tant que le contrat défini par l'interface est rempli. De plus dans le contexte de test, on peut remplacer très facilement les vrais objets par de faux objets qui suivent le même interface mais qui mimeront le comportement d'un objet normal en envoyant des donénes en dur, afin d'isoler l'objet. L'implémentation devient une question de configuration.
Cela fait beaucoup de "bonnes pratiques" d'un coup: separation of concerns, Inversion Of Control, classes testables, faire au plus simple (POJO), coder des interfaces.
Et les questions "matérielles", de charges pour la base de données par exemple sont laissés à la base de donnée, ce qui semble assez acceptable.
Donc, oui, je pensais aussi à l' IoC :-)
Pour le SOA : on dirait que c'est un peu du vent. Mais l'idée de programmer avec l'objectif derrière de délivrer un service, pourrait bien devenir peu à peu une sorte d'obligation, pour mettre en relation les données de serveur en serveur.
[^] # Re: Hasta la revolucion..
Posté par Le Rat Puant . Évalué à 1.
[^] # Re: Hasta la revolucion..
Posté par Gabriel . Évalué à 9.
Naturellement tu fera
ObjetQuiPermetAccesBaseDeDonnees o= new ObjetQuiPermetAccesBaseDeDonnees()
o.save (mesDonnees)
C'est ton objet qui appelle ObjetQuiPermetAccesBaseDeDonnees
Bref, tu as codé en dur le nom de l'objet qui te permet de faire de la persistence.
Tu pourrais mettre une interface (mais bien sûr tu mets déjà une interface), mais quand même quand tu vas instancier ton objet, il faudra bien dire quelle est la classe utilisée.
InterfacePersistance o= new ObjetQuiPermetAccesBaseDeDonnees()
Le principe de l'inversion de contrôle (aussi appelé drôlement "syndrôme d'Holywood") est:" Don't call me I call you"
Objet, ne demande pas une instance de ObjetQuiPermetAccesBaseDeDonnees. C'est un moyen extérieur qui va te passer la référence à cet objet- en l'occurence un framework.
Ce framework va lire un fichier xml de config où il y aura écrit : "Voici l'objet que je vais utiliser pour sauvegarder mes données : c'est ObjetQuiPermetAccesBaseDeDonnees"
Autrement dit, tu as défini ce qui relie chacune entre elles chacune des couche qui font ton appli.
Avantage : c'est défini en un seul endroit. Tu veux changer ton appel à une base de données par une gestion via un file système : tu changes la config. Ou tu veux tester ton objet - et pas l'accès à la base de données : au lieu d'utiliser l'objet qui fait l'accès à la base (et qui ets peut-être buggé) tu crées un faux objet (Mock) qui va mimer le comportement attendu - mais que tu veux pas tester.
Avantage aussi : un seul lieu pour centraliser le cycle de vie des objets. En général, un accès en base c'est un singleton. Là, c'est ton framework qui va être responsable de la vie de l'objet , donc de son unicité.
de même tu peux du coup très facilement, par config, quand tu crées un objet, dire d'executer telle méthode (log, sécurité) et ainsi tu implémentes en un seul endroit un comportement général (aop)
http://martinfowler.com/articles/injection.html(...)
http://www.dotnetguru.org/articles/dossiers/ioc/ioc.htm(...)
[^] # Re: Hasta la revolucion..
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: Hasta la revolucion..
Posté par Nicolas Delsaux (site web personnel) . Évalué à 1.
[^] # Re: Hasta la revolucion..
Posté par Laurent Sansonetti . Évalué à 4.
http://copland.rubyforge.org/(...)
[^] # Re: Hasta la revolucion..
Posté par Nicolas Delsaux (site web personnel) . Évalué à 2.
Tant mieux, parce que moi, la solution J2EE/EJB ne m'a pas du tout séduit : à chaque fois que j'ai eu des EJBs sous les yeux, j'ai trouvé que c'était nettement trop complexe pour le besoin exprimé. En fait, c'est bien simple, je n'ai jamais vu de cas où ça se justifiait.
ça amène d'un part à des solutions plus simples à construire et à appréhender.
Ca n'est pas non plus systématique. Une solution super-classe à base d'IoC pourra être particulièrement complexe à comprendre, pour le débutant, meêm si elle présentera bien plus d'élégance.
Deuxio, ça pousse (toujours plus) vers les modèles Model-View-Controller. On a donc une séparation des tâches qui devient nette, entre les controllers, le model et les vues.
Et c'est justement ça qui est pour nous évident, alors que pour d'autres il est incompréhensible de faire la séparation. Il y a encore un rude travail d'éducation à faire.
Et dans ce sens je trouve aussi que IoC est un achèvement : cela revient à découper ses classes de manière très strictes, à bien les tester. Chacun fait une seule chose mais la fait bien.
Puis seulement après à les re-cabler , à les relier avec le framework Spring ou Pico.
Mais pourquoi utiliser un framework pour faire ça ? C'est la grosse question que je me pose à propos de l'IoC. Effectivement, c'est très bien dans le concept, mais je ne vois pas pourquoi je vais passer par l'un ou l'autre pour recâbler mon appli.
Le tout est assez cohérent dans la démarche. De plus cela amène une plus grande solidité : si JDO ne suffit pas tu le remplaces dans ton cablage (IoC) par Hibernate ou par une solution jdbc, sans toucher au reste. Ce qui implique naturellement de coder par interface, afin de rendre le code remplaçable facilement: la classe qui utilise hibernate peut être remplacée par la classe qui utilise ojb (ou ejb) tant que le contrat défini par l'interface est rempli. De plus dans le contexte de test, on peut remplacer très facilement les vrais objets par de faux objets qui suivent le même interface mais qui mimeront le comportement d'un objet normal en envoyant des donénes en dur, afin d'isoler l'objet. L'implémentation devient une question de configuration.
Je demande quand même à voir. Tout programme cache dans ses entrailles une bonne dose de dépendances non inversées (ou complexité cyclomatique, tant qu'on y est à utiliser des termes de barbares), et les enlever ne mérite parfois pas l'effort qu'on y fournit.
Cela fait beaucoup de "bonnes pratiques" d'un coup: separation of concerns, Inversion Of Control, classes testables, faire au plus simple (POJO), coder des interfaces.
Oui, enfin, la doctrine KISS, ça fait un bout de temps que ça devrait être le livre de chevet des développeurs Java, même si en réalité ça n'est pas le cas, et de loin.
Et les questions "matérielles", de charges pour la base de données par exemple sont laissés à la base de donnée, ce qui semble assez acceptable.
Pas pour les DBAs ;-)
Là où un programme d'avant gérait lui-même sa charge par une espèce d'effet domino rigolo, le programme moderne risque fort de beaucoup plus charger (notamment dans le cas d'un mapping O/R), et de faire s'affoler inutilement le DBA (je l'ai vu encore tout récement). Et le problème, dans ce cas-là, c'est quon considère encore la base comme plus importante que le logiciel (un blasphème, à mon sens, mais bon ...).
Donc, oui, je pensais aussi à l' IoC :-)
Pour le SOA : on dirait que c'est un peu du vent. Mais l'idée de programmer avec l'objectif derrière de délivrer un service, pourrait bien devenir peu à peu une sorte d'obligation, pour mettre en relation les données de serveur en serveur.
En fait, le SOA, j'ai bien l'impression que ça permet de vendre plus de webservice, alors même que mon esprit orienté performance me sussure que les webservices sont au service d'une contreperformance évidente. mais bon, ça fait plaisir aux dicaïdors pressés ...
[^] # Re: Hasta la revolucion..
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
et j'ai déja eu de très dur débats avec des DBA pour leur dire que quand je développais, je m'en fouttais un peu de la db :)
http://about.me/straumat
[^] # Re: Hasta la revolucion..
Posté par Nicolas Delsaux (site web personnel) . Évalué à 1.
Excuse-moi de te dire ça froidement comme ça, mais ... tu rigoles, là ?
Parce que moi, ma logique métier, je la mets dans des POJOs, et mes EJBs (je dis mes, mais c'est uniquement didactique) ne servent qu'à la faire s'interfacer avec un monde d'entreprise. En disant ça, est-ce que je passe pour un demi-extra-terrestre, ou est-ce que je peux éventuellement être dans le vrai ?
et j'ai déja eu de très dur débats avec des DBA pour leur dire que quand je développais, je m'en fouttais un peu de la db :)
Tiens, c'est marrant, moi aussi. Et générallement, ces DBAs te disent que la charge de leur base est hyper-importante, avant même que quiconque ait fait le moindre test de charge de l'application sur la base, bref, ils te demandent à toi d'optimiser, parce que eux, ça les fatigue ;-)
[^] # Re: Hasta la revolucion..
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
C'est pareil que moi.. n'empeche que la logique métier est partagée au monde via les ejbs. c'est poru cela que j'utilise les ejbs :)
Pour les DBA, ils me disent qu'on peut pas faire abstration de la base de données ! tout à fait impossible et que de toute façon, ca dégraderait les performances
http://about.me/straumat
[^] # De la psychologie du DBA was Re: Hasta la revolucion..
Posté par Nicolas Delsaux (site web personnel) . Évalué à 1.
Il faut les comprendre : leur dire ça revient à leur dénier leur rôle de chef d'orchestre du système d'information, pour en faire de simples administrateurs d'archives. D'un coup, c'est moins classieux. D'un autre côté, c'est exactement leur boulot : une donnée dans une base est à peu près aussi utile qu'un classeur au fond des archives.
[^] # Re: De la psychologie du DBA was Re: Hasta la revolucion..
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
# C'est pas Neat-Bean...
Posté par Patrix (site web personnel) . Évalué à 3.
http://www.netbeans.org(...)
# Java trap
Posté par TazForEver . Évalué à 2.
http://www.gnu.org/philosophy/java-trap.fr.html(...)
projets libres basés sur Java ne tournant que sur JVM de Sun, pas vraiment libre en somme...
[^] # Re: Java trap
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
http://about.me/straumat
[^] # Re: Java trap
Posté par Stéphane Traumat (site web personnel) . Évalué à 0.
http://about.me/straumat
[^] # Re: Java trap
Posté par Nicolas Delsaux (site web personnel) . Évalué à 3.
Est-ce que tu utilises actuellement un ordinateur libre ?
Parce que bon, c'est bien gentil de développer avec une plateforme libre, mais ton OS, lui, il l'est ? (sans doute) Et ton processeur, est-il libre ? Le disque dur, la RAM, le câble réseau, les switches qui t'amènent jusqu'à LinuxFR, sont-ils complètement ouverts ?
Qui qu'on soit, il est toujours bon de se renseigner un minimum avant de causer, quand bien même on s'appelle Stallman.
Le processus définissant l'évolution du langage Java est libre, et organisé par le JCP. Ce qui n'est pas libre, ce sont les implémentations de machine virtuelle, dont celle de Sun. Maintenant, il me semble que cet appel à bosser sur CLASSPATH te vise autant que moi. Alors, si tu arrêtais de te plaindre pour l'aider ?
Maintenant, vous pouvez toujours me moinsser, si ça vous amuse d'assurer l'orthodoxie de LinuxFR ...
[^] # Re: Java trap
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
En même temps quand on s'appelle Nicolas Delsaux aussi on peut se renseigner... (et je ne prétends pas avoir la vérité absolue, mais bon quand on commence par « C'est un tissu d'âneries ou quoi ? » pour ensuite critiquer sans argument quelqu'un qui a déjà fait énormément de choses (qu'on l'on aime ou pas)...)
Les différences entre le matériel et le logiciel sont telles que les problématiques y sont complètement différentes (enfin jusqu'à ce que quelqu'un ait fabriqué une machine à multiplier les cartes mères ou les disques durs à coût nul).
Et même dans l'immatériel, les problématiques entre ce qui a une fonction utilitaire ou pas sont différentes. C'est d'ailleurs le coeur de la divergence d'opinion entre Debian et la FSF sur ce qu'est une documentation libre.
[^] # Re: Java trap
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: Java trap
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
L'avis de la FSF :
http://www.gnu.org/philosophy/linux-gnu-freedom.fr.html(...)
« Pour la même raison, ajouter de tels binaires aux sources Linux viole la GPL.
Les développeurs de Linux ont prévu de placer ces programmes de firmware dans des fichiers séparés; cela prendra des années avant d'y arriver, mais quand ce sera accompli, cela résoudra le deuxième problème; nous pourrions faire une version «Linux libre» qui ne contiendrait pas les fichiers de firmware non-libres. Ce ne sera pas très bénéfique en soi si la plupart des gens utilise la version «officielle» non-libre de Linux. Cela pourrait très bien arriver, car la version libre ne fonctionne pas sur bien des plateformes sans les programmes firmware non-libres. Le Projet «Linux libre» devra découvrir ce que font les programmes firmware et écrire le code source, peut-être en langage assembleur, sur un quelconque processeur intégré sur lequel il est exécuté. C'est un travail décourageant. Cela aurait été moins décourageant si nous l'avions fait petit à petit, au fil des années, plutôt que de le laisser s'accumuler. En recrutant des gens pour faire ce travail, nous devrons surmonter l'idée, répandue par quelques développeurs de Linux, que ce travail n'est pas nécessaire. »
[^] # Re: Java trap
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
J'ai bon ou pas ?
http://about.me/straumat
[^] # Re: Java trap
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
[^] # Re: Java trap
Posté par Yusei (Mastodon) . Évalué à 4.
Stallman dit au sujet de Linux qu'il est en partie non libre, et le projet GNU essaye de développer The Hurd.
Je ne vois pas d'incohérence entre les deux cas.
Évidemment, on peut faire remarquer que la plupart des BIOS ne sont pas libres, que le matériel lui même n'est pas libre, et utiliser cela pour "prouver" que l'on peut utiliser des logiciels propriétaires. C'est un peu bizarre d'utiliser l'imperfection du libre pour proposer encore plus d'imperfection, mais bon pourquoi pas.
La différence entre les deux cas, cependant, est qu'il est très difficile de se passer des BIOS propriétaires, et impossible de se passer de matériel propriétaire (à ce jour), alors qu'il est très facile de se passer de Java pour développer un nouveau projet. D'où la validité de la recommandation de Stallman. Après, on peut être d'accord avec lui ou pas, mais sa recommandation est cohérente.
[^] # Re: Java trap
Posté par Yves Dessertine . Évalué à -1.
... qui n'est pas libre non plus. Redescendez de votre nuage :)
[^] # Re: Java trap
Posté par Nicolas Delsaux (site web personnel) . Évalué à 2.
L'un des avantages de l'industrie informatique, c'est son pragmatisme. Si Bill Gates fait une connerie, n'importe qui ici lui dira (s'il le peut). De la même manière, le fait que Stallman ait écrit un tas de choses pour le libre ne signifie pas qu'il aura raison à tous les coups. Et en l'occurence, ce document est un tissu d'inepties. Par exemple, quand il dit
i vous développez un programme Java sur la plate-forme Java de Sun, vous êtes voués à utiliser de fonctionnalités Sun exclusives sans même vous en rendre compte.
Il se gourre grave. Toutes les classes fournies dans la JVM de Sun, comme dans les autres, sont définies et évoluent grâce au JCP (ou Java Community Process) sur lequel je vous laisse vous documenter librement, mais qui est nettement ouvert dans son processus d'évolution. Il garantit par ailleurs que les fonctionnalités d'une JVM qui y sont définies (en clair, tout les packages java.* ou javax.*) sont standardisés dans leur interface et dans leur implémentation.
Alors, évidement, je ne sais pas si le JCP respecte complètement la Philosophie du Libre comme il l'entend. Mais pour moi, je sais que je peux influencer les JSR en cours, et donc faire évoluer Java dans ma direction. Et ça me suffit largement.
De la même manière, l'argument selon lequel il fallait "sauver" (sous-entendu pour le libre) le C, parce que c'était le seul langage existant, et le shell, parce que bon, sinon, compiler, c'est pas gagné, mais que Java ne mérite pas ce sauvetage parce que l'arche du libre n'est pas assez grande tient vachement la route, mais alors avec une classe folle.
Et puis, terminer par une exhortation à aller vérifier sur le site de la FSF que le programme utilisé est bien libre, ça fait plus concours de hits à l'ancienne qu'autre chose. Surtout quand on compte le nombre de programmes Java majeurs Open Source (au choix Eclipse, Tomcat, Ant, JBoss, NetBeans, Struts (enfin, ça, c'est pas un bon exemple), Beehive, ...).
Bref, pour moi, ça sonne beaucoup plus comme une espèce de message du vieux développeur C bien content d'être libre etr qui nous emmerde tous que comme autre chose.
Les différences entre le matériel et le logiciel sont telles que les problématiques y sont complètement différentes (enfin jusqu'à ce que quelqu'un ait fabriqué une machine à multiplier les cartes mères ou les disques durs à coût nul).
Ca, c'est étayé, comme argument. Il y a des tonnes de différences, et alors ? La JVM est, quelquesoit son constructeur, censée être un processeur virtuel fonctionnant à la base comme interpréteur de bytecode en code machine pour 'larchitecture cible.
Dans un monde idéal, (que Sun n'a JAMAIS appelé de ses voeux), la JVM serait un coprocesseur (ça existe, les processeurs Java, mais ça marche moyen), et serait donc du matériel. Que dirait alors Stallman ? Faites plutôt vos opérations sur les coprocesseurs vidéo, au firmware nettement plus libre ?
[^] # Re: Java trap
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Si tu utilises Swing dans un logiciel libre en Java, il y a de fortes chances qu'il ne soit pas utilisable dans le « Monde Libre » défini dans le texte. Cette fonctionnalité est disponible dans la plate-forme Java de Sun mais pas dans Classpath.
Il aurait aussi pu parler de la plate-forme Java d'IBM. Bref ce n'est pas l'architecture Java qui est concernée mais les implémentations propriétaires.
Exemple en C++ :
« Dinkumware
http://www.dinkumware.com/manuals/reader.aspx?b=p/&h=map.html#m(...)
iterator erase(iterator where);
iterator erase(iterator first, iterator last);
size_type erase(const Key& keyval);
GCC STL v3
http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-3.3/cl(...)
void erase (iterator __position)
size_type erase (const key_type &__x)
void erase (iterator __first, iterator __last)
SGI STL
http://www.sgi.com/tech/stl/Map.html(...)
void erase(iterator pos)
size_type erase(const key_type& k)
void erase(iterator first, iterator last) »
Si tu as codé ton logiciel libre en C++ avec la bibliothèque STL de Dinkum et que tu as utilisé la valeur de retour de la fonction membre erase(), ton code utilise des fonctionnalités spécifiques à Dinkum (et absentes de la norme).
>
Dans un monde idéal, (que Sun n'a JAMAIS appelé de ses voeux), la JVM serait un coprocesseur (ça existe, les processeurs Java, mais ça marche moyen), et serait donc du matériel. Que dirait alors Stallman ?
La même chose (je présume) que pour les instructions MMX, 3DNow et Cie propres à certains processeurs. On pourrait avoir du logiciel libre sans dépendre de logiciels propriétaires. Par contre il faudrait forcément avoir un processeur de cette famille pour utiliser le logiciel. Le mieux serait bien sûr que d'autres fondeurs puissent cabler ces instructions.
[^] # Re: Java trap
Posté par Nicolas Delsaux (site web personnel) . Évalué à 2.
Sans doute parce que CLASSPATH n'est pas au niveau des autres JVM (je me demande même s'il s'agit d'une JVM validée). Les autres JVM doivent fournir Swing, qui fait partie des API de Java.
Il aurait aussi pu parler de la plate-forme Java d'IBM. Bref ce n'est pas l'architecture Java qui est concernée mais les implémentations propriétaires.
Je ne le comprend pas comme ça. Les classes java.* et javax.* sont disponibles dans toutes les JVM (ça, c'est le "contrat moral" que passent ceux qui fournissent des JVM). En revanche, lorsqu'on accède à une classe sun.tools.javac.Main (par exemple) on sait qu'on n'en disposera que dans la JVM de Sun (et encore, seulement en installant le JDK). Il me semble que Stallman mentionne plutôt le second cas (utiliser une classe non-standard en pensant qu'elle l'est) quel le premier (utiliser une classe standard, et tomber sur une "implémentation" ne respectant pas le standard).
Et dans ce cas, il se gourre violement. Le code que j'écris n'utilise pas autre chose que du java.* (enfin, presque, il y a un peu de org.apache.*, mais ça, c'est quasi-obligé), et peut donc s'exécuter indifférement sur une JVM Sun, IBM, BEA ou CLASSPATH, pour peu qu'icelle supporte réellement les bibliothèques java.*
[^] # Re: Java trap
Posté par tanguy_k (site web personnel) . Évalué à 6.
> chances qu'il ne soit pas utilisable dans le « Monde Libre » défini
> dans le texte. Cette fonctionnalité est disponible dans la plate-forme
> Java de Sun mais pas dans Classpath.
et ben non, Swing en libre ca existe !
http://forum.hardware.fr/forum2.php?config=hardwarefr.inc&post=(...)
De facon generale je rappelle que Java n'est pas moins libre que C++, C, C# ou meme UNIX.
Java c'est des specifications et un ensemble d'API, libre ensuite a chacun de programmer une implementation. Linus Torvalds a cree Linux il l'a voulu compatible avec UNIX, tout comme GCC implemente C++ et le C. Bref s'il n'y a pas d'implementation libre de Java c'est pas de la faute de Sun mais c'est de la faute des developpeurs de logiciels libres. Apres il est vrai que si Sun pouvait mettre Java sous LGPL ca serait "sympa".
[^] # Re: Java trap
Posté par Stéphane Brunner . Évalué à 2.
# Logiciel libre et java
Posté par Jiel (site web personnel) . Évalué à 5.
Pour ceux qui utilisent tout ça, ça a l'air pas mal avec les stats donnés plus haut... ça marche vraiment bien en pratique?
Merci d'avance :)
[^] # Re: Logiciel libre et java
Posté par hachesse . Évalué à -1.
voyons, faut quand meme rester raisonnable, le libre, c'est formidable certes, mais tomber dans l'extremisme n'apporte jamais de bon.
renoncer a tous les avantages de java parceque le JVM de sun n'est pas libre, tres peu pour moi, je prefere encore des initiatives comme celle d'IBM visant a faire ouvrir java plutot de de recoder une JVM qui sera toujours en retard (classpath n'est pas encore 100% compatabile avec le JDK 1.1)
[^] # Re: Logiciel libre et java
Posté par Stéphane Traumat (site web personnel) . Évalué à -2.
http://about.me/straumat
[^] # Re: Logiciel libre et java
Posté par Yusei (Mastodon) . Évalué à 5.
D'un autre côté, si tout le monde s'était dit ça au sujet, au hasard, de Photoshop, on n'aurait jamais eu GIMP.
J'ajouterais qu'on a de très bons langages et de très bonnes plateformes qui n'ont rien à envier à Java, en libre, et que beaucoup de gens choisissent Java parce que c'est connu, pas parce que c'est un bon produit.
(J'ai fait du Java, beaucoup... depuis j'ai découvert des langages qui font que je n'ai aucune envie d'y retourner... Qui a dit Ruby ? :-)
[^] # Re: Logiciel libre et java
Posté par Stéphane Traumat (site web personnel) . Évalué à 4.
Ruby, je ne le connais pas mais je sais que je peux tout faire en java et que vive les drivers jdbc :)
http://about.me/straumat
[^] # Re: Logiciel libre et java
Posté par Yusei (Mastodon) . Évalué à 1.
Je sais que je peux tout faire en "machine de Turing", mais c'est pas très réconfortant :-)
[^] # Re: Logiciel libre et java
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: Logiciel libre et java
Posté par tgl . Évalué à 4.
[^] # Re: Logiciel libre et java
Posté par Romain Vinot . Évalué à 1.
Dans n'importe quel language actuel, ça se fait en 3 lignes ou moins. En ruby, en perl, en python... En C++ pur, c'est un peu plus dur, mais avec n'importe quel framework C++, pas de problème.
Et sinon, comment tu fais en Java pour configurer l'accès à ta base de données ? Tu écris dans un fichier XML tellement imbittable qu'il faut une interface graphique pour écrire ce qu'il faut dedans pour le JNDI.
Dans n'importe quel language, le fichier de conf, il faut 2-3 lignes et c'est compréhensible par un mortel qui n'est pas spécalisé dans la techno.
Bref, ça tourne à du n'importe quoi tout ça...
[^] # Re: Logiciel libre et java
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Est ce qu'à un seul endroit tu m'as vu écrire que en ruby perl ou python, il était difficile de se connecter à une base de données ?
Et au lieu de me dire de ne pas donner de leçons sur les autres langages, apprends à ne pas donner de leçon en java que tu ne sembles pas connaitre.. tu n'as pas besoin forcément besoin de JNDI ou de fichier XML...
con = DriverManager.getConnection("jdbc:mysql:///test", "root", "secret");
Meme toi tu devrais comprendre non ?
TU dis vraiment n'importe koi, relis, apprends, et cesse de faire des amalgames
http://about.me/straumat
[^] # Re: Logiciel libre et java
Posté par Stéphane Traumat (site web personnel) . Évalué à 0.
http://about.me/straumat
[^] # Re: Logiciel libre et java
Posté par Romain Vinot . Évalué à 2.
Il m'aurait fallu tenir compte du contexte :)
[^] # Re: Logiciel libre et java
Posté par TImaniac (site web personnel) . Évalué à 1.
Et si t'avais pas les API et qu'il te fallait les écrire, tu crois pas que t'aurais du boulot et que tu rigolerais en Java ?
En Java, tu peux tout faire, du moment que celà reste de haut niveau.
Le langage Java a des limitations qui l'empêche d'utiliser certaines notions rendant impossible tout ce qui touche de près le matériel.
Bref, Java c'est bien, mais pas pour tout faire.
[^] # Re: Logiciel libre et java
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
Bien entendu, java ne permet pas de parler au processeurs mais à part ça.. réseau, db, fichiers, xml, thread, graphisme, 3d, portable.... tu peux à peu près tout faire...
http://about.me/straumat
[^] # Re: Logiciel libre et java
Posté par TImaniac (site web personnel) . Évalué à 0.
Ben ca peut servir à faire des API tiens !
J'imagines bien qu'il ne faille pas réinventer la roue, mais faut bien la fabriquer pour pouvoir l'utiliser...
Tu ne pourras jamais faire un système d'exploitation en Java par exemple, ou très limité ! Et puis faut bien la faire la machine virtuelle aussi :)
Bref, tu peux pas faire tout ce qui touche de près le système comme je l'ai dis. Tu ne peux pas faire de drivers par exemple.
D'où mon explication : tu peux tout faire, du moment que celà reste de haut niveau.
Autre truc : tu ne veux pas réinventer la roue et tu veux utiliser une bibliothèque non disponible en Java : tu vas devoir réinventer la roue ou faire un binding avec JNI, relativement pénible à écrire... celà devient parfois du travail de conception quand il faut essayer de contourner les limitations du langage Java (tout ce qui touche les pointeurs, structures, ne peuvent être "bindé" directement à la louche)
[^] # Re: Logiciel libre et java
Posté par Yusei (Mastodon) . Évalué à 3.
D'un autre côté, ça tourne un peu en rond... Tout langage a une API qui lui permet d'effectuer des calculs à un niveau inférieur, jusqu'au moment où on n'est plus dans le domaine du logiciel, mais dans celui du matériel.
Les langages de haut niveau ne proposent pas une API de bas niveau, mais ce n'est pas un bug, c'est une fonctionnalité. Donc en aucun cas un défaut lié à Java.
[^] # Re: Logiciel libre et java
Posté par TImaniac (site web personnel) . Évalué à 3.
Ben non, pas les langages de bas niveau, en l'absence d'API tu peux tout refaire à la main, sans aucune liaison avec une quelquonque bibliothèque : juste le compilateur pour traduire dans le langage machine.
Les langages de haut niveau ne proposent pas une API de bas niveau, mais ce n'est pas un bug, c'est une fonctionnalité.
Donc on est bien d'accord, Java est limité au Haut niveau et ne peut donc pas permettre de tout faire.
Mais tout de même, créer facilment des bindings est une feature intéressante justement pour un langage de haut niveau, et pour celà le langage Java n'est vraiment pas un exemple de simplicité.
[^] # Re: Logiciel libre et java
Posté par Yusei (Mastodon) . Évalué à 2.
Même l'assembleur possède une API. L'API, c'est ton interface avec le niveau d'en dessous, par définition. L'API en assembleur va te permettre de savoir quelle interruption fait quoi, quel registre correspond à quoi. Si tu ne sais pas comment t'interfacer avec la couche inférieure, tu ne peux rien faire.
Il n'y a pas de différence fondamentale entre l'assembleur qui te permet de manipuler des registres et un langage de plus haut niveau qui te permet de manipuler des structures de plus haut niveau.
[^] # Re: Logiciel libre et java
Posté par TImaniac (site web personnel) . Évalué à 2.
Même l'assembleur possède une API.
Je parlais plus généralement d'API en tant que bibliothèques de fonctions... Ce n'est pas pour moi de simples interfaces, il y a du code derrière et des algorithmes (c'est ce qui fait pour la grosse différence entre l'assembleur et les classes du JDK ;) ). Considérer les instructions matérielles comme un API me semble donc sortir du contexte, puisque constituant notre socle commun. On pourrait alors étendre les limites du langages aux limites des instructions de la JVM, qui sont encore plus handicapantes que les possibilités du langage.
Java peut simuler une machine de Turing. donc Java peut faire ce que peut faire n'importe quel ordinateur.
Cette machine sera virtuelle et non physique, et n'aura donc accès à aucun périphérique autre que les ressources mises à dispositions par la JVM ou par l'intermédiaire d'API écrits dans d'autres langages (Comme qui dirait, En théorie c'est faisable, mais dans la pratique celà ne marchera jamais). Java est un langage, on ne le compare pas à aux fonctionnalités d'une machine, mais plutôt aux possibilités d'expressions offertes par sa grammaire.
Ce que je veux dire, c'est que certains éléments sont infaisables en Java car inexprimable à l'aide de sa syntaxe. C'est pourquoi certaines fonctionnalités doivent être codés dans un autre langages. Ce n'est pas insurmontable dans l'ensemble, puisque le langage Java n'a pas cette ambition d'exploiter toutes les possibilités offerte par une machine, mais celà est plutôt embêtant dans le sens où ces insuffisances demandent à être comblées par des API "natifs", et c'est là que le bas blaisse, Java ne facilite vraiment pas l'intégration de ces API, JNI n'est vraiment pas flexible et demande beaucoup d'adaptation.
[^] # Re: Logiciel libre et java
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
En fait, le langage Java a pour but de faire abstraction des possibilités des machines en utilisant leur caractéristiques communes et ainsi permettre aux développeurs de développer de manière indépdante.
99% des applications existantes pourraient être développée en Java.
http://about.me/straumat
[^] # Re: Logiciel libre et java
Posté par Yusei (Mastodon) . Évalué à 2.
Il n'y a pas de différence.
[^] # Re: Logiciel libre et java
Posté par TImaniac (site web personnel) . Évalué à 2.
Un processeur offrant un jeu d'instruction et donc d'opération et d'enchaînement, tout comme un langage.
Enfin je ne penses pas que celà remette en cause globalement mon raisonnement vis à vis des "lacunes" de Java, mineures certes, mais poussant parfois à réinventer la roue tellement l'utilisation d'une bibliothèque écrite dans un autre langage est fastidieuse.
Et puis en Java, il manque la feature qui tue : on ne peut pas faire une fonction inverse qui prend 2 entiers (pas leur équivalent wrappés) et inverse leurs valeurs =)
ok je sors -->[]
[^] # Re: Logiciel libre et java
Posté par Yusei (Mastodon) . Évalué à 4.
On est à la fois d'accord et pas d'accord. Java peut simuler une machine de Turing, donc Java peut faire ce que peut faire n'importe quel ordinateur. Ça, c'est rêglé. Ensuite, Java obligeant à une abstraction vis à vis de la machine réelle sur laquelle il tourne, il impose des limitations d'accès à cette machine, là dessus on est d'accord.
[^] # Re: Logiciel libre et java
Posté par ckyl . Évalué à 3.
http://jnode.sf.net(...)
[^] # Re: Logiciel libre et java
Posté par TImaniac (site web personnel) . Évalué à 0.
[^] # Re: Logiciel libre et java
Posté par allcolor (site web personnel) . Évalué à 2.
C'est pas toi qui serait bidon par hasard ?
[^] # Re: Logiciel libre et java
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Logiciel libre et java
Posté par TImaniac (site web personnel) . Évalué à 2.
Et alors ? si le schéma l'a mis là ce n'est pas pour autant que y'a un lien direct entre les 2...
Suffit de voir où est la JVM... tout ce qui se trouve à droite devrait être au dessus de la JVM, sinon celà ne peut pas être en Java... Enfin je suppose que le schéma est plus "lisible" comme ceci, ils ont voulu faire l'analogie avec les fonctionnalités des kernels.
Y'a un n-kernel dont le but est d'effectuer (comme tout kernel) l'abstraction matérielle, bref, cet OS est en grande partie en Java si on prend la définition Windozienne d'un OS (avec les classes et tout), mais si on prend la définition Unixienne, y'a la moitié en rouge, la moitié en vert, et la partie eu rouge montre bien qu'on ne peut pas tout faire en Java.
[^] # Re: Logiciel libre et java
Posté par allcolor (site web personnel) . Évalué à 3.
[^] # Re: Logiciel libre et java
Posté par TImaniac (site web personnel) . Évalué à 2.
On s'en fou, il est là, et justement pour faire un des taf le plus important de l'OS.
La taille de la partie en rouge reflète la taille réelle de code natif de l'os et c'est pas 50% daisolai.
Moi j'aurai pas dit 50% non plus, mais dans ce acs la taille de la partie en rouge ne reflète PAS la taille réelle. Parcque sinon ca fait bien 50%, tout ce qui est au dessus de la JVM ce n'est plus l'OS.
Et puis il me fait marrer leur memory manager, y'a quand même le GC et le heap qui sont gérés "ailleur", dans un mélange vert/rouge qui montre bien que là encore faut de l'asm dès que sa touche au matos.
Bref, ils ont fait un OS en Java, mais ils se sont juste amuser à coder le maximum de choses en Java en évitantr la partie "sensible" parcque impossible à faire.
[^] # Re: Logiciel libre et java
Posté par ckyl . Évalué à 3.
n'importe quoi :-)
De nos jour la partie la plus importe d'un OS c'est certainement pas la couche basse qui s'addresse directement au materiel. C'est d'ailleur bien souvent une couche interchangeanble ou tu pourrais mettre n'importe quoi d'autre dessous. Par exemple le port de NetBSD sur certaines archis s'est fait en un week end. Et bien evidement tout n'est pas écrit en java ! Sans asm point de salut, de toute facon l'affaire est pliée. Tu connais un langage portable qui est capable de positionner les drapeaux PE et PG du registre CR0 ? Moi pas.
Donc quoi que tu fasses, tu auras toujours le langage machine en dessous et une abstraction de la machine juste au desus (ou alors tu fais un OS pour une archi donnée).
Si suis ton raisonement linux n'est pas en C. Pourtant la VM, les drivers, la gestion des I/O etc. est ecrite en C (tout comme dans jnode elle est ecrite en Java) et toutes les fonctions generiques sont en fait specialisées pour chaque archi a la compile et bien souvent ecritent.... en assembleur :-)
[^] # Re: Logiciel libre et java
Posté par TImaniac (site web personnel) . Évalué à 2.
C'est vrai que faire la première couche d'abstraction pour un OS c'est vraiment pas un taf important. C'est pas parcqu'il est "simple" qu'il est pas important.
Tu connais un langage portable qui est capable de positionner les drapeaux PE et PG du registre CR0
Oué mais au moins en C tu peux toujours faire asm("mov ax,bx"), c'est simple et ça marche. D'où ma remarque concernant JNI, qui est parfaitement imbittable avec élégance.
tu auras toujours le langage machine en dessous et une abstraction de la machine juste au desus (ou alors tu fais un OS pour une archi donnée
Oué mais si tu regrde bien le schéma de l'"OS" en Java, même la couche au dessus n'est pas en Java mais toujours en ASM...
Si suis ton raisonement linux n'est pas en C
Non j'ai pas dis celà. Ce que j'ai dit c'est que Java ne permet pas de tout faire. J'ai pas dit que le C pouvait, mais le C peut faire beaucoup plus.
(tout comme dans jnode elle est ecrite en Java)
Euh, c'est bien joli mais le mélange rouge/vert montre bien qu'il doivent impérativement utiliser de l'asm, même au dessus du n-kernel...
Franchement je vois pas où tu veux en venir :-) J'ai jamais dis que C pouvait tout faire, j'ai juste voulu montrer que Java était vraiment pas conçu pour faire du bas-niveau, ton exemple est parfait pour montrer celà.
PS : j'aimerai bien voir une appli écrite en C tourner sur jnode... Parcqu'un OS ne doit pas limiter l'utilisateur en l'obligeant à utiliser un seul langage avec GC et tout le tralala... Il doit lui laisser libre accès à la mémoire si l'utilisateur en a envi.
PS2 : tu gère comment la mémoire d'une carte graphique avec un driver en Java ?
[^] # Re: Logiciel libre et java
Posté par allcolor (site web personnel) . Évalué à 2.
Une vm peut faire tourner plusieurs langages (vm = virtual machine). Bien sûr le langage qui tourne de base sur une jvm, c'est java. Mais tu as par exemple rhino qui permet de faire du js, jpython du python... et pourquoi pas du C qui aurait comme target la jvm.
Oué mais si tu regrde bien le schéma de l'"OS" en Java, même la couche au dessus n'est pas en Java mais toujours en ASM...
Mais non les drivers, la gestion mémoire sont écrite en java. Il est évident que pour booter du java, il faut du code natif, c'est ce que fait ce nkernel qui bootstrap une minivm qui bootstrap la vm finale. Maintenant l'accès au matériel n'a rien avoir avec le fait que ça soit java ou non. Après ce que le proc execute c'est toujours du code natif. La vm compile à la volée en code binaire. Le code asm/C de jnode est ridicule comparé au code java. Dire que jnode n'est pas un OS en java est de la grosse foutaise.
[^] # Re: Logiciel libre et java
Posté par TImaniac (site web personnel) . Évalué à 2.
Tout à fait d'accord. Après la vm peut quand même limiter les possibilités.
pourquoi pas du C qui aurait comme target la jvm.
Parcque les instructions de la JVM ne le permettent pas. La JVM n'a pas du tout les mêmes instructions qu'un proc classique...
Mais non les drivers, la gestion mémoire sont écrite en java.
mais si moi je te parlais de ce qu'il y avait au dessus du n-kernel, driver et IO sont au dessus de la JVM.
Dire que jnode n'est pas un OS en java est de la grosse foutaise.
Pas pour moi. C'est comme si tu faisais une voiture sans moteur : c'est joli, mais même si le moteur est petit, voir simple à faire, c'est un élément vital. Pour moi le boulot principal d'un OS est de fournir la première couche d'abstraction du matos, et de gérer l'allocation des ressources (processeur et mémoire centrale).
Dans JNode, tout ce taf est fait grâce à l'assembleur, ils ont juste rajouté une surcouche Java pour la gestion mémoire (parcque par derrière tout ce fait au niveau du GC et de la JVM, la gestion des processus étant faite au niveau de la JVM, etc.
[^] # Re: Logiciel libre et java
Posté par allcolor (site web personnel) . Évalué à 2.
C'est faux. La jvm est une machine de turing universelle... alors je vois pas pourquoi on pourrais pas faire un compilo qui target la jvm. Peut-être du au model de la jvm, le resultat ne sera pas forcement performant mais faisable ça l'est et sur les spec de la jvm actuelle.
[^] # Re: Logiciel libre et java
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Logiciel libre et java
Posté par allcolor (site web personnel) . Évalué à 2.
Il y a un point d'entrée dans la vm qui permet d'accéder aux matos, et tu codes avec l'interface qui va bien et tu auras accès en java à la zone mémoire de la carte, je vois pas où se situe le problème. Il est évident qu'il y a une couche native qui donne l'accès au pointeur de la mémoire, à partir de là, tu fais tout le reste en java.
[^] # Re: Logiciel libre et java
Posté par TImaniac (site web personnel) . Évalué à 2.
Et après je fais comment pour faire des optimisations si je n'ai pas accès à la pile ? Je vais tout me colletiner sur le tas ? Parcque bon un driver c'est quand même principalement de l'optimisation des ressources, avec des astuces toutes les 2 lignes, je parle dans le cas d'une carte graphique...
[^] # Re: Logiciel libre et java
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
# à propos de classpath
Posté par Alex G. . Évalué à 3.
Y-a-t-il de la réutilisation de bouts de codes d'autres projets GPL. Mono et classpath font-il un peu de travail commun ? (les api sont très différentes mais travaillent sur le même type d'objets, exemple opur faire le module sur les polices d caractères il faut un spécialiste des polices et du code surement proche dans les deux cas).
Je demande ça car je me demande toujours si la réutilisation du code est une utopie ou on y arrive parfois ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.