Strings: equals vs ==

Panda9296

Bekanntes Mitglied
String vergleicht man mit equals, nicht mit ==
das stimmt so nicht. Den Inhalt kannst du mit equals effizient prüfen, allerdings prüfst du mit == ob ein String auf den selben String zeigt, wie der String auf den gezeigt wird. Dies ist dann der Fall, wenn der String bereits im Stringpool vorhanden ist. Der Stringpool ist ein recyclingpool, der erheblich Speicher sparen soll, da Strings sehr Speicher lastig sind. Wenn du also == statt equals benutzt kann es durch aus funktionieren:

[CODE lang="java" title="Beispiel"]String a="Hello";
String b= new String("Hello");

String c= "Hello";
String d= "hello";

boolean ab= a.equals(b); // ergibt true
boolean ab2= a==b //ergibt false -> new erzeugt ein neues Objekt von String und ignoriert immer den Pool
boolean ac = a.equals(c);// ergibt true
boolean ac2= a==c // ergibt true-> der String ist im Stringpool vorhanden und die REFERERENZ c zeigt auf das selbe Objekt
boolean ad = a.equals(d); // ergibt false Java ist UpperCase empfindlich
boolean ad2= a==d;// java findet aufgrund des Kleinbuchstaben den String nicht im Pool

//kleine Randanmerkung: boolische Werte werden vor der Zuweisung ausgewertet, deswegen ist es möglich dies ohne Klammern zu demonstrieren [/CODE]
 

thecain

Top Contributor
Kann, ist das entscheidende Wort. Und am Fall vom TE sieht man ja gerade wie es eben nicht geht.
Obwohl deine Aussage stimmt, vergleicht man Strings mit equals und nicht mit ==.
 

Panda9296

Bekanntes Mitglied
Kann, ist das entscheidende Wort. Und am Fall vom TE sieht man ja gerade wie es eben nicht geht.
Obwohl deine Aussage stimmt, vergleicht man Strings mit equals und nicht mit ==.
ja in diesem Fall hast du Recht, da man aber davon ausgehen muss, dass der Fragensteller Anfänger ist, finde ich dies trotzdem wichtig, es auch präzise zu formulieren
 

thecain

Top Contributor
Nein, es ist total irrelevant.

Ich entwickle seit über 10 Jahren Java und der hatte noch nie kontakt mit dem Stringpool ausser in der Theorie. Für einen Anfänger ist das total belanglos, das Einzige was er wissen muss, ist das Strings mit equals verglichen werden. IMMER! Zumal deine Auflistung auch nicht vollständig ist.
 

X5-599

Top Contributor
Sehe ich anders. Mir missfällt es ebenfalls, dass hier immer und immer wieder auf dieses "Strings vergleicht man mit equals nicht mit ==" Mantra verwiesen wird. So als wenn es NIEMALS Sinn ergeben könnte einen Ausdruck zu haben in dem ein String mittels "==" behandelt wird. Dabei wäre an dieser Stelle ein wunderbarer Moment den Unterschied zwischen Objektzustand und Objektidentität zu erklären.
 

LimDul

Top Contributor
Für einen Anfänger ist es wichtig das Mantra zu lernen "Strings vergleich man nicht mit equals". Es gibt für quasi alles Ausnahmen.

Mit Ausnahmen von Regeln darf man sich dann beschäftigen, wenn man die Regel verinnerlicht & verstanden hat. (Oder wenn man irgendwelche Oracle Zertifizierungen ablegen will, die sich mit obskuren Randthemen der VM beschäftigen :D).

Man sollte man anfangs diese Regeln immer als relativ absolut hinnehmen. Die Fälle, wo eine Ausnahme Sinn ergibt, kann man als Anfänger nie abschätzen. Und selbst als Experte liegt man daneben. Wir hatten jetzt im Projekt einen Bug, wo wir zwei Objekte mit == vergleichen haben, die eigentlich Pseudo-Enums sind und eigentlich nur einmal existieren können. Denn die werden über eine Java EE ApplicationScoped Bean geladen. Tja eigentlich - aber nach ca. 2 Wochen Laufzeit war der JBoss der Ansicht zwei Instanzen der Objekte zu haben. Warum weiß keiner und lies sich bis jetzt auch nicht rausfinden.
 
K

kneitzel

Gast
Also gerade bei der Zielgruppe Anfänger sehe ich das ähnlich wie @thecain. Da gibt es gewisse Regeln und die machen einfach Sinn.

Und so lange, wie man die Details nicht verstanden hat, gilt die Regel! Ausnahme von der Regel muss begründet werden! Da muss jemand die Details kennen! Diese Details muss man aber nicht zwingend kennen! Ein Entwickler kann gut Software Entwickeln mit Strings ohne die Details zu verstehen / zu kennen. Er wendet einfach diese Regel an.

Nehmen wir ein anderes Beispiel: Eine Regel, die ich oft nenne: SQL Anweisungen werden nicht aus Strings zusammen gestückelt! PreparedStatement und gut ist es!
Die Regel ist natürlich Quatsch! Spätestens im Bereich DDL funktioniert das nicht. Also sobald die Abfragen nicht mehr DML sondern DDL sind, dann haut es nicht mehr hin. Man muss also nicht einmal komplexe Scenarios entwerfen, wo dynamisches SQL notwendig ist. Rein der Wechsel von Data Manipulation Language hin zur Data Definition Language reicht da aus. Aber das interessiert den Anfänger nicht: Der bastelt sich irgendwelche Tabellen mit Mühe hin in einer GUI und will Daten abfragen / eintragen und gut ist es. Wenn es sich damit beschäftigt, dann kommt er auf Grenzen. Und dann beschäftigt er sich hoffentlich im Detail damit (Ja, ich bin ein Optimist - Oft frickeln sich die Leute das nur zusammen aus Stücken, die sie irgendwo finden ... gibt sogar eine Webseite, die einem Codebeispiele auf GitHub für eine Klasse sucht ... Dinge, die die Welt nicht braucht meine ich ....).

Daher: Klare feste Regeln - die Ausnahmen der Regel kommen von alleine irgendwann mal, so man lange genug dran bleibt. Aber nur so hält man es am Anfang einfach und übersichtlich.

sondern es wirklich sinnvoll ist.
Das ist eine böse Einschränkung... Menno ... reicht doch, dass es funktioniert und es jemandem gefällt ... Außerdem: Wie sollen wir die Lieferfristen reißen, wenn wir nicht tagelang nach so Fehlern suchen müssen? :)
 

Panda9296

