[ https://issues.apache.org/jira/browse/SPARK-4819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15086092#comment-15086092 ]
Sean Owen commented on SPARK-4819: ---------------------------------- That's basically what I did, and then added some Guava API methods onto it as well to increase backwards compatibility. But it's in an org.apache.spark package. (And I reimplemented it since I don't think we can use Oracle's code here.) Do you mean keep it in the java.util package? That has some appeal but isn't that prohibited by the JVM? I forget. I feel like this is inviting the same crazy classloader problems we had with the current Guava usage. > Remove Guava's "Optional" from public API > ----------------------------------------- > > Key: SPARK-4819 > URL: https://issues.apache.org/jira/browse/SPARK-4819 > Project: Spark > Issue Type: Sub-task > Components: Spark Core > Affects Versions: 1.2.0 > Reporter: Marcelo Vanzin > Assignee: Sean Owen > Attachments: SPARK_4819_null_do_not_merge.patch > > > Filing this mostly so this isn't forgotten. Spark currently exposes Guava > types in its public API (the {{Optional}} class is used in the Java > bindings). This makes it hard to properly hide Guava from user applications, > and makes mixing different Guava versions with Spark a little sketchy (even > if things should work, since those classes are pretty simple in general). > Since this changes the public API, it has to be done in a release that allows > such breakages. But it would be nice to at least have a transition plan for > deprecating the affected APIs. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org For additional commands, e-mail: issues-h...@spark.apache.org