VisualVM ist eine Open-Source Software zum Profilen von Java-Applikationen und Verfolgen von Referenzen. Screenshots sagen mehr als 1000 Worte.

 

 

Because of a contest in a German Java forum I tried to formulate the shortest Java Quine:

enum _{_;{String _="enum _{_;{String _=%c%s%1$c;System.out.printf(_,34,_);}}";System.out.printf(_,34,_);}}

To compile and run under Windows (with Unix you need to redirect Exceptions to /dev/null and use diff):

>javac _.java 
>java _ 2> NUL > Quine.out 
> fc Quine.out _.java 
Vergleichen der Dateien Quine.out und _.JAVA 
FC: Keine Unterschiede gefunden 
>jrunscript -e "print(new java.io.File('_.java').length())"
106

I haven’t found a shorter solution on the net, so I suppose this is the shortest for now.

Für die Anbildung an den JMX-Server dient nicht nur die JConsole, sondern verschiedene andere Wege sind denkbar, etwa über HTTP oder über einen eigenen Client, der über RMI kommuniziert.

JMXConnectorServer für den Server

Zur Veröffentlichung der MBeans über RMI ist der JMXConnectorServer verantwortlich. Damit die MBeans an die RMI-Registry gebunden werden, wird eine besondere URL verwendet, die den Service genau beschreibt. Die JMXServiceURL hat den allgemeinen Aufbau:

service:jmx:<protocol>://[[[<host>]:<port>]/<path>]

Vor dem Start des Programms muss die RMI-Registry für Anmeldungen bereit sein; da unser Programm auf dem gleichen Rechner arbeitet, starten wir den RMI-Namensdienst selbst.

LocateRegistry.createRegistry( 1099 );
MBeanServer server = ManagementFactory.getPlatformMBeanServer();
String url = „service:jmx:rmi:///jndi/rmi://localhost/maze“
JMXConnectorServer connectorServer = JMXConnectorServerFactory.newJMXConnectorServer(
new JMXServiceURL( url ), null, server );
connectorServer.start();

ObjectName name = new ObjectName( „com.tutego.insel.jmx:type=Maze“ );
MazeMBean maze = new Maze();
server.registerMBean( maze, name );

JOptionPane.showMessageDialog( null, „Ende“ );
System.exit( 0 );

JConsole mit Remote-Connection

Mit der JConsole könnten wir nun Verbindung aufnehmen, in dem unter Remote Connection die URL service:jmx:rmi:///jndi/rmi://localhost/maze Einsatz findet.

JMXConnector für den Client

Auf der Clientseite gibt es mit JMXConnector den Gegenspieler zum JMXConnectorServer. Das Objekt liefert uns mit getMBeanServerConnection() ein MBeanServerConnection-Objekt, was sozusagen die Repräsentation des MBean-Servers MBeanServer auf der anderen Seite entspricht (genauso genommen gilt für die Schnittstellen: MBeanServer extends MBeanServerConnection). Über getAttribute() lassen sich dann zum Beispiel Properties erfragen.