Bekanntes Mitglied
Also, wenn ich so sehe, welche Diskussion das losgelöst hat muss ich die Damen und Herren doch mal an dieser Stelle fragen, was schadet es, diese Information zusätzlich, passend zu dieser Situation zur Verfügung zu stellen, sodass dieser Beitrag die Möglichkeit der Wiederverwertung, im Bezug der Informationsbeschaffung zu diesem Thema hat. Der Leser kann so selbst entscheiden, ob diese Information interessant ist oder nicht. Ich finde hingegen die Diskussion, ob die Information erwähnt werden soll oder nicht," !effizient" . Meine Damen und Herren, ich gehe nach dem Grundsatz: Besser mehr als zu wenig, solange es übersichtlich bleibt. Mein Beispiel sollte eine kleine Erweiterung der FALSCHEN Behauptung sein, die ich einfach ergänzen wollte, damit der Leser später nicht durcheinander kommt. Falls ich damit am Ziel vorbei geschrammt bin, tut mir das leid, allerdings muss ich darauf hinweisen, dass die hier ausgeführte Diskussion zur Nichtlesbarkeit beigetragen hat und ich finde, dass da jeder für sich entscheiden sollte.
 
K

kneitzel

Gast
Also, wenn ich so sehe, welche Diskussion das losgelöst hat muss ich die Damen und Herren doch mal an dieser Stelle fragen, was schadet es, diese Information zusätzlich, passend zu dieser Situation zur Verfügung zu stellen, sodass dieser Beitrag die Möglichkeit der Wiederverwertung, im Bezug der Informationsbeschaffung zu diesem Thema hat. Der Leser kann so selbst entscheiden, ob diese Information interessant ist oder nicht. Ich finde hingegen die Diskussion, ob die Information erwähnt werden soll oder nicht," !effizient" . Meine Damen und Herren, ich gehe nach dem Grundsatz: Besser mehr als zu wenig, solange es übersichtlich bleibt. Mein Beispiel sollte eine kleine Erweiterung der FALSCHEN Behauptung sein, die ich einfach ergänzen wollte, damit der Leser später nicht durcheinander kommt. Falls ich damit am Ziel vorbei geschrammt bin, tut mir das leid, allerdings muss ich darauf hinweisen, dass die hier ausgeführte Diskussion zur Nichtlesbarkeit beigetragen hat und ich finde, dass da jeder für sich entscheiden sollte.
Es schadet in so fern, als dass es Anfänger verwirrt. Man wird heutzutage doch erschlagen. Was muss man alles können?

Also muss man schauen, was für Informationen sind wichtig und welche nicht. Das Ergebnis sind sonst tolle Lösungen. So ist eine tolle Lösung für den String Vergleich, die hier im Forum schon angeboten wurde:
string1.intern() == string2.intern()
Damit hat man einen funktionierenden Vergleich.

Java:
    public static void main (String[] args) {
        String string1 = "Hallo";
        String string2 = new String(string1);
        System.out.println(string1 == string2); // false
        System.out.println(string1.intern() == string2.intern()); // true
    }

Daher bin ich weiter davon überzeugt, dass man Leute nicht mit unnötigen Details verwirren sollte. Die Details kann sich jeder gerne unabhängig erarbeiten, wenn er es braucht. Aber gewisse Komplexitäten verstecke ich, weil es einfach unsinnig ist!
 

DrPils

Bekanntes Mitglied
Ich als Anfänger bin immer froh über solche Details. Man lernt eben sehr gut wenn man verschiedene Dinge miteinander verknüpft.
Wenn ich dahinter komme wieso "abc" == "abc" true zurückgibt, komme ich auch dahinter dass Strings problematisch für den Speicher sein können, da sie Immutable sind und bei jeder "änderung" ein neues Objekt erzeugt werden muss, dann leuchtet mir auch der Sinn des StringBuilders ein, usw.
Da alles miteinander verknüpft ist, geht es einfach schneller in den Kopf und bleibt länger dort.
 
K

kneitzel

Gast
Ich als Anfänger bin immer froh über solche Details. Man lernt eben sehr gut wenn man verschiedene Dinge miteinander verknüpft.
Wenn ich dahinter komme wieso "abc" == "abc" true zurückgibt, komme ich auch dahinter dass Strings problematisch für den Speicher sein können, da sie Immutable sind und bei jeder "änderung" ein neues Objekt erzeugt werden muss, dann leuchtet mir auch der Sinn des StringBuilders ein, usw.
Da alles miteinander verknüpft ist, geht es einfach schneller in den Kopf und bleibt länger dort.
Aber auch da vermengst Du ein paar Dinge etwas meine ich.

Das Strings nicht verändert werden können, hat ja mit dem "abc" == "abc" erst einmal nichts zu tun. String ist in erster Linie einfach eine Klasse. Und wie bei allen Instanzen wird hier bei == nur ein Vergleich der Referenzen durchgeführt. Das ist der Grund, warum man beim Vergleich von Werten in einer Klasse halt equals nutzen soll und nicht ==.

Dass "abc" == "abc" true ergibt, hat damit erst einmal nichts zu tun. Das ist eine Optimierung, die vorgenommen wird. Die spielt aber da ansonsten erst einmal nicht wirklich mit rein und ist für den Anfänger auch wenig interessant. Wenn das interessiert, dann würde sogar die grobe Info reichen, dass da halt etwas optimiert wird. Das String Literal im Code wird immer zur gleichen String Instanz. Also dazu muss ich noch nicht einmal intern() verstehen oder kennen. Und das nützt einem Anfänger bitte genau was? Was kann der Anfänger bitte mit genau diesem Wissen über intern() anfangen? Außer eben es missbrauchen und sich freuen, dass es in seiner kleinen Welt tatsächlich keine Probleme zu geben scheint?

Aber wie dem auch sei:
Du hast da jetzt paar Dinge verstanden. Ändert das etwas daran, dass Du Instanzen mit equals vergleichst? Siehst Du irgend einen Nutzen von einem String Vergleich mit == in irgend einer Situation? ==> #7 von @thecain
Denn genau das wäre ein Grund, an der Regel festzuhalten. So lange es aber keinen Grund gibt, dann ist die Regel ja gut und sinnvoll.
 
K

kneitzel

Gast
Dann sind wir uns doch einig. Das ist ja auch nie als unnützes Wissen abgetan worden. Ausgangspunkt war die Aussage "das stimmt so nicht" bezüglich der Regel.

Und welches Wissen man einem Anfänger um die Ohren haut oder eben nicht, da kann jeder die Meinung vertreten, die er möchte. Das ist ja auch nicht für alle Anfänger gleich, so dass es da kein richtig oder falsch gibt.
 

White_Fox

Top Contributor
Es ist ja durchaus sinnvoll, einen Anfäger nicht mit zu vielen Details gleichzeitig zu erschlagen.
Wenn ich aber überlege wieviele Entwickler sich - zumindest in meinem Bereich - stets an Dogmen und feste Regeln halten, selbst wenn man ihnen deren Sinn und Hintergrund irgendwann einmal erklärt hat tritt dieser nach einigen Jahren Regeldenken einfach immer mehr in den Hintergrund und ist irgendwann dem Denken entschwunden. Geblieben ist ein "So macht man das einfach immer".

Ich persönlich bin ja der Meinung, man sollte auf Regeln und Dogmen grundsätzlich verzichten und stattdessen Erkenntnis und Verständnis der Sache in den Vordergrund stellen. Regeln sind was für Computer und dressierte Affen. Wenn ich da an das leidige Thema Stützkondensatoren bei elektronischen Schaltungen denke, huiuiuiuiui....

