We
have two build environments for release to production - one we build and
regularly test; other is maintained by the global build team that
generates certified binaries for release.
We got a compilation issue in the environment maintained by the global team. The
compilation is fine in our environments and release environment it
fails. We looked at all tagging etc...no problem. Finally it came down
to compiler version. We used javac -> 1.8.0_66-b17 and release environment uses javac -> 1.8.0_05. The upgrade fixed the issue.
But, what did we code that has caught a bug in this range? Here it is.
Following are two overloaded methods that execute the given function in the context of a tenant.
public static R executeForTenant(String tenantId, Function function)
public static void executeForTenant(String tenantId, Consumer consumer)
public void loadPreferenceInto(String tenant, Configuration configuration)
Following are two overloaded methods that execute the given function in the context of a tenant.
public static
public static void executeForTenant(String tenantId, Consumer
public void loadPreferenceInto(String tenant, Configuration configuration)
The usage is as follows..
executeForTenant(tenant, (t) -> loadPreferenceInto(t, configuration));
executeForTenant(tenant, (t) -> loadPreferenceInto(t, configuration));
This
is ambiguous, compiler cannot determine which one to pick. The
void-ness is also compatible with Function generic type R since the
statement body is an expression.
So we changed the invocation to
executeForTenant(tenant, (t) -> { loadPreferenceInto(t, configuration); });
This {} ensures the statement body is not an expression. So it should pick Consumer parameter based executeForTenant method.
This {} ensures the statement body is not an expression. So it should pick Consumer parameter based executeForTenant method.
The change worked in our environment but failed in release; obviously the bug was fixed in between the builds - 1.8.0_20 to be precise.
Here are the bugs:
http://bugs.java.com/ bugdatabase/view_bug.do?bug_ id=8043734
http://bugs.java.com/ bugdatabase/view_bug.do?bug_ id=8029718
http://bugs.java.com/
http://bugs.java.com/
Compiler commit that fixes the bug
http://hg.openjdk.java.net/ jdk8u/jdk8u-dev/langtools/rev/ acd64168cf8b
http://hg.openjdk.java.net/
Lambda expression resolution (from above link)
A lambda expression (15.27) is potentially compatible with a functional interface type (9.8) if all of the following are true: - The arity of the targeted type's function type is the same as the arity of the lambda expression. - If the targeted type's function type has a void return, then the lambda body is either a statement expression (14.8) or a void-compatible block (15.27.2). - If the targeted type's function type has a (non-void) return type, then the lambda body is either an expression or a value-compatible block (15.27.2).
Interesting ride, it has been for last 2 days....
No comments:
Post a Comment