JMXServiceURL u = new JMXServiceURL( „service:jmx:rmi:///jndi/rmi://localhost/maze“ );
JMXConnector c = JMXConnectorFactory.connect( u );
MBeanServerConnection mbsc = c.getMBeanServerConnection();
ObjectName name = new ObjectName( „com.tutego.insel.jmx:type=Maze“ );
System.out.println( mbsc.getAttribute( name, „MaxNumberOfPlayers“ ) );

Schnittstelle und Klasse für die MBean

package com.tutego.insel.jmx;

public interface MazeMBean
{
void setMaxNumberOfPlayers( int numberOfPlayers );
int getMaxNumberOfPlayers();
void dragonAlarm();
}

package com.tutego.insel.jmx;

public class Maze implements MazeMBean
{
private int numberOfPersons;

public void setMaxNumberOfPlayers( int numberOfPersons )
{
this.numberOfPersons = numberOfPersons;
}

public int getMaxNumberOfPlayers()
{
return numberOfPersons;
}

public void dragonAlarm()
{
System.out.println( „Heul. Huhuhuhu.“ );
}
}

Hier möchte ich mich bei Ihnen, Herrn Dr. Ralf Kunze, und Team der Universität Osnabrück herzlich bedanken. Es freut mich sehr, dass Sie für ihre Vorlesungsunterlagen http://www-lehre.inf.uos.de/~binf/2007/index.html „Objekt-orientierte Programmierung in Java“ im Sommersemester 2007 so viel Abschnitte der Insel gebrauchen konnten. Immer wieder beglückt es mich, wenn Referenten und Dozenten Abschnitte 1:1 übernehmen und damit die Qualität meines Buches „Java ist auch eine Insel“ auch für den wissenschaftlichen Alltag bestätigen. (Ich wusste auch nicht, dass Rechtschreibfehler im Buch ebenfalls zum Insel-Kult gehören, und sie deshalb auch immer mitkopiert werden müssen.) Dass Sie dabei die Insel erst an dritter Stelle Ihrer Literaturangaben platzieren, ist selbstverständlich zu verzeihen. Besonders gefallen hat mir auf Ihrer Uni-Seite die Aussage „Zum legalen online Lesen, herunterladen oder auch kaufen“. Das finde ich gut, denn „illegales Online-Lesen“ wäre ja quatsch. Natürlich habe weder ich noch mein Verlag Galileo-Computing etwas dagegen einzuwenden, wenn ohne Nachfrage die geglücktesten Abschnitte kopiert und ohne Kennung der Quellen übernommen werden – Seite für Seite als Zitat zu kennzeichnen ist natürlich lästig. Das ist Arbeiten im Sinne von Stanisław Jerzy Lec: „Von der Mehrzahl der Werke bleiben nur die Zitate übrig. Ist es dann nicht besser, von Anfang an nur die Zitate aufzuschreiben?“

Ich war so frei, einige Ihrer Folien auf meinen Blog aufzunehmen. Ich hoffe, Sie sehen von Klagen wegen Urheberrechtsverletzungen ab; immerhin kopiere ich Ihre Texte hier ohne Nachfrage. (Alles Aufzulisten wäre zu viel Arbeit.
Das sind nur einige Beispiele mit direkten Kopien ganzer Absätze
für je eine Folie.)

Insel	Kopie
throws bei überschriebenen Methoden Überschriebene Methoden in einer Unterklasse dürfen nicht mehr Ausnahmen auslösen wie schon beim throws-Teil der Oberklasse aufgeführt sind. Da das gegen das das Substitutionsprinzip verstoßen würde, kann eine Methode der Unterklasse – nur dieselben Ausnahmen wie die Oberkasse auslösen – Ausnahmen spezialisieren oder – weglassen.	throws bei überschriebenen Methoden Überschriebene Methoden in einer Unterklasse dürfen nicht mehr Ausnahmen in der throws-Klausel deklarieren als schon bei der throws- Klausel der Oberklasse aufgeführt sind Das würde gegen das Substitutionsprinzip verstoßen. Eine Methode der Unterklasse kann: –dieselben Ausnahmen wie die Oberkasse auslösen –Ausnahmen spezialisieren –weglassen
Abschlussbehandlung mit finally Nach einem (oder mehreren) catch kann optional ein finally-Block folgen. Die Laufzeitumgebung führt die Anweisungen im finally-Block immer aus, egal, ob ein Fehler auftrat, oder die Anweisungen im try-catch-Block optimal durchliefen. Das heißt, der Block wird auf jeden Fall ausgeführt, auch wenn im try-catch-Block ein return, break oder continue steht oder eine Anweisung eine neue Ausnahme auslöst. Der Programmcode im finally-Block bekommt auch gar nicht mit, ob vorher eine Ausnahme auftrat oder alles glatt lief. Sinnvoll sind Anweisungen im finally-Block immer dann, wenn Operationen immer ausgeführt werden sollen. Eine typische Anwendung ist die Freigabe von Ressourcen oder das Schließen von Dateien.	Abschlussbehandlung mit finally Nach einem (oder mehreren) catchkann optional ein finally-Blockfolgen Die Laufzeitumgebung führt die Anweisungen im finally-Blockimmer aus, egal, ob ein Fehler auftrat, oder die Anweisungen im try/catch-Block optimal durchliefen. Das heißt, der Block wird auf jeden Fall ausgeführt, auch wenn im try/catch-Blockein return, break oder continuesteht oder eine Anweisung eine neue Ausnahme auslöst Der Programmcode im finally-Blockbekommt nicht mit, ob vorher eine Ausnahme auftrat Sinnvoll sind Anweisungen im finally-Blockimmer dann, wenn Operationen immer ausgeführt werden sollen Eine typische Anwendung ist die Freigabe von Ressourcen oder das Schließen von Dateien
Bei der Konvertierung eines größeren Ganzzahltyps in einen kleineren werden einfach die oberen Bits abgeschnitten. Eine Anpassung des Vorzeichens findet nicht statt. Die Darstellung in Bit zeigt das sehr anschaulich: int ii = 123456789; // 00000111010110111100110100010101 int ij = –123456; // 11111111111111100001110111000000 short si = (short) ii; // 1100110100010101 short sj = (short) ij; // 0001110111000000 System.out.println( si ); // –13035 System.out.println( sj ); // 7616	Bei der Konvertierung eines größeren Ganzzahltyps in einen kleineren werden einfach die oberen Bits abgeschnitten Eine Anpassung des Vorzeichens findet nicht statt Die Darstellung in Bit zeigt das sehr anschaulich: int m = 123456789; // 00000111010110111100110100010101 shorts m = (short) m;// 1100110100010101 System.out.println(sm); // -13035 int n = -123456;// 11111111111111100001110111000000 short sn= (short) n;// 0001110111000000 System.out.println(sn); // 7616
Eine Datei oder ein Verzeichnis besitzt zahlreiche Eigenschaften, die sich mit Anfragemethoden auslesen lassen. In einigen wenigen Fällen lassen sich die Attribute auch ändern. boolean canExecute(), canRead(), canWrite(). true, wenn die Ausführungsrechte/Leserechte/Schreibrechte gesetzt sind. long length() Gibt die Länge der Datei in Byte zurück oder 0L, wenn die Datei nicht existiert oder es sich um ein Verzeichnis handelt. long lastModified() Liefert den Zeitpunkt, zu dem die Datei zum letzten Mal geändert wurde. Die Zeit wird in Millisekunden ab dem 1. Januar 1970, 00:00:00 UTC, gemessen. Die Methode liefert 0, wenn die Datei nicht existiert oder ein Ein-/Ausgabefehler auftritt. boolean setLastModified( long time ) Setzt die Zeit (wann die Datei zuletzt geändert wurde). Die Zeit ist wiederum in Millisekunden seit dem 1. Januar 1970 angegeben. Ist das Argument negativ, dann wird eine IllegalArgumentException ausgelöst.	Eine Datei oder ein Verzeichnis besitzt zahlreiche Eigenschaften, die sich mit Anfragemethoden auslesen und teilweise auch ändern lassen: boolean canExecute() (Java6), canRead(), canWrite()liefern true, wenn die Ausführungsrechte/Leserechte/Schreibrechte gesetzt sind long length() Gibt die Länge der Datei in Byte zurück oder 0L, wenn die Datei nicht existiert oder es sich um ein Verzeichnis handelt long lastModified() Liefert den Zeitpunkt, zu dem die Datei zum letzten Mal geändert wurde. Die Zeit wird in Millisekunden ab dem 1. Januar 1970, 00:00:00 UTC, gemessen. Die Methode liefert 0, wenn die Datei nicht existiert oder ein Ein-/Ausgabefehler auftritt boolean setLastModified(longtime)Setzt die Zeit (wann die Datei zuletzt geändert wurde). Die Zeit ist wiederum in Millisekunden seit dem 1. Januar 1970 angegeben. Ist das Argument negativ, dann wird eine IllegalArgumentException ausgelöst
Die Schnittstellen Closeable und Flushable Closeable wird von allen lesenden und schreibenden Datenstrom-Klassen implementiert, die geschlossen werden können. Das sind alle Reader/Writer- und InputStream/OutputStream-Klassen. void close() throws IOException. Schließt den Datenstrom. Einen geschlossenen Strom noch einmal zu schließen hat keine Konsequenz. Flushable findet sich nur bei schreibenden Klassen und ist insbesondere bei denen wichtig, die Daten puffern. void flush() throws IOException Schreibt gepufferte Daten in den Strom.	Closeableund Flushable Closeable wird von allen lesenden und schreibenden Datenstrom-Klassen implementiert, die geschlossen werden können Das sind alle Reader/Writer-und InputStream/OutputStream-Klassen void close() throws IOException schließt den Datenstrom. Einen geschlossenen Strom noch einmal zu schließen hat keine Konsequenz Flushable findet wird nur bei schreibenden Klassen implementiert. Flushable ist insbesondere bei Klassen wichtig, die Daten puffern void flush() throws IOException schreibt gepufferte Daten in den Strom
Ein SequenceInputStream-Filter hängt mehrere Eingabeströme zu einem großen Eingabestrom zusammen. Nützlich ist dies, wenn wir aus Strömen lesen wollen und es uns egal ist, was für ein Strom es ist, wo er startet und wo er aufhört. Der SequenceInputStream lässt sich erzeugen, indem im Konstruktor zwei InputStream-Objekte mitgegeben werden. Soll aus zwei Dateien ein zusammengesetzter Datenstrom gebildet werden, benutzen wir folgende Programmzeilen: InputStream s1 = new FileInputStream( „teil1.txt“ ); InputStream s2 = new FileInputStream( „teil2.txt“ ); InputStream s = new SequenceInputStream( s1, s2 ); Ein Aufruf irgendeiner read()-Methode liest nun erst Daten aus s1. Liefert s1 keine Daten mehr, kommen die Daten aus s2. Liegen keine Daten mehr an s2, aber wieder an s1, ist es zu spät.	Ein SequenceInputStream-Filterhängt mehrere Eingabeströme zu einem großen Eingabestrom zusammen Nützlich ist dies, wenn wir aus Strömen lesen wollen und es uns egal ist, was für ein Strom es ist, wo er startet und wo er aufhört. Der SequenceInputStreamlässt sich erzeugen, indem im Konstruktor zwei InputStream-Objekte mitgegeben werden Soll aus zwei Dateien ein zusammengesetzter Datenstrom gebildet werden, benutzen wir folgende Programmzeilen: InputStream s1 = newFileInputStream(„datei1.txt“); InputStream s2 = newFileInputStream(„datei2.txt“); InputStream s = newSequenceInputStream(s1, s2); Ein Aufruf irgendeiner read()-Methodeliest nun erst Daten aus s1 Liefert s1keine Daten mehr, kommen die Daten aus s2 Kommen keine Daten mehr von s2, aber wieder von s1 können diese nicht mehr verarbeitet werden
Swing bietet viel mehr Komponenten als AWT. Das AWT bietet zum Beispiel keine Tabellen oder Bäume. Schaltflächen und Labels nehmen Symbole auf, die sie beliebig um Text angeordnet darstellen. Swing-Komponenten können transparent und beliebig geformt sein; eine Schaltfläche kann wie unter Mac OS X abgerundet sein. Jede Swing-Komponente kann einen Rahmen bekommen. AWT-Komponenten arbeiten nicht nach dem Model/View-Prinzip, nach dem die Daten getrennt von den Komponenten gehalten werden.	Swing bietet viel mehr Komponenten als AWT, so bietet AWT zum Beispiel keine Tabellen oder Bäume Schaltflächen und Labels können Symbole aufnehmen, die sie beliebig um Text angeordnet darstellen Swing-Komponenten können transparent und beliebig geformt sein. Eine Schaltfläche kann wie unter Mac OS X abgerundet sein. Jede Swing-Komponente kann einen Rahmen bekommen AWT-Komponenten arbeiten nicht nach dem Model/View-Prinzip, nach dem die Daten getrennt von den Komponenten gehalten werden
Jeder Swing-Komponente kann mit der Methode setBorder() ein Rahmen zugewiesen werden. Ein Rahmen ist eine Klasse, die die Schnittstelle Border implementiert. Swing stellt einige Standardrahmen zur Verfügung: AbstractBorder. Abstrakte Klasse, die die Schnittstelle minimal implementiert BevelBorder. (Eingelassener) 3D-Rahmen CompoundBorder. Rahmen, der andere Rahmen aufnehmen kann EmptyBorder. Rahmen, dem freier Platz zugewiesen werden kann EtchedBorder. Noch deutlicher markierter Rahmen LineBorder. Rahmen in einer einfachen Farbe in gewünschter Dicke MatteBorder. Rahmen, der aus Kacheln von Icons besteht SoftBevelBorder. 3D-Rahmen mit besonderen Ecken TitledBorder. Rahmen mit einem String in einer gewünschten Ecke	Jeder Swing-Komponente kann mit der Methode setBorder()ein Rahmen zugewiesen werden. Ein Rahmen ist eine Klasse, die das Interface Borderimplementiert. Swing stellt einige Standardrahmen zur Verfügung: AbstractBorder Abstrakte Klasse, die die Schnittstelle minimal implementiert. BevelBorder (Eingelassener) 3D-Rahmen CompoundBorder Rahmen, der andere Rahmen aufnehmen kann EmptyBorder Rahmen, dem freier Platz zugewiesen werden kann EtchedBorder Noch deutlicher markierter Rahmen LineBorder Rahmen in einer einfachen Farbe in gewünschter Dicke MatteBorder Rahmen, der aus Kacheln von Icons besteht SoftBevelBorder3D-Rahmen mit besonderen Ecken TitledBorder Rahmen mit einem String in einer gewünschten Ecke

Auch für zwei Beispiele durfte die Insel Vorlage sein. (Das ist rechtlich sicher, da die Insel im Vorwort erlaubt, dass alle Beispiele frei verwendet werden können.) Das eine ist JCheckBoxDemo, welches als CheckBoxDemo mit anderen Grafiken und Beschriftungen — aus der Auswahl "Ein Colt für alle Fälle" und "MacGyver" wird "Informatik A und Informatik B" — einer weiteren Zeile im Listener ein neues Leben führt.

Oder

package com.javatutor.insel.thread.group;

public class ShowThreadsInMain
{
 public static void main( String[] args )
 {
   ThreadGroup top = Thread.currentThread().getThreadGroup();

   while ( top.getParent() != null )
     top = top.getParent();

   showGroupInfo( top );
 }

 public static void showGroupInfo( ThreadGroup group )
 {
   Thread[] threads = new Thread[ group.activeCount() ];

   group.enumerate( threads, false );
   System.out.println( group );

   for ( Thread t : threads )
     if ( t != null )
       System.out.printf( "%s -> %s is %sDaemon%n",
                          group.getName(), t, t.isDaemon() ? "" : "no " );

   ThreadGroup[] activeGroup = new ThreadGroup[ group.activeGroupCount() ];
   group.enumerate( activeGroup, false );
   for ( ThreadGroup g : activeGroup )
     showGroupInfo( g );
 }
}

Und das Beispiel vom Doktor:
package threadgroup1;

/**
* Informationen ueber die laufenden Threads liefern.
*
* @author Ralf Kunze (rkunze@uos.de), Institut fuer Informatik, Universitaet
*         Osnabrueck
* @date 06.05.2007
*/
public class ThreadInfo {
 public static void main(String[] args) {
  ThreadGroup top = Thread.currentThread().getThreadGroup();

  while (top.getParent() != null)
   top = top.getParent();

  showGroupInfo("    ",top);
 }

 public static void showGroupInfo(String indent, ThreadGroup group) {
  Thread[] threads = new Thread[group.activeCount()];

  group.enumerate(threads, false);
  System.out.println(indent + group);

  for (Thread t : threads)
   if (t != null)
    System.out.printf("%s%s -> %s is %sDaemon%n",
                                       indent ,group.getName(), t, t.isDaemon() ? "" : "no ");

  ThreadGroup[] activeGroup = new ThreadGroup[group.activeGroupCount()];
  group.enumerate(activeGroup, false);
  for (ThreadGroup g : activeGroup)
   showGroupInfo(indent+indent, g);
 }
}
Das @author-Tag gefällt mir besonders. Die indent-Erweiterung ist natürlich anzuerkennen. Das habe ich gleich übernommen. Daher gefällt mir der wissenschaftliche Austausch so sehr. Leider gibt es das JavaDoc-Tag @date nicht (zumindest bis Java 6), aber man kann ja schon für die Zukunft programmieren.
Insgesamt finden sich sehr viele Abschnitte aus dem Kapitel IO, Thread, Reflection und Netzwerk in den Uni-Unterlagen, aber in der Reihenfolge, Satzbau und Formulieren sind auch in anderen Kapiteln deutliche Ähnlichkeiten zu erkennen. Danke für die Hommage.
			

Inselupdate: Die Laufzeitumgebung von Sun liefert noch über 3000 Klassendateien in den Paketen sun und sunw aus. Diese internen Klassen sind nicht offiziell dokumentiert[1], aber zum Teil sehr leistungsfähig und erlauben selbst direkten Speicherzugriff oder können Objekte ohne Standard-Konstruktor erzeugen:

com/tutego/insel/sun/UnsafeInstance.java, Ausschnitt

Field field = sun.misc.Unsafe.class.getDeclaredField( "theUnsafe" );
field.setAccessible( true );
sun.misc.Unsafe unsafe = (sun.misc.Unsafe) field.get( null );
File f = (File) unsafe.allocateInstance( File.class );
System.out.println( f.getPath() ); // null

File hat keinen Standard-Konstruktor, noch nicht einmal einen privaten. Diese Art der Objekterzeugung kann bei der Deserialisierung (siehe dazu Kapitel 13) hilfreich sein.

---

[1] Das Buch “Java Secrets“ von Elliotte Rusty Harold geht den Klassen nach, ist aber schon älter.

Manche Ereignisbehandler sind für Schaltflächen so ähnlich, dass Entwickler nur einen Listener mit mehreren Schaltflächen verbinden möchten. Dann taucht nur das Problem auf, wie der Listener die Schaltflächen unterscheiden kann. Eine Idee wäre, die Beschriftung mit getText() auszulesen – das bringt allerdings das Problem mit sich, dass die Software stark landessprachlich ist, denn bei mehrsprachigen Anwendungen kann sich die Aufschrift ändern. Eine andere Lösung wäre mit getSource() zu arbeiten. Doch dann müsste im Listener die Komponenten für einen Vergleich verfügbar sein, was sie oft nicht ist.

Als Lösung bietet die AbstractButton-Klasse die Methode setActionCommand() an, mit der sich eine Kennung, der sogenannte Action-Command setzen lässt.

abstract class javax.swing.AbstractButton extends JComponent implements ItemSelectable, SwingConstants

• void setActionCommand( String command )
  Setzt einen neuen Kommandostring, wenn das Ereignis ausgeführt wird.

Der Listener kann diesen Action-Command mit getActionCommand() aus dem ActionEvent auslesen.

class java.awt.event.ActionEvent extends AWTEvent

• String getActionCommand()
  Liefert den String, der mit dieser Aktion verbunden ist.

Ohne explizites Setzen ist der Action-Command standardmäßig mit der Beschriftung der Schaltfläche initialisiert.

Wird Java unter MS Windows ausgeführt, so ergibt sich hin und wieder die Aufgabe, Eigenschaften der Windows-Umgebung zu kontrollieren. Viele Eigenschaften des Windows-Betriebssystems sind in der Registry versteckt, und Java bietet als plattformunabhängige Sprache keine Möglichkeit, diese Eigenschaften in der Registry auszulesen oder zu verändern. (Die Schnittstelle java.rmi.registry.Registry ist eine Zentrale für entfernte Aufrufe und hat mit der Windows-Registry nichts zu tun. Auch das Paket java.util.prefs mit der Klasse Preferences erlaubt nur Modifikationen an einem ausgewählten Teil der Windows-Registry.)

Um von Java auf alle Teile der Windows-Registry zuzugreifen, gibt es mehrere Möglichkeiten, unter anderem:

• Windows Registry API Native Interface (http://tutego.com/go/jnireg), die frei zu benutzen ist und keiner besonderen Lizenz unterliegt.
• http://www.cogentlogic.com/jndi/ einen JNDI Service Provider for Windows Registries für teure 299 kanadische Dollar.
• Preferences unter Windows realisiert: java.util.prefs.WindowsPreferences. Damit ist keine zusätzlich native Implementierung – und damit eine Windows DLL im Klassenpfad – nötig. Die Bibliothek https://sourceforge.net/projects/jregistrykey/ realisiert eine solche Lösung.
• reg zum Setzen und Abfragen von von Schlüsselwerten.

Beispiel   Zeigen den Dateinamen für den Desktop-Hintergrund an:

$ reg query „HKEY_CURRENT_USER\Control Panel\Desktop“ /v Wallpaper

! REG.EXE VERSION 3.0

HKEY_CURRENT_USER\Control Panel\Desktop

Wallpaper REG_SZ C:\Dokumente und Einstellungen\tutego\Anwendungsdaten\Hintergrund.bmp

Ein Persistence Context verwaltet Entities und kontrolliert ihren Lebenszyklus.

Man unterscheidet zwei Arten von Persistence Context:

–Transaction-scoped Persistence Context

–Extended Persistence Context

•Mit EntityManagerFactory.createEntityManager() bekommt man den Extended Persistence Context.

–createEntityManager() liefert den Application-Managed Entity Manager.

•Der Persistence Context beginnt, wenn der Application-Managed Entity Manager erzeugt wird und endet erst dann, wenn der Entity-Manager geschlossen wird.

•Werden Entities geladen, so bleiben sie so lange im Extended Persistence Context, bis der der Kontext geschlossen oder alle Entities ausdrücklich gelöscht werden.

–Entities bleiben also sehr lange „manged“ und nur dann „detached“, wenn der Entity-Manager geschlossen wird.

 

•Der Transaction Persistence Context ist der übliche Persistence Context eines „Container-Managed Entity Managers“, der also über den Container injiziert wird.

@PersistenceContext EntityManager em;

•Der EntityManager erzeugt pro Transaktionen einen neuen Persistence Context.

–Der Persistence Context endet bei einem Commit oder Rollback der Transaktion.

•Innerhalb der Transaktion werden die zum Beispiel über find() oder Query geladenen Entites zu managed Entities.

•Da nach der Transaktion der Persistence Context endet, werden die dort verwalteten Entities detached.

 

•Da der Transaction Persistence Context pro Transaktion aufgebaut wird, ist die Anzahl der verwalteten Objekte relativ klein.

•Der Extended Persistence Context ist oft deutlich länger und kann nach einer Zeit sehr viele Objekte aufnehmen.

–Damit kann das zu einem Speicherproblem werden.

 

•Um beim Extended Persistence Context kein Speicherproblem zu bekommen gibt es unterschiedliche Strategien:

–Von Zeit zu Zeit clear() vom EntityManager aufrufen. Das detached Objetkte.

–Auf das passende Lazy-Load achten.

–Weniger Objekte laden: Bei unachtsamem Design werden oft viel zu viele Objekte geladen.

•Besonders Gib-Mir-Alles-Ausdrücke wie „select o from Entity o“ sind gefährlich, da die Anzahl der Objekte groß sein kann, obwohl nur ein kleiner Teil der Objekte wirklich benötigt wird.

–Eine Paginierung kann hier sinnvoller sein um nur das zu laden, was zum Beispiel sichtbar ist.

 

•Einzelne Entities lassen sich nicht aus dem Entity-Manger entfernen (detachen).

–Bei Hibernate oder anderen Implementierungen funktioniert das, bei JPA standardmäßig nicht.

•Aber andersherum gibt es eine Lösung.

–Also alles freigeben, bis auf ausgewählte Objekte.

•Gibt es einen Verweis auf eine Entity-Objekt vom Persistence Context aus und von außen, und wird dann clear() den Persistence Context löschen, wird der Garbage-Collector das Objekt natürlich nicht freigeben.

–Das losgelöste Entity-Objekt kann später mit merge() wieder in den Persistence Context gesetzt werden.