switch to scala 2.13 and remove deprecation warning for JavaConverters

[johanneshiry]

We are using tscfg with scala 2.13.x and we get lot's of deprecation warnings:

object JavaConverters in package collection is deprecated (since 2.13.0): Use `scala.jdk.CollectionConverters` instead

I prepared a small adaptions to use the (in 2.13 newly introduced) scala.jdk.CollectionConverters to get rid of this warnings. But this would be a breaking change as it would require 2.13. Is there any interest in updating to 2.13 or is the intended way to stay with 2.12 and ignore the warnings for now?

I know this is just a small benefit that comes with a breaking change, but I thought I would ask it anyway as it has become a little bit annoying in our projects to have these deprecation messages everywhere.

[carueda]

Thanks for the suggestion.

Will have to look at this more closely when time permits, but couple of quick reactions:

• Updating to 2.13 should in general not be a big deal: i) the tool is described more in terms of being a command-line program (not a library per se); and ii) for the java users (eg. via the maven plugin (@timvlaer)) they would be bringing in whatever scala supporting version anyway. But again, I may still be missing something important to consider here.

• Despite the above, maybe consider something like https://github.com/ghik/silencer to at least avoid the annoying deprecation warnings.

Comments welcome.

[johanneshiry]

Thanks for the fast reply.
Some comments on your quick reactions:

• if the tool should be more considered as a cli program and not a library I share your opinion that it doesn't make any difference if it is compiled with Scala 2.13 or 2.12. As we have mostly mixed Java/Scala projects I also share your point that it won't affect any Java projects if Scala 2.13 will be used.
• what needs to be considered though is, that the generated config class will require Scala 2.13 as the import of scala.jdk.CollectionConverters will be placed in the generated config class. Hence, if someone uses the cli to generate a Scala config class the project the config class is generated for needs to be set up in Scala 2.13 . An alternative to this would be, that we could provide a special flag which allows the config class generation for Scala 2.12 and the default config class generation would be for Scala 2.13. This would allow downward compatibility. So we would be able to serve both, Scala 2.12 and Scala 2.13 projects. Assuming that you're open for such a flag which provides the Scala version, I can hand in a proposal PR with the changes that are needed from my point of view and we can continue discussing based on the proposal then.
• thanks for the hint for https://github.com/ghik/silencer - will definitely take a look at this and see if we can make use of it.

Looking forward to read your comments on this.

[carueda]

You're right, I was forgetting about the generated Scala code itself!

Yes, please go ahead with a PR for what you propose. And I just pushed some changes that are relevant in general. Please have a look at your convenience. Thanks again.

EDIT: note that I started using https://github.com/scala/scala-collection-compat as part of trying to still cross build to 2.12 as well, at least for the time being.

[carueda]

OK, I'm done with my preparation changes. Now the only reference to scala.collection.JavaConverters._ is in this method for the Scala generation. So, this will be the part to be made dependent on the new flag, with scala.jdk.CollectionConverters._ to be used by default, and scala.collection.JavaConverters._ if that new flag is given. Thanks again for the nice proposal!

[johanneshiry]

Thank you very much for your preparation changes. I changed the code accordingly, added two (very simple) tests and adapted the readme as well. Pls let me know if I missed something else that needs to be done.

[carueda]

Thanks again! I just did some minor adjustments and published the new v0.9.96 (as usual, released the executable here in github, and the artifact to maven central).