Hi,

ich hab mich hier mal umgesehen aber leider keine direkte Antwort auf meine Frage gefunden.

Ich entwickle DB's unter R5, nicht webfähig. Meist klassische DB's (also Dokumenten-Sammlung, Workflow, Firmen-/Personen..., etc.).

Dabei nutze ich ausschließlich LScript und Formelsprache.

Gibt es hier bereits Potential, auch Java einzusetzen? Also evtl. als bessere Alternative zu Formel/Script in manchen Situationen.

Ich versuche nämlich mich zu motivieren, auch Java zu lernen, und wenn ich das täglich umsetzen könnte, täte ich mir da leichter

Oder bringt das erst was
 - mit R6
 - wenn DB auch webfähig
??

cu,
TMC

Hi,

konkret unter Domino5 ist die Java Unterstützung nicht so toll.
Es wird lediglich die Java Version 1.1.8 unterstützt.
Dies ist eine Uralt-Version aus dem Jahre 1998.
Unter Domino6 gibt es eine wesentlich bessere Unterstützung (Java 1.3.1).

Bei Java ist die Version sehr wichtig.
Es ist eine recht neue Sprache, die sich zwischen 1998 und 2001 (Erscheinungsjahr von Java1.3.1) dramatisch weiter entwickelt hat.
Der Sprung Java1.3 -> Java 1.4 ist nicht mehr so dramatisch.
Problem von Java1.1.8 ist auch, daß ca. 95% der openSource packages nicht dafür ausgelegt sind. Und mein liebstes Hobby ist eben genau das Einbinden von openSource packages.

Viele Organisationen haben Java Server wie Tomcat oder Websphere parallel zu Domino laufen.
Betrachtest du die Zukunft, investiert IBM schätzungsweise 100x mehr Geld in Java Technologie als in Lotus Domino.
Microsoft hat in ihrem .NET Framework viele Konzepte von Java übernommen. C# kann als eine Art Java-Clone gesehen werden.

Überleg dir also selber, was du mit deiner Zeit machst.
In jedem Fall benötigt Java eine *systematische* Einarbeitung. Sonst bekommst du es nicht gebändigt. Es sind eine Reihe neuer Konzepte, v.a. im Kontext der Objektorientierung. Auch wird es ein immer weiteres Feld. Neue Ideen im Kontext von diversen Themen wie Systemintegration, Projektmanagements, Testmanagement, automatischer Codegenerierung etc. pp. werden in der Java-Welt einfach stärker rezepiert als bei Domino. Man wird quasi gezwungen, sich damit auseinander zu setzen.

(keine Aufschneiderei, sondern einfach mein momentaner Standpunkt)
Lotus gehört IBM und IBM setzt stark auf Java. Deshalb denken seit Jahren viele LotusShops über Java nach und machen teilweise auch Dinge damit. Die werden dann aber meist nicht von Quereinsteigern aus der Lotus-Welt, sondern von
a) Universitäts (nicht BA) Absolventen erstellt, die sich langjährig mit Java auseinandergesetzt haben und später zum Shop dazugestossen sind.
b) seit Jahren javaranch-, javablogs- und de.comp.lang.java Süchtigen wie mir mit einer Schrankwand an Javabüchern, die aus historischen Gründen irgendwie in einem Lotus-Job waren.  
erstellt.

Die Java und Lotus Welt sind extrem verschieden. Für Java muß man ganz neu über Projektmanagement, Programmierstil, etc. nachdenken. Es ist keine RAD-Plattform, sondern eine moderne Programmiersprache.  

Gruß Axel
Gruß Axel

Hm. Für meinen Geschmack wird hier ein bischen zu stark dazu geneigt, Java als Frontend- und Web-Technologie zu sehen.

Natürlich kann man die GUI-API Swing erfolgreich einsetzen. Auch Dinge wie JSP/Servlets/Struts, Tomcat und bald auch Portlets sind ziemlich effiziente Methoden, um Webanwendungen zu schreiben. Gerade auch weil es hier ziemlich weit fortgeschrittene Ansätze der automatischen code Generierung mit Entwicklungstools der nächsten Generation gibt.

Trotzdem: Die meisten Einsätze liegen IMHO eindeutig im Backend-Bereich.
Also so Dinge wie Systemintegration.
Bei mir ist es nun ein SOAP-Client für Domino, für den Java wohl die beste Lösung ist. Ich kann die bestehende Domino SOAP Connector nicht nehmen, da man da die xml4j.jar im Domino-Programmverzeichnis austauschen muß. Das ist dem Kunden zu kriminell.
 
Nächsten Monat gehts um Zugriff auf irgendwelche Novell Verzeichnisse wofür auch immer.    

Es läuft auch sicher nicht mehr alles auf Domino. Und ich mag es.

Qojote nutzt es zur Datenbankintegration und wirkt auch recht Java freundlich. In der RDBMS Programmierung ist Java mittlerweile eine wichtige Sprache. Stored Procedures können zumindest auf Oracle und DB2 mit Java geschrieben werden. Es gibt sehr gute Dinge für fortgeschrittnere Sachen wie Transaktionsunterstützung und Objekt-Relationales Mapping.

