jcom <-> com4j

[UPollaehne]

Hi,

ich probiere hier gerade mein Plugin auf COM Benutzung umzustellen und habe dafür die com4j eingesetzt, da sie die Fähigkeiten von Java 5 voll ausnutzt und ein early binding (VTable) anstatt late binding (Dispatch) verwendet.

Jetzt entdecke ich gerade, dass ja im TV-Browser schon jcom eingesetzt wird und zwar ausschliesslich im OutlookExporter des Kalender Plugins.

Wäre es möglich jcom gegen com4j auszutauschen?

[bodo]

Nicht mehr für diese Version. Und auch nur, wenn du das machst . Wir haben den Quelltext gespendet bekommen. Ich schätze keiner von uns hat da Plan von .

Btw: vielleicht ist das hier viel eleganter:
https://jna.dev.java.net/

Einfach ein Interface deklarieren und eine DLL benutzen können ist eine sehr sehr mächtige Geschichte, oder?

[UPollaehne]

Nicht mehr für diese Version.

Und das heisst genau was? Ist damit 2.5.1 gemeint? Damit habe ich eigentlich kein Problem, da ich mit den Umstellungen noch einiges zu tun habe.

Und auch nur, wenn du das machst . Wir haben den Quelltext gespendet bekommen. Ich schätze keiner von uns hat da Plan von .

Ich habe kein Problem damit die Klasse umzubauen, wenn ich dafür die Bibliothek bekomme. Mein Problem dabei ist, dass ich hier zuhause kein Outlook zum Testen habe (Hint Hint! ).

Btw: vielleicht ist das hier viel eleganter:
https://jna.dev.java.net/

Ungefähr so elegant wie das hier: https://nlink.dev.java.net/

Einfach ein Interface deklarieren und eine DLL benutzen können ist eine sehr sehr mächtige Geschichte, oder?

Ja, wenn man denn eine DLL hat, die man ansprechen kann.

Um es mal aus Apple Sicht zu beschreiben:
Outlook bietet das Microsoftäquivalent einer AppleScript Schnittstelle. So etwas spricht man natürlich sinnvollst über die passende Schnittstelle an.
Das ganze nennt sich dann COM (Component Object Model) und kann in einer DLL sein, kann aber auch genausogut in der Anwendung selbst stecken. Beide kann man aber über die oben aufgeführten Bibliotheken nicht wirklich sinnvoll ansprechen.

Bei COM gibt es dann noch den Unterschied zwischen early und late binding.
In Java ist das Vergleichbar mit dem direkten import der Klasse (early binding) im Gegensatz zu Reflection (late binding). Welche der beiden Methoden in Java bequemer und effizienter ist, muss ich ja nicht erwähnen. Bei COM sieht es da genauso aus.

[UPollaehne]

Um die Sache mal wieder aufzuwärmen (und weil ich hier einen DataService gebastelt habe, der die com4j braucht).

Stand der Dinge ist:
Ihr könnt wegen des Outlook Exports nicht auf jcom verzichten und könnt nicht auf com4j umstellen (da Ihr vermutlich auch kein Outlook habt).
Ich kann das Outlook Export Teil auch nicht ändern, da ich kein Outlook habe und darum nicht testen kann.

Wäre es Euch denn möglich die com4j.jar und com4j.dll mit in die Auslieferung zu übernehmen? Denn im Gegensatz zu jcom wird com4j noch aktiv gepflegt.

[bodo]

Also einfach für ein Plugin weitere Jars hinzufügen werden wir nicht machen. Dann kommt schnell ein weiterer Plugin-Entwickler und noch einer und noch einer . Wir hätten dann quasi einen "Dammbruch" begangen und alle würden sich darauf beziehen.

Geschickter wäre es, wenn jemand das Outlook-Krams auf die andere Bibliothek migriert und aktiv weiterpflegt. Momentan haben wir ja nichtmal jemanden, der diesen Part weiterentwickeln kann .