Java 7 -> Java8 code breakage scenarios

[Dan Smith]

I think we might be maintaining a full list somewhere; I'll investigate.

I think you've pretty much covered the main issues.  Off the top of my head:

- API changes via default methods can cause compile-time clashes; not a new problem (same can happen with new methods in classes), but default methods encourage API changes.

- Inference changes may cause a recompiled expression to have a different type, triggering downstream errors or overload resolution changes.  This includes diamond class instance creation and method invocation.  We're generally more accommodating of different target types, which means this might most often manifest itself as an ambiguity error or a "better" overload resolution choice.

- There are some VM changes that will lead to different behavior where there's currently an Error thrown (not observable under consistent compilation from Java source).

—Dan

On Feb 27, 2013, at 10:41 AM, Srikanth S Adayapalam <srikanth_sankaran at in.ibm.com> wrote:

> Is there a list of scenarios documented somewhere that enumerates the 
> situations under which a valid Java 7 program will either (a) cease to 
> be a valid Java 8 program (b) or will exhibit a different behavior ? 
> 
> Looks like default methods clash can cause (a) and the (unlikely) usage 
> of diamond inference usage in method arguments can cause (b). 
> 
> I would be curious to see what other cases exist. 
> 
> TIA, 
> Srikanth.