On Mon, 19 Feb 2018 16:12:05 +0300, Alexander Nozik wrote:
On 19.02.2018 15:58, Gilles wrote:
Unless I'm totally off base, I guess a code written in Kotlin
needs specific support (e.g. a library dependency) to be run
on a JVM.
If you do not use standard library, then no, you do not need anything
else. And I mean that code could be rewritten in java and all
references to the standard library replaced by pure java analogues.
But I can convert kotlin code back to Java.
Is it a one-time port (and thereon, maintenance is done on the
Java code)? Or do you mean a conversion step (as part of the
build for example) that creates Java sources (or bytecode) so
that maintenance requires coding in Kotlin?
I mean one-time conversion. What we are talking about is a minor
change to the code that probably won't need special long-time
My project currently is in Java 8, Groovy and Kotlin, and I am not
able to support something, which requires backward compatibility with
older versions (do not really have tome for that).
Commons math does not
support newer versions of JVM with functional features,
My latest suggestion is to target Java 8.
I totally agree. Java 8 adds a lot of functional-style features which
are life-savers for mathematical tools.
so for now it
easier to think in kotlin,
Not for me. :-}
I can imagine it has interesting features for those who
use it. But are those indispensable for the project we
are talking about?
The major things are extension functions and receivers. Everything
could be done using plain old java, but it looks much more
and then produce Java6 compatible
Do you have a requirement to use Java 6?
I have requirement for Java 8, but I am sure, everything could be
implemented using older standards.
I have few different things in mind. Most of them are possible and
rather simple in pure Java. I will get back to you, when I have a
piece of free time to work on it.
I've opened a report on the NUMBERS JIRA project:
and a dedicated git branch:
Please use it for your upcoming pull requests.
Thanks a lot,
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org