:strip_icc():strip_exif()/u/3678/stimpy.jpg?f=community)
Wat jij vergeten bent, hoeft voor mij geen spoed te zijn.
:strip_exif()/u/26181/Hunnypot-new60.gif?f=community)
:strip_exif()/u/31397/dilbert2.gif?f=community)
Je kan ook misschien MS Java.Net gebruiken? 
We adore chaos because we like to restore order - M.C. Escher
Java.NET is van Remotesoft: http://www.remotesoft.com/javanet/index.html:
Je kan ook misschien MS Java.Net gebruiken?
Waarschijnlijk bedoel je Visual J#. Maar daar zit ik niet aan te denken. Gewoon de API van de serverside Java-applicatie aanroepen en de teruggekeerde waarden gebruiken in een .NET applicatie.:
Je kan ook misschien MS Java.Net gebruiken?
Ik vraag me dan af of het gemakkelijk in .NET gedaan kan worden omdfat Microsoft zegt dat je alle talen kan gebruiken. Waarschijnlijk zal je dus eerst de API moeten parsen naar XML/SOAP zodat deze gebebruitk kan worden in .NET. Rechtstreeks de API aanspreken kan waarschijnlijk niet.
Wat jij vergeten bent, hoeft voor mij geen spoed te zijn.
Als je dit zo goed weet misschien kan je dan ook eens een antwoord bedenken op de gestelde vraag ipv je druk te maken over of Java APi nou wel of niet een taal is.
Wat jij vergeten bent, hoeft voor mij geen spoed te zijn.
Verwijderd
Ik wijs de topicstarter op een lees/denkfout, als je daar problemen mee hebt dan ga je maar bij een moderator klagen.:
Als je dit zo goed weet misschien kan je dan ook eens een antwoord bedenken op de gestelde vraag ipv je druk te maken over of Java APi nou wel of niet een taal is.
/u/63681/soia.png?f=community)
/u/2046/pooh2.png?f=community)
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
doel je hier op het feit dat een van de mooie dingen van .NET is dat je 1 API hebt, die in alle .NET talen gelijk is, en dat gebruik maken van de java API dus redelijk zinloos zou zijn?
zo niet: kun je dan even toelichten wat je bedoelt?
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik bedoel met name dat de tweede kijk op de zaak in feite het bestaansrecht/nut van een enigszins onnodig incompatible platform in twijfel trekt. Aangezien het platform echter bestaat is het niet zo nuttig om dat bestaansrecht/nut te bespreken....
.
Deze standaard libraries (en de native code die erbij hoort) is echter niet open. Als deze wel open was, zou een andere partij vrij eenvoudig een port kunnen maken naar .NET. Hiervoor moeten enkele vervelende problemen worden opgelost (reflectie, primitieven, classloader), maar dit gaat maar om een hele kleine kern. Java Collections en Swing zullen bijvoorbeeld vrijwel geen aanpassing van de code vereisen. Sun zal dit natuurlijk nooit doen, maar handelt hiermee absoluut niet in belang van de ontwikkelaar, die gewoon sommige extreem goede Java libraries in .NET wil gebruiken.
De situatie is op .NET is hetzelfde als op het Java Platform: alle talen die op de JVM draaien kunnen gebruik maken van de Java API. Dat is alleen een heel oud discussie-punt waar je niet echt een duidelijke punt achter kan zetten
.Zeker niet, .NET api's zal je ook in een bepaalde taal moeten implementeren (C# bijvoorbeeld). Waarom zou je dan geen libraries willen gebruiken die in Java geimplementeerd zijn? Het Java Platform kent een heleboel uitermate interessante bibliotheken die menigeen maar wat graag op .NET zou willen zien draaien (Xalan, Xerces, Jing, FOP, Batik, Corba implementatied, JDBC drivers om maar eens wat te noemen). Als de 'basis' libraries van Java 2 Standard Edition volledig op .NET zouden kunnen draaien zouden vrijwel ale deze libraries direct kunnen draaien op .NET omdat compilatie van Java naar IL niet echt een punt is. Het beschikbaar maken van deze libraries zou dus als een enorme katalysator kunnen werken en eigenlijk is het doodzonde en een kleine ramp voor de ontwikkelaar dat hier niet direct uitzicht op is. Dat het mogelijk is, heeft Microsoft al laten zien omdat de antieke Java versie die Microsoft nog mocht distribueren al wel aangeboden wordt om J++ klanten niet al te veel te naaien.
Deze standaard libraries (en de native code die erbij hoort) is echter niet open. Als deze wel open was, zou een andere partij vrij eenvoudig een port kunnen maken naar .NET. Hiervoor moeten enkele vervelende problemen worden opgelost (reflectie, primitieven, classloader), maar dit gaat maar om een hele kleine kern. Java Collections en Swing zullen bijvoorbeeld vrijwel geen aanpassing van de code vereisen. Sun zal dit natuurlijk nooit doen, maar handelt hiermee absoluut niet in belang van de ontwikkelaar, die gewoon sommige extreem goede Java libraries in .NET wil gebruiken.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
ah zo, thx
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Haha
Je zegt het alsof je jezelf erg veel lef vindt hebben .Het hangt er vanaf wat hij precies wil. Als ik het goed begrijp wil hij gewoon een library gebruiken die in Java geschreven is. Het hangt het een beetje van de aard van de library af of het nuttig is om deze met SOAP aan te gaan spreken.
Als het een library is die duidelijk fungeert als een software component waarmee je data uit wilt wisselen, kan SOAP een prima oplossing zijn als de overhead van deze vorm van communicatie tussen een Java VM en .NET geen probleem is.
Veel libraries fungeren echter niet bepaald als software component en bieden met name functionaliteit aan aan andere code (denk aan Java Collections, Corba, JDBC, Swing, JAXP, TrAX bijvoorbeeld). Ik zou niemand aan willen reden om met dergelijke libraries te gaan gebruiken via SOAP.
Dit gaat precies over datgene waar ik het hierboven over heb. Ik geloof alleen niet dat ik dat project erg serieus moet nemen als ik het zo bekijk. Allereerst is de naam Java .NET kansloos dus het wordt duidelijk niet gedaan door mensen die goed nadenken en ik zie nog weinig concreets. Er zijn wel interessantere initiatieven op dit punt denk ik.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
Soms heb ik hier 't idee dat ik nog een aardig groentje ben. Hoewel ik erg gecharmeerd ben door het concept van SOAP, heb ik het slechts eenmaal in de praktijk gebruikt (ok, ook meteen een groot project), en kan ik nog niet zo'n goed oordeel vellen over alle voor- en nadelen. (Is ook niet echt mijn gebied, moet ik eerlijk toegeven.):
Haha
Dat zijn we natuurlijk met elkaar eens. Alleen vermoedde ik, door zijn "serverside-applicatie"-opmerking dat het vooral om datauitwisseling en niet zozeer om functionaliteit ging. (Dan lijkt een client-server model me sowieso erg nadelig, daar heeft soap niet zoveel mee te maken).
Mwah, er doen hier aardig wat mensen met veel minder achtergrond hun mond open hoor
. Het is prima om het er niet mee eens te zijn: nu de manier waarop je het probleem opvatte duidelijk is, had je in feite nog gelijk ook.Idd.
Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment
/u/13469/ada.png?f=community)
Ja dit kan, tenzij je een eigen VM wil maken, loosly coupled. De meest voor de hand liggende oplossing (maar niet die met de beste performance) is SOAP. Door de grote hoeveelheid tools werkt dat ook het lekkerst waarschijnlijk
Je kan bv. lekker de code voor je laten genereren en je merkt dan nauwlijks nog (tijdens het coden in ieder geval) dat je eigenlijk loosly coupled aan het werken bent. Verwacht echter nooit dezelfde performance.. hoe minder de functie doet hoe groter in verhouding het verschil wordt. Bv. een functie aanroepen die simpel weg een variabele returned is in SOAP waarschijnlijk minimaal 10.000 keer zo traag.. maar als je een complexe functie hebt die 10 seconden over z'n berekening doet is het verschil relatief veel kleiner. Hou hier dus rekening mee in je design. Ook functies die een erg grote hoeveelheid data returnen worden trager.
Is performance *wel* heel belangrijk voor je zoek dan liever een andere oplossing als SOAP (1 van die oplossingen is het porten van je code naar .NET).
Opera OpenOffice.org Jabber Psi jabber://llama@mordax.com
/u/2305/crop653618cca8542_cropped.png?f=community)
Pagina: 1