Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ignore null in generic lambdas parameters #419

Closed
wants to merge 1 commit into from

Conversation

jvican
Copy link
Member

@jvican jvican commented Sep 28, 2017

This is a WIP and needs to be double-checked before merge.

Related but not exact reasons why this happens can be found in JDK's
issue tracker: https://bugs.openjdk.java.net/browse/JDK-8178523?jql=text%20%7E%20%22lambda%20generic%20type%22

We ignore nulls that are returned by getActualTypeArguments.

It would be good to file a ticket in JIRA before merge.

Fixes #389.

dwijnand
dwijnand previously approved these changes Sep 29, 2017
Copy link
Member

@dwijnand dwijnand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@@ -496,12 +498,18 @@ object ClassToAPI {
api.Projection.of(api.Singleton.of(pathFromString(p)), cls)
}
}

// sbt/zinc#389: Ignore nulls coming from generic parameter types of lambdas
private[this] def ignoreNulls[T: scala.reflect.ClassTag](genericTypes: Array[T]): Array[T] =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ClassTag isn't necessary.

@jvican jvican force-pushed the temporary-fix branch 2 times, most recently from ad6638d to b05a5c9 Compare September 29, 2017 08:57
@jvican
Copy link
Member Author

jvican commented Sep 29, 2017

Things that I need to do before merge:

  • Update commit message and PR with description of fix and trade-offs.
  • Open ticket in JDK's issue tracker to keep track of this one.

private[this] def parameterTypes(m: Method): Array[Type] =
ignoreNulls(m.getGenericParameterTypes)
private[this] def parameterTypes(c: Constructor[_]): Array[Type] =
ignoreNulls(c.getGenericParameterTypes)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did the previous iteration of this patch that only applied the filter on getActualTypeArguments fail the test in CI?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the issue is that I forgot to push the latest local changes last night, which included this.

@dwijnand dwijnand modified the milestones: 1.0.2, 1.0.3 Sep 29, 2017
@jvican
Copy link
Member Author

jvican commented Oct 11, 2017

This slipped through the rocks. Handling tomorrow.

@jvican
Copy link
Member Author

jvican commented Oct 12, 2017

It looks like I cannot sign in into JDK's issue tracker, so I won't be filing a ticket. I'm updating the commit message with the reason behind this problem.

`Method.getGenericParameterType` may sometimes return `null` for the
return types when the method's return type is indeed generic. It's not
clear yet where this "sometimes" happens, but it looks like the JDK is
not able to tell the return type of a lambda returning the generic
class.

This can be seen in the `java-lambda-typeparams` scripted test. In this
context, lambda metafactory synthesizes a lambda class that returns a
class that is parameterized in its return type. In that context, when
`ClassToAPI` inspects the synthesized lambda and tries to figure out the
full return type of it, the `null` is returned.

It looks like the Java reflection API sparingly returns `null`s. We can
see that in `ClassToAPI` where we guard against `null`s in lots of other
places. So the guard added by this commit is not a novelty, but rather
the norm.

Fixes sbt#389.
@jvican
Copy link
Member Author

jvican commented Oct 26, 2017

This PR has been updated with a better commit message.

Copy link
Member

@dwijnand dwijnand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eed3si9n over to you, for 1.0.3.

@eed3si9n
Copy link
Member

So this should target 1.0.x branch, right?

@eed3si9n eed3si9n changed the base branch from 1.x to 1.0.x October 26, 2017 20:47
@eed3si9n eed3si9n changed the base branch from 1.0.x to 1.x October 26, 2017 20:49
Copy link
Member

@eed3si9n eed3si9n left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using GitHub UI to change the base is going to pull in commits from 1.x.
@jvican Could you rebase this branch on top of current 1.0.x please?

@eed3si9n
Copy link
Member

Closing this in favor of #446.
Note that 1.0.x is slightly ahead of 1.x now.

@eed3si9n eed3si9n closed this Oct 26, 2017
@jvican
Copy link
Member Author

jvican commented Oct 27, 2017

Thanks for the rebase. I missed this notification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants