Verständnisproblem mit String.replaceAll

[takidoso]

Hallo und Halli,
also irgendwie ist bei mi rder wurm drinn aber eigetnlich sollte das nicht so schwer sein...

Ich möchte mit einem gewöhnlichen String.replaceAll() Eine Zeichenkette mit etwas ersetzten. nun bekomme ich aber merkwürdigerweise einen java.lang.StringIndexOutOfBoundsException
was ich überhaupt nicht begreifen kann.

folgende Daten sind mittels Trace nachweislich vorhanden:
resolvedCommand=cmd /c copy <inputDir><inputFile> <outputDir><cp_output>
token=<inputDir>
inputDir=d:\workspace\File-Demon\tmp\input\
outputDir=d:\workspace\File-Demon\tmp\output\
inputfile=d:\workspace\File-Demon\tmp\output\

und das Statement in dem es kracht ist folgendes

resolvedCommand = resolvedCommand.replaceAll(token, inputDir);

Dabei soll es hier lediglich <inputDir> ersetzen mit Inhalt von variable inputDir.

in der Beschreibung finde ich in einer angewandten Routine folgenden Hinweis

* @throws  IndexOutOfBoundsException
     *          If the replacement string refers to a capturing group
     *          that does not exist in the pattern
     */
    public Matcher appendReplacement(StringBuffer sb, String replacement) {

allderdings verstehe ich diesen Hinweis nicht vielleicht kann mir jemand da weiterhelfen was wirklich damit gemeint ist.
der Stacktrace ist folgender

Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 34
	at java.lang.String.charAt(String.java:558)
	at java.util.regex.Matcher.appendReplacement(Matcher.java:696)
	at java.util.regex.Matcher.replaceAll(Matcher.java:806)
	at java.lang.String.replaceAll(String.java:2000)
	at de.equens.filedemon.FileProcessor.generateApplCall(FileProcessor.java:352)
	at de.equens.filedemon.FileProcessor.doOneDirTurn(FileProcessor.java:178)
	at de.equens.filedemon.FileProcessor.run(FileProcessor.java:105)
	... 1 more

Ich kapiere wirklich nicht wie es hier zum Index 34 kommt. Irgendwas verstehe ich wohl von den einzubrngenden Parametern nicht

für Hinweis sehr dankbar

Takidoso

 

[MeinerEiner_80]

Moin!
Folgedes:
"\" Wird als escape Sequenze genutzt und kann unter Java nicht alleine stehen, sondern nur in Kombination mit einem zweiten Zeichen. So bezeichnet \n beispielsweise einen Zeilenumbruch.
Mit \\ würdest du dagegen wirklich ein einziges \ bekommen. Man kann es sich so merken:
Der Javac Compiler macht aus einem "\\" ein "\".
Und:
Ein Regex macht aus "\\" ebenfalls "\".
Da die replaceAll() Methode davon ausgeht, das du einen Regex nutzt, müsste dein Aufruf eher so lauten:

String resolvedCommand="cmd /c copy <inputDir><inputFile> <outputDir><cp_output>";
       String token="<inputDir>";
       String inputDir="d:\\\\workspace\\\\File-Demon\\\\tmp\\\\input\\\\";
       System.out.println(resolvedCommand.replaceAll(token, inputDir));

Oder.. nutz einfach die replace() Methode.. Hier wird nicht mit Regex gearbeitet.
Aber an den Compiler denken, falls du die Variable inputdir in deinem Quellcode deklarierst:

String inputDir="d:\\workspace\\File-Demon\\tmp\\input\\";

*grüssle*
MeinerEiner

 

[takidoso]

Hallo MeinerEiner,
Wenn ich Dich richtig verstehe verwendet die repaceAll Methode nicht nu rim ersten String eine regex sonder auch im String mit dem ersetzt werden soll?
ist irgendwie putzig bzw verwirrt mich

Ich hatte es eigetnlich so verstanden, dass der erste String der reuläre Ausdruck ist, der die Stellen beschreibt die ersetzt werden sollen. der 2.String war meiner Auffassung der String mit dem ersetzt werden sollte. Wenn ich es richtig sehe gehören die Zeichen '<' und '>' nicht zu den in Regex reservierten Zeichen. So hatte ich da keinen Argwohn.

Tatsächlich habe ich dden String der hier anstelle eines anderen ersetzt werden soll in einer Konfigurationsdatei.
Ich versuche das mal mit der normalen replace-Routine, auch wenn diese (leider) vermutlich nicht alle erwischen würde.

 

[takidoso]

Na prima mit dem normalen Rplace geht es nun richtig gut.
Man gut das ich hier die Freiheit hatte auch mit Java 5 zu arbeiten, sonst wäre es vermutlich nicht so leicht was passendes zu finden.

Dank nochmal an MeinerEiner für den Hinweis

Takidoso