Declarative Immutability in Java

[Martijn Verburg]

Hi John,

No problem, I think the JLS summit will be the way to go for sure. It's a
well thought out proposal and it will be good to have the real experts
chime in at the conference where they can focus.

Cheers,
Martijn

On 11 May 2016 at 13:35, John Crowley <jdcrowley at gmail.com> wrote:

> Martin,
>
> Thanks so much for the feedback - that is exactly what I’m looking for at
> this point.
>
> Interspersed detailed comments below.
>
> Best,
>
> *John Crowley*
> Westport, CT
>
>
> On May 11, 2016, at 4:27 AM, Martijn Verburg <martijnverburg at gmail.com>
> wrote:
>
> Hi John,
>
> Interesting stuff. Some quick feedback:
>
> *TLDR:*  I am not a JVM engineer and can't comment properly on the
> validity of this proposal (I don't know what I don't know).  In order for
> this to be discussed with the right people I suggest you submit this to the
> next JVM Language Summit (http://openjdk.java.net/projects/mlvm/
> jvmlangsummit/) in August.  Any proposed change like this need buy in
> from the core JVM team, and the language summit is the first place to
> start socialising this research.
>
>
> JDC: Completely agree. I’ve been looking to get some first-level feedback
> to see if the whole thing makes sense or has a fatal flaw. If nobody finds
> said obvious flaw then will submit as you suggested.
>
>
> *General Advice / Feedback*
>
> It's very clear that you've put a lot of proper thought into this which is
> great!  However to set expectations:
>
> 1.) This proposal is large and very impactful and given that the core JVM
> team has a long roadmap planned already, this may not get a lot of air
> time or attention right now.
>
>
> JDC: Understand, and I’m certainly not trying to jam this into the next
> release. But do want to get the discussion started for the future.
>
>
> 2.) Chances are that the core JVM team has thought deeply about a lot of
> this as well over the years, so don't be surprised if you do get a "Yeah
> we've thought about this and decided not to do it because of X" response
> when they do look at it.
>
>
> JDC: Very possible. That’s exactly what I’m trying to flush out at this
> stage of the game. Something like this may well have been considered in the
> past and problems discovered.
>
>
> 3.) There are some interactions here with the proposed Value Types work as
> well as potentially (Java 9) project Jigsaw security restrictions /
> interactions that you might bump up against.
>
>
> JDC: Will take a look. Haven’t done a deep dive into JDK9 yet, but am
> getting started.
>
>
> 4.) Do you have any of this prototyped?  It's generally a good idea to
> have code 'strawmen' to discuss ideas around.
>
>
> JDC: Just getting started on that. Am initially working (using JDK9) on at
> least being able to parse the syntax. Again, before putting in a ton of
> work I’d like some expert\s to have a basic "sanity check" - if the
> approach is not workable, would rather find out now than later!
>
>
> 5.) Tag's seem to be a new construct for the JVM and the language to
> understand, that's a barrier WRT to effort.  Have you thought about an
> pure annotation based approach instead?  There's also going to be a real
> challenge with the concept of adding tags to variable names for the
> compiler.
>
>
> JDC: Understand, that’s why I’m trying to modify the parser to see if at
> least the syntax works. Also, am hoping that the whole thing can be a
> compile-time process and not require any JVM changes at all (it will
> require additions to the compiled class format, but these would be ignored
> by the JVM and used only by the compiler). If JVM changes turn out to be
> required, then the whole level of effort issue skyrockets and also
> introduces runtime performance issues.
>
>
> *Specific Feedback*
>
> 1.) I probably wouldn't use java.util.Date in your first example, as it
> itself is famously mutable and not thread safe.  Java 8 comes with
> immutable date/time APIS, I'd swap to those.
>
>
> JDC: Understand your point and will consider. Used java.util.Date
> partially because it is so flawed that it makes a good example of several
> of the points raised in the proposal.
>
>
> 2.) Java 7 added some 'deeper' cloning via the Objects and Arrays API
> which you might want to look at for some of your early cloning code / and
> problem description
>
>
> JDC: Thanks, was not aware - will take a look.
>
>
> There's more, but I'll stop there as I think the bigger questions need to
> be discussed first.
>
> JDC: Thanks again. As mentioned, at this point I really am looking for a
> "sanity check" whether this is possible (and useful) or has some fatal
> problem - so we can stop wasting time.
>
>
>
> Cheers,
> Martijn
>
> On 11 May 2016 at 01:49, John Crowley <jdcrowley at gmail.com> wrote:
>
>> Hi All,
>>
>> This has bugged me for years as a missing ingredient in Java, and was
>> finally able to reduce it to a concrete proposal.
>>
>> If anyone has interest and bandwidth, would like to have some experts
>> review this and provide a sanity check - is this complete, consistent,
>> useful?
>>
>> Summary from the beginning of the abstract:
>>
>> This note proposes a pervasive mechanism to declare that variables,
>> object instances, and methods are mutable or immutable within a standard
>> object-oriented language.
>>
>> The goal of this research is to make the declaration of mutability an
>> integral part of the type structure of the language. This allows the
>> developer to declare, and the reader (and compiler) to determine, if a
>> variable or object instance is mutable or immutable within a specific
>> context, or is immutable throughout the application.
>>
>>
>> The full document is at -
>> https://drive.google.com/file/d/0B9h3YMINZ271SGo4TXI5TTZCaW8/view?usp=sharing
>> <
>> https://drive.google.com/file/d/0B9h3YMINZ271SGo4TXI5TTZCaW8/view?usp=sharing
>> >.
>>
>> Sorry for the overall length - could only attack this as a mechanism
>> which is pervasive throughout the language.
>>
>> Thanks for any help, and am available for questions or discussion.
>>
>> John Crowley
>> Westport, CT
>>
>>
>>
>>
>>
>>
>
>