Scott, Yes, we are still using scala 2.8.0 at LinkedIn. We do plan to upgrade to a later version of scala at some point. However, this may take some time since we will need to upgrade other scala projects at LinkedIn at the same time.
It's unfortunate that code change is needed in order to support scala 2.10. What are the things that you are looking for in scala 2.10? Thanks, Jun On Fri, Apr 5, 2013 at 1:10 PM, Scott Carey <sc...@richrelevance.com> wrote: > Kafka 0.8 and trunk by default have SBT set up to cross-compile 2.8.0, > 2.8.2, 2.9.1 and 2.9.2, and it defaults to 2.8.0. > > I assume that one of the major contributors requires 2.8.0. Any > approximation on how long will that last? > Dropping 2.8.0 would be beneficial because some uses of Java Conversions > is replaced with Java Converters (in 2.10 +), and Java Converters was not > added until 2.8.1. > http://stackoverflow.com/questions/8301947/what-is-the-difference-between-j > avaconverters-and-javaconversions-in-scala > > https://issues.apache.org/jira/browse/KAFKA-717 is attempting to add build > support for Scala 2.10. The required changes to support 2.10 use Java > Converters, which is not available in 2.8.0. > > The other item required to support Scala 2.10 is to move from > scala.StaticAnnotation to scala.annotation.StaticAnnotation. > Scala 2.10.x has only scala.annotation.StaticAnnotation. > Scala 2.9.x has both scala.StaticAnnotation (deprecated) and > scala.annotation.StaticAnnotation. > Scala 2.8.x has only scala.StaticAnnotation > > Dropping support for 2.8.x entirely and supporting only 2.9.x and 2.10.x > would make 2.10.x support easy. > If 2.8.2 is required (but not 2.8.0), then some sort of conditional > compile or two flavors of the source code where > scala.annotation.StaticAnnotation is used will be required. Use of > StaticAnnotation is very limited. > If 2.8.0 must be kept, then two versions of all code that uses Java > Conversions APIs will also need to be maintained. > > I can't find any discussions about 2.8.0 usage requirements. I also don't > know enough about sbt to configure cross compilation to use different > source files for different cases, which would solve the problems above but > add some maintenance burden. > > >
