Cook Captain a écrit 216 commentaires

Il existe des bibliothèques qui permettent d'attaquer les ports parallèles de manière assez simple. Si tu as peu d'expérience en programmation de bas niveau, c'est plutot par là que je commencerai à chercher. (rien ne sert de réinventer la roue - sauf si c'est pour apprendre).

Si tu veux faire du portable, il existe une petite api, développée en C, disponible sous Linux et Windows et qui peut être attaqué en Java : http://www.geocities.com/Juanga69/parport/(...)
Sur leur page d'accueil, tu trouveras pas mal d'infos intéressantes (particulièrement dans la section links).

Certes, il s'agit de négligence mais ce n'est pas aussi facile que cela parait de controler tout le code que l'on peut mettre dans un projet. Rien de plus simple pour un développeur acculé par le temps (et c'est souvent le cas) que de repomper sauvagement qq milliers lignes de code GPL d'un projet libre. Et pour le vérifier, c'est vraiment pas évident.

Ca n'excuse pas la faute mais cela peut tout de même expliquer que certaines boites ont pu se faire "piéger". (et je suis presque certain que cela ne se sait pas, en interne comme en externe, dans 99% des cas).

La communaité libre n'apprécie pas (à juste titre) la license proposée par Sun pour son environnement Java (comme elle n'apprécie pas la license DB2 d'IBM, de Photoshop, de Windows, etc...). Cela ne signifie pas qu'elle n'apprécie pas les mérites technologique du langage. Loin s'en faut. Regarde le nombre de projets libres écrits en Java, c'est assez impressionant.

> De mémoire, on n'a jamais vu une telle réaction
> pour le choix d'un autre langage dans un LL.

J'aurais bien été tenté par ksh88...

Pourquoi ? simplement que la seule personne qui a proposé ses services pour faire ce genre de boulot était un développeur Java. C'est expliqué en détail dans un post plus ci-dessous.

C'est con parfois la vie !

Pour mon meilleur ennemi : http://www.thisiscool.com/gcc_mingw.htm(...)

Comme nid à troll on ne fait pas mieux. Et en plus c'est bourré de conneries ( Blackdown n'est pas libre mais "appartient" de fait à Sun, les projets Java libres sont nettement antérieurs à Mono, plus la cote : sur monster.fr 530 offres d'emplois en Java pour 92 en C#, bref que du n'importe quoi!). C'est tjs navrant de voir que moteurs à priori sérieux reprennent ce genre de news.

Pas de panique. Selon un dev. de Classpath, il semble possible de faire tourner Oo 2. avec un environnement java libre : http://spindazzle.org/green/(...)

De toute manière le libre cela se mérite, il ne suffit pas de le décréter. C'est à la communauté libre de prendre son avenir en main pour produire un environnement libre en Java de qualité (et non de chialer/crier sur Sun qui ne fait pas comme elle le souhaiterait). Si certain, ici et ailleurs codaient autant qu'ils gueulaient, il est probable que bcp de projets libres seraient plus avancés.

Et/ou de contribuer à GCJ/Classpath. Notons que Redhat (et compagnie...) fait un travail formidable de ce coté. Vivement un environnement (complètement) libre en Java.

<i> Perdu. Le passage au 35h c'est fait sans diminution de salaire annuel. Du moins dans les textes. Dans ce cas s'etait sur. Tout le monde etait content, car rapporte a l'heure ca faisait une augmentation</i>

A court terme surement. A moyen et long terme c'est une autre histoire.

Quand tu bosses 35h, attends toi à être payé pour ... 35h.

Avec Jakarta je sais pas mais avec celle la tu peux.

http://www.enterprisedt.com/products/edtftpj/overview.html(...)

Tu te relis pas ou t'es de mauvaise foi.

C'est de toi trois posts plus haut :

C'est pas du tout la même philosophie que .NET, celà a des inconvénients, que j'ai cité, mais ausis des avantages : ils forcent le portage sur la plateforme en réécrivant le code à réutiliser et on y gagne en portabilité.

et maintenant :

C'est ce que je reproche à Java : il faut souvent tout réécrire pour tout réutiliser

Comprenne qui pourra !!!

Dans le cas de l'introspection tu aurais une classe dérivée au lieu de ta classe de base. Je ne pense pas que cela soit bien grave...

Il ne l'ont pas choisi car Sun ne voulait pas changer son bytecode comme l'a fait Microsoft. De toute manière, changer le byte code casse beaucoup plus de choses. En tout état de cause, je ne sais pas si c'est un bon choix car de tout manière, il faudra bien qu'un jour le byte code évolue.

Non, pas dans ce cas la. Une implémentation des génériques à la C# entrainerait, je l'ai déja dit un changement de byte code, (comme cela a été le cas pour C#) mais pas d'incompatibilté majeure.

Si pour réutiliser l'existant tu doit réécrire tout le code, c'est effectivement un avantage ERNORME.