Und gerade das Thema Objektidentität kann man gar nicht früh genug begreifen, wenn man Java lernt. Ich muß @Panda9296 da Recht geben, gerade weil das eine beliebte Anfängersache ist, ist das ein prima Aufhänger um dieses Thema dranzunehmen. Und es ist ja nun nicht gerade kompliziert und unübersichtlich, wie ich finde - aber trotzdem absolut wichtig.
 

Wurstkopp

Bekanntes Mitglied
Dinge hinterfragen und verstehen ist ja schön und gut, aber die Aussage "Strings vergleicht man mit equals, nicht mit ==" bleibt nun mal so stehen. Wie schon geschrieben ist es vermutlich nie sinnvoll selber Strings per Referenz zu vergleichen.
Und auch für den Lerneffekt finde ich das Beispiel Strings mit dem internen Stringpool und dessen nicht direkt sichtbaren "Compilermagic" die damit einhergeht, für Anfänger sehr schlecht geeignet. Das ist ein klassischer Sonderfall. Genau wie bei den Wrapper Klassen wo wir ein ähnliches Thema neulich schon mal hatten: https://www.java-forum.org/thema/bei-foreach-index-des-elements-ermitteln.189099/post-1228598
Da gibt es doch bestimmt bessere Beispiele für Java-Beginner.

Also zum"String vergleicht man mit equals, nicht mit ==" kann man im besten Fall noch ein "und hier ist der Grund wieso das so ist: *Link*" hinzufügen. Ist meiner Ansicht nach aber nicht zwingend nötig.

PS:
Code:
boolean ad = a.equals(d); // ergibt false Java ist UpperCase empfindlich
Das heißt "case sensitive" :)
 

X5-599

Top Contributor
Nenn mir einen Ort an dem es Sinn macht. Nicht wo es funktioniert, sondern es wirklich sinnvoll ist.

Konstanten vielleicht? Enums gab es nicht von Anfang an und wenn jemand Softwareentwicklung professionell machen will wird er früher oder später damit konfrontiert werden. Sich dann hinzustellen und stolz wie bolle zu behaupten: "Ha! Das KANN ja gar nicht funktionieren, weil das macht man nicht so" wär' schon ziemlich peinlich, oder?
 

LimDul

Top Contributor
Konstanten vielleicht? Enums gab es nicht von Anfang an und wenn jemand Softwareentwicklung professionell machen will wird er früher oder später damit konfrontiert werden. Sich dann hinzustellen und stolz wie bolle zu behaupten: "Ha! Das KANN ja gar nicht funktionieren, weil das macht man nicht so" wär' schon ziemlich peinlich, oder?
Selbst die würde ich mit Equals vergleichen. Und es sagt ja niemand hier "Das funktioniert nicht" sondern "Das macht man nicht, weil es Situationen gibt, wo es nicht funktioniert".
 

X5-599

Top Contributor
Es geht mir nicht darum wie du es machen würdest sondern wie es bereits gemacht wurde. Z.b. Legacy Code einer Firma. Darum das "wenn man das professionell machen will".
Auch kann ich verstehen wenn ein alt gedienter eben keine Enums erstellen will für zwei, dei Konstanten. Der nimmt dann eben Strings. Enums werden doch auch mittels == verglichen. Da sagt komischerweise niemand, dass es "keinen Sinn ergibt" das so zu tun...
 

thecain

Top Contributor
Bei Konstanten kommt es ja auch wieder darauf an, wo du die Werte her hast und wie die Konstanten instaziiert worden sind. Du wirst ja selten 2 Konstanten miteinander vergleichen, die du direkt als String instanziiert hast...
Java:
class Scratch {
    private static final String ONE = "Azul Systems, Inc.";
    private static final String TWO = System.getProperty("java.vendor");


    public static void main(String[] args) {
        System.out.println(TWO);
        if (ONE == TWO) {
            System.out.println("Equal");
        } else {
            System.out.println("Not Equal");
        }
        if (ONE.equals(TWO)) {
            System.out.println("Equal");
        } else {
            System.out.println("Not Equal");
        }
    }
}
UPPS

Enums sind ja auch keine Strings. Zudem ist es für Enums in der JLS spezifiziert, dass sie mit == verglichen werden dürfen.
Because there is only one instance of each enum constant, it is permitted to use the == operator in place of the equals method when comparing two object references if it is known that at least one of them refers to an enum constant.
 
K

kneitzel

Gast
Enums sind Klassen mit einer festen Anzahl Instanzen von denen zur Laufzeit keine weiteren Instanzen angelegt werden können. Da will man also die Referenzen vergleichen. Und denen auch noch einen State zu verpassen - würde gehen, aber ist aber zumindest unüblich und ich hätte da durchaus die Problematik von wegen "unexpected behaviour". Wobei das nicht 100% korrekt ist, da enum ja auch etwas richtung Singleton missbraucht werden kann und da kann es ein state geben. Damit das Equals aber Sinn macht, müsste die Frage erlaubt sein, ob der Inhalt gleich ist.

Also könnte ich sowas haben wie:

Java:
public enum Boss {
    CEO("Konrad", "Neitzel", 1),
    CSO("Konrad", "Neitzel", 1);

    private String firstName;
    private String lastName;
    private int personnelNumber;

    Boss (final String firstName, final String lastName, final int personnelNumber) {
        this.firstName = firstName;
        this.lastName = lastName;
        this.personellNumber = personnelNumber
    }
    
    // getter / setter / equals / HashCode
}
Dann hätte ich so eine Art Singleton - es kann nur einen CEO und CSO geben. Und da will ich dann ggf. ein equals haben.
==> Aber hier habe ich dann auch den klaren Unterschied zwischen CEO == CSO und CEO.equals(CSO). Wobei auch schon das Design extrem negativ auffällt. Aber ein ordentliches Beispiel fällt mir da nicht ein. Und ich bezweifle irgendwie, dass man etwas sinnvoll aufbauen kann, dass equals bei Enums Sinn ergeben.

Und Konstanten vergleichen? Was soll das für einen Sinn machen? Ja, du kannst String Literale und Konstanten mit == vergleichen. Also du kannst in deinem Code schreiben:
Java:
if ("hallo" == "test") { ... }

Nur das macht keinen Sinn! Ebenso zwei Konstanten:
Java:
if (WHATEVER_1 == WHATEVER_2) { ... }
Macht so nicht wirklich Sinn. Wann und wo checkst Du in Deinem Code Konstanten, sprich Dinge, die doch festgelegt sind? Dir sollte der Inhalt der Konstanten doch bekannt sein, d.h. Du solltest wissen, ob diese gleich sind oder nicht.

Also mir erscheint das doch extrem konstruiert. Und der Punkt:
und stolz wie bolle zu behaupten: "Ha! Das KANN ja gar nicht funktionieren, weil das macht man nicht so" wär' schon ziemlich peinlich, oder?
Das ist doch auch nie die Aussage! Die Aussage ist, dass man etwas auf eine bestimmte Art und Weise macht. Aber das bedeutet nicht, dass Andere Wege (hier das ==) nicht doch (in bestimmten Situationen) funktionieren könnten.

