Hallo Manfred,

erstmal Glückwunsch zur Ausschaltung des Störfeuers.

Ich habe mich noch nicht mit LS2J beschäftigt. Wenn ich mit Java in Lotus arbeite ist es bislang immer pur-Java (etwa ein Agent, 1 Applet, 1 GUI, die von aussen zugreift).
Du hast da einen interessanten Punkt aufgebracht. Und das ist leider wieder so ein Ding, wo offenbar etwas nicht so sauber von Lotus implementiert bzw. dokumentiert wird.

Durch
wird ein Objekt erzeugt, dass den von der JavaVM verwalteten Heap Speicher belegt. Genau gesprochen ist es ein anonymes, lokales Objekt, da es von keiner Referenzvariable gehalten wird und Methoden-scope hat (keine Instanzvariable in ersten Version).
In einem reinen Java Programm würde das keine Probleme machen. Nach dem return der Methode wäre das Objekt eligible for garbage collection und der entsprechende Speicher würde zu einem geeigneten Zeitpunkt vom Garbage Collector freigegeben. Hmm genau gesprochen kann aus dem aufrufenden code das Objekt gehalten werden. Aber das ist in der Regel kein Problem... Arbeite später an umfangreicheren Erklärung...

Offenbar hält aber LS2J aus für mich derzeit nicht nachvollziebaren Gründen eine Referenz auf ein Objekt, das von einer Methode zurückgegeben wird, die einen nicht-void, nicht-primitiv-Datentyp (int, fload, boolean, etc.) besitzt. Solange eine Referenz auf das Objekt gehalten wird, ist es nicht "eligible for garbage collection".  

Du hast den richtigen Weg gefunden. Du schreibst den String einfach in eine Instanz-Variable, die du pro Durchlauf überschreibst.

Beispiel:
1. Durchlauf:
after completion method void getRSSFeed():
Object-Instanz-Variable GetRssFeed.returnURLContent hält String-Objekt "foo".
2. Durchlauf:
after completion method void getRSSFeed():
Object-Instanz Variable GetRssFeGetRssFeed.returnURLContent verliert Referenz auf String-Objekt "foo" und hat neue Referenz auf neues String-Objekt "bar". Das String-Objekt "foo" ist eligible for Garbage Collection. "bar" wird referenziert.
usw.  


Da der von der Java Virtual Maschine verwaltete Heap Speicher nicht mehr volläuft, schlägt der Java Garbage Collector in der neuen Version offenbar irgendwann zu.  

Sierra/Bates Buch hat sicher ein Kapitel zu den Grundlagen von Java Garbage Collection  

Das hört sich alles komplizierter an als es ist.
Noch was: Bei Methoden mit void-Rückgabe benötigst du kein return. Das letzte return in der Methode kannst du entfernen.

Wie du weisst gibt es keine dummen Fragen, wenn du noch Fragen hast.

Ein anderer Weg wäre vielleicht mit einem Singleton zu arbeiten (später mehr).  

Gruß Axel

Hallo Axel,

danke für Deine Ausführungen - verstehe mal wieder nicht alles, aber das wird schon...

>>erstmal Glückwunsch zur Ausschaltung des Störfeuers.<<

Ja, da habe ich mich wirklich gefreut. Zumal auf meine Frage im 6er notes.net Forum nicht mal ansatzweise ein Lösung kam. Habe dort aber heute meinen Weg gepostet (meine Frage war am 14.01 wenn Du´s dort mal lesen möchtest).

Du schreibst:
>>LS2J behandelt das Objekt der Klasse GetRSSFeed offenbar als Singleton. Du erzeugst ja aus dem code immer neue Objekte der Klasse GetRSSFeed. Nur ist LS2J offenbar so schlau, dass es immer das selbe Objekt wiederverwendet. Sonst würde das mit dem Überschreiben der Instanzvariable returnURLContent so gar nicht funktionieren.<<

Nö, mache ich nicht. Es wird nur EIN Object erstellt und immer wieder referenziert. Das sieht in LS so aus:
Dim js As JavaSession
Set js = New JavaSession
   
Dim getRSSFeedClass As JavaClass
Dim getRSSFeedObject As JavaObject
   
Set getRSSFeedClass = js.GetClass("GetRSSFeed")
Set getRSSFeedObject = getRSSFeedClass.CreateObject ' 1x Object erstellen/instanzieren
...
' Properties wie URL, Proxy usw. setzen
...
Call getRSSFeedObject.getRSSFeed() ' Aufruf mit IMMER gleichem Object in einer Schleife
Set jProperty = getRSSFeedClass.GetProperty("returnURLContent")
html = jProperty.GetValue( getRSSFeedObject )

