Mailing-List: contact issues-help@spark.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 18 Nov 2016 00:35:58 +0000 (UTC)
From: "Joseph K. Bradley (JIRA)" <jira@apache.org>
To: issues@spark.apache.org
Message-ID: <JIRA.13018951.1478546028000.309135.1479429358424@Atlassian.JIRA>
In-Reply-To: <JIRA.13018951.1478546028000@Atlassian.JIRA>
References: <JIRA.13018951.1478546028000@Atlassian.JIRA> <JIRA.13018951.1478546028328@arcas>
Subject: [jira] [Commented] (SPARK-18321) ML 2.1 QA: API: Java
 compatibility, docs
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 18 Nov 2016 00:36:00 -0000


    [ https://issues.apache.org/jira/browse/SPARK-18321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15675287#comment-15675287 ] 

Joseph K. Bradley commented on SPARK-18321:
-------------------------------------------

I'm guessing it's because it's a private class within a file with a different name containing other classes.  I think it's OK to leave and hopefully fix in the unidoc gen later on.

> ML 2.1 QA: API: Java compatibility, docs
> ----------------------------------------
>
>                 Key: SPARK-18321
>                 URL: https://issues.apache.org/jira/browse/SPARK-18321
>             Project: Spark
>          Issue Type: Sub-task
>          Components: Documentation, Java API, ML, MLlib
>            Reporter: Joseph K. Bradley
>            Priority: Blocker
>
> Check Java compatibility for this release:
> * APIs in {{spark.ml}}
> * New APIs in {{spark.mllib}} (There should be few, if any.)
> Checking compatibility means:
> * Checking for differences in how Scala and Java handle types. Some items to look out for are:
> ** Check for generic "Object" types where Java cannot understand complex Scala types.
> *** *Note*: The Java docs do not always match the bytecode. If you find a problem, please verify it using {{javap}}.
> ** Check Scala objects (especially with nesting!) carefully.  These may not be understood in Java, or they may be accessible only via the weirdly named Java types (with "$" or "#") which are generated by the Scala compiler.
> ** Check for uses of Scala and Java enumerations, which can show up oddly in the other language's doc.  (In {{spark.ml}}, we have largely tried to avoid using enumerations, and have instead favored plain strings.)
> * Check for differences in generated Scala vs Java docs.  E.g., one past issue was that Javadocs did not respect Scala's package private modifier.
> If you find issues, please comment here, or for larger items, create separate JIRAs and link here as "requires".
> * Remember that we should not break APIs from previous releases.  If you find a problem, check if it was introduced in this Spark release (in which case we can fix it) or in a previous one (in which case we can create a java-friendly version of the API).
> * If needed for complex issues, create small Java unit tests which execute each method.  (Algorithmic correctness can be checked in Scala.)
> Recommendations for how to complete this task:
> * There are not great tools.  In the past, this task has been done by:
> ** Generating API docs
> ** Building JAR and outputting the Java class signatures for MLlib
> ** Manually inspecting and searching the docs and class signatures for issues
> * If you do have ideas for better tooling, please say so we can make this task easier in the future!


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org