Du kannst extrem miesen Code schreiben. Generell alle Bezeichner sollten eine UID sein! Mit einem zufälligen Buchstaben aus dem Bereich a-zA-Z am Anfang. Also Klasse gfcf174e6200811ebadc10242ac120002 mit Methode U145ae978200911ebadc10242ac120002 und einer Variable P27f9b306200911ebadc10242ac120002.

So Code wie:
Java:
gfcf174e6200811ebadc10242ac120002 P27f9b306200911ebadc10242ac120002 = new gfcf174e6200811ebadc10242ac120002();
P27f9b306200911ebadc10242ac120002.U145ae978200911ebadc10242ac120002();
funktioniert!

Aber ich denke, dass Du einer Regel, dass man das so nicht machen sollte, durchaus zustimmen wirst, oder?
 
K

kneitzel

Gast
Und warum gibt es gegen diese Regel so einen Widerstand?
- Es gibt sehr viele Fälle, wo die Missachtung zu Problemen führt (Siehe z.B. den eigentlichen Thread, in dem dieser dann ja abgespalten wurde).
- Es gibt bisher kein Beispiel, bei dem eine Nichtbefolgung anzuraten wäre oder wo die Befolgung gar zu Problemen führen würde...

Es werden regelmäßig andere Regeln aufgestellt (auch hier im Forum), die komplett willkürlich sind und für die es keinen Grund gibt:
- Klassen starten mit einem Großbuchstaben.
- Methoden mit einem kleinen Buchstaben.
- Variablen (incl. Parameter) starten mit einem kleinen Buchstaben.
- ...

Komplett willkürlich! Und bei privaten Instanz- und Klassenvariablen sogar kontraproduktiv!
In C# / .Net starten Methoden auch mit einem großen Buchstaben. Also es geht anders - meine Java Programme funktionierten nach dem Umstieg auch problemlos, selbst wenn ich das mal "falsch" gemacht habe.

So hat Microsoft bezüglich privater Member absolut keine Regeln vorgegeben. (Da gibt es nur Regeln oder besser Empfehlungen für sichtbare Elemente in Libraries.)
Die Variablen in Instanzen / Klassen sind von außen nicht zugänglich, aber es macht Sinn, die z.B. mit einem _ anfangen zu lassen.

Diese Regeln machen es sogar fehleranfällig. Dieses this.something = something; ist blöd. Wenn die Variable vorher nicht so hieß und die Methode / Konstruktor die Zuweisung ohne this. davor hatte, dann macht ein refactoring die Funktionalität kaputt. Habe ich nie verstanden, wieso das so gesehen wird in Java. Ein einfaches _ davor bei den variablen und das Problem ist aus der Welt.(Aber man hat ja Workarounds - Parameter sind bei mir immer final - dann schimpft im genannten Fall der Compiler.)

Aber: Diese Regeln werden akzeptiert. Wir schreiben, wie es sein sollte. Ohne Aufschrei! Da kann man extrem viel diskutieren zumal man Probleme finden und aufzeigen kann! (Wobei das ja auch nur Empfehlungen sind. Was anderes können wir ja nicht machen. Regeln ziehen Konsequenzen von Seiten einer Autorität bei Nichtbefolgen nach sich. Das haben wir ja nicht ...)
 

White_Fox

Top Contributor
Und warum gibt es gegen diese Regel so einen Widerstand?
Also, zumindest ich leiste keinen Widerstand gegen diese Regel. Ich leiste Widerstand gegen Regeln allgemein, weil ich Regeln allgemein als schlechtes Entwicklerdenken betrachte.


Es werden regelmäßig andere Regeln aufgestellt (auch hier im Forum), die komplett willkürlich sind und für die es keinen Grund gibt:
- Klassen starten mit einem Großbuchstaben.
- Methoden mit einem kleinen Buchstaben.
- Variablen (incl. Parameter) starten mit einem kleinen Buchstaben.
Naja, ich würde es Konvention und nicht Regel nennen. Auf Konventionen einigt man sich, Regeln werden aufgestellt.
Und diese Konventionen haben ja allgemein auch einen Sinn, nämlich den Quellcode besser lesbar zu machen - dafür sind sie hilfreich, deshalb werden sie von den meisten Entwicklern auch übernommen.


Die Variablen in Instanzen / Klassen sind von außen nicht zugänglich, aber es macht Sinn, die z.B. mit einem _ anfangen zu lassen.
Das hingegen würde mir z.B. gar nicht schmecken, diese Abartigkeit ist in C häufig verbreitet. Variablennamen mit _ beginnen kommen da auch hin und wieder vor, aber vor allem macht man das bei Makros. Manches fängt da mit _ an, aber manches auch mit __, und ich finde daß man zuverlässig erkennen können sollte wann ein Zeichen zu Ende ist. Das ist ähnlicher Käse wie der Tabulator als Blocktrenner in Python.
 

mrBrown

Super-Moderator
Mitarbeiter
Wenn ich dahinter komme wieso "abc" == "abc" true zurückgibt, komme ich auch dahinter dass Strings problematisch für den Speicher sein können, [...]
... und dann kommt man darauf, dass man alle Strings besser intern'en sollte, und landet dann bei schlechterer Laufzeit und mehr Speicherverbrauch, hat also wieder nur Negatives erreicht.

Konstanten vielleicht? Enums gab es nicht von Anfang an und wenn jemand Softwareentwicklung professionell machen will wird er früher oder später damit konfrontiert werden. Sich dann hinzustellen und stolz wie bolle zu behaupten: "Ha! Das KANN ja gar nicht funktionieren, weil das macht man nicht so" wär' schon ziemlich peinlich, oder?
Sich aber dann nicht hinzustellen und das als sehr schlechten Code aufzuzeigen, ist noch peinlicher ;)

Völlig egal wie altgedient der Entwickler ist und wie legacy der Code ist – in Code aus diesem Jahrtausend sollte sowas einfach nicht mehr vorkommen. Gibt ja auch genug Fälle, in denen es dann plötzlich nicht mehr funktioniert, weil der Wert aus einer Datei geladen muss oder aus sonstwas für Gründe. Es gibt und gab nie auch nur ein Argument, warum man es machen sollte.
 

DrPils

Bekanntes Mitglied
.. und dann kommt man darauf, dass man alle Strings besser intern'en sollte, und landet dann bei schlechterer Laufzeit und mehr Speicherverbrauch, hat also wieder nur Negatives erreicht.
Also Wissen nur isoliert vermitteln. Weil ich sonst auf falsche Ideen kommen könnte?

Ich kam nicht auf die Idee. Aber wenn hätte ich mir mit Sicherheit Gedanken drüber gemacht, recherchiert und im Zweifel hier nachgefragt und wäre dank eurer Hilfe nochmal bisschen klüger geworden.
 
B

BestGoalkeeper

Gast
Das String Pooling/Interning wird zwar immer besser, es kann jedoch ein falsches Verfahren, nämlich nicht auf zeichenorientierte Gleichheit zu prüfen, nicht ersetzen...

