Bug in Java String klasse?

devian_der_999

Mitglied
Hallo liebes Forum,

mir ist da mal was bei der Stringklasse aufgefallen.Jetzt wollte ich fragen ob das verhalten normal ist(oder ob es an mir liegt :D ) und wenn ja dann hoffe ich darauf, dass mir jemand erklären kann warum das so ist :):):)

Also wenn ich folgenden code ausführe:

Java:
import test1.test2.test3.Meins;

public class startUp {

	public static void main(String[] args) {
		Meins meins = new Meins();
		String test1 = meins.getClass().getSimpleName();	// <-- in test1 ist das komische verhalten
		System.out.println(meins.getClass().getSimpleName()); //gibt "Meins" aus
		

	}
}

Giebt er mir korreckt "Meins" aus. Wenn ich die Applikation jetzt im Debuger starte und bei Zeile 8 einen Breakpoint setze und mir die Stringvariable test1 angucke, erkenn ich das im value (das ja jedes String Object hält) trotzdem noch der ganze Name als char[] gehalten wird. (In dem beispiel "import test1.test2.test3.Meins")

Jetzt hab ich mir die methode getSimpleName() Angeschaut und die sieht so aus :

Java:
public String getSimpleName() {
	if (isArray())
	    return getComponentType().getSimpleName()+"[]";

	String simpleName = getSimpleBinaryName();
	if (simpleName == null) { // top level class
	    simpleName = getName();   //<--- in das if springt er !
	    return simpleName.substring(simpleName.lastIndexOf(".")+1); // strip the package name 
	}
	// According to JLS3 "Binary Compatibility" (13.1) the binary
	// name of non-package classes (not top level) is the binary
	// name of the immediately enclosing class followed by a '$' followed by:
	// (for nested and inner classes): the simple name.
	// (for local classes): 1 or more digits followed by the simple name.
	// (for anonymous classes): 1 or more digits.

	// Since getSimpleBinaryName() will strip the binary name of
	// the immediatly enclosing class, we are now looking at a
	// string that matches the regular expression "\$[0-9]*"
	// followed by a simple name (considering the simple of an
	// anonymous class to be the empty string).

	// Remove leading "\$[0-9]*" from the name
	int length = simpleName.length();
	if (length < 1 || simpleName.charAt(0) != '$')
	    throw new InternalError("Malformed class name");
	int index = 1;
	while (index < length && isAsciiDigit(simpleName.charAt(index)))
	    index++;
	// Eventually, this is the empty string iff this is an anonymous class
	return simpleName.substring(index);
    }

meine eigentliche Frage ist jetzt: Ist das verhalten der methode substring normal?

Gruß
Euer Devian
 
Hallo,

auf deine Frage kann ich erstmal nur mit "Ja" antworten.

Könntest du mal etwas genauer erklären, was du jetzt da für nicht normal hälst?

Gruß

Sascha
 
Hi.
meine eigentliche Frage ist jetzt: Ist das verhalten der methode substring normal?
Mal ehrlich: was kümmert dich das? ;-]

Wie irgendwas intern implementiert ist, ist doch völlig egal - solange das richtige herauskommt.

Evlt. ist die Funktion substring so clever und gibt einen Zeiger direkt auf den Anfang des einfachen Namens in dem übergeordneten einfachen binären Strings zurück um Speicher zu sparen...

Gruß
 
Wenn du mal schaust gibt es in der Stringklasse auch ein offset. Das sagt aus, wo der String startet, der Rest ist wie deepthroat schon sagt. Der Substring hält eine Referenz auf das komplette char-Array-Object. Es wird halt ein offset gesetzt, ab wo in dem Array gelesen werden soll.

Gruß

Sascha
 
Hallo,

das ist kein Bug sondern eine interne Optimierung der Klasse String.

Bei:
Java:
    String s1 = "abcde";
    String s2 = s1.substring(2);
    
    System.out.println(s1);
    System.out.println(s2);
wird nur ein char[] erzeugt. Der zweite String (s2) verweist auf das char[] von s1 und speichert sich im "offset" die eigentliche Startposition des Strings.
Dadurch wird die Erzeugung eines zusätzlichen char[] gespart. Funktioniert deshalb gut, weil String immutable ist.

Auf ähnliche Optimierungen findet man auch in der Datenstruktur "Rope":
http://en.wikipedia.org/wiki/Rope_(computer_science)
http://ahmadsoft.org/ropes/
http://www.cs.ubc.ca/local/reading/proceedings/spe91-95/spe/vol25/issue12/spe986.pdf

Gruß Tom
 
Zurück