Und die Generizität in 1.5 ist einfach nur krank, schwach und nicht typsicher. Nur damit sie die VM nicht ändern mussten, ist eine List<Person> dasselbe wie eine List<Auto>, weil die Übersetzung homogen ist (Übersetzung in die Klasse List, die statt dem generischen Parameter einfach "Object" einsetzt).
Vollste Zustimmung.
Frage: Ist diese schwache Pseudo-Generizität besser als gar keine ???
(Bin mir da nicht sicher)
the continuation:
Ob OR/M überhaupt möglich ist, hängt von der konkreten Anwendung ab.
Klingt komisch, ist es auch, denn möglich ist der Einzsatz von ORMs immer.
Diese überspitzte Formulierung soll verdeutlichen, daß es Objektmodelle gibt, mit denen
ORM grundsätzlich sehr problematisch ist.
Grundsätzlich heißt, daß es da tool/implementierungs unabhängige Probleme gibt.
Nennen wir es "OR-mismatch"
Ich meine damit nicht die bekannten Dinge wie: wie bilde ich Polymorphie auf RDBS ab,
sondern Performanceprobleme.
Nicht möglich soll also heissen: kein laufzeiteffektives Mapping möglich.
(uneffektiv heißt hier praktish nicht verwendbar)
Da sind übliche Performancetweaks wie lazy-loading, n+1 selects avoidance,
diverstestes Caching-Strategien schon inkludiert.
Komplexe Objektmodelle wo jedes Objekt von jedem abhägt,
möglichst tief, möglichst viele, ... sind dafür besonders anfällig.
(Objekt hat "Kindobjekte", welche wiederum Kindobjekte hat, welche wiederum ...)
Diese grundsätzlichen Probleme zu erwähnen ist imho wichtiger als Details der
verfügbaren OR-Mapper zu diskutieren.
Insbesondere weil es gerne (eigentlich immer) verschwiegen bzw unbekannt ist.
Erfahungsgemäß: Hat man Performanceprobleme mit ORM
(und die üblichen Tricks a la lazy-loading helfen nix),
nützt ein Tausch des ORMs nichts.
(wahrscheinlich ein ungünstiges Objektmodell für ORMs)
EJB 3.0: IMHO recht genial und durchaus gelungen ...
Komplexere Mappings für die ich mit reinem Hibernate Tage gebraucht hab
gehen in Stunden/Minuten von der Hand ...
Nachteil: Sieht alles recht eazy aus, hat aber leider eine Menge versteckter
Komplexitäten -- ORM sei dank.
ibatis ist interessant, aber für mich kein ORM.
Wenn's denn eine reine objektorientierte DB sein darf -> db40 ansehen.
Oki, Ende des Monologs.
Jo, des ist nicht leicht zu durchblicken 
Die Schwierigkeit liegt da natürlich auf vielen Ebenen möglichst bunt vermischt.
nachdem ich mir nun das thema ejb 3.0 jpa genauer angesehen habe, würde mich auch interessieren, ob ich diese api auch für eine rcp anwendung mit j2se verwenden kann.
Vorausgesetzt das hier ist gemeint:
(3.0'er) Entitybeans "Embedded"/"Containerlos"/"Unmanaged"/"Lokal"/"In nicht J2EE Umgebung" verweden zu können.
Ja, das geht definitiv.
Soweit ich mich erinnern kann ist das sogar ziemlich trivial, der einzige Unterschied zum Deployment der EBs in einem EJB3 Container sind ein paar Änderungen im persistence.xml file.
Was dann bleibt ist quasi ein "Vereinfachtes Hibernate".
(bzw welches OR/M tool die jeweilige JDA Impl. auch immer verwendet, bei Hibernate ist's IMHO jedenfalls eine deutliche Vereinfachung)
In diesem Zusammenhang ist überingens JBoss' embeddable-EJB3-Container ziemlich interessant.
(zumindestens die Idee/der Ansatz, leider dzt noch "unbrauchbar alpha")
jetzt bin ich wieder etwas schlauer: die ejb 3.0 spezifikation JSR-220 spezifiziert ja die java persistant api. hibernate setzt ja genau das mit hibernate entitymanager und hibernate annotations um. also eigentlich kann man ja dann hibernate und ejb 3.0 jpa nicht so 1:1 vergleichen, oder?
Genau.
to be continued whenever more time .... (sh***y post-vacation week)
Hi,
Hab recht viel (reallife-projekt) Erfahrungen mit ejb 3.0 & "O/R-Mappern" gesammelt.
Für eine halbwegs sinnvolle/ausführliche Antwort (pro/kontra ejb 3.0 bzw OR/M bzw OO-DBs) fehlt mir allerdings atm die Zeit 
Werde mich dann in ein paar Tagen in die Diskussion "einklinken", soferne es eine gibt
Sollte ich stressbedingt vergessen -> Mail / PM = np
mfg,lb
tja, dafür hat der Windows-User tolle Tools wie Calculator und Paint...so isses ja ned
Hey,hey,hey, ja nicht Solitaire vergessen.
Windows _IST_ Solitaire-OS.
Nicht elitär, nicht rudimentär, nein, solitär.
You see, I come from a time in the nineteen-hundred-and-seventies when computers were used for two things - to either go to the moon, or play Pong… nothing in between. Y’see, you didn’t need a fancy operating system to play Pong, and the men who went to the moon–God Bless ‘em–did it with no mouse, and a plain text-only black-and-white screen, and 32 kilobytes of RAM.
But then ’round ’bout the late 70’s, home computers started to do a little more than play Pong… very little more. Like computers started to play non-Pong-like games, and balance checkbooks, and why… you could play Zaxxon on your Apple II, or… write a book! All with a computer that had 32 kilobytes of RAM! It was good enough to go to the moon, it was good enough for you.
It was a golden time. A time before Windows, a time before mouses, a time before the internet and bloatware, and a time… before every OS sucked.
[...]
Then Windows 95, then 98, man solitaire never ran so great, and every single version came out late, but I guess that’s the way it goes.
[...]
sorry für ot, aber das mußte jetzt sein
Zitat von Wolfibolfi
Gratuliere zum 1000er, Lordi!
Thx
Achja, ich mach' bei solchen/ähnlichen Problem meistens einen Hardwarecheck. (memtest, dft, primes95, 3dmark,mit knoppix/jollix/... booten... etc,etc)
Klingt zwar nicht nach "echtem" Hardwareproblem (naja, eigentlich schon, via hardware) , aber schaden kann sowas nie.
viel glück
Hmpffff ... wahhh ... hasse nix mehr als windowsprobleme von bekannten zu lösen
bei dem konkreten problem würd ich am ehesten beim chipset driver ansetzen.
das heißt: lesen lernen.
"nur" telefonieren, wecker & uhr.
go.
go for go
da gab es auch so ein total gutes Umweltspiel, wo man kaputte Wälder roden musste, Papier selbst machen und solche Sachen, was es sosnt auch nirgendswo in nem anderen Spiel gab, aber echt fun machte!
das hört sich doch stark nach Ökolopoly on ???
Ich hab schon welche benutzt, wo ich erst nachträglich gemerkt hab, in welcher Sprache sie verfasst wurden. Cocoa/Java machts möglich.
Azureus find' ich ein gutes Beispiel für ein sehr gelungens Java-basierendes GUI.
Generizität hätte auch vom Anfang an drin sein sollen.
Leider ist es unsauber und typunsicher implementiert,
damit man die JVM nicht updaten musste.
Full ack.
War ziemlich entäuscht davon, aber trotzdem besser als gar keine Generizität
Schade, dass (trotz allen Gegenbekundungen) Java immer noch für Programme mit User Interfaces saulangsam ist und Swing so eine Krücke
(in jeder Hinsicht) ist.
Swing:
Ja, auch full ack.
Eine Zumutung für User und Programmierer.
Aber SWT/RCP find' ich beispiesweise gut/besser.
Und es gibt da noch genug andere - gute - Ansätze ...
Die Existenz eines langsamen/eher schlechten GUI Frameworks heisst IMHO nicht, daß Java generell ungeignet für GUI Anwendungen ist.
Du behauptest also, dass Java genauso performant ist wie C/C++? Das nehm ich mal an, sonst würdest du nicht sagen, dass es ein Gerücht ist. Aber allein, dass es eine Interpretersprache ist, isses schon langsamer. Warum sollte das ein Gerücht sein?
Tja, definert mal was es bedeutet, eine Sprache X sei performanter als eine Sprache Y.
Eine Dimension dieser Schwachsinnigkeit ist, daß Sprachen keine Performance haben können.
Höchstens konkrete Compiler/Interpreter dieser Sprachen.
C++ sei also performanter als Java ?
Welcher C++ Compiler mit welchen Optimierungen/Einstellungen ?
Welche JVM mit welchen Einstellungen ?
Selbst wenn das fixiert ist, kann ich problemlos einen derart miesen C++ Compiler schreiben, der garantiert schlechter als jede jemals exisitierende JVM ist.
Daraus folgt -> Java ist performanter als C++ !?
Der umgekehrte Fall kann genauso konstruiert werden, also
gilt beides ?! Häh ?
Gut, wenn das geklärt ist: Wie sieht's denn aus, wenn Programm A performanter in Sprache X ist, aber Programm B performanter in Y ? Ist dann X performanter oder Y ?
Oder vielleicht umgekehrt ?
Warum A und B und nicht C ?
Zählt man alle möglichen Programme ?
Wenn geklärt ist, wie man das macht, bleibt noch die Killerfrage: bildet man das arithmetische Mittel oder gar das Geometrische ?
Die höchste Ebene dieser Schwachsinnigkeit kommt aber erst: Es ist völlig irrelevant 
(Ok, nicht in allen Fällen, schon klar, aber viel öfter als
man denkt)
Selbst wenn man - wie auch immer - zum Ergebnis kommt Sprache X sei performanter als Y.
Stichwort Optimize-later bzw ganz allgemein -> Design Patterns "weise" verweden -> sprachunabhängig extrem wichtig ...
Überlebenswichtig für einen guten Software-Engineer würd ich mal sagen aus eigener leidvoller Erfahrung.
Ebenso auf dieser Liga -> Algorithmen-Design, das ist noch völlig sprachunabhänig ..
Weniger Abstrakt: Man nehme einen schlechten Programmierer, der eine Aufgabe in einer "schnellen" Sprache lösen soll, und einen Guten, der die selbe Aufgabe in einer "langsamen" Programmiersprache lösen soll.
Frageeeeee: Wird das Programm in der schnellen Programmiersprache schneller/besser als das in der Langsamen ?
----------------------------------------
Nimmt man einigermassen moderne C++ Compiler und JVMs, so ist der Performacegap weitaus geringer als meist angenommen.
edit:
ganz nett, auch wenn memory-usage vergleich imho krass sinnlos ist ...
End of Blablababla ...
long l = 6446131400L;
sollte compilieren.
Mir fehlt da:
Das bessere Zusammenspiel von allem.
Das ist aber ein Wiederspruch, denn das Spring Framework ist eine Implementierung der J2EE Spezifikation.
Jein.
Nein:
Seh' ich anders.
Spring selbst bietet z.B *keine* Unterstützung für Entity-Beans.
Aber es läßt sich sehr gut mit (anderen) Persistenz-Frameworks kombinieren, z.b Hibernate.
Ebenso für den Bereich Security ... da bietet Spring out of the Box nichts an, aber es gibt Open-source Frameworks, die diese Lücke füllen ...
Definitiv interessant, was da unter "...the leading " full-stack Java/J2EE application framework" verstanden wird ...
Ja: Du hast recht, hab das schlecht formuliert, klingt so als ob Spring und J2EE nix miteiander tu tun hätten. Des stimmt natürlich nicht. Andererseits muß Spring nicht im Kontext von J2EE eingesetzt werden.
Eigentlich will/wollte ich eher auf lightweight-container (z.b spring, pico,...) versus heavy-weight container (jboss, weblogic etc). hinaus
ejb3 ... das ist ein kapitel für sich
Ich hasse J2EE, insbeosndere EJBs, bin grosser Fan des Spring Frameworks, daher kann ich dieses Buch
-- J2EE Development without EJB. sehr empfehlen.
Wahrscheinlich nicht *genau* was Du suchst, aber extrem gut.
Kenne besagtes J2EE Antipatern Buch, ziemlich 08/15.
Meine Meinung: J2EE ist ein einziges Antipattern
Eine (komplexe/RW) J2EE Anwendung entwicklen zu müssen prägt fürs Leben *g*
Mfg, LB
Könnte bitte mal irgendein Admin meine Vermutung bestätigen, daß hinter den anderen Benutzernamen im Forum wirkliche Menschen und keine Bots stehen, danke.
In Wirklichkeit ist das Inf-Forum ein riesiger Turing Test 