Insofern hat das Gros meiner Vorredner recht, Strings vergleicht man mit equals() - und nicht mit ==. ;)
 
K

kneitzel

Gast
Also Wissen nur isoliert vermitteln. Weil ich sonst auf falsche Ideen kommen könnte?

Ich kam nicht auf die Idee. Aber wenn hätte ich mir mit Sicherheit Gedanken drüber gemacht, recherchiert und im Zweifel hier nachgefragt und wäre dank eurer Hilfe nochmal bisschen klüger geworden.
Es ist ja toll, dass es Leute gibt, die auch an Hintergründen und ähnliches interessiert sind. Aber das ändert nichts daran, dass man gerade Anfänger mit Informationen nicht zuschmeißen sollte, die diese doch in der Regel nicht interessieren und die auch nicht hilfreich sind. Jemand der Java lernen will und gerade dabei ist, Kontrollstrukturen zu begreifen, der muss nicht lernen, was intern() bei Strings bedeutet oder so. Wo hören wir denn sonst auf? Da kann ich dann noch die ganze Spezifikation der VM bringen? Wo ziehst Du eine Grenze?


Also, zumindest ich leiste keinen Widerstand gegen diese Regel. Ich leiste Widerstand gegen Regeln allgemein, weil ich Regeln allgemein als schlechtes Entwicklerdenken betrachte.
Also das ist einfach ein Wording vermute ich, aber gerade einen guten Entwickler zeichnet es aus, dass er Regeln befolgt. Clean Code ist einfach eine Sammlung von Regeln. Schau dir doch alles einmal an. DRY: Don't Repeat Yourself -> Klare Regel! So kannst Du vieles durchgehen und du wirst auf ganz viele Regeln stoßen!

Und ohne Regeln geht es doch nicht. Alles basiert auf Regeln! Die Java Sprache ist einfach nur eine ganze Menge an "Regeln", die willkürlich festgelegt wurden und in Spezifikationen nieder geschrieben wurden. Da stecken Regeln drin! Und wenn Du die nicht befolgst, dann schimpft der Compiler.

Oder wenn Du gewisse Tools nutzt: Da hast Du dann Regeln und wenn Du die nicht befolgst, dann schimpft die Code Analyse mit dir!
Und wenn Du Regeln nicht einhältst, dann lassen Dich Tools noch nicht einmal einchecken!

Du findest das ständig und überall. Warum dagegen auflehnen? Regeln machen Sinn. Man muss Regeln diskutieren. Man legt die fest. Aber dann hat man sich dran zu halten und das ist gut so. Und das führt unter dem Strich (meistens) zu besserem Code.

Und Pattern sind auch nur eine Art Regel. Wie baue ich dieses oder jenes? Das sind auch eine Form von Regeln!

Also Regeln allgemein abzulehnen halte ich für sehr kurz gedacht. Du magst ablehnen, dass Regeln immer einzuhalten sind. Das steht aber auch nicht zur Diskussion. Da waren wir immer offen und haben doch gefragt: Wo passt es nicht? Wo siehst Du Ausnahmen? Aber Ausnahmen sprechen nicht gegen Regeln, so die Regeln etwas gut steuern.

Das ist meine Sichtweise. Und ich habe etwas Probleme, euch zu verstehen. Sorry, ich will nicht sagen, dass ihr Unrecht habt, aber im Augenblick sehe ich nicht wirklich eure Position incl. der Argumente dafür (und damit die Argumente gegen diese Regel oder Regeln allgemein).
 

LimDul

Top Contributor
Also, zumindest ich leiste keinen Widerstand gegen diese Regel. Ich leiste Widerstand gegen Regeln allgemein, weil ich Regeln allgemein als schlechtes Entwicklerdenken betrachte.



Naja, ich würde es Konvention und nicht Regel nennen. Auf Konventionen einigt man sich, Regeln werden aufgestellt.
Und diese Konventionen haben ja allgemein auch einen Sinn, nämlich den Quellcode besser lesbar zu machen - dafür sind sie hilfreich, deshalb werden sie von den meisten Entwicklern auch übernommen.



Das hingegen würde mir z.B. gar nicht schmecken, diese Abartigkeit ist in C häufig verbreitet. Variablennamen mit _ beginnen kommen da auch hin und wieder vor, aber vor allem macht man das bei Makros. Manches fängt da mit _ an, aber manches auch mit __, und ich finde daß man zuverlässig erkennen können sollte wann ein Zeichen zu Ende ist. Das ist ähnlicher Käse wie der Tabulator als Blocktrenner in Python.
Ich glaube wir sind da gar nicht so weit auseinander. Ob ich es Regel, Konvention oder Best Practice nenne, ist mir erst mal egal. (Bei Strings würde in dem Kontext tatsächlich von Regel sprechen, weil ich immer noch kein Beispiel sehe wo es anders sinnvoll ist).

In einer idealen Welt würde ich tatsächlich auch sagen
* Man sollte es auch so machen
* Es gibt Fälle wie z.B. diesen hier, wo man es aber auch so machen kann
* Aber das sollte eine begründete Ausnahme sein

Problem: Diese ideale Welt gibt es nicht. Entwickler sind unterschiedlich kompetent, bzw. auch auf unterschiedlichen Leveln. Und insbesondere im Lernprozess (Egal ob Studium, Ausbildung, Weiterbildung, Selbst-Studium) ist die Kapazität Dinge wirklich vollständig zu begreifen beschränkt.

Daher sollte das Ziel sein, dass Wissen so zu vermitteln, dass der Empfänger am meisten davon hat. Sprich das in dem Kontext am Ende Programme mit möglichst wenig Fehlern rauskommen. Und da ist es nach meiner Erfahrung oft sinnvoller Dinge erstmal relativ dogmatisch darzustellen in der Form "Man macht es so.". Zwar sollte man immer erwähnen, dass es auch andere Möglichkeiten gibt, aber dabei bin ich Befürworter davon "die sollte man aber normalerweise nicht nutzen. Wenn doch sprechen wir noch mal drüber". Je besser ich den Empfänger einschätzen kann um so weiter mache ich dieses Fass auf.

Aber mir ist lieber - vor allen bei Anfängern - die bekommen lieber 20 Leitplanken, an die sie sich halten, anstelle 5 Beispiele mit 15 Ausnahmen. Denn zum einen (Kapazität ist begrenzt) fehlen dann andere Dinge, weil man auf die 5 Fälle ausführlicher eingegangen ist und zum anderen werden insbesondere Anfänger diese Ausnahmen an Stellen nutzen wo sie schlicht nicht sinnvoll oder gar falsch sind.
 

LimDul

Top Contributor
Bezüglich Regeln fällt mir ein Punkt ein.

Regeln sind genau dann schlecht wenn sie als Selbstzweck da stehen. Sprich, wenn die Erklärung für "Warum muss ich es so machen" ist "Weil die Regel es sagt" und auf Nachfrage "Wofür dient die Regel" die Antwort kommt "Keine Ahnung, ist halt eine Regel". Dann wird es problematisch.

