Hi Stephen, I'm not sure which link you are referring to for the example code -- but yes, the recommendation is that you create the enum in Java, eg. see
https://github.com/apache/spark/blob/v1.4.0/core/src/main/java/org/apache/spark/status/api/v1/StageStatus.java Then nothing special is required to use it in scala. This method both uses the overall type of the enum in the return value, and uses specific values in the body: https://github.com/apache/spark/blob/v1.4.0/core/src/main/scala/org/apache/spark/status/api/v1/AllStagesResource.scala#L114 (I did delete the branches for the code that is *not* recommended anymore) Imran On Wed, Jul 1, 2015 at 5:53 PM, Stephen Boesch <java...@gmail.com> wrote: > I am reviving an old thread here. The link for the example code for the > java enum based solution is now dead: would someone please post an updated > link showing the proper interop? > > Specifically: it is my understanding that java enum's may not be created > within Scala. So is the proposed solution requiring dropping out into Java > to create the enum's? > > 2015-04-09 17:16 GMT-07:00 Xiangrui Meng <men...@gmail.com>: > >> Using Java enums sound good. We can list the values in the JavaDoc and >> hope Scala will be able to correctly generate docs for Java enums in >> the future. -Xiangrui >> >> On Thu, Apr 9, 2015 at 10:59 AM, Imran Rashid <iras...@cloudera.com> >> wrote: >> > any update here? This is relevant for a currently open PR of mine -- >> I've >> > got a bunch of new public constants defined w/ format #4, but I'd gladly >> > switch to java enums. (Even if we are just going to postpone this >> decision, >> > I'm still inclined to switch to java enums ...) >> > >> > just to be clear about the existing problem with enums & scaladoc: right >> > now, the scaladoc knows about the enum class, and generates a page for >> it, >> > but it does not display the enum constants. It is at least labeled as a >> > java enum, though, so a savvy user could switch to the javadocs to see >> the >> > constants. >> > >> > >> > >> > On Mon, Mar 23, 2015 at 4:50 PM, Imran Rashid <iras...@cloudera.com> >> wrote: >> >> >> >> well, perhaps I overstated things a little, I wouldn't call it the >> >> "official" solution, just a recommendation in the never-ending debate >> (and >> >> the recommendation from folks with their hands on scala itself). >> >> >> >> Even if we do get this fixed in scaladoc eventually -- as its not in >> the >> >> current versions, where does that leave this proposal? personally I'd >> >> *still* prefer java enums, even if it doesn't get into scaladoc. btw, >> even >> >> with sealed traits, the scaladoc still isn't great -- you don't see the >> >> values from the class, you only see them listed from the companion >> object. >> >> (though, that is somewhat standard for scaladoc, so maybe I'm reaching >> a >> >> little) >> >> >> >> >> >> >> >> On Mon, Mar 23, 2015 at 4:11 PM, Patrick Wendell <pwend...@gmail.com> >> >> wrote: >> >>> >> >>> If the official solution from the Scala community is to use Java >> >>> enums, then it seems strange they aren't generated in scaldoc? Maybe >> >>> we can just fix that w/ Typesafe's help and then we can use them. >> >>> >> >>> On Mon, Mar 23, 2015 at 1:46 PM, Sean Owen <so...@cloudera.com> >> wrote: >> >>> > Yeah the fully realized #4, which gets back the ability to use it in >> >>> > switch statements (? in Scala but not Java?) does end up being kind >> of >> >>> > huge. >> >>> > >> >>> > I confess I'm swayed a bit back to Java enums, seeing what it >> >>> > involves. The hashCode() issue can be 'solved' with the hash of the >> >>> > String representation. >> >>> > >> >>> > On Mon, Mar 23, 2015 at 8:33 PM, Imran Rashid <iras...@cloudera.com >> > >> >>> > wrote: >> >>> >> I've just switched some of my code over to the new format, and I >> just >> >>> >> want >> >>> >> to make sure everyone realizes what we are getting into. I went >> from >> >>> >> 10 >> >>> >> lines as java enums >> >>> >> >> >>> >> >> >>> >> >> https://github.com/squito/spark/blob/fef66058612ebf225e58dd5f5fea6bae1afd5b31/core/src/main/java/org/apache/spark/status/api/StageStatus.java#L20 >> >>> >> >> >>> >> to 30 lines with the new format: >> >>> >> >> >>> >> >> >>> >> >> https://github.com/squito/spark/blob/SPARK-3454_w_jersey/core/src/main/scala/org/apache/spark/status/api/v1/api.scala#L250 >> >>> >> >> >>> >> its not just that its verbose. each name has to be repeated 4 >> times, >> >>> >> with >> >>> >> potential typos in some locations that won't be caught by the >> >>> >> compiler. >> >>> >> Also, you have to manually maintain the "values" as you update the >> set >> >>> >> of >> >>> >> enums, the compiler won't do it for you. >> >>> >> >> >>> >> The only downside I've heard for java enums is enum.hashcode(). >> OTOH, >> >>> >> the >> >>> >> downsides for this version are: maintainability / verbosity, no >> >>> >> values(), >> >>> >> more cumbersome to use from java, no enum map / enumset. >> >>> >> >> >>> >> I did put together a little util to at least get back the >> equivalent >> >>> >> of >> >>> >> enum.valueOf() with this format >> >>> >> >> >>> >> >> >>> >> >> https://github.com/squito/spark/blob/SPARK-3454_w_jersey/core/src/main/scala/org/apache/spark/util/SparkEnum.scala >> >>> >> >> >>> >> I'm not trying to prevent us from moving forward on this, its fine >> if >> >>> >> this >> >>> >> is still what everyone wants, but I feel pretty strongly java enums >> >>> >> make >> >>> >> more sense. >> >>> >> >> >>> >> thanks, >> >>> >> Imran >> >>> > >> >>> > >> --------------------------------------------------------------------- >> >>> > To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org >> >>> > For additional commands, e-mail: dev-h...@spark.apache.org >> >>> > >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org >> For additional commands, e-mail: dev-h...@spark.apache.org >> >> >
