Yep, I agree with that, but I guess losing the first-class citizen status within Flink will make many companies currently in doubt finally adopt Java. For non-FP shops or companies without a strong command of Scala, using Java will simplify things in general and avoid some unnecessary pains (hiring & training). Although possible, IMO using Scala without the required serialization support for its specific types nor a nice API wrapper feels a bit artificial and awkward, especially once Java 17 is supported, and I don't think it is worth it for most cases.
Salva On 2022/10/05 19:26:49 David Anderson wrote: > I want to clarify one point here, which is that modifying jobs written in > Scala to use Flink's Java API does not require porting them to Java. I can > readily understand why folks using Scala might rather use Java 17 than Java > 11, but sticking to Scala will remain an option even if Flink's Scala API > goes away. > > For more on this, see [1] and some of the examples it points to, such as > those in [2]. > > [1] https://flink.apache.org/2022/02/22/scala-free.html > [2] https://github.com/sjwiesman/flink-scala-3 > > On Tue, Oct 4, 2022 at 6:16 PM Clayton Wohl <cl...@gmail.com> wrote: > > > +1 > > > > At my employer, we maintain several Flink jobs in Scala. We've been > > writing newer jobs in Java, and we'd be fine with porting our Scala jobs > > over to the Java API. > > > > I'd like to request Java 17 support. Specifically, Java records is a > > feature our Flink code would use a lot of and make the Java syntax much > > nicer. > > >