Für xml gibt es extrem sinnvolle Zusatztools/Pakete. Dagegen ist die xml Unterstützung in Domino sehr low level.  

Entwicklungstools wie Eclipse oder WSAD sind wesentlich komfortabler und erweiterbarer/flexibler als Domino Designer 6.

Gruß Axel

muss mir auch noch dringend endlich ein paar von diesen innovativen M$.Net Server auf meinen Testrechner installieren  

... das ganze hat natürlich auch eine dunkle Seite.
1. Es ist komplexer. Java-Code hat das Potential wesentlich übersichtlicher zu sein als Notes-Anwendungen. Ich hatte aber vorletzte Woche so ein eigentlich Trivial-Ääplet unter den Fingern (von einem Kunden), das chaotischer war, als alles was ich je in Domino gesehen habe ausser vielleicht einem gewissen Großprojekt mit dem Decknamen Achmed (jetzt echt nicht rassistisch gemeint). Wobei ich keine Geddys-Anwendungen kenne.
Das Applet wurde von jemanden geschrieben, der wirklich nicht wußte was er tat (wichtige Motivation für die MGWs   )
EINEN GEWISSEN BESTAND AN JAVA-THEORIE UND DANACH DESIGN PATTERNS SOLLTE MAN SICH SCHON ANEIGNEN...

2. v.a. openSource Projekte sind häufig schlecht dokumentiert und die Fehlermeldungen sind, nun ja. Ich habe Stunden über Nachrichten wie
"null Bean in context null could not be found"
gebrütet.
Ein Kollege hofft seit 3 Tagen auf eine email Rückantwort eines xindice Entwicklers (hoffentlich ist der nicht im Urlaub   )

3. Manche openSource Projekte sind einfach nicht gut programmiert. Ein gutes Beispiel ist apache.jarkarta.commons (das inzwischen zwecks Überarbeitung von apache zurückgezogen wurde). Und ich sagte noch: nimm nicht apache.jarkarta.commons.HTTPClient. Und prompt kamen dann 2 Stunden später total seltsame Fehlermeldungen von fehlenden Paketen, die eigentlich gar nicht im Produkt sein sollten.

4. Jeden Woche ist im Grunde Release Wechsel. Ständig benutzt man neue APIs. Man macht das natürlich auch, weil die immer besser werden. Aber manchmal wünsche ich mir ein 3 monatiges keine-neuen-frameworks-mehr Moratorium.

...ich hoffe es fühlt sich jetzt keiner persönlich beleidigt, als Anwender versuche ich hingegen JAVA wo es geht zu vermeiden.

NÖ   . Nehme irgendwie berufsmäßige Sachen nicht mehr emotional.

Ich habe das Gefühl das Firmen hergehen und neue Produkte in JAVA schreiben weil Sie der Meinung sind das diese dort schneller und dadurch billiger entwickelt werden kann,

YUP  

dabei geht aber öfters das Userinterface, Stabilität und Performance zugrunde...

O.k. ich habe auch Probleme mit gewissen Swing Anwendungen (z.B. DB2 7.2 Control-Center). Du hast ja bei deiner Beschwerdeliste gesagt, daß viele jetzt erst auf Java umsteigen. Sind also viele "faktische" 1.0er Releases in deiner Liste.

Das Performance-Argument gilt für viele Teilbereiche nicht mehr. Man hört oft, Java wäre eine "interpretierte Sprache". Das ist Unsinn. Moderne JIT Compiler, Hotspot Engines und ähnliches Zeuch wandelt den Java Runtime code (Bytecode) automatisch in nativen binär-Code um.

Meine eigenen Java Programme sind stabiler als alles andere was ich programmiere, weil der Entwicklungsprozeß strukturierter ist (das ist für mich das wichtigste pro-Java Argument).

TIPP: Hast du auf deinem Computer eine neue Java Runtime Umgebung installiert? Falls nicht versuche einfach mal auf http://www.java.com zu gehen, lad das Teil runter und installiere das mal. Vielleicht geht danach alles schneller...
Du kannst ja eine Sonnenbrille aufsetzen, damit die vielen Java Logos da ein bißchen gedämpfter sind. .  

Gruß Axel

Wir sollen i.d. Firma zum Jahreswechsel noch auf R6 umsteigen.
Evtl. werd ich mich dann mit Java beschäftigen.

Also wenn Ihr mich fragt, hat unser IT-Entscheider einen Knall.
Er hat doch tatsächlich noch im November 2003 (!!) komplett R5-Anwender-Schulungen für alle MA durchführen lassen. Ich hab ihn daraufhin mal dezent hingewiesen, wie es um R5 steht bei IBM, und dass er sich Support bald mal knicken kann (den IBM-Link dazu habe ich leider gerade nicht parat).

So wie es aussieht bleibe ich daher erst mal bei R5 und entwickle weiter fleißig unter R5 DB's, ein Wechsel ist mittlerweile nich nicht mal angedacht  

Jetzt sind wir aber keine Bank und hätten auch die Kohle, jederzeit zu wechseln.....

TMC