[SPARK-3266] [Java] Change JavaRDDLike trait to abstract class.#2186
Closed
JoshRosen wants to merge 1 commit intoapache:masterfrom
Closed
[SPARK-3266] [Java] Change JavaRDDLike trait to abstract class.#2186JoshRosen wants to merge 1 commit intoapache:masterfrom
JoshRosen wants to merge 1 commit intoapache:masterfrom
Conversation
JavaRDDLike's current design is a holdover from an earlier prototype that tried to achieve code-reuse for methods like map(), filter(), etc. using the same builder-trait pattern that the Scala collections library uses. This approach didn't work due to some compiler issues, but unfortunately we never removed the confusing trait implementation. This patch changes JavaRDDLike from a trait to an abstract base class. This should be source-compatible with earlier versions. This change resolves some problems with certain inherited methods having the wrong signatures in the bytecode (such as max(); see SPARK-3266).
|
QA tests have started for PR 2186 at commit
|
|
QA tests have finished for PR 2186 at commit
|
|
QA tests have started for PR 2186 at commit
|
|
QA tests have finished for PR 2186 at commit
|
Contributor
|
test this please |
Contributor
Author
|
This almost certainly breaks binary compatibility; sorry for letting this PR sit for so long. I'll try to update it today or tomorrow. |
JoshRosen
added a commit
to JoshRosen/spark
that referenced
this pull request
Oct 26, 2014
This PR addresses a Scala compiler bug ([SI-8905](https://issues.scala-lang.org/browse/SI-8905)) that was breaking some of the Spark Java APIs. In a nutshell, it seems that methods whose implementations are inherited from generic traits sometimes have their type parameters erased to Object. This was causing methods like `DoubleRDD.min()` to throw confusing NoSuchMethodErrors at runtime. The workaround is to move the implementations of these methods out of the trait. Ideally, I'd like to just delete the trait and convert it into an abstract class, but this technically breaks binary compatibility because it removes an interface (see apache#2186). Instead, I remove the method implementations from the traits and put them in AbstractJavaDStream and AbstractJavaRDD classes that inherit from their respective traits. This leads to a bit of redundancy, but I think it's the cleanest general solution that maintains binary compatibility. I also improved the test coverage of the Java API.
Contributor
|
ping @JoshRosen, trying to decrease the number of open SQL PRs ;) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
JavaRDDLike's current design is a holdover from an earlier prototype that tried
to achieve code-reuse for methods like map(), filter(), etc. using the same
builder-trait pattern that the Scala collections library uses. This approach
didn't work due to some compiler issues, but unfortunately we never removed
the confusing trait implementation.
This patch changes JavaRDDLike from a trait to an abstract base class.
This should be source-compatible with earlier versions.
This change resolves some problems with certain inherited methods having the
wrong signatures in the bytecode (such as max(); see SPARK-3266).