Regeln sind nicht zum Selbstzweck da, sondern sollen etwas sicherstellen. SonarQube z.B. hat bei jeder Regel "Why is this a problem" als Erklärung da stehen. Und sowas halte ich für essentiell, dass man nachlesen kann, was die Regel eigentlich absichert. Denn dann habe ich auch die Möglichkeit (so denn mich die Tools lassen dagegen zu verstoßen, wenn ich feststelle "Ok, die Regel ist Sinnvoll. aber in meinem konkreten Fall muss ich aus Grund X und Y dagegen verstoßen, wenn ich es Regelkonform bauen würde, würden dafür folgende Nachteile auftreten die gravierender als dieser Regelverstoss sind".
 

Panda9296

Bekanntes Mitglied
also in den Büchern die ich durch gearbeitet habe, wurden der Pool im Kapitel 2 gleich nach den Strings erklärt. Nochmal diese Diskussion ist wesentlich sinnloser ob das Sinn macht oder nicht ^^...
 

mrBrown

Super-Moderator
Mitarbeiter
Also Wissen nur isoliert vermitteln. Weil ich sonst auf falsche Ideen kommen könnte?

Ich kam nicht auf die Idee. Aber wenn hätte ich mir mit Sicherheit Gedanken drüber gemacht, recherchiert und im Zweifel hier nachgefragt und wäre dank eurer Hilfe nochmal bisschen klüger geworden.
Nein, natürlich alles vermitteln – aber nicht alles muss man direkt einem, der grad anfängt mit Java und noch nicht über String-Vergleiche hinaus ist, erklären. Es gibt einen Haufen Wissen, der deutlich wichtiger ist.

Der String Pool ist für 99% der Entwickler ohne jegliche Praxisrelevanz, damit kommt man in der "echten Welt" quasi nie in Berührung. Nahezu jedes Mal, wenn der relevant sein könnte, macht man grad Unsinn, den man besser sein lässt.


also in den Büchern die ich durch gearbeitet habe, wurden der Pool im Kapitel 2 gleich nach den Strings erklärt.
Das war doch auch Vorbereitung auf irgendeine Oracle-Prüfung?

Ich hab grad nur in "Java ist auch eine Insel" gesucht, zu "Constant Pool" & "String Pool" gab's zumindest keinen Treffer.


Das String Pooling/Interning wird zwar immer besser
Eigentlich dürfte das seit zig Jahren völlig gleich bleibend sein. Was sich geändert hat sind Optimierung des GCs, die machen aber was anderes.
 

White_Fox

Top Contributor
Und ohne Regeln geht es doch nicht. Alles basiert auf Regeln! Die Java Sprache ist einfach nur eine ganze Menge an "Regeln", die willkürlich festgelegt wurden und in Spezifikationen nieder geschrieben wurden. Da stecken Regeln drin! Und wenn Du die nicht befolgst, dann schimpft der Compiler.

[..]

Na kneitzel, ich glaube da übergeneralisierst du meine Aussage etwas. Auf die Regeln nach denen mir der Compiler meinen Code um die Ohren haut, habe ich als Javaanwender keinen Einfluß - das ist in diesem Kontext ein Sachzwang.
Aber @LimDul hat das sehr schön herausgearbeitet, was ich meinte - Danke. Das erspart mir weitere Erklärungen. Nur dieses eine noch:


Aber mir ist lieber - vor allen bei Anfängern - die bekommen lieber 20 Leitplanken, an die sie sich halten, anstelle 5 Beispiele mit 15 Ausnahmen. Denn zum einen (Kapazität ist begrenzt) fehlen dann andere Dinge, weil man auf die 5 Fälle ausführlicher eingegangen ist und zum anderen werden insbesondere Anfänger diese Ausnahmen an Stellen nutzen wo sie schlicht nicht sinnvoll oder gar falsch sind.

Vielleicht ticke ich an dieser Stelle einfach anders: Ich würde lieber die fünf Beispiele mit den 15 Ausnahmen nehmen unter der Vorraussetzung, die dahinterstehenden Umstände -- ich nenne es hier mal Gesetzmäßigkeiten -- mitgeliefert zu bekommen, und spare mir dafür die 20 Leitplanken.

Ich war im Auswendiglernen schon immer hundsmiserabel, das Verstehen des Warums ging mir dagegen immer leichter von der Hand. Erfahrungsgemäß stecken hinter den fünf Beispielen und 15 Ausnahmen vielleicht drei Gesetzmäßigkeiten, das lernt sich fix.

Und wie ich bereits sagte: Ich finde nicht, daß das Thema Objektidentität so schwer ist, alsdaß man dem Anfänger die Regel mitgeben muß. Lieber sollte man das Vergleichen von Objekten erstmal komplett aussparen und sich auf primitive Datentypen beschränken, wenn man Kontrollstrukturen lehren will und der Brocken zu groß wird.
 

mihe7

Top Contributor
Ich verstehe das Problem hier nicht: ein String ist ein Objekt wie jedes andere. Natürlich kann man auf Identität prüfen, natürlich gibt es Fälle, wo das sinnvoll sein kann und zwar der Performance wegen (man spart sich einen Methodenaufruf, da in equals per Best Practise sowieso auf Identität geprüft wird). In der absolut überwiegenden Mehrheit der Fälle möchte ich aber nicht wissen, ob zwei gegebene Objekte identisch sind, sondern ob sie gleich sind.
 

Panda9296

Bekanntes Mitglied
Nein, natürlich alles vermitteln – aber nicht alles muss man direkt einem, der grad anfängt mit Java und noch nicht über String-Vergleiche hinaus ist, erklären. Es gibt einen Haufen Wissen, der deutlich wichtiger ist.

Der String Pool ist für 99% der Entwickler ohne jegliche Praxisrelevanz, damit kommt man in der "echten Welt" quasi nie in Berührung. Nahezu jedes Mal, wenn der relevant sein könnte, macht man grad Unsinn, den man besser sein lässt.



Das war doch auch Vorbereitung auf irgendeine Oracle-Prüfung?

Ich hab grad nur in "Java ist auch eine Insel" gesucht, zu "Constant Pool" & "String Pool" gab's zumindest keinen Treffer.



Eigentlich dürfte das seit zig Jahren völlig gleich bleibend sein. Was sich geändert hat sind Optimierung des GCs, die machen aber was anderes.
schau im schrödinger da findest du viele Treffer=)

So am Rande... wollen wir uns nicht alle in einen Raum stellen und dabei einen Knüppel um die Ohren hauen? Geht bestimmt schneller. Sonst sollten wir einen Verlag konsultieren... Vielleicht hat es dann Sinn, diesen Thread fortzusetzen :D
 
Zuletzt bearbeitet:

mrBrown

Super-Moderator
Mitarbeiter
schau im schrödinger da findest du viele Treffer=)
Tatsächlich, da wird erklärt.

Allerdings ist das alles andere als gut, ich schwanke noch zwischen "sehr missverständlich" und "falsch"...


