Reference implementation

Sat Oct 31 12:43:44 PDT 2009

Peter: And yet you use java every day, where this happens all the time. Just
6 months ago I was hacking around on some pre-generics code, for example.
Your argument is spanning the cart in front of the horse: "Language
evolution is complex, so if we close our eyes and stick our fingers in our
ears, maybe it'll go away!" - language evolution is there. Yes, it's
complicated, but we have to deal with it. A source statement helps up deal
with it a little better. Yes, it also makes the concept more _visible_, but
it's always been there. The fact that the JLS ignores the concept of
evolution is a BAD thing, not a good thing.

Neal: as I mentioned, the source statement may not have any effect, other
than generating a warning or 'not compatible with this version' error. For
the smarter compilers that know how to deal with it, it's the compiler that
decides to use a different version of the JLS when compiling the source file
- not a dictate written in the JLS. I don't understand why you see such an
enormous difference between "javac -source 1.4 MyFile.java" and "javac
MyFile.java" with a "source 1.4;" at the top of the file - it's a small
semantic difference that is useful all around. Getting hung up on some
theoretical purity-of-the-spec argument seems rather silly, given that
pragmatically speaking there's no problem whatsoever. Lots and lots of
languages allow you to change compiler flags via magic comments. This is
just that, except without using "//" syntax.

--Reinier Zwitserloot

On Sat, Oct 31, 2009 at 6:24 PM, Peter Levart <peter.levart at gmail.com>wrote:

> 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.
> >
>