----- Original Message ----- > Hi Andrew, > > On 15.12.2014 18:40, Andrew Hughes wrote: > > The main thing that concerns me is the loss of the original author > > information, but I'm not sure if we have a solution for this as yet. > > I tend to go with the original author as the changeset author > > (hg commit --user <username>) but that also has the downside of > > not crediting the backporter. > > > > I guess both it and the original reviewer could be looked up via > > the changeset in 7, which is: > > > > 6938454: Unable to determine generic type in program that compiles under > > Java 6 > > Summary: a redundant dubtyping check causes spurious inference failure > > Reviewed-by: jjg > > > > I think that's meant to be 'subtyping' ;) > > As we discussed some time ago, for backports we could add a new > commit message header like "Authored-by: <original fix author>", > but it likely requires jcheck modification and updating official > rules.
Yes, I remember this discussion. I was hoping someone might be able to provide feedback on any progress on getting this supported in jcheck, as I've not heard of it being added. > > > I hadn't realised this. Is there a reason the following hunks are absent? > > > > diff -r ed354a00f76b -r 36c4ec4525b4 > > src/share/classes/com/sun/tools/javac/comp/Attr.java > > --- a/src/share/classes/com/sun/tools/javac/comp/Attr.java Tue Jul 27 > > 11:52:11 2010 -0700 > > +++ b/src/share/classes/com/sun/tools/javac/comp/Attr.java Thu Jul 29 > > 15:56:25 2010 +0100 > > @@ -1694,8 +1694,22 @@ > > //if the type of the instance creation expression is an > > interface > > //skip the method resolution step (JLS 15.12.2.7). The type > > to be > > //inferred is of the kind <X1,X2, ... Xn>C<X1,X2, ... Xn> > > - clazztype = new ForAll(clazztype.tsym.type.allparams(), > > - clazztype.tsym.type); > > + clazztype = new ForAll(clazztype.tsym.type.allparams(), > > clazztype.tsym.type) { > > + @Override > > + public List<Type> getConstraints(TypeVar tv, > > ConstraintKind ck) { > > + switch (ck) { > > + case EXTENDS: return types.getBounds(tv); > > + default: return List.nil(); > > + } > > + } > > + @Override > > + public Type inst(List<Type> inferred, Types types) throws > > Infer.NoInstanceException { > > + // check that inferred bounds conform to their bounds > > + infer.checkWithinBounds(tvars, > > + types.subst(tvars, tvars, inferred), > > Warner.noWarnings); > > + return super.inst(inferred, types); > > + } > > + }; > > } else { > > //if the type of the instance creation expression is a class > > type > > //apply method resolution inference (JLS 15.12.2.7). The > > return type > > > > diff -r ed354a00f76b -r 36c4ec4525b4 > > src/share/classes/com/sun/tools/javac/comp/Infer.java > > --- a/src/share/classes/com/sun/tools/javac/comp/Infer.java Tue Jul 27 > > 11:52:11 2010 -0700 > > +++ b/src/share/classes/com/sun/tools/javac/comp/Infer.java Thu Jul 29 > > 15:56:25 2010 +0100 > > @@ -458,7 +457,7 @@ > > > > /** check that type parameters are within their bounds. > > */ > > - private void checkWithinBounds(List<Type> tvars, > > + void checkWithinBounds(List<Type> tvars, > > List<Type> arguments, > > Warner warn) > > throws InvalidInstanceException { > > These parts of the original fix were excluded because they are > related to diamond ("<>") operator support, which appeared in > Java 7 and is not a part of Java 6. > Ah, ok. > > Do the new tests added by the change pass? > > Yes, I checked newly added testcases, and also all existing > javac jtreg tests (langtools/test/tools/javac) - all of them passed. > Ok, this looks good to go. > Thanks, > Nikolay > > > > >> Thanks, > >> > >> Ivan > >> > >> 6938454: Unable to determine generic type in program that compiles under > >> Java 6 > >> Reviewed-by: aph > >> Contributed-by: nikgor <niko...@azulsystems.com> > >> > >> > >> > >> On 11/12/2014 22:01, Andrew Haley wrote: > >>> On 12/11/2014 06:59 PM, Nikolay Gorshkov wrote: > >>>> Me and my colleagues have a consensus that the patch is important to us > >>>> - > >>>> we are responsible for introducing a regression into OpenJDK 6 (breaking > >>>> Apache Flume 1.5.0 compilation), and so we have to fix it. We have > >>>> already > >>>> included this patch into our OpenJDK 6 -based products, and now we are > >>>> interested in upstreaming it to OpenJDK 6 itself to minimize the > >>>> difference > >>>> in codebase. > >>> Reluctantly, OK. I am crossing my fingers and hoping that this > >>> is the last we'll see of this bug! We shall see. > >>> > >>> Thanks for your patience, > >>> Andrew. > >>> > >>> > >> > >> > > > > Thanks, > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07