<div dir="ltr">Just a friendly reminder... still waiting on input regarding the questions below (which were in response to Brian's earlier email).<br><br>Thanks,<br>-Archie<br><div><br>On Mon, Mar 3, 2014 at 2:55 PM, Archie Cobbs <span dir="ltr"><<a href="mailto:archie@dellroad.org" target="_blank">archie@dellroad.org</a>></span> wrote:<br>

<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Brian,<br><br>Thanks for your comments.<div class="">
<br>
<br>On Mon, Mar 3, 2014 at 11:45 AM, Brian Goetz <span dir="ltr"><<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><b>Idea #2: Allow non-this code prior to
          super()/this() call in constructors</b><br>
      <div><blockquote type="cite">
    </blockquote></div>
    This is well-traveled ground; this request has come up, and been
    shot down, many times.  If anything, the language spec is already
    too loose here, allowing too many unsafe operations (e.g., calling
    virtual methods from constructors, allowing constructor to publish
    'this', etc) and this would make this problem dramatically worse.  <br></div></blockquote><div><br></div></div><div>I would like to better understand what you're saying here. I am certainly not interested in changes that would weaken language safety, so I must be misunderstanding something.<br>


<br>When you refer to calling virtual methods and publishing 'this', do you mean prior to superclass constructor invocation? If so how is that possible currently? Because the JVM spec seems to <a href="http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.10.2.4" target="_blank">disallow</a> it..  I'm referring to the sentence "Before that method invokes
                     another instance initialization method of <code>myClass</code>
                     or its direct superclass on <code>this</code>, the only operation the method can
                     perform on <code>this</code> is assigning fields declared
                     within <code>myClass</code>." I take this to mean that for example that you couldn't pass 'this' as a parameter, assign it to a field, invoke a method on it, or do anything else that would allow its uninitialized escape.<br>


<br></div><div>Or, if you meant calling virtual methods and publishing 'this' after super()/this(), then how does this proposal have any relation to those problems? They are on the "other side" of super()/this() line, so to speak, and this proposal would not make them any more permitted than they already are.<br>


</div><br><div>It seems like the JVM spec gets it right - i.e., you can do (mostly) whatever you want prior to super()/this() as long as it doesn't try to make use of an uninitialized 'this', and no uninitialized 'this' can escape. It seems reasonable to want the JLS to more closely mirror this sensible stance.<br>


<br>I must be missing something...<br></div><div class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">

<b>Idea #3: Allow generic type declarations
          wherever normal type declarations are allowed</b><br>
      
    
    Obviously "wherever normal type declarations" is broader than you
    mean.  What you're looking for is the ability to "uncapture" a
    captured variable, giving it a name.  As you've pointed out, generic
    methods already provide you the ability to do that, and what you're
    asking for is do to that 'inline' in a block of code.  My
    recommendation is to try and take this to the next step (a more
    detailed analysis); I think you'll find you'll run into complexity
    at multiple levels.  <br></div></blockquote><div><br></div></div><div>I may not be smart enough to actually reach those multiple levels of complexity... :) Can you give me an example?<br></div><div><br>In case it wasn't already clear... the original simplistic thought was that at any variable declaration where the declared type is generic, you could have the option of piggybacking onto that a generic type variable declaration.<br>


<br></div><div>So any:<br><br></div><div>   <span style="font-family:courier new,monospace">final List<?> x = ...</span><br><br></div><div>could be changed to:<br><br></div><div>  <span style="font-family:courier new,monospace">final <T> List<T> x = ...</span><br>


<br></div><div>and the T would be declared as a bound type variable with the same scope as 'x'.<br><br></div><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


<div bgcolor="#FFFFFF" text="#000000"><b>Idea #5: Allow enum types to have generic type
            parameters</b><br>
        
      
    
    Another frequent suggestion.  I agree it would have been better if
    it were done this way initially, and the cost would have been low. 
    The cost of doing this now in a binary-compatible way would be
    higher.  <br></div></blockquote><div><br></div></div><div>Ah, I didn't realize there was a binary compatibility problem here. What specifically is the problem?<br></div><div> <br></div><div>Thanks,<br>-Archie<span class="HOEnZb"><font color="#888888"><br>

<br></font></span></div><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">-- <br><div dir="ltr">Archie L. Cobbs<br></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Archie L. Cobbs<br></div>
</div></div></div>