Da ist LS2J wohl doch nicht so schlau...?

Vielleicht noch was für den Java-Crack zum schmunzeln, ich selbst kann mir das auch nicht richtig erklären:
Ich hatte ja aus lauter Verzweiflung alles mögliche probiert und bin noch auf den folgenden Effekt gestossen, vielleicht hast Du dafür eine Erklärung?

Als ich statt:
return bufResult.toString()

das hier:
String URLContent = bufResult.toString();
return URLContent;

verwendet hatte, war die Laufzeit des Agenten schon mindestens doppelt so lange wie vorher. Für einen Moment dachte ich, das wäre schon die Lösung, hat aber den Tot nur etwas verzögert...

Gruss
Manfred

ist total nicht Objekt-orientiert.

das ist aber die derzeitige Lösung auch nicht  

Übliche Dinge wie Objects auf null setzen und System.runFinalization(); bzw. System.gc(); (war ein Tipp auf meine Frage im notes.net 6er Forum) haben etwas Linderung gebracht - richtig geholfen hat das alles aber nicht.

Das mit dem System.gc() soll den garbage collector davon überzeugen zu starten. Das ist aber kein zuverlässiges Mittel. Du kannst den garbage collector nicht wirklich aus Programmcode kontrollieren.

Deine Lösung war schon gut.
Ähnlich geht man beispielsweise oft vor, wenn man Informationen aus parallel laufenden Threads benötigt.

Gruß Axel

naja respekteinflössend ist vielleicht nicht das richtige Wort.
Es ist interessant.
Manchmal bin ich sprachlich einfach ein bischen unexakt.  
All diese ganzen Methodologie-Diskussionen.
3 Leute eine Meinung:
Scott Ambler, Lasse Koskela, Ilja Preuss auf Javaranch letzte Woche

auch ein guter Essay (leider nur in Spanisch) und eine total andere Meinung:
http://www.javahispano.org/download/tutoriales/MetodosAgiles.pdf

Daher war der Einsatz von Java eher Mittel zum Zweck und ich schon so froh, dass es jetzt überhaupt funktioniert.

Ist der Weg auch schlecht, ist es manchmal doch wichtig, was hinten heraus kommt... ;-)

also meine Aussage, das sei nicht objektorientiert, solltest du keinesfalls als Kritik auffassen! Sondern als Grund dafür, Axels Vorschlag mit einer statischen Methode mal zu probieren (falls deine unerwarteterweise noch mal Probleme bereitet)
Und der Weg ist keinesfalls schlecht, sondern gut (IMHO).

Hallo Thomas!

>>also meine Aussage, das sei nicht objektorientiert, solltest du keinesfalls als Kritik auffassen!<<

Thomas, wenn man von einem Thema noch keine richtige Ahnung hat, ist es etwas schwierig, eine Aussage als "Kritik" oder "Anregung" zu unterscheiden. Beides läuft aber letztlich auf das gleiche hinaus: Irgendwas scheint noch nicht so OK zu sein und könnte besser gemacht werden. Ich nehme Kritik (so gut das geht, innerer Schweinehund, kennt jeder) auch nicht persönlich, sondern versuche immer mal zu überlegen, ob da nicht doch was dran ist. Meistens ist das ja auch so...

>>Sondern als Grund dafür, Axels Vorschlag mit einer statischen Methode mal zu probieren (falls deine unerwarteterweise noch mal Probleme bereitet)<<

Hatte ich ja geschrieben. Ich versuche, alle Tipps von Axel zu verstehen und probiere das mit Eclipse auch aus. In diesem konkreten Fall verstehe ich den Ansatz mit der "Static-Geschichte" noch nicht richtig, was da denn der genaue Unterschied ist.

>>Und der Weg ist keinesfalls schlecht, sondern gut (IMHO).<<

Danke! :-)

Gruss
Manfred

Hatte ich ja geschrieben. Ich versuche, alle Tipps von Axel zu verstehen und probiere das mit Eclipse auch aus. In diesem konkreten Fall verstehe ich den Ansatz mit der "Static-Geschichte" noch nicht richtig, was da denn der genaue Unterschied ist.

Der Unterschied zwischen "normalen" Methoden

und statischen Methoden

ist, dass du, um die "normale" Methode aufrufen zukönnen eine Instanz der Klasse benötigst

statische Methoden kannst du ohne eine Instanz aufrufen

damit liegst du richtig