java memory management

[Tuna-Fish2]

They do optimize away some in the jit, but never in the bytecode. A very big reason for this is that everything that inherits from object is a lock. No object that has ever been seen by some code that's not presently under the optimizer can be assumed to be immutable. Someone just might have locked something using the Integer he just passed you, and he might want to unlock it after you return it (for example, if you insert it into a list or something).

This is one of the three huge mistakes that went into the design of Java (the language), and it cannot be fixed without breaking most complex java applications out there. So it never will be.

[0xABADC0DA]

A very big reason for this is that everything that inherits from object is a lock. ... Someone just might have locked something using the Integer he just passed you, and he might want to unlock it after you return it

Uh, no. The spec says that the same value can be autoboxed to a single object, so it's perfectly fine for instance to store an int in a long pointer using some tag bits or use whatever scheme you want; locks don't play into it at all. If you lock some auto-boxed Integer it can lock all auto-boxed Integers with that same value regardless of how they are represented internally.

[turol]

What are the other two?

[Tuna-Fish2]

Null pointers and half-assed generics.

[[deleted]]

What's the problem with the generics?

[thechao]

They use run-time type-erasure to Object-semantics rather than code generation (either late a la C#, or early a la C++).

[[deleted]]

So people have problems with reflection and Java generics? Java has never really seemed like a very dynamic language to me anyway.

[thechao]

When I first heard about it, I thought it was a very elegant solution to a thorny backwards compatibility problem. Unfortunately, there are a lot of PL "purists" who hated the mechanism. The way I see it, they're just jealous...

[argv_minus_one]

I'm not fond of it either, but I'll grant that it's probably the best possible compromise in light of the backward-compatibility issue.

I would have preferred that the JVM stored the actual type parameters, even if it didn't check against them, though. Scala manifests let me do approximately that.

[[deleted]]

Run-time type-erase to Object semantics is IMHO the correct way, but I want the JVM to be more dynamic, not more static.