Viele Frameworks und Libs entwickeln sich aus “Best Practices” die sich in einem Projekt ergeben. Bzw. als Lösung auf die Probleme die aufgetreten sind.
Bei vielen gibt es auch ein Hello World Beispiel, wie, wieso und warum das ganze funktioniert.
Bei diesem Projekt sieht es IMHO etwas mau aus.
Daher würde ich gerne mal einen Anwendungsfall vorstellen, bei dem ich mir vorstellen könnte Neco4j einzusetzen. Es handelt sich allerdings eher um ein Spielzeug-Projekt um sich mit persistenten Datenstrukturen vertraut zu machen und evtl. Lücken in Neco4j zu schließen.
TicTacToe als einfaches Spiel mit einer einfachen Datenstruktur.
Player current;
List board;
}```
Sowie einer
```class History {
List<GameState> history;
}
Das ganze mit Undo- Redo über die Spielzüge. Die Krux an der Geschichte ist ja immer, wenn ein history-Eintrag erstellt wird, dann benötigt man eine neue Liste für das board, was sehr ungünstig sein kann.
Ein anderes Beispiel, das ich in einem Vortrag gesehen habe ist hier zu finden.
In der History müsste nur gespeichert werden, auf welche Felder jeweils gezogen worden ist. Daraus und aus dem aktuellem Feld lassen sich alle vorherigen Positionen rekonstruieren.
Richtig, es lässt sich “rekonstruieren”. Bei TicTacToe ist der Schmerz auch nicht allzugroß.
Aber nur angenommen die Domäne verschiebt sich in die Richtung des Pixeleditors.
64 x 64 Pixel.
Könnte man in einer Liste ablegen.
Jetzt macht man zwei Million Änderungen.
Auch noch kein Problem. Erst recht nicht mit veränderbaren Datenstrukturen.
Jetzt möchte man Undo implementieren und hat mehrere Möglichkeiten.
Man speichert das komplette Bild nach jeder Änderung ab.
Man speichert jede Änderung, also das Delta.
Benötigt viel Speicher. Lookup auf einen beliebigen Datensatz in der History funktioniert tadellos. Implementierung trivial.
Der Speicherverbrauch ist gering im Vergleich zu 1.
Ein Lookup erfordert einen hohen Aufwand. Will ich das Bild zum Zeitpunkt 1.000.000, dann sind das eine Million Operationen.
Hier steckt zusätzlicher Implementierungsaufwand drin.
Was ich mir, wenn Neco4j einen Sinn machen sollte wünsche ist.
Ein Speicherverbrauch wie in 2.
Die Geschwindigkeit wie in 1.
Einen Implementierungsaufwand wie in 1.
Nun stellt sich die Frage ob dies Möglich ist und Neco4j dies leisten kann?
Und wenn man dies anhand eines Beispieles oder Beispielhaften Projektes sehen könnte, dann würde ich dies überaus interessant finden.
Marco13 hat mit JCuda und den Samples auch Beispiele wie das ganze in Aktion aussieht.
Java One T-Shirt-Contest mit der Restriktion eines Projekts mit Hazelcast, hat auch gewisssermassen das ein oder andere hervorgebracht, wie das ganze in Aktion aussieht. (Mittlerweile ist Hazelcast ein Riesenprojekt, das an verschiedenen Stellen zu finden ist)
Der Speicherverbrauch einer strikten immutablen Liste ist derselbe wie bei LinkedList, und die Geschwindigkeit wird ähnlich sein - wobei es natürlich auf die Zugriffsart ankommt. Für schnellen wahlfreien Zugriff gibt es mindestens eine Alternative, die mehr Speicher braucht und komplizierter ist, aber O(log(n)) Lesezugriff bietet.
Unabhängig von der Eignung für ein bestimmtest Projekt fände ich ein bißchen Anwendungsbezug (also auch, wenn der Anwendungsfall nicht „perfekt“ ist) nicht schlecht. Im Moment gibt es (wenn ich das richtig in Erinnerung habe - hab’ schon ewig nicht mehr reingesehen :o ) Unit-Tests. Aber das Spektrum über Unit-Tests hinaus, über Performance-Tests und Samples, auch abzudecken, wäre gut. Auch wenn ich immernoch das Gefühl habe, VIEL zu wenig zu wissen, als dass ich gute, nachhaltige Beiträge liefern könnte, würden Samples vielleicht ganz allgemein die Verwendung verdeutlichen, und die Performance-Tests die Bedenken zerstreuen, die ich beim letzten Codelesen wegen des häufigen Auftretens von „reverse()“ hatte. Ich notier’ mir das mal als „TODO“. Ob damit das „Henne-Ei-Problem“ gelöst wird (nicht zu wissen, wie das Interface aussehen muss <-> Nicht zu wissen, wie es verwendet wird), wird sich zeigen…
Das Henne-Ei-Problem ist etwas kleiner geworden: Im Experimental-Branch habe ich als Gegenstück zu LazyList eine StrictList programmiert, das gemeinsame Interface List herausgezogen (schon klar, sollten wir noch umbenennen…), und aus diesem wiederum das Interface Sequence, so dass auch Stream mit hineinpasst. Alles sicher noch buggy, und bestimmt fehlen nützliche Methoden, aber vielleicht könnt ihr mal reinschauen.
Falls wir uns entscheiden, in diese Richtung zu gehen, würde ich vorschlagen, das ganze erst mal ein wenig zu konsolidieren sowie allen interessanten Code aus der alten NecoList herüberzuretten. Als nächstes könnten wir das in den Master-Branch mergen, und **dann **erst wäre aus meiner Sicht ein Demo-Projekt sinnvoll.
Als Projekt wäre vielleicht ein Sudoku-Solver oder so nicht schlecht: Das Projekt wäre nicht trivial und könnte Listen gut gebrauchen, man braucht keine tolle Oberfläche und hat auch genügend fertige Implementierungen, wenn man sich inspirieren lassen will.
The bug Loading... still persists.
Of course it would be much easier to just comment on the bug in the issue tracker, but I don’t see how to do so. How do I get an account or how do I add comments anonymously?
So instead of adding just a comment „affects also Java 8u25“ I have to create a completely new bug report via this website for every affected Java release. Thank you very much!
Actually I’m not sure anymore what is worse: Is it this critical bug which causes major security issues in my company since all employees are forced to stay with an outdated Java or is it the whole process of reporting Java bugs. I really haven’t seen such a closed bug tracking system for years now. How can this be related to an „openjdk“??? One really gets the feeling you are not interested in bug reports at all! Otherwise you would not try to make reports as hard and intransparent as possible (I did not even get a notification for my last bug report, neither that it was created nor that it was closed as duplicate. I had to search for it on the web myself). So please don’t wonder if people switch to Scala or other languages. They ALL have a better understanding of how to work with the community. Or look at JetBrains and how they handle users of their open source or commercial products: Of course they allow users to report bugs in their issue tracker and they also inform the users about changes. That’s how one does it!
Ich weis nicht in wieweit das für euer Projekt relevant ist, aber für den Anwendungsfall kann man eine gemischte Vorgehensweise wählen: Es wird jeweils das Delta gespeichert, und in gewissen Abständen das ganze. Ähnlich wie z.B bei Videos glaube ich gibts dann quasi einen Keyframe zu dem man springen kann und die nächsten paar Bilder sind dann von dem abhängig.
) Unit-Tests. Aber das Spektrum über Unit-Tests hinaus, über Performance-Tests und Samples, auch abzudecken, wäre gut. Auch wenn ich immernoch das Gefühl habe, VIEL zu wenig zu wissen, als dass ich gute, nachhaltige Beiträge liefern könnte, würden Samples vielleicht ganz allgemein die Verwendung verdeutlichen, und die Performance-Tests die Bedenken zerstreuen, die ich beim letzten Codelesen wegen des häufigen Auftretens von „reverse()“ hatte. Ich notier’ mir das mal als „TODO“. Ob damit das „Henne-Ei-Problem“ gelöst wird (nicht zu wissen, wie das Interface aussehen muss <-> Nicht zu wissen, wie es verwendet wird), wird sich zeigen…