In Java werden Strings, so gut es geht, wiederverwendet. Das ist überhaupt nicht unhygienisch, sondern dient dazu, Speicherplatz zu sparen. Dieses Wiederverwenden funktioniert aber nur für Strings, die ohne Konstruktor angelegt werden. Mit Konstruktor wird immer ein neues Stringobjekt angelegt. Problem: Legst du sehr, sehr oft den gleichen String an, verbraucht dies unnötig Speicher. Besonders übel ist das, wenn du dir zum Beispiel in einer Schleife einen String zusammenbaust und in jeder Schleifeniteration etwas an den String drangehängt wird.

Den Absatz finde ich mindestens missverständlich:

Das "ohne Konstruktor anlegen" gilt ja nicht nur für das direkte Anlegen mit Konstruktoren, sondern jegliche String Erzeugung – außer eben bei Literalen (und konstante Ausdrücken mit diesen) – ist aber nur eine Kleinigkeit.
Viel wesentlicher: das beschriebene Problem hat überhaupt nichts mit String-Pooling zu tun. Alle Strings, die man z.B. dynamisch in einer Schleife erzeugt, haben nichts mit dem String-Pool zu tun.
Das "Problem" ist dort ja einfach nur immutability – die ist zwar Grundvoraussetzung für String Pooling, aber genau diese wird in dem Kapitel kein einziges Mal erwähnt.



Das schwankt auch zwischen missverständlich und Falsch...

Der Wert "Läufer" landet auch schon bei *1 im String Pool, es ist völlig egal was man mit dem Literal macht, das landet auch wenn man das an den Konstruktor von String übergibt im String-Pool.

Und auch die Grafik ist falsch, korrekt sähe das etwa so aus:
Untitled Diagram-3.png

Die eigentlichen Daten des Strings, das char (bzw. byte) -Array, also der "Speicherfresser", liegt dabei nur einmal im Heap. Was doppelt existiert ist nur das String-Objekt, das hat aber eben einen konstanten Overhead, der in den meisten Fällen zu vernachlässigen ist



Und was mich persönlich fast am meisten stört, nachdem Seitenlang über speicherfressende Strings und warum StringBuilder besser sind geredet wurde, kommt sowas:
Java:
String text = "";
for(int i=1; i<=99; i++) {
  text += "Luftballon " + i + "\n";
}

was dann verbessert wird zu:

Java:
StringBuilder textMitStringBuilder = new StringBuilder(1377*1);
for(int i=1; i<=99; i++) {
  textMitStringBuilder.append("Luftballon " + i + "\n");
}

-.-
 

thecain

Top Contributor
Ich finde schon die Wortwahl schrecklich.. "unhygienisch", "beim Recycling mitmachen"...

1377*1... Das mach ich jetzt immer so!

Bei solchen Themen ist, wenn man es Wissen will, mit der JLS am Besten bedient
 

Panda9296

Bekanntes Mitglied
also es war mein erstes Buch... ich muss sagen, der Einstieg war okay und ich kam gut mit. Aber dieses Buch ist von Anfang an Geschmackssache und man muss der Typ dafür sein
 
K

kneitzel

Gast
Aber das mit dem Aneinanderhängen von Strings ist ja nicht wild. Man kann ja in der Schleife direkt den GC aufrufen, um die nicht mehr benötigten Strings gleich los zu werden .... das ist wie beim Kochen: zwischen den Arbeitsschritten immer die Arbeitsplatte sauber wischen!

Sorry, das konnte ich mir jetzt nicht verkneifen. Ist natürlich relativ großer Schwachsinn ... Aber eine Regel für Anfänger, den GC in Ruhe zu lassen, stelle ich jetzt nicht auf :)
 

mrBrown

Super-Moderator
Mitarbeiter
Ich finde schon die Wortwahl schrecklich.. "unhygienisch", "beim Recycling mitmachen"... 1377*1... Das mach ich jetzt immer so!
Naja, über Geschmack kann man bekanntlich nicht streiten ;) Gefällt mir zwar auch nicht gut, aber der "lockere" Stil kommt bei vielen halt auch gut an.

also es war mein erstes Buch... ich muss sagen, der Einstieg war okay und ich kam gut mit.
Ich glaub gerne, dass man damit gut klar kommt und es für den Einstieg auf völlig okay ist.

Nur eben sind manche Themen für den Einstieg völlig ungeeignet – weil zu komplex für Einsteiger und zu schwierig sinnvoll zu erklären.
 
K

kneitzel

Gast
Also der Standard GC bietet das nicht. Aber mess gibt ja diverse Implementationen und man kann zur Not auch einen angepassten GC erstellen...

Macht aber keinen Sinn. Ich wüsste jetzt keinen Grund für sowas...
 
B

BestGoalkeeper

Gast
weil zu komplex für Einsteiger
Und das legst du fest, welches Buch für wen geeignet ist und welches nicht?

Außerdem ist das eine schematische Darstellung und Vereinfachung, die per se nicht falsch ist.

Bei solchen Themen ist, wenn man es Wissen will, mit der JLS am Besten bedient
Dort aber oft nicht ausreichend erklärt, weil es für den Programmierer unerheblich ist ob ein String interned ist oder nicht weil man Strings mit equals() vergleicht...

