String[] items = oldString.split(" ");
String stringToKeep = new String(items[0]);

Will allow the original string to be garbage collected.

Instead, his proposal is merely for the JVM to attempt a more aggressive recovery strategy before dying with an OutOfMemoryError. It’s true that in such a case, one might reasonably expect the JVM to run its garbage collector to try to find some memory that can be freed. But during any “ordinary” run of the garbage collector, there is still plenty of memory available, and so the “last ditch effort” that Andrew describes (looking for some strings to free) would simply not be invoked.

Andrew’s solution seems fairly reasonable. Ask yourself: would you rather that your program immediately die with an OutOfMemoryError, or that the JVM spends some time in a search for additional memory before it gives up? To me, it seems better to win some of the time than to lose all of the time.

Foo,”Baz,Baz”,Qux

> Variables should default to string type too
WTF are you smoking? How about real type inference, rather than picking one type and raising it up above the others?

Modifying the GC to look for the (rare) instances of large strings where only a small substring is kept seems likely to be a performance killer. People already whine about GC languages being slow, making one slower for a rare case doesn’t seem to be a very good tradeoff. Let a few CS grad students work on a fast and efficient mechanism for handling this case in the JVM, and *then* look into adding it in.

@mark - Java isn’t Ruby, nor should it be. The ultimate problem with Ruby and languages like it is that too often the advocates want to turn every other language into a poor copy of their favorite language, so they can smugly point out that everyone else should be using their favorite language.

Take, for example, statement separators. They’re useful, in that they *conveniently* let you wrap long statements across several lines, aiding readability. Newline-terminated statements require compiler magic (confusing to the reader) or continuation characters (ugly), which is fine in small, uncomplicated, or low-use programs.

And as for the elimination of “String”, well, consistency is preferential to conciseness. One of Java’s biggest warts is the package-private scope being “default”, instead of making it a required keyword. Verboseness may not be a virtue, but it’s not always a sin, either.

* * *

I think the idea of making the javadoc more clear is the best approach. I don’t think I would have looked at “String x = reader.readLine().split(pattern)[1];” as a potential memory “leak” — it’s a non-obvious issue. Good catch.

I couldn’t resist

I think ultimately one huge problem with languages like C and similar is that they make simple stuff more complicated than necessary.

Take aside memory manipulation or pointer handling - these can stay complicated, but why not try to find the easiest approach altogether - in general? The requirement for a semicolon is one example - it shouldnt be needed. It adds no meaningful information
to the human coder (unless he wants to use multiple instructions on the same line, but this is not a common cause, because people like readable code)

Java should be a lot shorter. And Variables should default to string type too, without a need to specify “String”.