Ne fais pas exprês de ne pas comprendre. Je viens de dire plusieurs fois que le framework .Net était énorme et que justement que Mono n'était pas près d'en venir à bout (si'il y arrive un jour). En tout cas dans la version actuelle, il en est trés loin.

>> C'est justement pour ça que j'ai pas trop confiance en M$...
>si c'est juste parcqu'ils ont oublier de documenter 2 ou 3 fonctions dans des vieux APIs, voilà quoi...
Je te trouve un peu naif sur ce coup la :-)

> c'est possible comme dans Mono, mais dans un cas c'est encouragé
La je comprends plus trop, M$ et consorts s'emmerdent à batir le framework .Net pour encourager l'appel de fonction natives. Ils sont masos ces mecs !!!

> l'autre cas [java] c'est déconseillé
Déconseillé, mais possible. (c'est trés différent)

> avec un JNI inbittable
Il ya des générateurs de stub JNI trés bien fait. De plus si tu utilises gcj tu peux toujours te rabattre sur CNI à la fois plus simple et plus performant.

Pour un nouveau projet, il est beaucoup plus interessant de partir à priori sur une technologie portable et à effectuer le minimum en natif. (un peu comme le C vs Asseembleur) et non pas le contraire.

> il est de toute façon toujours possibler plus tard
> de résoudre ce problème en faisant ce travail
> supplémentaire

Non il est justement beaucoup plus facile de faire l'inverse.

> jedirais même que leur implémentation des generics
> va plutôt limiter dans le futur

Une implémentation n'est jamais gravée dans la pierre. Comme l'a fait C#, cela obligera à un changement du bytecode.

D'ou l'intérêt de classpath.

http://www.gnu.org/software/classpath/classpath.html(...)

> ils forcent le portage sur la plateforme en réécrivant
> le code à réutiliser et on y gagne en portabilité.

C'est un gag ou quoi :-)))
Si pour toi la portabilité consiste en une réécriture du code alors là je comprends mieux tes arguments...

> tu oublies la pile "Microsoft" dans les API de Mono
J'oublie rien du tout. Vu sur le site Mono.
http://www.mono-project.com/about/licensing.html(...) (Q131)
Mono dans sa version actuelle n'implémente que le minimum du framework .Net soit les core class couverte par la norme ECMA + qq autres. C.a.d trés peu. Impossible de faire tourner une appli Win.Forms.

> Et ils vont plutôt vite
J'espère pour eux... car y a du boulot.

> Il y a 2 ou 3 trucs qui ne sont pas documentés parcque non destinés à être utilisés (ou alors jsute par Word et Outlook ;) )
C'est justement pour ça que j'ai pas trop confiance en M$...

> Bref tu dis vraiment n'importe quoi.
Je pense que je suis pas seul ici dans ce cas...

Te faches pas :-(, voici l'url :

http://klomp.org/mark/gij_eclipse/(...)

Mono implémente une VM, plus les 3 librairies de base que M$ à gentiment standardisé pour faire plaisir au bon peuple. Donc il est relativement facile de sortir Mono en même temps que M$. Sauf que ça n'a absolument aucun sens au niveau de la portabilité entre les environnements. A partir du moment ou les environnements ne sont pas compatibles (et ne le seront sans doute jamais), je vois pas vraiment l'intérêt de copier commes des bénets M$, avec tous les risques que cela comporte.

Pour Java, il faut comprendre la plate-forme dans son ensemble, et la difficulté vient essentiellement de la mise à jour des librairies (au niveau de la JVM les nouvelles fonctionnalités sont relativement simples à implémenter). En revanche si tu considères, Mono + dotNet, tu t'exposes exactement aux mêmes problèmes, en pire, car les api M$ sont énormes, peu documentées, et sujettes à des évolutions sans préavis. (cf Wine).

Maintenant, comme dans Mono, rien n'empêche une appli Java d'appeler des fonctions natives, ex. http://java-gnome.sourceforge.net/news.en.html(...) . Et tant qu' à faire du non portable, tu peux utiliser GCJ et CNI (plus simple et + rapide que JNI).

Bof ! Dans ma boite, on a du PC x86 (linux et Windows), du Mac OS X et du Solaris et Java fonctionne trés bien sur ces plate-formes. (Je pense que j'aurais pris ma retraite quand .Net pourra supporter toutes ces machines... :-)

Soi dit en passant les dernières JVM d'Apple sont maintenant tout à fait performantes (et stable, ce qui n'a pas tjs été le cas).

Pour pleine de bonnes raisons.

* En fait l'autoboxing peut entrainer des trucs bizarres :

public int compute(int a, int b) {
return a+b ;
}

Qu'est ce qui se passe quand tu fais :

Integer AA = new Integer(1) ;
Integer BB = null ;
int sum = compute (AA, BB) ;

Tu auras un null pointer exception sur une methode qui ne comporte que des types primitifs !!!

* De plus l'autoboxing peut entrainer des pb de perfs assez conséquent si on n'est pas vigilant. (création et destruction d'objets).

Bref moi non plus je ne suis pas un fan...