Reference implementation

Sat Oct 31 11:24:41 PDT 2009

Reinier,

Even if compiler would know and work happily (correctly) with a plethora of language variations 
called "Java" where the same snippet of code would mean different things in different versions, I 
for certain would be very frustrated to work in such an environment (as I'm no computer).

Peter

On Saturday 31 October 2009 03:40:50 Reinier Zwitserloot wrote:
> You keep asserting that 'source' is a major feature update, and I keep
> telling you that you're wrong. I'm forced to keep pointing out that
> 'source' doesn't have a big impact on the size of the JLS.
> 
> the notion of source version isn't part of the JLS spec, but that's
> not a problem. The JLS chapter on the source keyword merely needs to
> explain its format and how it's context sensitive (as it must appear
> at the top of the CU, this is easy). It should probably include a
> footnote on what the source property is generally used for, but it
> doesn't have to.
> 
> There's precedent for this of course: Last time I checked, the javadoc
> tool's documentation isn't part of the JLS, and yet javadoc are things
> that appear in java source files.
> 
> It does not even need to define what a compatible java compiler should
> do in the face of a source keyword. It merely needs to state that a
> compiler MAY fully support them and compile each file accordingly, but
> a compiler may also simply refuse to compile the file if its not a
> version the compiler is aware of. The only added requirement is that a
> java compiler may not compile a source file without at the very least
> emitting a warning if the source property isn't something it can deal
> with.
> 
> Turning to the pragmatic for a moment:
> 
> Either the concept of 'source' is obvious to java programmers (which I
> assert), or, if it isn't, the -source property should be removed from
> javac for being confusing. I've never heard any complaints, so real
> world experience indicates Joe Q. Coder can deal with it.
> 
> Current javacs can already support older versions via the -source
> parameter, so presumably mixing codebases isn't difficult. If for
> whatever reason it actually is, the next version can start out by
> locking down the version the first time it encounters a source
> statement, and aborting with an error if a different one shows up in
> the same compile run. Experience will dictate the future fate of mixed
> compilation: If loads of folks complain about the cool things they
> could do if only mixed compilation works, it's worth investing some
> time in, and if not, then not.  Real world experience beats guesswork
> by language designers every time.
> 
> 
> Complicating migration isn't really a fair argument. Three options:
> 
> 1. v(X+1) is fully backwards compatible anyway. Consider the versions
> aliases then, as far as the compiler is concerned. Or, include a tool
> in the JDK's bin dir that simply updates the version number. By
> definition, this can't cause problems.
> 
> 2. v(X+1) is almost but not entirely fully backwards compatible. By
> definition, then, a new feature has been included that would have been
> a much bigger deal without the source statement, so if we ever get
> here, the source statement has already proved its worth its weight in
> gold. A migrator tool in the JDK bin dir can update a source tree,
> highlighting (or automatically fixing, even) the rare cases where vX
> code is no longer legal (or does something different in) v(X+1) code.
> 
> 3. v(X+1) is not backwards compatible. Presumably v(X+1) is then a
> major update, akin to v1.5 over v1.4, but making _actual_ breaking
> changes has still become a much easier proposal, and a migrator is
> still much easier in this scenario: if a certain code snippet is legal
> in vX  and also legal in vX+1 but has a different meaning, a source
> migrator without source keywords can't tell if a source file is pre-
> or post- change, and thus, if you run it twice on the same file, you'd
> break stuff. That would be bad. The existence of the source keyword
> has made this big change possible, whatever it is, so clearly it is
> again worth it.
> 
> 
> Thus, either (A) the impact is negligible, or (B) it makes possible an
> update that wouldn't have been possible without it.
> 
> Examples of how a source keyword + a migrator would have been useful
> for JDK7:
> 
> Making module a non-context-sensitive keyword would be trivial: The
> updater finds any usage of 'module' as an identifier, and tosses back-
> quotes around them. caveat: Java adds a rule that backquotes indicate
> identifiers, but given that there are other languages on the JVM that
> for example accept something like "+" as a valid identifier, this
> seems like a smart plan anyhow. 'module' as an identifier is pretty
> rare, so even without the backquotes, a migrator can simply tell you
> about them.
> 
> Complaints about 'try' not being an appropriate keyword for ARM would
> be easier: A new keyword could have been added for it instead.
> 
> Concerns about simple vs. complex vs. full-complex would be much less
> urgent: It seems that the cases where they are incompatible are either
> non-existent, or otherwise quite rare, so a migrator can easily
> identify where it happens and manually add explicit generics into the
> diamond operator to fix the problem, without turning someone's source
> into an unrecognizable mess. You yourself quite rightly consider
> future language flexibility an important thing to keep in mind. A
> source keyword is quite a big deal when you take future flexibility
> into consideration.
> 
> 
>   --Reinier Zwitserloot
> 
> On 2009/30/10, at 14:48, Neal Gafter wrote:
> > Howard-
> >
> > Let me recap the conclusions as I recall them.
> >
> > Your parallel with WiFi breaks down; your proposal for a source
> > declaration
> > would be an enormous change to the specification; the change would
> > be a tiny
> > benefit (if any).
> >
> > The parallel with WiFi breaks down because software, by its very
> > nature,
> > evolves.  While wireless devices are generally fixed once
> > manufactured, any
> > given program is likely to undergo extensive changes over its
> > lifetime.  One
> > of the main purposes of changes to the Java language is to make such
> > program
> > evolution easier by providing further facilities for programmers to
> > use.
> > But if a prerequisite to using language features in version 8, for
> > example,
> > requires modifying your source code remove or refactor the use of
> > features
> > that are no longer supported (e.g. wildcards, presuming we come up
> > with an
> > alternative that is migration-compatible), it could become an enormous
> > burden to use any new features in existing code.  One might as well
> > give
> > version 8 a new name (e.g. Scala).
> >
> > It is an enormous change because, by moving the version
> > specification into
> > the realm of the language, the language specification must provide a
> > precise
> > meaning to any given value of the version string.  That means it must
> > incorporate a full specification for all of the supported versions.
> > In
> > addition, it must specify the meaning of programs composed of a
> > mixture of
> > source file versions.  While that kind of specification would be
> > useful
> > today, it is not required as part of the language specification, and
> > it is
> > not provided in the JLS.  I can easily imagine that would double the
> > size of
> > the JLS.  Clearly, that is far outside the scope of project Coin.
> >
> > Finally, the proposal would only be of the smallest benefit.  All of
> > the
> > issues we've been wranging with for each of the proposed language
> > features
> > still has to be addressed.  We still have to consider backward
> > compatibility
> > if we want programmers to be able to use these features *in the
> > context of
> > an existing code base*.  So adding that enormous work item to
> > project coin
> > would not reduce the amount of work for any of the individual
> > features under
> > consideration.
> >
> > In short, a version declaration is neither a silver bullet, nor a
> > solution
> > to any problem we've been struggling with.
> >
> > Cheers,
> > Neal
> >
> > On Fri, Oct 30, 2009 at 2:06 AM, Howard Lovatt
> >
> > <howard.lovatt at iee.org>wrote:
> >> Joe,
> >>
> >> As I recall the discussions on source, for that matter the diamond
> >> operator
> >> re. more extensive type inference, was that the technical
> >> discussion had
> >> not
> >> reached a consensus, but the discussions ended because the outcome
> >> was
> >> decreed (presumable by some process within Sun). Your reply,
> >> "discussed
> >> extensively ...", implies that some form of consensus was reached,
> >> which is
> >> not my recollection.
> >>
> >> You, and many others, have more in-depth knowledge of the compiler
> >> than I
> >> have, undoubtedly. However an in-depth knowledge can be both a
> >> blessing and
> >> a curse. There are many examples were someone with a wider breadth,
> >> but not
> >> so in-depth, knowledge can come up with a solution by bringing
> >> expertise
> >> for
> >> other areas. An example of where versioning is very successful is
> >> WiFi,
> >> over
> >> a short time scale we have gone from 802.11a to n. The letters are
> >> the
> >> version numbers, the protocols are different, but the hardware can
> >> run
> >> multiple versions because much of the infrastructure is common (RF
> >> amplifiers, aerials, etc.). Can you not see the parallels: different
> >> versions a to n (Java source versions) and the same underlying
> >> hardware
> >> (the
> >> JVM)? The committees that specify WiFi have the same issues: a formal
> >> specification, mass deployment, multiple vendors, etc., and the
> >> solution
> >> that has proven to work well is versioning.
> >>
> >> Taking ideas from others and other domains is well established in
> >> science
> >> in
> >> general, e.g. Isaac Newton, in 1676 said, "If I have seen a little
> >> further
> >> it is by standing on the shoulders of Giants." Perhaps you could
> >> consider
> >> standing on the shoulders of the WiFi giants.
> >>
> >> -- Howard.
> >>
> >> 2009/10/29 Joseph D. Darcy <Joe.Darcy at sun.com>
> >>
> >>> No Howard, your source statement was discussed extensively on this
> >>> list
> >>> (see the archives) and it is not a silver bullet and is not going
> >>> to be
> >>
> >> part
> >>
> >>> of JDK 7, no matter how many times you bring it up or in how many
> >>> venues.
> >>>
> >>> -Joe
> >>>
> >>> Howard Lovatt wrote:
> >>>> Wouldn't it be simpler to introduce a source statement in Coin,
> >>>> forget
> >>
> >> the
> >>
> >>>> diamond operator, and get 7 out. Having introduced source, 8 can be
> >>>> incompatible with previous Java versions (except at the JVM level),
> >>>> wildcards dropped, generics reified, and type inference for
> >>>> methods and
> >>>> declarations improved.
> >>>>
> >>>> -- Howard.
> >>>>
> >>>> ---------- Forwarded message ----------
> >>>> From: Maurizio Cimadamore <Maurizio.Cimadamore at Sun.COM>
> >>>> To: Reinier Zwitserloot <reinier at zwitserloot.com>
> >>>> Date: Thu, 29 Oct 2009 15:13:21 +0000
> >>>> Subject: Re: Reference implementation
> >>>>
> >>>> Reinier Zwitserloot wrote:
> >>>>> Actually, those 3 examples don't seem too bad for future
> >>>>> expansion.
> >>
> >> Sure,
> >>
> >>>>> reification is a hard nut to crack, but it always has been.
> >>>>
> >>>> Just to clarify - I said that these 3 decisions have made
> >>>> reification
> >>>> *nearly* impossible - not impossible at all. I guess that the
> >>>> length of
> >>>> your
> >>>> proposal for dealing with cast speak for itself (if we need to
> >>>> kinda
> >>>> workaround to the fact that now it's possible to write generic
> >>>> cast even
> >>>> without reification support that means that the decision does
> >>>> jeopardize
> >>>> further language evolution - e.g it prevents reified Java from
> >>>> using
> >>>> classic
> >>>> syntax for casts - note that this problem does not occur with
> >>>> instanceof).
> >>>>
> >>>> As far as my other two issues - I'm not concerned about typing and
> >>
> >> safety
> >>
> >>>> -
> >>>> what I'm concerned about is performances - if you have instances of
> >>>> Foo<#1>
> >>>> or Foo<#1 extends Object & Comparable<? extends Object &
> >>>> Comparable <
> >>
> >> ...
> >>
> >>>>> are you sure that the VM could still perform decently? The Java
> >>
> >> subtyping
> >>
> >>>> algorithm with generics and wildcards is complex enough that it
> >>>> suffices
> >>
> >> a
> >>
> >>>> bit of twists and turns to make javac to run out of Stack (even
> >>>> in cases
> >>>> where subtyping can be proved). What does that mean to have such a
> >>>> subtyping
> >>>> test inside the JVM ? That's what I'm worried about.
> >>>>
> >>>> Maurizio
> >>>
> >>> ______________________________________________________________________
> >>> This email has been scanned by the MessageLabs Email Security
> >>> System.
> >>> For more information please visit
> >>
> >> http://www.messagelabs.com/email________________________________________
> >>______________________________
> >>
> >>
> >>
> >>
> >> --
> >> -- Howard.
> 