Mein kleines Projekt (Designfragen)

[Liberty]

Moin,

ich fange gerade mit einem Projekt an, bei dem ich zu ein paar Designfragen eure Meinung bzw. eure Tipps gebrauchen könnte.

Kommandozeilenargumente verarbeiten

Wie kann man am elegantesten/einfachsten die auf der Kommandozeile übergebenen Argumente auswerten? Grundsätzlich ist die Reihenfolge bei mir (standardkonform, nehme ich mal an):

programm [Optionen] [Inputdatei] [Outputdatei]

Die Optionen sind entweder ganz simple -[a-z]* oder enthalten auch Parameter, die ich durch einen Doppelpunkt von der Option trennen wollte, also z.B.: -sl:8. Ich weiß jetzt nicht, ob das Format einigermaßen mit irgendwelchen de-facto-Standards zusammenpasst, aber ich wollte auf jeden Fall das Leerzeichen als Delimiter erhalten.
So, das Prinzip dürfte klar sein, jetzt frage ich mich, wie ihr eine solche Kommandozeile (die auch durchaus komplex werden kann mit 10+ Optionen) auswerten würdet: RegExp oder gibt's da vielleicht irgendwelche anderen Klassen in der CL, die mir noch nicht aufgefallen sind?
Die Optionen selbst werden in einer eigenen Klasse verwaltet, das scheint mir der sauberste Ansatz zu sein.

Bytepuffer

In dem Projekt manipulieren diverse Threads parallel einen oder mehrere Inputstreams. Diese Threads ziehen ihre Daten aus einem statischen Puffer und schreiben ihren Output in einen anderen Puffer gleicher Bauart. Grundsätzlich habe ich mit der Threadsicherheit auch kein Problem, ich frage mich allerdings, welche Datenstruktur der Puffer intern verwenden sollte, ganz naiv würde ich ein einfaches Bytearray (byte[puffergroesse] daten) nehmen, aber ich kenne mich z.B. mit den neuen Collections nicht wirklich aus. Haben die irgendwelche Vorteile (bessere Performance?), die ich hier gebrauchen könnte?

Wie gesagt, dieses Topic ist nur für die von euch, die nicht wissen, wohin mit ihrer Zeit und ihrem Wissen ;-)

So long,
Liberty

[mehlvogel]

Zu den Kommandozeilenargumenten kann ich nichts sagen.

Zu dem Bytepuffer. Collections machen da wahrscheinlich erst Sinn, wenn du mehr als bytes verarbeiten willst und die Größe variabel bleiben soll. Dort wären unter Umständern dann die synchronisierten, sprich auf Multi-Threading ausgelegten Varianten der Listen von Vorteil.

[anda_skoa]

Ad Kommandozeilenparameter:
http://jargs.sourceforge.net/
http://jopt-simple.sourceforge.net/

Ciao,
_

[Waxolunist]

Juhu, Senf dazugeben !!

Für die Kommandozeilenparameter gibts auf shellSkript-Ebene Getopts. Das gleiche gibts auch in vielen verschiedenen Varianten in Java. Einfach mal nach Getopts und Java suchen.

Das gibts von SourceForge: http://dolphin.sourceforge.net/getopt/

Nicht vergessen darf man in diesem Fall aber Jakartas Common CLI.
http://jakarta.apache.org/commons/cli/introduction.html
Diese scheint weiter entwickelt zu sein.


Leider habe ich mit beiden noch nicht ausführlich genug gearbeitet um ein gutes objektives Urteil abzugeben.


-----------------------------

Bytestreams/Buffers -- nun angeblich haben sich die nio-Klassen ja gebessert, besonders seit Version 6. Schon in 1.4.2 war ich mit den nio-Klassen zufrieden. Unter 5 und 6 habe ich sie noch nicht verwendet. Aber sieh dir mal die Klasse java.nio.ByteBuffer an.

------------------------------

Selber proggen ist natürlich immer auch eine Möglichkeit, aber ich erfinde generell das Rad ungern mehrmals, weshalb ich immer gerne auf schon fertige getestete Libs umsteige, sofern es die Lizenzen erlauben, auch wenn damit gerne mal schnell eine Programmgröße von ein paar MB für ein kleines Programm erreicht wird, da oft viel unnötiges in den libs ist. Aber man kann sich ja nur die wirklich notwendigen Klassen herausholen, wenn man mal ein Projekt ausliefert oder weitergibt.
Zudem bekommt man so ein wenig Erfahrung im Umgang mit anderen Bibliotheken und die Einarbeitungszeit wird durch geringere Testzeit wieder hereingeholt.

mfg, Christian

[Waxolunist]

@anda_skoa

