JAVA help!!!

Can you be more clear about what you mean with "String routines"?

Do you mean the methods of the String class?

>>296442
Java has no primitive string type, so operations with strings are greatly simplified by using the String and StringBuffer classes.

You should probably get your head round how pointers work in Java first, or you're just going to get more confused. Everything that's not a char, boolean, or a number (byte, short, int, long, float, double) is a pointer to an object, and that includes arrays (which are objects) and strings (which are Strings). Java passes everything by value, including pointers.

If you're looking to do string manipulation, you need to decide if your code is performance-critical or not. If it is, instantiate an appropriately-sized StringBuffer ahead of time, and mutate the contents of the StringBuffer. If it's not (and it's not), then just work with string literals and infix operators like in VB, PHP or JS. The JVM has extremely good GC, and can optimise away almost all of your throwaway Strings.

>>296461
Another tip for OP, I remember in my first ever Java class they asked us to think of Strings as a list of chars

>>296463
They are in C, but not in Java. In Java a char[] would be an array of chars, and a StringBuffer is the object that behaves like a char array.

In Java, Strings are immutable, which means you can't modify them ever. You can't get a pointer to a char inside them, because that would break immutability. The only way to interact with Strings is through their methods, so you can't know and shouldn't care whether there's a char array or a unicorn inside them*.

If you try to do something like

String s = "string";
String l=s;
s = s.toUpperCase();
system.out.print(l);
system.out.print(" - ");
system.out.println(s);

You get "string - STRING", not "STRING - STRING", because toUpperCase() can't modify the String, because nothing can modify a String, so it creates a completely new String and returns it.


* Java strings are actually folded. Because they can never be modified, the JVM is free to deduplicate them by using parts of big strings to make small strings. If I write String s = "string"; String bs = "big string"; String rbs = "really big string", the compiler only puts "really big string" in the string table, and s and bs are stored as pointers into it. If I could modify rbs, I'd also change s and bs, which is one reason why I can't.

to add to what >>296461 said, string in java are immutable, that means if you make any modifications to a string it will actually make a new string with said modifications and let the old one get garbage collected. this is part of the reason why stringbuilder is helpful if you are doing lots of modifications onto a particularly large string (avoiding memory trashing and unnecessary gc cycles). you can read more on the implementation of stringbuilder in its documentation

>>296480
>stringbuilder is helpful if you are doing lots of modifications onto a particularly large string (avoiding memory trashing and unnecessary gc cycles).

Any modern compiler does this for you, so you can concentrate on writing legible code.
http://stackoverflow.com/questions/2971315/string-stringbuffer-and-stringbuilder/2971323#2971323

The rule of thumb is:

"Is this executing millions of times a second?"
Yes --> Use JNI
No --> Use Strings leave the donkey-work to the compiler

There are very few scenarios where performance is so important that you're fucking about with StringBuilders, but performance is not important enough for you to use C through JNI, and it's pretty-much a given that your project isn't one of these scenarios.

>>296497
>Any modern compiler does this for you
for the most part yes, but there are still exceptions (no pun intended)