= JPApi =

Soll eine Bibiothek für eine "Java Persistenz API" werden, die flach und einfach ist,

'' Es kann losgehen, ich brauche nun eine Abstraktion, für mich privat (Homepage) und für ein paar Freunde. (JensKapitza)''

|Lizenz | [BSD], [LGPL]
|Projektname |[JProxyApi|JPApi]
|SVN | kommt noch
|CVS | kommt noch
|Entwickler |JensKapitza, wer noch?
|OpenJPA| hmm muss man sich mal näher angucken


||Fragen||Antworten
|Darf ich mit der Apache-Lizenz nicht freie Lib's benutzen?| Mit der GPL darf ich das nicht aber die Apache Lizenz wollte ich nicht auch noch auseinander nehmen





== Ziele, die man erreichen sollte ==

* kompatibel mit JDK >= 1.5
* wenige bis hin zu gar keinen Abhängigkeiten
* Möglichst wenig Konfiguration
* Annotationen an der vorhandenen API von Sun orientieren (EJB)
* unsere API an der API von Sun orientieren (?)
* kurze Ladezeit (im Vergleich z.B. zu Hibernate)
* ClassLoader, Interfaces und Klassen auch drüber hinaus aus lesbar machen (Konfigurations Klasse, * addClass() *)
* so weit wie möglich Nutzung vorhandener APIs (z.B. ~BeanInfo, ~PropertyDescriptor, Collections wie List oder Set, etc.)
* Laszy Listen, Sets, ...
* SQL als Abfrage sprache
* Object Cache, nur änderungen in Datenbank speichern
* Treiber unabhängig, eigene Driver.class als Proxy nutzen
* reconnect, oder STATEMENTS doppelt absetzen bei einem Ping timeout



== Features ==

* Mapping
* Caching (PREPARED Statement)
* Connection POOL
* Konfiguration durch Java Quellcode, Konventionen, Annotationen, Konfigurationsdateien, vorhandene Datenbank (in dieser Reihenfolge)
* Im Normalfall stehen alle Eigenschaften einer Bean in einer einzigen Datei (im Java-Quelltext)
* automatische Erstellung von GUIs (Web und Swing)
* Arbeit mit mehreren Datenbanken gleichzeitig (mit übergreifenden Fremdschlüsseln)
* Caching von Metainformationen



== Observer-Pattern ([Wikipedia|http://de.wikipedia.org/wiki/Beobachter_%28Entwurfsmuster%29]) ==

* Änderungen werden direkt in der Datenbank gemacht
* Die Observer-Funktionalität sollte automatisch in vorhandene Beans eingebaut werden (läuft übrigens bereits bei ThomasBayen mit BCEL)
** BCEL (http://bcel.apache.org) - Bytecode-Manipulation, wird von vielen bekannten Projekten genutzt
** SERP (http://serp.sf.net) - Alternative zu BCEL
** Jasmin (http://jasmin.sf.net) - Bytecode-Assembler
** AspectJ (http://www.eclipse.org/aspectj) - aspektorierentiertes Java
** Proxy-Objekte (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/reflect/Proxy.html) - Lösung aus dem JDK
** abgeleitete Klassen on the fly erzeugen. (Kann man in [Java6|http://java.sun.com/javase/6/docs/api/javax/tools/JavaCompiler.html] einfach einen Compiler aufrufen?) (siehe auch [Dynamic Java Compiler|http://www-systems.cs.st-andrews.ac.uk/wiki/Dynamic_Java_Compiler])
*** das sollte mit [Janino|http://www.janino.net/] gehen. -PeterHormanns
** abgelietete Klassen in einer Scriptsprache erzeugen (geht mit Rhino, das in Java6 enthalten ist oder auch mit Groovy).
* Es sollte möglich sein, den Observer auch selbst zu implementieren (ganz ohne BCEL) - das macht dessen Funktionsweise transparenter.



== Design-Entscheidungen ==

Hier möchte ich kontroverse Dinge sammeln bzw. Entscheidungen dokumentieren, die nicht sofort offensichtlich sind.

=== Wie direkt ist die Verbindung zur Datenbank? ===

Eine Möglichkeit ist es, unabhängige Beans (mit Fremdschlüsseln ggf. einen Beanbaum) zu laden. Diese werden dann frei bearbeitet und werden mit einer update-Methode wieder zurückgeschrieben. Das andere Extrem ist es, wenn jeder getter und setter der Bean direkt auf einen SQL-Befehl gemappt wird. Zwischenlösungen sind denkbar. Für verschiedene Probleme sind verschiedene Bindungsstärken sinnvoll. Was sollte nun wirklich implementiert werden?

=== Was nimmt man für die Modifikation der Beans ===

* Die o.g. Bytecodegeneratoren können unser Problem wohl alle lösen. Allerdings ist die Codeerzeugung alles andere als intuitiv und einfach. Andererseits kann man durch Delegation dazu kommen, daß man die eigentliche Funktionalität wieder in richtigem Java schreiben kann. Man kann die persistente Klasse als Ableitung der Original-Beanklasse implementieren. Wenn diese Lösung einmal steht (ich habe es bereits mit BCEL gemacht), ist sie eigentlich ganz gut.
* Proxy-Objekte bauen auf einem Interface statt auf einer Bean-Class auf. Man müsste also zu jeder Beanklasse ein identisches Interface haben. Vielleicht erstellt man dieses per BCEL? Es entsteht dann das Problem, daß das Proxy-Objekt nicht mehr die Klasse der ursprünglichen Bean hat. Das kann zu Verwirrung führen. Hibernate scheint so zu arbeiten, da mir dort genau dieses Problem aufgefallen ist.
* AspectJ ist garantiert die eleganteste und intuitivste Lösung. Scheinbar kann man es neuerdings sogar dazu bringen, in einer Standard-Umgebung zu laufen (ohne Precompiler). Es erlaubt aber leider nicht, zusätzliche Methoden in einer Klasse zu erzeugen. Es modifiziert immer die Originalklasse, d.h. auch nicht-persistente Instanzen der Klasse werden verändert.



== Was ist eine Bean? ==

* BCEL nutzen um Klassen zu bearbeiten, Event handling

{{{
public class Bean {

   private Feld a;

   public Feld getA()  { return a; }
   public setA(Feld b) { a = b;   }
}
}}}



== Links ==

*[offizielle*>> <<[offizielle >>FAQ zu JPA von Sun|http://java.sun.com/javaee/overview/faq/persistence.jsp]
<<*[Artikel*>> <<[Artikel von Sun über JPA|http://java.sun.com/developer/technicalArticles/J2EE/jpa/]
<<*[BeanKeeper|http://netmind.hu/beankeeper] scheint mir ein leichtgewichtiger Ansatz, wenn es nicht Hibernate oder JPA sein soll...  --PeterHormanns
----
;Kategorien:KategorieJava