This is a follow up to https://bugs.openjdk.java.net/browse/JDK-8244231 (https://github.com/openjdk/valhalla/pull/482) for issues
deliberately deferred from there:

(1) Types.isSubtype visitor has this code pattern in com.sun.tools.javac.code.Types.TypeRelation#visitClassType

           @Override
            public Boolean visitClassType(ClassType t, Type s) {
                Type sup = asSuper(t, s.tsym);
                if (sup == null) return false;
                // If t is an intersection, sup might not be a class type
                if (!sup.hasTag(CLASS)) return isSubtypeNoCapture(sup, s);
                return sup.tsym == s.tsym
                    && (t.tsym != s.tsym ||
                        (t.isReferenceProjection() == s.isReferenceProjection() && t.isValueProjection() == s.isValueProjection()))
                     // Check type variable containment
                    && (!s.isParameterized() || containsTypeRecursive(s, sup))
                    && isSubtypeNoCapture(sup.getEnclosingType(),
                                          s.getEnclosingType());
            }

The check
(t.isReferenceProjection() == s.isReferenceProjection() && t.isValueProjection() == s.isValueProjection()))
should be better coded as
t.getFlavor() == s.getFlavor()
but at the moment this is problematic in some cases and needs to be further investigated.

(2) Same issue with isSameTypeVisitor:

return t.tsym == s.tsym
                    && t.isReferenceProjection() == s.isReferenceProjection()
                    && t.isValueProjection() == s.isValueProjection()
                    && visit(getEnclosingType(t), getEnclosingType(s))
                    && containsTypeEquivalent(t.getTypeArguments(), s.getTypeArguments());

should just check for the flavor being the same.

(3) In the definition of com.sun.tools.javac.code.Types#erasure a TODO has been left in with the comment:
// Todo: Handle Type variable case.

(4) There is a TODO task left in LambdaToMethod that needs follow up

// Todo: Investigate to see if a defect should be reported against runtime lambda machinery

(5) There is an half hearted attempt to find a place for ACC_REF_DEFAULT in com.sun.tools.classfile.AccessFlags.
I don't think it belongs there really since it is not a part of the class flags. But I have stuck this in here for now - In javap code to reference ACC_REF_DEFAULT symbolically this is useful (since the compiler's definition from Flags.java is not visible there in javap)