How come strings are immutable in Java?

How come strings are immutable in Java?

they aren't immutable always.

for instance certain string concatenations in looping constructs are usually "optimized" to StringBuilder's

String is immutable because you don't want people fucking with the value of strings in the various places a string could be passed around in. also because of how Java handles storing strings for memory and performance reasons.

faster something something

>be java
>have two different kinds of strings
>mutable one has to be garbage collected (who knows when that will be)
>gotta make a mutable one to make a non mutable one
>find out it doesn't really matter because processors aren't shit anymore

the state of java

Anything that isn't a primitive type should be immutable honestly.

>complaining about muh garbage collectors in Java

Learn how to actually use java kid.

Because
>Needing mutexs for a threadsafe fizzbuzz

because the type system, ergo the jvm, couldn't work if they were

wut are you on about tard.

if your shit isn't reentrant or mutually exclusive, of course you might run into thread unsafety.

>people keep calling java "portable" and how it runs on every machine
>turns out that's actually just barely true enough to not be a boldfaced lie
If you need something else to be installed on the machine first for your stuff to work, then it's not portable, holy fuck.

Immutability is just better for things that don't have the tendency to mutate often.

You have StringBuilder and more in case you DO want frequent mutations on a String.

Strings should always be immutable. If you want a non-secure language use python and enjoy waiting 5 minutes for it to fizzbuzz to 1 billion.

the only reason C is portable is because a compiler exists for every platform.

even platforms are not interoperable. there always must be some compatibility layer there, the question is how thick do you want your compatibility layer to be?

for java, the runtime is puny in comparison to the actual software written for it. java is for building entire cities of code. C is for building a fast car.

You don't remember what it was like back in the 90s. Java was a breath of fresh air. Everything was proprietary as fuck and nothing was cross compatible. Java applets were the shit.

Thank god for C# though.

so then literally nothing is portable.
wow, brave statement.

Nope. Of course it would still work if Strings were mutable, there are many mutable things in Java.

But it's not a sane default. Sane and faster is immutable. You won't have to actually re-check for a possibly changed string.length or hash, it's just what it is when the String was created. Even if a thousand other objects also have access to it, the immutable stuff is just immutable and done.

You see supposed to use char arrays.

no java is still better than C# because muh freedom

>Thank god for C# though.
Thank god MS didn't succeed with making it popular for anything else other than things closely tied to MS products, indeed.

Java remains open, the JVM has a thriving set of better languages, corporations use that primarily, and it's not all in the hands of MS (or even Oracle, GPL is GPL).

>not all in the hands of Oracle
>OpenJDK is literally same devs and likely the same codebase as nonfree Java

There are like 8 functional alternative JREs even without counting Dalvik and ART, which are obviously powerful platforms on their own and which are now pretty much safe even against US software patent nonsense claims.

Apart from that, Oracle hasn't really rocked the GPL boat at all, and if they did, it's very possible the whole ecosystem would jump ship to RedHat, Google, IBM, a new Java development community or whoever else champions the best fork.

Meanwhile if MS changes anything on .NET or C#, you're fucked. Everyone that matters will go along with it, they're generally reliant on interactions with MS API anyhow. Very few use it for anything else.
Java is a much safer bet & works better on Linux and so on. The ecosystem in general is quite a bit bigger, so you also have more good frameworks to use. And if the syntax gets on your nerves, there are quite many other good JVM languages.

No, I can compile a program for arm on x86 and it won't need a fucking arm-based jvm coming with it

t. 800mb cross-compiling toolchain

to be fair, that's irrelevant though just like java runtime is irrelevant in

Except that binary will not run on all x86 and ARM processors and will require humongous set of toolchains to cross-compile in case you just want to produce all possible binaries in advance (which actually still is annoying as fuck to work with down the line).

Why do so many people hate Java without actually knowing anything about it?

ya ok and what happens when your targeted kernel abi doesn't fucking work on someone else's "arm" machine?

also does this arm machine have a hardware floating point? because some ARMv7Ls don't have HF for instance.

hell take it back a bit with intel x86. not all intel x86 cpu's have the same fucking instruction sets.

then you have endianess to worry about if you're doing "low level stuff" in C which is likely what you'll have to do if you want avoid relying on anything on the system other than the kernel.

but with java, you make thef aggot install it with their package manager, require it as part of the base system and almost all .class and .jars will fucking run with little to no headache. go further and you can make uberjars now and don't even need to worry about classpath all that often; uberjars can even completely remove the need for war's and dealing with servlet container configuration as well.

The MIT licensed .NET Core would like a word with you

also these points because fuck C++ and I fucking hate dealing with timesys.

The relevant thing for the vast majority of THAT ecosystem is that the MS API people develop *against* continue to work. If only the extend, extinguish variant of the proprietary MS .NET supports these important APIs on MSSQL, Office, Windows and so on, everyone who matters will be right back with the proprietary .NET, because that's why they even use it in the first place.

Not that they actually even switched to .NET core yet, it doesn't even support many of these API well at this point on its end.

uint8_t pointers actually.