@FremyCompany: En effet, mais généralement quand une application est pilotable par des classes .Net, ces classes sont aussi COM-exposables.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
@FremyCompany: En effet, mais généralement quand une application est pilotable par des classes .Net, ces classes sont aussi COM-exposables.
Pour faire une integration "in process" des plateformes MS (par exemple si je veux intégrer une bibliothéque .Net directement dans un code java, sans passer par les web services), en dehors de COM, je ne vois pas une autre Technologie MS que l'on peut utiliserEnvoyé par _skip
il existe des bridges java-.NET qui font plutôt bien leur travail, en particulier JNIBridge
Ah je n'étais pas au courant de l'existence de ce "pont", donc j'ai mal choisi mon exemple pour illustrer l'importance actuelle de la technologie COM. En fait ce que je voulais faire comprendre c'est que, comme COM est plus ancien et plus intégré dans des bibilothéques de plusieurs langages, si on veut utiliser .Net "in proces" dans un environnement qui ne possède pas de "pont" .Net, il faudrait qu'on "enveloppe" d'abord les composant .Net dans des composants COM et créer ainsi soit même ses propres "pont"
Je pense plutôt que l'application est pilotable via OLE/COM et que ce sont ces objets COM qui sont utilisés via interop en .NET.
Les applications Microsoft sont rarement écrites en dotNET. Au mieu elle propose une interface via dotNET.
Bon je n'ai pas regardé les versions 2007 non plus mais je doute que ça change de si tôt.
Plus ou moins. Sur la plateform dotNET, il est clair que la démarche de Microsoft est de tout proposer accessible depuis dotNET.Je sais pas si je me trompe mais je vois vraiment COM comme une technologie mourante sur le point d'être remplacée.
Cependant, il existe généralement aussi la version Win32 avec des objets COM.
Par exemple, le dernier client SQL Server ADO.NET avec SqlClient. Avec SQL 2005, Microsoft a mis à jour le framework. Malgré tout, il existe également SQL Native client qui est exclusivement basé sur les objets COM.
dotNET ne fait pas encore tout sur Windows. Il y a toujours une bonne couche de code natif, avec des objets COM. Et je pense qu'il y aura toujours du code natif.
Donc je pense que dotNET va prendre beaucoup d'importance par rapport à COM, mais que COM continuera d'exister pendant encore un bon moment...
Office 2007 est bel et bien en .Net, ses DLLs COM sont devenus des assemblys COM-Visible.
office 20007 est écrit au complet en .net?
managed?
Je ne sais pas si c'est en totalité, mais c'est bien possible...
Des frameworks payants en java/J2EE ???Lol, parle d'homgénéité pour Java si tu veux, mais laisse moi quand même rire un bon coup
Java en lui même est homogène, mais son framework "de base" est trop court, ce qui oblige à passer par d'autres frameworks (parfois payants)... qui eux sont myriades et pas du tout homogénéisé. Sans compter les dépendances entre eux
Ma foi cela existe peut-être mais grand dieux, pourquoi faire ? Depuis des années je bosse sur java et je n'ai jamais utilisé que des librairies et des frameworks LIBRES et/ou GRATUITS (Struts, Spring, apache libs..., GWT) et leur potentiel est assez satisfaisant pour ne pas chercher la même chose en version payante ailleurs ! (Et je n'ai jamais entendu parler d'une telle chose...)
Pourrais-je avoir des exemples des frameworks payants que tu utilises stp ? (par curiosité) merci d'avance.
PS : en quoi JAVA n'est-il pas homogène ? Sa structure et ses specs en font un des langages les plus homogènes que je connaisse... là encore merci de donner des exemples pour étayer vos arguments svp !
Personnellement en .NET on est aussi parfois obliger de passer par des frameworks payants.
Et en .NET c'est beaucoup plus rares les librairies gratuites et performantes.
Il est pas bon mon argument ?Java en lui même est homogène, mais son framework "de base" est trop court, ce qui oblige à passer par d'autres frameworks [...] qui ne sont pas forcément compatibles entre eux.
Pour le comprendre, suffit de voir comment fonctionne éclipse et ses plugins (même si maintenant cela va mieux car pas mals de plugins ont été "intégrés" à l'IDE).
Pour ce qui est des frameworks payants, je ne dis pas qu'ils sont indispensables, je dis qu'ils existent voilà tout. Faut pas tout mélanger non plus.
Salut
Ok, et comment fonctionne eclipse et ses plugins ?Pour le comprendre, suffit de voir comment fonctionne éclipse et ses plugins (même si maintenant cela va mieux car pas mals de plugins ont été "intégrés" à l'IDE)
C'est pas au contraire l'une des preuves vivantes de la puissance de la plateforme Java et OSGi ?
En fait, tu as des tonnes du plugins (c'est bien) mais qui sont souvent rendondants, et chacun à ses avantages. Seulement, ils ne sont pas compatible entre eux, ont des intérdépendances casse-pieds et parfois difficiles à cerner (un plugin A peut demander le plugin B, qui ne s'installe que si le plugin C et D sont installés mais qui rentre en conflit avec le plugin K suites à des noms de classe semblables, mais celui-ci apporte une fonctionnalité vraiment intéressante et est nécessaire au plugin L, qui est lui aussi très chouette, et ainsi de suite).
Si au moins ces liens étaient clairs, mais ce n'est pas le cas, et si les plugins étaient décrit mieux que par un simple nom - ce qui n'est a nouveau pas le cas, - ca irait peut-être déja mieux...
De plus, chaque plugin redéfinit souvent les mêmes types de fonctions ce qui alourdit inutilement tout le truc.
J'ai utilisé visual studio avec les librairies devexpress, et cela a beau être payant ça met sur le cul tant en terme de productivité que de puissance.
Je produis des IHM d'une qualité surprenante en quelque minutes, et à 98% en visuel.
Ca, quand je lance mon eclipse, c'est vraiment la chose qui me manque, surtout lorsqu'on travaille beaucoup avec des composants comme les JTable qui ne peuvent quasiment pas être manipulés dans les éditeurs. C'est quand même agréable lorsque l'on peut voir ses colonnes dans l'IDE, fixer leur libellé, leur donner les bonnes dimensions...
Pour moi, ce qui pêche en java c'est vraiment ça....
VS n'a pas besoin de DevExpress pour être plus performant qu'Eclispe.
Mais c'est normal, car même le language a été prévu pour (attributs ComponentModel.*, Windows.Forms.*, Windows.Forms.ComponentModel.*, ...). A ma connaissance, il n'y a aucun équivalent à "<Designer(...)>" ou a "<TypeConverter(...)>" ou encore à plein d'autres en Java.
Netbeans 6 commence à être pas mal, mais est encore loin de s'approcher de ce que j'ai vu de Visual Studio ... en 2001. C'est sûr que Visual doit être ultra productif quand on veut faire un logiciel de compta en standalone.
Mais pour autant, je n'ai aucune envie de basculer vers Visual. L'avantage de Java est que tout est gratuit, documenté et fiable. Il faut avoir cependant un peu de jugeotte pour ne pas partir dans des technos qui risquent d'être désuettes.
Avec .NET, il faut éviter de partir dans des technos... qui mettent la clé sous la porte. Moins facile à évaluer
Et l'avantage de .Net est que tout est gratuit, documenté et fiable.
Soyons sérieux 30 secondes, ton argument ne tient pas la route.
Le monde .Net est aussi fournit en frameworks et composants gratuits et/ou opensource que le monde Java.
D'autre part, permet-moi de douter qu'il n'existe pas de produits développés en Java qui soit payant ?C'est une clause de la licence d'utilisation ? Article 133.5 : Si vous développez en Java, votre produit doit être opensource et gratuit ?
La seule chose à déplorer côté .Net est que Visual Studio est payant, plutôt cher, et qu'il se positionne comme l'environnement incontournable grâce à la puissance et au confort d'utilisation qu'il apporte.
Il existe néanmoins des projets tel que SharpDevelop qui sont suffisement aboutis pour être parfaitement viables en entreprise; donc au prix de quelques sacrifices de confort, les alternatives gratuites existent quand même.
E
D'autre part, permet-moi de douter qu'il n'existe pas de produits développés en Java qui soit payant ?
Ceux qui peut coûter cher, plutôt que les frameworks, c'est certains serveurs d'applications (typiquement Websphere d'IBM qui tourne sur le JDK d'IBM (qui lui n'est pas open source)) (bon après, il y a des avantages par rapport à d'autres serveurs gratuit/open source évidemment)
Le designer de netbeans commence à ressembler à quelque chose, au moins la disposition visuelle de composants peut se faire sans imbrication de layout/panels et autres immondices.
J'ai commencé il y a 6 ans avec jbuilder 7, et là je vois la différence. Il est bien que la communauté java réalise à quel point le GUI est important dans une application, c'est quand même ce que l'utilisateur voit, et le but d'une majorité d'application est de satisfaire un utilisateur.
Il y a quand même quelque chose qui m'étonne, vous croyez donc qu'il est impossible de se planter en utilisant des technologies open source et gratuites? J'ai assez vite fait de trouver autour de moi des exemples d'entreprise qui ont voulu économiser des sous et qui se sont plantées royalement.
Vs2008 est payant et alors? Si vous faites trois fenêtres un peu complexes avec le designer vous avez déjà économisé un temps qui vaut plus cher que la licence. Il faut pas simplement regarder le prix d'un produit mais aussi le temps qu'il fait économiser, et là c'est de l'investissement.
Dans cette même optique, il m'est arrivé de payer pour des composants alors qu'il existait des alternatives gratuites et cela justement pour pouvoir profiter d'un SUPPORT. C'est bien joli d'économiser 200 euros mais lorsqu'on est bloqué 3 jours avec un post dans le forum d'une communauté à attendre que quelqu'un ait bien envie de répondre, c'est vrai qu'on gagne des sous là!
Bon je vais pas faire basculer le débat sur de l'open source, mais ce n'est pas parce que c'est gratuit que c'est tout rose que ça fait économiser plein d'argent. Et ce n'est pas parce que c'est dotnet que c'est payant et qu'il n'existe rien de valable et gratuit sur le net.
Voilà je veux qu'on discute un peu de productivité entre Java et .Net en rebondissant sur l'exemple que tu as cité.
Si je veux faire un logiciel de compta en Java, il y a déjà des ERP open source et fiables (et j'insiste sur la fiabilité..) qui font cela. Donc il me suffira juste de l'adapter à mon besoin, et pour sa maintenance et son extension, je peux tirer profit de la communauté.
Pour le faire en .Net je vais probablement réinventer la roue. Peut être je peux rapidement faire de belle fenêtre.., mais la maintenance risque d'être plus longue, car je risque mettre le même nombre de temps que la communauté open source à mis pour obtenir le logiciel avec un certain degré de stabilité.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager