Hallo zusammen,
ist es möglich eine Dll aus VB in Java zu nutzern ?
Hier schonmal probiert?
Gruß
Wenn es sich um richtiges VB handelt und nicht um VB.NET, dann wäre das schon möglich. Einen Mischmasch aus .NET und Java solltest du dir aber besser so schnell es geht aus dem Kopf streichen, das haben dir die Leute im anderen Thread auch schon gesagt. Entscheide dich für eine Plattform und wenn du unbedingt beide brauchst, dann überleg dir da was sinnvolleres, wie Interprozesskommunikation, aber eben nicht dieses Rumgemantsche.
Was mich ja mal interessieren würde ist, warum du überhaupt sowas versuchst? Warum willst du bestimmte Parts in .NET schreiben und dann in Java einbinden? Was versprichst du dir davon bzw. warum machst du es nicht gleich alles in Java? Oder wenn du die Parts schon in .NET schreibst, warum schreibst du dann nicht gleich alles in .NET?
Ich rate mal:
Weil .NET einen besseren/direkteren Zugriff auf OS-Features erlaubt als Java?
Dieses „entweder Java oder was anderes“ geht nun mal nicht immer, bzw. macht nicht immer Sinn.
Wir haben hier eine recht große Java Anwendung, welche viele Teile in C/C++ macht, weil es mit Java einfach nicht möglich ist, oder mit Java doch zu langsam wäre (geht viel um Bildbearbeitung, auch mit passender Hardwareanbindung).
Alles in C/C++ machen wäre eine Möglichkeit. Aber der Entwicklungsaufwand wäre da noch größer. Mit 90% Java und 10% C/C++ kommt die Entwicklung schnell voran und das Ergebnis entspricht den Vorstellungen. Und da die C/C++ Seite sowohl für Linux als auch Windows und Mac gebaut werden kann, sind alle 3 Major-Plattformen abgedeckt. Wieso also nicht mischen?
Klar, es macht nicht immer und überall Sinn. Aber es generell zu „verteufeln“ ist auch nicht okay.
[QUOTE=tuxedo]Ich rate mal:
Weil .NET einen besseren/direkteren Zugriff auf OS-Features erlaubt als Java?
Dieses „entweder Java oder was anderes“ geht nun mal nicht immer, bzw. macht nicht immer Sinn.
Wir haben hier eine recht große Java Anwendung, welche viele Teile in C/C++ macht, weil es mit Java einfach nicht möglich ist, oder mit Java doch zu langsam wäre (geht viel um Bildbearbeitung, auch mit passender Hardwareanbindung).
Alles in C/C++ machen wäre eine Möglichkeit. Aber der Entwicklungsaufwand wäre da noch größer. Mit 90% Java und 10% C/C++ kommt die Entwicklung schnell voran und das Ergebnis entspricht den Vorstellungen. Und da die C/C++ Seite sowohl für Linux als auch Windows und Mac gebaut werden kann, sind alle 3 Major-Plattformen abgedeckt. Wieso also nicht mischen?
Klar, es macht nicht immer und überall Sinn. Aber es generell zu „verteufeln“ ist auch nicht okay.[/QUOTE]
Dagegen sage ich auch nichts 
Aber reines C++ ist eine andere Geschichte als .NET, denn diese Libs können von Java verwendet werden. Es gibt auch das eine oder andere Programm, das für die Oberfläche Java verwendet und die Kernlogik in C oder C++ oder sonst wie umgesetzt hat. Aber dabei werden meist native Libs verwendet und diese kann Java auch nutzen. Was Java nicht nutzen kann, sind Kompilate von .NET, denn auch wenn diese die Endung .dll haben, es sind keine nativen Libs, sondern .NET-Libs und können auch nur von .NET-Anwendungen verwendet werden. Darum war mein Einwand das entweder mit der einen Technologie oder mit der anderen vollständig umzusetzen. Oder man verwendet doch beide Technologien, aber dann eher auf IPC-Basis. Ich weiß, dass es wohl irgendwelche Bridges geben soll, diese aber eben nicht sonderlich zuverlässig sein sollen (keine Ahnung, nicht ausprobiert). Es eine sehr gute soll es wohl geben, aber die kostet einiges und fällt damit wohl in den meisten Fällen ebenfalls aus dem Rahmen. Aber selbst wenn sie halbwegs laufen, da bleibt dennoch ein komisches Unbehagen, dass da was falsch läuft. Die Entwicklung in mehreren Sprachen ist an sich nichts neues, aber es gibt in der Regel einen guten Grund dafür (z.B. C/C++ wegen Performance-Boosts bei gewissen Modulen). Aber Java und .NET … ??
Jedenfalls verteufel ich das nicht generell, aber sowas sollte man sich gut überlegen und bei Bedarf auch nutzen, aber dann sinnvoll und nicht irgendwie oder „weil ich das eine in der einen Sprache besser kann und das andere in der anderen“. Das kommt immer wie gewollt und nicht gekonnt rüber. In der Firma benutzen wir ausschließlich JVM-Sprachen, wobei geschätzte 95% in Java implementiert ist, und beim Nebenjob kommt ausschließlich .NET zum Einsatz. Den Bedarf haben ich in beiden Fällen noch nicht gehabt und auch nicht gesehen, die jeweils andere Seite einbeziehen zu müssen. Man muss sich einfach zu helfen wissen, Möglichkeiten gibt es in beiden Welten.
Aber das ist nur meine bescheidene Meinung. Ich habe jedenfalls manchmal so Threads gesehen (in anderen Foren), wo jemand unbedingt mit dem Kopf durch die Wand wollte, komme was da wolle, nur damit derjenige etwas auf eine bestimmte Art und Weise umsetzen könnte (meist war es deswegen, weil man das andere nicht konnte) und auf keinerlei Empfehlungen oder sonst was eingegangen ist. Im Endeffekt wurde daraus eine dreckige Lösung, die „irgendwie“ lief (falls es überhaupt zu einer Lösung kam), aber eher eine Zeitbombe war, und zudem viel mehr Zeit mit dem Durchbruch durch die Wand verschwendet wurde als sich mit dem Unbekannten auseinander zu setzen und es gleich richtig zu machen. Natürlich kann man nicht erwarten, dass jemand alles kennt (wer weiß schon alles), darum fragt man ja auch. Aber selbst wenn es etwas geben sollte, das auch sogar zuverlässig funktioniert (in diesem Fall kenne ich jedenfalls nichts), und man unbedingt zwei Technologien verwenden muss, die mit eigenen Mitteln nicht kompatibel sind, dann ist IPC meist eine gute Möglichkeit beides zusammen zu bringen. Muss ja kein komplexes Protokoll oder WebService sein, im einfachsten Fall werden nur Strings hin und her geschickt, das kann schon reichen. Aber dafür ist es dann gezielt und sauber umgesetzt.
Man kann ja nicht alles immer neu programmieren, deshalb ist das unter Umständen schon sinnvoll.
Wenn es die Architektur hergibt, könnte man den IIS bemühen, mit dem Visualstudio einfach Endpoints für Webservices generieren und diese dann von Java aus nutzen. Erfordert zwar einen Server, erlaubt dafür die Nutzung von .NET Funktionen mit relativ geringem Aufwand.
Und da sind wir dann bei einer Form von IPC