Jetzt warst du schneller und hast 2 weitere Getopt-Varianten auf Sourceforge gebracht.

Es gibt echt unendlich viele davon.

[Liberty]

Moin,

danke für eure Anregungen, damit kann ich schon mal einiges anfangen! Auf den ersten Blick werde ich wohl meine Puffer doch selbst schreiben, der ByteBuffer in java.nio erscheint mir auf den ersten Blick doch sehr mächtig zu sein (und wie sieht's da eigentlich mit der Threadsicherheit aus?) wobei meine Puffer nebenbei noch ein paar andere Interfaces implementieren müssen. Da erscheint es mir dann doch sinnvoller, die Klasse von Grund auf neu zu entwickeln.

Aber was die Kommandozeilenparser angeht, scheint mir JArgs ziemlich genau das zu sein, wonach ich suche, klein und handlich. Vielleicht schreibe ich mir selbst irgendwann auch noch mal so einen Parser, aber da das ja nun wirklich nicht die Königsdisziplin der Informatik ist, werde ich für den Anfang erstmal JArgs oder ein ähnliches Framework nehmen und wenn ich später Zeit hab', kann ich ja immer noch meinem persönlichen Perfektionismus fröhnen.

So long,
Liberty

P.S.:
Weiß jemand von euch zufällig aus dem Kopf, ob in der ThreadGroup "system" immer die gleichen Daemon-Threads laufen (also "Reference Handler", "Finalizer" und "Signal Dispatcher") oder variiert das von VM zu VM? Und ist der Garbage Collector im "Finalizer" angesiedelt oder ist das nochmal etwas anderes?

[Liberty]

Moin,

nochmal danke für eure Tipps, ich habe jetzt für die Kommandozeilengeschichte doch JOpt Simple genommen und das funktioniert wunderbar, doch ich habe ein Problem, denn ich kriege das Konzept der Input und Output Streams in Java einfach nicht auf die Reihe...

Das JOpt-Simple-Framework bietet eine function printHelpOn() an, die eine Übersicht der zur Verfügung stehenden Optionen auf den Bildschirm schreibt. Ein einfacher Aufruf

parser.printHelpOn(System.out);

funktioniert wie gewünscht, aber danach gibt es ein kleines Problem, denn die Methode schließt nach der Ausgabe den Stream, d.h. alle darauffolgenden Aufrufe von System.out.println() führen irgendwo ins Nirvana, aber nicht auf den Bildschirm.

Der Sourcecode für die printHelpOn()-Funktionen ist übrigens:

public void printHelpOn( OutputStream sink ) throws IOException {
        OutputStreamWriter writer = null;

        try {
            writer = new OutputStreamWriter( sink );
            printHelpOn( writer );
        }
        finally {
            if ( writer != null )
                writer.close();
        }
}

public void printHelpOn( Writer sink ) throws IOException {
    sink.write( new OptionParserHelpFormatter().format( recognizedOptions ) );
}

Also sehe ich das überhaupt richtig, dass das writer.close() den kompletten Stream schließt?
Wenn ja, dann würde ich gerne statt System.out einen neuen Stream von System.out ableiten, den ich dann an die Funktion printHelpOn() übergeben kann, so dass danach der alte Stream immer noch geöffnet ist.
Ist das möglich und falls ja, wie?
Ich sitz' hier jetzt schon 'ne halbe Stunde an dem Problem und weiß genau, irgendwo mache ich mal wieder einen riesigen Denkfehler, aber wenn ihr glaubt, ich komm' drauf

Danke im voraus!

So long,
Liberty

[Liberty]

Moin,

ich arbeite immer noch fleißig an meinem Projekt und ich wollte in die Doku ein paar statistische Daten schreiben, so nach dem Motto 10.000 Zeilen Code, davon 8.000 Javadoc, x Methoden, y Klassen und so weiter und so fort.

Kennt ihr da ein Tool, dass mir derartige Daten aus meinen Quelltexten errechnen könnte? Ich habe mich eben schon an Google versucht, aber sobald ich "Java" und "Statistik/Statistics" als Suchworte eingeben, ist die Suchmaschine auf der völlig falschen Spur, deshalb frage ich einfach mal hier nach...

So long,
Liberty

[mehlvogel]

Ich weiß du wolltest Eclipse nicht mehr hören, aber es gibt da nen Plugin für Eclipse: Metrics -- http://metrics.sourceforge.net/

Ich hab auf deren Webseite aber gerade gesehen, und jetzt wirds für dich interessant, dass das ganze auch "headless" mit ant laufen soll (hab aber nur flüchtig geschaut, weiß also nicht was das genau heißt). Vielleicht kannst du damit ja etwas anfangen.