Ich würde hier https://en.wikipedia.org/wiki/String_interning und hier https://stackoverflow.com/questions/10578984/what-is-java-string-interning und hier https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html#jvms-5.1 ansetzen zu lesen.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
M Warum Strings mit equals vergleichen... Allgemeine Java-Themen 6
M String#equals(), Probleme mit großen Strings? Allgemeine Java-Themen 4
O regulärer Ausdruck zum durchsuchen eines Strings verwenden Allgemeine Java-Themen 2
B HeapSort für Array of Strings funktioniert nur teilweise Allgemeine Java-Themen 3
W JSON parsen eines ,mit JS.stringify erstellten Strings Allgemeine Java-Themen 27
L allgemein Strings händisch in Liste sortieren Allgemeine Java-Themen 47
N MySQL mit Strings Allgemeine Java-Themen 3
T Letztes Zeichen eines Strings enfernen Allgemeine Java-Themen 14
G Objekte mit Strings Aufrufen Allgemeine Java-Themen 8
W Collections Suche Collection, um Strings mit Indizees versehen Allgemeine Java-Themen 47
V Datentypen Graphikrechner 2/Strings und Variablen in Doubles umwandeln Allgemeine Java-Themen 6
LimDul Mittels Streams aus Strings A B C den String A, B und C machen Allgemeine Java-Themen 12
Meeresgott Best Practice Strings auf Inhalte vergleichen Allgemeine Java-Themen 1
N DNA Strings vergleichen Allgemeine Java-Themen 1
Q-bert Strings aus der JList in eine Datenbank speichern Allgemeine Java-Themen 1
K Vergleich von Strings von Objekten Allgemeine Java-Themen 4
J Strings int textdokumente speicher Allgemeine Java-Themen 3
KeVoZ_ Nacheinander folgende Strings in Textdokument auf neue Zeile schreiben Allgemeine Java-Themen 6
K Strings sortieren: 2 Kritieren Allgemeine Java-Themen 5
A Vector Strings in Array splitten Allgemeine Java-Themen 6
B Wie vergleiche ich Strings in einer Liste? Allgemeine Java-Themen 5
T Strings über Bluetooth zwischen PC,µc oder Samrtphone senden und empfangen Allgemeine Java-Themen 0
N Methoden Methoden einer Klasse auf Grundlage eines Strings aufrufen Allgemeine Java-Themen 6
K Bestimmten Bereich eines Strings lesen Allgemeine Java-Themen 6
H RegularExpression zwischen zwei Strings Allgemeine Java-Themen 2
Neumi5694 Operatoren regEx für das Erstellen eines Strings verwenden Allgemeine Java-Themen 3
H Strings vergleichen Allgemeine Java-Themen 9
O Mustererkennung in Strings Allgemeine Java-Themen 4
Y String-Collection: längste gemeinsame Strings / Prefixe Allgemeine Java-Themen 3
F Problem mit Strings Allgemeine Java-Themen 8
D Strings chemisch splitten Allgemeine Java-Themen 3
K Wörter in Strings zählen Allgemeine Java-Themen 7
L Strings nach sortiertem String zurück ordnen Allgemeine Java-Themen 0
L Strings nach gleichem Muster ordnen Allgemeine Java-Themen 4
L Fragen für Facharbeit: Analyse von Strings in Java Allgemeine Java-Themen 4
D Strings vergleichen; Komma ignorieren Allgemeine Java-Themen 3
K Java Operatoren mit Strings darstellen Allgemeine Java-Themen 8
G Strings erzeugen Allgemeine Java-Themen 20
B HTML Tags in Strings umwandeln Allgemeine Java-Themen 4
N Input/Output Vergleich von identischen Strings schlägt fehl Allgemeine Java-Themen 5
U Große Liste von Strings mit indiziertem Zugriff Allgemeine Java-Themen 31
A ,,Textformatierungsbefehle" für strings deaktivieren Allgemeine Java-Themen 8
S Strings vergleichen Allgemeine Java-Themen 11
C Strings in Excel einlesen! Allgemeine Java-Themen 2
S Strings gehen "kaputt" wenn ich in CVS ein und wieder auschecke. Allgemeine Java-Themen 2
X Datentypen Prozentualer Abgleich zwischen 2 Strings (Pattern?) Allgemeine Java-Themen 3
R MD5-Hash eines Strings bestimmen Allgemeine Java-Themen 2
C Strings und JSON Objekte so klein wie möglich im Speicher ablegen Allgemeine Java-Themen 5
J String zerlegen in einzelne Strings Allgemeine Java-Themen 7
F Konstanten mir Strings "verknuepfen" Allgemeine Java-Themen 10
1 zwei Strings vergleichen Allgemeine Java-Themen 16
L Object Instanz anhand eines Strings Allgemeine Java-Themen 10
S vector & strings Allgemeine Java-Themen 26
N Strings mit null wiedergabe Splitten Allgemeine Java-Themen 4
K Strings sortieren (knifflig) Allgemeine Java-Themen 7
P Codierung der strings umändern Allgemeine Java-Themen 10
N Zahlen in Strings einer ArrayList sortieren Allgemeine Java-Themen 14
F 2 Strings zusammenfügen Allgemeine Java-Themen 2
D Strings von HTML befreien Allgemeine Java-Themen 17
S Strings zu Color-Instanzen parsen? Allgemeine Java-Themen 7
C Strings zwischen 2 Zeichen auslesen Allgemeine Java-Themen 7
T Explizite Typkonversation mit Strings Allgemeine Java-Themen 9
R Locale spezifische DateFormat Strings? Allgemeine Java-Themen 3
M Wie kann ich alle System.out Strings in ein log window umleiten? Allgemeine Java-Themen 6
R Java function die Strings escaped, sodass ich sie in Javascript verwenden kann? Allgemeine Java-Themen 4
ruutaiokwu objektreferenz eines strings... Allgemeine Java-Themen 9
data89 [Kurze Frage] Ähnlichkeit zweier Strings ermitteln Allgemeine Java-Themen 19
S bestimmte Strings spliten! Allgemeine Java-Themen 7
Daniel_L Suche nach ganzen Wörtern (wholeword) in Strings? Allgemeine Java-Themen 4
A Strings joinen, Standard-Library? Allgemeine Java-Themen 9
Y Mal wieder vergleichen von Strings.[Leider noch ein Problem] Allgemeine Java-Themen 18
data89 Die Größe eines Strings in Byte berechnen? Allgemeine Java-Themen 12
A Auslesen von Strings aus einer xls-Datei Allgemeine Java-Themen 16
G Spezialfrage zu Strings Allgemeine Java-Themen 11
C Textteile aus Strings extrahieren? Allgemeine Java-Themen 6
J Teile eines Strings ersetzen Allgemeine Java-Themen 2
G schnell Strings vergleichen Allgemeine Java-Themen 4
J Name eines Strings durch einen String festlegbar? Allgemeine Java-Themen 2
G Strings zerlegen und substrings auslesen Allgemeine Java-Themen 2
Z Letztes zeichen eines strings löschen Allgemeine Java-Themen 3
V Speicherplatz eines Strings? Allgemeine Java-Themen 12
H MIDlets und Strings Allgemeine Java-Themen 2
C Pixelanzahl eines Strings ermitteln Allgemeine Java-Themen 12
T Strings darf nur Ziffern, +/- haben Allgemeine Java-Themen 9
A Fehler beim Ersetzen eines Strings Allgemeine Java-Themen 3
G Strings die Zahlen enthalten sinnvoll sortieren (A2 < A10 Allgemeine Java-Themen 4
G byte[] mit Strings füllen Allgemeine Java-Themen 2
H strings in datei verschlüsseln , auslesen mit klartext aber! Allgemeine Java-Themen 2
F Strings in JList ausrichten/links/rechts/mittig Allgemeine Java-Themen 10
H ein Teil des Strings rausfiltern Allgemeine Java-Themen 8
E Viele if Abfragen auf viele Strings --> Alternative zu if Allgemeine Java-Themen 8
C Strings zu groß um damit zu arbeiten Allgemeine Java-Themen 31
V Lib für Strings suchen und ersetzen (erweitert) Allgemeine Java-Themen 3
P Schnelles Auslesen von Strings für Syntaxhighlighting? Allgemeine Java-Themen 2
X Strings aus einer ArrayList zählen Allgemeine Java-Themen 11
C HASH Algorithmus 2 Strings ergeben das Selbe. Allgemeine Java-Themen 2
G Datei zeilenweise in Strings speichern Allgemeine Java-Themen 36
S Methode zum Zählen von Buchstaben in Strings gesucht Allgemeine Java-Themen 11
I vergleich und zählen von Strings Allgemeine Java-Themen 7
V Strings aus externen Dateien Einlesen (Sudoku) Allgemeine Java-Themen 25

Ähnliche Java Themen

Neue Themen


Oben