What happened to the "mutable struct" debate?

[Vitaly Davidovich]

So let me say that I'm one of the people that would like to see mutable
value types *offered*, not encouraged or promoted for general use cases.

Also, ints aren't mutable :) Variables holding the int are (e.g. locals,
fields), but not ints themselves.

If Brian & co could somehow be swayed to add them, I suspect this would
drag in the requirement that you should be able to pass them by reference.
Without that, they're of marginal utility since you can't avoid copying
costs.  Passing things by reference would be yet another entirely new
concept to java, and given some of the sentiment I've read on this list
thus far, this would comatose some people.

I'm with you in terms of being annoyed with having to manually unroll data
structures/abstractions to get performance.  I'll still take immutable
value types with a welcome sign, but alas, the mutable aspect doesn't seem
promising.

P.S. this is the first I hear of anyone moving away from java to C# or Go
in this space (Go, in particular, has its own problems with a subpar GC as
far as I know).  Do share.

sent from my phone
On Jan 22, 2015 10:32 PM, "Andrew Purtell" <apurtell at apache.org> wrote:

> I've also recently arrived here. This would seem to be a fairly important
> writeup left wanting.
>
> Our mantra is “codes like a class, works like an int.”
>
>
> Stating the obvious, from a newcomer's perspective, ints are mutable.
>
> In my part of the Java universe, we are under pressure because data volume,
> response latency requirements, and arrival rates are too high for copying
> the bulk of data (in GC or working with immutable data structures). This
> class of problem is encompassing more and more of the so-called big data
> space as time goes on, and the best available existing strategies for a
> Java application is a resort to kludgy custom representations with
> primitive arrays or "structs" stored off-heap (with use of Unsafe for
> allocation and direct access). Java cannot provide object-like views over
> data that is simply too bulky for copying around. The impedance mismatch
> suggests consideration of alternatives. Some in the space are abandoning
> Java for alternatives like C++, C#, and Go. Maybe I fundamentally
> misunderstand the intent and usefulness of value types and they cannot be
> an answer for this, but more information available in this regard would be
> very helpful, especially if there is another option. I think increasingly
> the assumption is Java will concede the space of big data applications to
> other languages.
>
>
> On Thu, Jan 22, 2015 at 2:36 PM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
> > Hi Moh!  Good to have you here.
> >
> > The sad answer is: we've got a long list of "road not taken" items for
> > which we intend to write up our thoughts on why those roads were not
> > taken.  As you can imagine, though, such writeups compete for time with
> > many other activities, and so they often lag behind...
> >
> >
> >
> > On 1/22/2015 5:30 PM, Rezaei, Mohammad A. wrote:
> >
> >> I recently joined the list and I can't find any references to the
> >> justification behind restricting value types to final fields (aka
> >> immutable).
> >> As Brian says (
> http://mail.openjdk.java.net/pipermail/valhalla-dev/2015-
> >> January/000734.html), "There are some people who would prefer something
> >> more like mutable structs" and yet, the value types proposal (
> >> http://cr.openjdk.java.net/~jrose/values/values-0.html) takes
> >> immutability as a given.
> >>
> >> Is the issue considered settled? Is the justification documented?
> >>
> >> Thanks
> >> Moh
> >>
> >>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>