Re: Dropping support for Scala 2.9.x
+1 for dropping 2.9 On Wed, Jul 8, 2015 at 9:15 AM, Sriharsha Chintalapani wrote: > I am +1 on dropping 2.9.x support. > > Thanks, > Harsha > > > On July 8, 2015 at 7:08:12 AM, Ismael Juma (mli...@juma.me.uk) wrote: > > Hi, > > The responses in this thread were positive, but there weren't many. A few > months passed and Sriharsha encouraged me to reopen the thread given that > the 2.9 build has been broken for at least a week[1] and no-one seemed to > notice. > > Do we want to invest more time so that the 2.9 build continues to work or > do we want to focus our efforts on 2.10 and 2.11? Please share your > opinion. > > Best, > Ismael > > [1] https://issues.apache.org/jira/browse/KAFKA-2325 > > On Fri, Mar 27, 2015 at 2:20 PM, Ismael Juma wrote: > > > Hi all, > > > > The Kafka build currently includes support for Scala 2.9, which means > that > > it cannot take advantage of features introduced in Scala 2.10 or depend > on > > libraries that require it. > > > > This restricts the solutions available while trying to solve existing > > issues. I was browsing JIRA looking for areas to contribute and I quickly > > ran into two issues where this is the case: > > > > * KAFKA-1351: "String.format is very expensive in Scala" could be solved > > nicely by using the String interpolation feature introduced in Scala > 2.10. > > > > * KAFKA-1595: "Remove deprecated and slower scala JSON parser from > > kafka.consumer.TopicCount" could be solved by using an existing JSON > > library, but both jackson-scala and play-json require 2.10 (argonaut > > supports Scala 2.9, but it brings other dependencies like scalaz). We can > > workaround this by writing our own code instead of using libraries, of > > course, but it's not ideal. > > > > Other features like Scala Futures and value classes would also be useful > > in some situations, I would think (for a more extensive list of new > > features, see > > > http://scala-language.1934581.n4.nabble.com/Scala-2-10-0-now-available-td4634126.html > > ). > > > > Another pain point of supporting 2.9.x is that it doubles the number of > > build and test configurations required from 2 to 4 (because the 2.9.x > > series was not necessarily binary compatible). > > > > A strong argument for maintaining support for 2.9.x was the client > > library, but that has been rewritten in Java. > > > > It's also worth mentioning that Scala 2.9.1 was released in August 2011 > > (more than 3.5 years ago) and the 2.9.x series hasn't received updates of > > any sort since early 2013. Scala 2.10.0, in turn, was released in January > > 2013 (over 2 years ago) and 2.10.5, the last planned release in the > 2.10.x > > series, has been recently released (so even 2.10.x won't be receiving > > updates any longer). > > > > All in all, I think it would not be unreasonable to drop support for > Scala > > 2.9.x in a future release, but I may be missing something. What do others > > think? > > > > Ismael > > > -- Grant Henke Solutions Consultant | Cloudera ghe...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
Re: Dropping support for Scala 2.9.x
I am +1 on dropping 2.9.x support. Thanks, Harsha On July 8, 2015 at 7:08:12 AM, Ismael Juma (mli...@juma.me.uk) wrote: Hi, The responses in this thread were positive, but there weren't many. A few months passed and Sriharsha encouraged me to reopen the thread given that the 2.9 build has been broken for at least a week[1] and no-one seemed to notice. Do we want to invest more time so that the 2.9 build continues to work or do we want to focus our efforts on 2.10 and 2.11? Please share your opinion. Best, Ismael [1] https://issues.apache.org/jira/browse/KAFKA-2325 On Fri, Mar 27, 2015 at 2:20 PM, Ismael Juma wrote: > Hi all, > > The Kafka build currently includes support for Scala 2.9, which means that > it cannot take advantage of features introduced in Scala 2.10 or depend on > libraries that require it. > > This restricts the solutions available while trying to solve existing > issues. I was browsing JIRA looking for areas to contribute and I quickly > ran into two issues where this is the case: > > * KAFKA-1351: "String.format is very expensive in Scala" could be solved > nicely by using the String interpolation feature introduced in Scala 2.10. > > * KAFKA-1595: "Remove deprecated and slower scala JSON parser from > kafka.consumer.TopicCount" could be solved by using an existing JSON > library, but both jackson-scala and play-json require 2.10 (argonaut > supports Scala 2.9, but it brings other dependencies like scalaz). We can > workaround this by writing our own code instead of using libraries, of > course, but it's not ideal. > > Other features like Scala Futures and value classes would also be useful > in some situations, I would think (for a more extensive list of new > features, see > http://scala-language.1934581.n4.nabble.com/Scala-2-10-0-now-available-td4634126.html > > ). > > Another pain point of supporting 2.9.x is that it doubles the number of > build and test configurations required from 2 to 4 (because the 2.9.x > series was not necessarily binary compatible). > > A strong argument for maintaining support for 2.9.x was the client > library, but that has been rewritten in Java. > > It's also worth mentioning that Scala 2.9.1 was released in August 2011 > (more than 3.5 years ago) and the 2.9.x series hasn't received updates of > any sort since early 2013. Scala 2.10.0, in turn, was released in January > 2013 (over 2 years ago) and 2.10.5, the last planned release in the 2.10.x > series, has been recently released (so even 2.10.x won't be receiving > updates any longer). > > All in all, I think it would not be unreasonable to drop support for Scala > 2.9.x in a future release, but I may be missing something. What do others > think? > > Ismael >
Re: Dropping support for Scala 2.9.x
Hi, The responses in this thread were positive, but there weren't many. A few months passed and Sriharsha encouraged me to reopen the thread given that the 2.9 build has been broken for at least a week[1] and no-one seemed to notice. Do we want to invest more time so that the 2.9 build continues to work or do we want to focus our efforts on 2.10 and 2.11? Please share your opinion. Best, Ismael [1] https://issues.apache.org/jira/browse/KAFKA-2325 On Fri, Mar 27, 2015 at 2:20 PM, Ismael Juma wrote: > Hi all, > > The Kafka build currently includes support for Scala 2.9, which means that > it cannot take advantage of features introduced in Scala 2.10 or depend on > libraries that require it. > > This restricts the solutions available while trying to solve existing > issues. I was browsing JIRA looking for areas to contribute and I quickly > ran into two issues where this is the case: > > * KAFKA-1351: "String.format is very expensive in Scala" could be solved > nicely by using the String interpolation feature introduced in Scala 2.10. > > * KAFKA-1595: "Remove deprecated and slower scala JSON parser from > kafka.consumer.TopicCount" could be solved by using an existing JSON > library, but both jackson-scala and play-json require 2.10 (argonaut > supports Scala 2.9, but it brings other dependencies like scalaz). We can > workaround this by writing our own code instead of using libraries, of > course, but it's not ideal. > > Other features like Scala Futures and value classes would also be useful > in some situations, I would think (for a more extensive list of new > features, see > http://scala-language.1934581.n4.nabble.com/Scala-2-10-0-now-available-td4634126.html > ). > > Another pain point of supporting 2.9.x is that it doubles the number of > build and test configurations required from 2 to 4 (because the 2.9.x > series was not necessarily binary compatible). > > A strong argument for maintaining support for 2.9.x was the client > library, but that has been rewritten in Java. > > It's also worth mentioning that Scala 2.9.1 was released in August 2011 > (more than 3.5 years ago) and the 2.9.x series hasn't received updates of > any sort since early 2013. Scala 2.10.0, in turn, was released in January > 2013 (over 2 years ago) and 2.10.5, the last planned release in the 2.10.x > series, has been recently released (so even 2.10.x won't be receiving > updates any longer). > > All in all, I think it would not be unreasonable to drop support for Scala > 2.9.x in a future release, but I may be missing something. What do others > think? > > Ismael >
Re: Dropping support for Scala 2.9.x
+1. But can we also look at this from the deployment base point view and find out how many production deployments are still using 2.9? If there is not any, dropping it is really an easy decision. Thanks Sent from my iPhone > On Mar 27, 2015, at 8:21 AM, Ismael Juma wrote: > > Hi all, > > The Kafka build currently includes support for Scala 2.9, which means that > it cannot take advantage of features introduced in Scala 2.10 or depend on > libraries that require it. > > This restricts the solutions available while trying to solve existing > issues. I was browsing JIRA looking for areas to contribute and I quickly > ran into two issues where this is the case: > > * KAFKA-1351: "String.format is very expensive in Scala" could be solved > nicely by using the String interpolation feature introduced in Scala 2.10. > > * KAFKA-1595: "Remove deprecated and slower scala JSON parser from > kafka.consumer.TopicCount" could be solved by using an existing JSON > library, but both jackson-scala and play-json require 2.10 (argonaut > supports Scala 2.9, but it brings other dependencies like scalaz). We can > workaround this by writing our own code instead of using libraries, of > course, but it's not ideal. > > Other features like Scala Futures and value classes would also be useful in > some situations, I would think (for a more extensive list of new features, > see > http://scala-language.1934581.n4.nabble.com/Scala-2-10-0-now-available-td4634126.html > ). > > Another pain point of supporting 2.9.x is that it doubles the number of > build and test configurations required from 2 to 4 (because the 2.9.x > series was not necessarily binary compatible). > > A strong argument for maintaining support for 2.9.x was the client library, > but that has been rewritten in Java. > > It's also worth mentioning that Scala 2.9.1 was released in August 2011 > (more than 3.5 years ago) and the 2.9.x series hasn't received updates of > any sort since early 2013. Scala 2.10.0, in turn, was released in January > 2013 (over 2 years ago) and 2.10.5, the last planned release in the 2.10.x > series, has been recently released (so even 2.10.x won't be receiving > updates any longer). > > All in all, I think it would not be unreasonable to drop support for Scala > 2.9.x in a future release, but I may be missing something. What do others > think? > > Ismael
Re: Dropping support for Scala 2.9.x
+1 I was on a project that ended up not using kafka - and this was one reason: there are many other third party libraries that do not even have 2.9 versions so the interdependencies did not work. 2015-03-27 7:34 GMT-07:00 Stevo Slavić : > +1 for dropping 2.9.x support > > Kind regards, > Stevo Slavic. > > On Fri, Mar 27, 2015 at 3:20 PM, Ismael Juma wrote: > > > Hi all, > > > > The Kafka build currently includes support for Scala 2.9, which means > that > > it cannot take advantage of features introduced in Scala 2.10 or depend > on > > libraries that require it. > > > > This restricts the solutions available while trying to solve existing > > issues. I was browsing JIRA looking for areas to contribute and I quickly > > ran into two issues where this is the case: > > > > * KAFKA-1351: "String.format is very expensive in Scala" could be solved > > nicely by using the String interpolation feature introduced in Scala > 2.10. > > > > * KAFKA-1595: "Remove deprecated and slower scala JSON parser from > > kafka.consumer.TopicCount" could be solved by using an existing JSON > > library, but both jackson-scala and play-json require 2.10 (argonaut > > supports Scala 2.9, but it brings other dependencies like scalaz). We can > > workaround this by writing our own code instead of using libraries, of > > course, but it's not ideal. > > > > Other features like Scala Futures and value classes would also be useful > in > > some situations, I would think (for a more extensive list of new > features, > > see > > > > > http://scala-language.1934581.n4.nabble.com/Scala-2-10-0-now-available-td4634126.html > > ). > > > > Another pain point of supporting 2.9.x is that it doubles the number of > > build and test configurations required from 2 to 4 (because the 2.9.x > > series was not necessarily binary compatible). > > > > A strong argument for maintaining support for 2.9.x was the client > library, > > but that has been rewritten in Java. > > > > It's also worth mentioning that Scala 2.9.1 was released in August 2011 > > (more than 3.5 years ago) and the 2.9.x series hasn't received updates of > > any sort since early 2013. Scala 2.10.0, in turn, was released in January > > 2013 (over 2 years ago) and 2.10.5, the last planned release in the > 2.10.x > > series, has been recently released (so even 2.10.x won't be receiving > > updates any longer). > > > > All in all, I think it would not be unreasonable to drop support for > Scala > > 2.9.x in a future release, but I may be missing something. What do others > > think? > > > > Ismael > > >
Re: Dropping support for Scala 2.9.x
+1 for dropping 2.9.x support Kind regards, Stevo Slavic. On Fri, Mar 27, 2015 at 3:20 PM, Ismael Juma wrote: > Hi all, > > The Kafka build currently includes support for Scala 2.9, which means that > it cannot take advantage of features introduced in Scala 2.10 or depend on > libraries that require it. > > This restricts the solutions available while trying to solve existing > issues. I was browsing JIRA looking for areas to contribute and I quickly > ran into two issues where this is the case: > > * KAFKA-1351: "String.format is very expensive in Scala" could be solved > nicely by using the String interpolation feature introduced in Scala 2.10. > > * KAFKA-1595: "Remove deprecated and slower scala JSON parser from > kafka.consumer.TopicCount" could be solved by using an existing JSON > library, but both jackson-scala and play-json require 2.10 (argonaut > supports Scala 2.9, but it brings other dependencies like scalaz). We can > workaround this by writing our own code instead of using libraries, of > course, but it's not ideal. > > Other features like Scala Futures and value classes would also be useful in > some situations, I would think (for a more extensive list of new features, > see > > http://scala-language.1934581.n4.nabble.com/Scala-2-10-0-now-available-td4634126.html > ). > > Another pain point of supporting 2.9.x is that it doubles the number of > build and test configurations required from 2 to 4 (because the 2.9.x > series was not necessarily binary compatible). > > A strong argument for maintaining support for 2.9.x was the client library, > but that has been rewritten in Java. > > It's also worth mentioning that Scala 2.9.1 was released in August 2011 > (more than 3.5 years ago) and the 2.9.x series hasn't received updates of > any sort since early 2013. Scala 2.10.0, in turn, was released in January > 2013 (over 2 years ago) and 2.10.5, the last planned release in the 2.10.x > series, has been recently released (so even 2.10.x won't be receiving > updates any longer). > > All in all, I think it would not be unreasonable to drop support for Scala > 2.9.x in a future release, but I may be missing something. What do others > think? > > Ismael >
Dropping support for Scala 2.9.x
Hi all, The Kafka build currently includes support for Scala 2.9, which means that it cannot take advantage of features introduced in Scala 2.10 or depend on libraries that require it. This restricts the solutions available while trying to solve existing issues. I was browsing JIRA looking for areas to contribute and I quickly ran into two issues where this is the case: * KAFKA-1351: "String.format is very expensive in Scala" could be solved nicely by using the String interpolation feature introduced in Scala 2.10. * KAFKA-1595: "Remove deprecated and slower scala JSON parser from kafka.consumer.TopicCount" could be solved by using an existing JSON library, but both jackson-scala and play-json require 2.10 (argonaut supports Scala 2.9, but it brings other dependencies like scalaz). We can workaround this by writing our own code instead of using libraries, of course, but it's not ideal. Other features like Scala Futures and value classes would also be useful in some situations, I would think (for a more extensive list of new features, see http://scala-language.1934581.n4.nabble.com/Scala-2-10-0-now-available-td4634126.html ). Another pain point of supporting 2.9.x is that it doubles the number of build and test configurations required from 2 to 4 (because the 2.9.x series was not necessarily binary compatible). A strong argument for maintaining support for 2.9.x was the client library, but that has been rewritten in Java. It's also worth mentioning that Scala 2.9.1 was released in August 2011 (more than 3.5 years ago) and the 2.9.x series hasn't received updates of any sort since early 2013. Scala 2.10.0, in turn, was released in January 2013 (over 2 years ago) and 2.10.5, the last planned release in the 2.10.x series, has been recently released (so even 2.10.x won't be receiving updates any longer). All in all, I think it would not be unreasonable to drop support for Scala 2.9.x in a future release, but I may be missing something. What do others think? Ismael
