How come strings are immutable in Java?
>>62209370
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
>>62209370
Anything that isn't a primitive type should be immutable honestly.
>>62209433
>complaining about muh garbage collectors in Java
Learn how to actually use java kid.
>>62209370
Because
>Needing mutexs for a threadsafe fizzbuzz
>>62209370
because the type system, ergo the jvm, couldn't work if they were
>>62209472
wut are you on about tard.
if your shit isn't reentrant or mutually exclusive, of course you might run into thread unsafety.
>>62209370
>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.
>>62209370
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.
>>62209512
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.
>>62209512
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.
>>62209512
so then literally nothing is portable.
wow, brave statement.
>>62209477
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.
>>62209370
You see supposed to use char arrays.
>>62209544
no java is still better than C# because muh freedom
>>62209544
>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).
>>62209586
>not all in the hands of Oracle
>OpenJDK is literally same devs and likely the same codebase as nonfree Java
>>62209610
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.
>>62209550
No, I can compile a program for arm on x86 and it won't need a fucking arm-based jvm coming with it
>>62209729
t. 800mb cross-compiling toolchain
>>62209775
to be fair, that's irrelevant though just like java runtime is irrelevant in >>62209541
>>62209729
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?
>>62209729
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.
>>62209718
The MIT licensed .NET Core would like a word with you
>>62209718
>>62209775
>>62209793
also these points because fuck C++ and I fucking hate dealing with timesys.
>>62209875
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.
>>62209563
uint8_t pointers actually.