RandomAccessBuffer

[Spacerat]

Tach z'sammen
Ich suche verzweifelt nach einer Art ByteBuffer, welcher, ähnlich StringBuilder, über die Methoden [c]insert()[/c], [c]delete()[/c], [c]append()[/c] und [c]get()[/c] verfügt, das ganze blos auf Byte-Basis. Ich lande bei der Suche immer nur bei RandomAccessFile (Dateibasis statt Speicherbasis). Der ist aber für meine Verwendung, genauso wie StringBuilder (speichert 2 Bytes pro Eintrag), völlig inakzeptabel. Kann doch in Zeiten von [c]java.nio[/c] nicht wahr sein, das man so etwas essentielles selbst Entwickeln muss. Aber möglicherweise bin ich ja auch nur zu dämlich, das richtige zu finden.

 

[FArt]

Kann doch in Zeiten von [c]java.nio[/c] nicht wahr sein, das man so etwas essentielles selbst Entwickeln muss. Aber möglicherweise bin ich ja auch nur zu dämlich, das richtige zu finden.

lol... so was "essentielles" habe ich bisher noch nicht benötigt und würde ich in wenigen Minuten selber klöppeln ... ist schließlich nicht mehr als eine Fingerübung.

Wenn es für jede spezielle Anforderung gleich etwas fertiges gäbe (vielleicht sogar im JDK selber), dann wäre das Teil noch aufgeblähter als es eh schon ist.

 

[Spacerat]

lol... so was "essentielles" habe ich bisher noch nicht benötigt und würde ich in wenigen Minuten selber klöppeln ... ist schließlich nicht mehr als eine Fingerübung.

Wenn es für jede spezielle Anforderung gleich etwas fertiges gäbe (vielleicht sogar im JDK selber), dann wäre das Teil noch aufgeblähter als es eh schon ist.

Selber lol ... Mit dem "aufgebläht" hast du natürlich vollkommen Recht...
Aber um mal auf das "essentielle" zurück zu kommen. Wieviele Java-Entwickler da draussen könnten nicht hin und wieder mal RandomAcces auf Speicherbasis gebrauchen? Also ich hätte genug Anwendungsgebiete. Nehmen wir z.B. mal ein Jar- oder Zip-Archiv und versuchen es in Java zu manipulieren, also darin befindliche Dateien zu ändern oder zu löschen bzw. neue hinzuzufügen. Da geht afaik nur über Zip- bzw. Jar-Streams möglicherweise auch in Verbindung mit RandomAccessFile. Da kann unter Umständen die Anzahl der Plattenzugriffe recht schnell wachsen. Beim Löschen eines Eintrags sieht das dann wohl so aus. Lesen über InputStream und zum OutputStream spoolen, bis der zu ändernde Eintrag gefunden ist, Eintrag überspringen und InputStream bis zum Ende weiter zum OutputStream spoolen. Wenn man Keine Listen für die zu manipulierenden Einträge verwendet, kann das ganz schön Zeit in Anspruch nehmen. Wäre so ein RandomAccessBuffer dafür nicht geeigneter, also schneller? Und was beschehrt uns die JRE mit [c]java.nio[/c]? Auschliesslich starre, in ihrer Grösse nicht veränderbare Buffer... die sind ja auch unbedingt nötig, und blähen nicht nur die JRE auf?

 

[FArt]

Ich glaube das Problem ist relativ low-level. Die meisten arbeiten mit APIs, die auf höherem Level eine Problematik betrachten und somit sich nicht damit rumquälen, Bytes zu manipulieren. Gerade zu deinem Beispiel gibt es genügend APIs, die sinnvoll mit ZIP Archiven umgehen können. Intern, wie gesagt, ist das dann schnell selber gebaut, wenn nötig.

Ein Hinweis darauf, dass du tatsächlich einer der wenigen bist der das benötigt ist sicherlich:
- bei Google ist nichts sinnvolles zu finden (ok, hängt auch davon ab, dass man die richtigen Begriffe findet)
- die "essentielle" Implementierung hat es nicht in bekannte Tools, APIs oder gar ins JDK geschafft