- Style. There’s a tremendous amount of variation in Scala style because>
> > >> of its type system, implicits, macros, and functional nature. There are>
> > >> very good people out there that can write good Scala that isn’t>
> > readable by>
> > >> the 99%.>
> > >> - Binary compatibility. Scala tends to be a little more brazen about>
> > >> breaking binary compatibility in major releases and those happen a bit>
> > more>
> > >> often than with Java. That’s not a problem for any potential source>
> > code in>
> > >> the project, but it could present some dependency issues someday.>
> > >> - Testing. There’s N > 1 test frameworks and testing styles within>
> > those,>
> > >> so there’s a lot of options for introducing more variability into the>
> > tests.>
> > >> - NiFi uses a lot of statics in setting up properties and relationships>
> > >> and the like, and idiomatic Scala approaches that stuff a bit>
> > differently,>
> > >> so it’ll be necessary to impose some style guidelines so there isn’t too>
> > >> much variation.>
> > >>>
> > >> That said, there are some things that won’t be problematic:>
> > >>>
> > >> - As mentioned, processors written in Scala do just work.>
> > >> - The scala-maven-plugin works just fine allowing mixed Java-Scala>
> > >> projects (btw, it’d probably be not super great to do mixed Java-Scala>
> > and>
> > >> mixed Maven-SBT though).>
> > >> - A lot of the above concerns could be addressed by having clear style>
> > >> guidelines.>
> > >>>
> > >> Another thing: most of the projects I see deliver separate jars for>
> > Scala>
> > >> components are delivering idiomatic APIs wrapping Java (or vice versa).>
> > I>
> > >> think publishing a separate set of jars/nars for stuff written in>
> > Scala>
> > >> would be odd since here it’d mostly be processors with new functionality>
> > >> and not functionality for using Scala. I could imagine a lib of>
> > implicits,>
> > >> traits, classes that could make the Scala development more enjoyable.>
> > That>
> > >> probably would make sense to deliver that way.>
> > >>>
> > >> -joey>
> > >>>
> > >> On Feb 10, 2018, 10:33 AM -0600, Bryan Bende
> > >> <bb...@gmail.com<mailto:bb...@gmail.com>>, wrote:>
> > >> > I agree more with Andy about sticking with Java. The more varying>
> > >> languages>
> > >> > used, the more challenging it is to maintain. Once the code is part of>
> > >> the>
> > >> > Apache NiFi git repo, it is now the responsibility of the committers>
> > and>
> > >> > PMC members to maintain it.>
> > >> >>
> > >> > I’d even say I am somewhat against the groovy/Spock test code that>
> > Andy>
> > >> > mentioned. I have frequently spent hours trying to fix a Spock test>
> > that>
> > >> > broke from something I was working on. Every committer is familiar>
> > with>
> > >> > JUnit, but only a couple know Spock. Just using this as an example>
> > that>
> > >> > every committer knows Java, but only a couple probably know Scala,>
> > >> Clojure,>
> > >> > etc.>
> > >> >>
> > >> > On Sat, Feb 10, 2018 at 10:25 AM Jeff
> > >> > <jt...@gmail.com<mailto:jt...@gmail.com>> wrote:>
> > >> >>
> > >> > > +1 to Joe's response. If you can develop a component in Groovy or>
> > Scala>
> > >> > > (or Clojure!) more quickly/comfortably, or if allowing components>
> > >> written>
> > >> > > in other languages would encourage people to contribute more, I'm>
> > all>
> > >> for>
> > >> > > it.>
> > >> > >>
> > >> > > On Sat, Feb 10, 2018 at 7:42 AM Joe Witt
> > >> > > <jo...@gmail.com<mailto:jo...@gmail.com>>>
> > wrote:>
> > >> > >>
> > >> > > > i personally would be ok with it for an extension/processor>
> > provided>
> > >> it>
> > >> > > > integrates well wit
