> Rather, I think the TR code itself is badly in need of a clean up, to improve modularity and to give some thought to extensibility.
I agree, but it's very difficult to make a business case for "improve modularity and extensibility" without a concrete use case behind it that can justify doing that refactoring beforehand. Whereas converting from Java to Kotlin can be done fairly easily on a piecemeal basis over time by devs in their free time. > The solution to that is not easy, nor is it fast. It's a process of making small, incremental improvements to the cleanliness of TR with minimal risk to stability. That actually sounds like what would happen during a conversion to Kotlin. In fact, that's basically what I did when I converted TrafficRouter.java to Kotlin yesterday: https://github.com/rawlinp/trafficcontrol/commits/kotlin-tr. The auto-conversion was pretty straightforward -- there were only 3 errors I had to fix manually for it to compile. The rest was just fixing most of the warnings/suggestions pointed out by IntelliJ, most of which helped clean things up a bit, making it more readable and less verbose. Combing over the results of the conversion like that is also a great way to find even more things that can be cleaned up, which in most cases would go ignored because no one is just combing over TR looking for things to clean up. > Somewhat less of a concern is shrinking the pool of developers by choosing a less mature, less widely adopted language. I understand Kotlin is on the rise and is in demand but is still dwarfed by the 20+ years of Java. I agree this is also less of a concern -- I think Java devs can learn Kotlin pretty quickly because Kotlin is basically just an enhanced version of Java. Also, the community did choose to replace the original Traffic Ops with a language 20+ years it's junior, and that was a tremendous amount of work compared to what converting Java to Kotlin would be. One of the main tenets of a CDN is reliability, and all of the features around null safety in Kotlin (https://kotlinlang.org/docs/null-safety.html) can seriously help out there, especially if the entire codebase was Kotlin. While the codebase is a mix of the two, there is more chance of a NullPointerException coming from Java code because all Java references are nullable, and Kotlin needs to maintain that interoperability. Some of the nastier bugs in TR have stemmed from NullPointerExceptions due to not knowing that an argument was nullable, and with Kotlin's built-in nullable vs non-nullable types, that problem is way less likely to occur. If we were to develop TR 2.0 for instance (instead of just converting TR 1.0), I'd hope we could use a language like Kotlin which has solved the Billion Dollar Mistake. - Rawlin On Tue, Jun 22, 2021 at 9:14 PM Eric Friedrich <[email protected]> wrote: > > Zach- > > First of all, thanks for trying to build a bigger tent here, I really > appreciate that effort. > > (Personal comments, not as chair) > > I agree that Traffic Router is difficult to work on, and that presents a > large barrier to entry. However, I don't think that is a result of language > choice. Rather, I think the TR code itself is badly in need of a clean up, > to improve modularity and to give some thought to extensibility. > > Recently one of my coworkers added a new feature to TR. He is incredibly > experienced with Java, but had many problems trying to create a clean > integration. > > Converting TR to Kotlin wouldn't improve or solve any of these issues. I > fear that even as we try to attract new contributors, they would be > frustrated with the state of TR and not continue as ongoing contributors. > > The solution to that is not easy, nor is it fast. It's a process of making > small, incremental improvements to the cleanliness of TR with minimal risk > to stability. > > > Somewhat less of a concern is shrinking the pool of developers by choosing > a less mature, less widely adopted language. I understand Kotlin is on the > rise and is in demand but is still dwarfed by the 20+ years of Java. > > --Eric > > > > On Tue, Jun 22, 2021, 7:14 PM Chris Lemmons <[email protected]> wrote: > > > I don't have a strong opinion on Kotlin; I haven't used it to any real > > degree. I do know it interoperates with the Java API and compiles down > > to the JVM. So in terms of the openness of the platform, it's not any > > more "open" than Oracle's OpenJDK. It does compile down to native > > code, but then we'd need to replace (or convert and maintain) all our > > dependent libraries. > > > > So if Kotlin helps with maintainability, I say we go for it. I don't > > know that we're winning any additional openness we don't already have, > > though. > > > > On Tue, Jun 22, 2021 at 4:44 PM Taylor Frey <[email protected]> wrote: > > > > > > I too +1 > > > > > > My experience porting a Java project to Kotlin was specific to Android in > > > the past (re: years ago). I recall my general impression of Kotlin to > > have > > > some extraneous and unnecessary syntactic sugar (What's up with the > > > for/loop keywords?), but it was an overall solid language. I appreciate > > the > > > terseness and brevity of things like variable declarations w/ implicit > > data > > > types and `data classes`, which addresses a long standing complaint about > > > Java's overly verbose syntax. Language aside, the automated porting back > > > then wasn't exactly perfect, but a few things have changed since then; 1) > > > the language specification has solidified over the years, 2) tooling has > > > matured, and 3) is manageable to manually intervene if necessary. > > > > > > > As a side note, because of Oracle's aggressive legal practices, and > > > because > > > they really do want you to think that they own Java (see: Google LLC > > v. > > > Oracle America, Inc.), using Java in Apache Traffic Control is not > > > really > > > in the spirit of free software. Kotlin is an Apache 2.0-licensed > > > project, > > > so switching to Kotlin would be a true FOSS win for the ATC > > community. > > > > > > I think the true benefit is moving away from the Java API, which is under > > > such contention, without changing underlying implementation (such as a > > > transition to another, non-JVM, language might incur). > > > > > > On Tue, Jun 22, 2021 at 11:42 AM Chatterjee, Srijeet > > > <[email protected]> wrote: > > > > > > > +1 > > > > Sounds like a fun project! > > > > > > > > --Srijeet > > > > > > > > On 6/21/21, 8:43 PM, "Zach Hoffman" <[email protected]> wrote: > > > > > > > > Hi Traffic Control! > > > > > > > > As you all may know, the current implementation of Traffic Router > > runs > > > > on > > > > Java 8. While coding directly in Java is still done, there are some > > > > reasons > > > > to be critical of Java. > > > > > > > > Java often has very verbose syntax when trying to accomplish simple > > > > things. > > > > This has made the Traffic Router codebase grow larger over time, > > > > leading to > > > > maintainability issues. Also, Java suffers from lack of > > compile-time > > > > safety > > > > in some ways that more modern languages do not. For these reasons, > > and > > > > because Java is a very old language, some developers who may > > otherwise > > > > be > > > > interested in contributing to Apache Traffic Control may be > > > > disinterested > > > > contributing to Traffic Router in particular, simply because they > > want > > > > to > > > > work with more modern languages that do not have the issues that > > Java > > > > does. > > > > > > > > Kotlin, a JVM language devised by Jetbrains with the goal of > > tackling > > > > these > > > > problems, has exploded in popularity in recent years, and Kotlin is > > > > becoming a standard way to use the JVM, with Google choosing it as > > the > > > > preferred language to for developing Android apps. More > > importantly, > > > > as the > > > > Intellij IDEA Kotlin plugin lets you convert Java sources to Kotlin > > > > (either > > > > at the file level or an entire project, or anywhere in between), > > > > Kotlin has > > > > become a low-effort way to decrease tech debt across large Java > > > > projects. > > > > > > > > Back to Traffic Router: In order to gauge how we would benefit from > > > > converting Traffic Router to Kotlin (it really is a matter of > > > > *converting*, > > > > not rewriting), I converted all of the tests in the Traffic Router > > > > "Core" > > > > module to Kotlin. You can see the result here (as you can see from > > > > GitHub > > > > Actions, the TR tests all pass): < > > > > > > > > > > https://urldefense.com/v3/__https://github.com/zrhoffman/trafficcontrol/commits/tr-kotlin__;!!CQl3mcHX2A!UCz457i9stX5A-AP8jvvWo21Rqa43JRsC1jQt_fo5nb07raZxByUR9gAGVPZTI4tGhalAel2$ > > > > > > > > > > > > > Some observations: > > > > - Without any putting any effort into optimizing the existing code, > > > > lines > > > > of code shrunk from 10572 in Java to 10217 in Kotlin. See: < > > > > > > > > > > https://urldefense.com/v3/__https://github.com/zrhoffman/trafficcontrol/commit/5add06bccc__;!!CQl3mcHX2A!UCz457i9stX5A-AP8jvvWo21Rqa43JRsC1jQt_fo5nb07raZxByUR9gAGVPZTI4tGqGQTevX$ > > > > > > > > > - Because it now includes the Kotlin standard library, the Traffic > > > > Router > > > > RPM size increases from 48MB to 58MB. > > > > - The converted sources benefit from Kotlin's null safety and type > > > > safety > > > > (avoiding wildcard types). See < > > > > > > > > > > https://urldefense.com/v3/__https://github.com/zrhoffman/trafficcontrol/commit/0c2eec39d9__;!!CQl3mcHX2A!UCz457i9stX5A-AP8jvvWo21Rqa43JRsC1jQt_fo5nb07raZxByUR9gAGVPZTI4tGjjMNj-F$ > > > > > (Kotlin > > > > error resolution) and < > > > > > > > > > > https://urldefense.com/v3/__https://github.com/zrhoffman/trafficcontrol/commit/d8a0fd3bca__;!!CQl3mcHX2A!UCz457i9stX5A-AP8jvvWo21Rqa43JRsC1jQt_fo5nb07raZxByUR9gAGVPZTI4tGoysImMb$ > > > > > (Kotlin > > > > warning resolution) for the changes involved. > > > > > > > > As a side note, because of Oracle's aggressive legal practices, and > > > > because > > > > they really do want you to think that they own Java (see: Google > > LLC v. > > > > Oracle America, Inc.), using Java in Apache Traffic Control is not > > > > really > > > > in the spirit of free software. Kotlin is an Apache 2.0-licensed > > > > project, > > > > so switching to Kotlin would be a true FOSS win for the ATC > > community. > > > > > > > > So, converting the rest of Traffic Router would be relatively fast > > and > > > > easy, would result in *no* functionality gained or lost, would > > leave TR > > > > usage totally unchanged, would make development more enjoyable for > > > > current > > > > TR devs, and would maybe catch the interest of additional devs who > > > > otherwise may not be interested in Traffic Router. > > > > > > > > How does this sound? > > > > > > > > -Zach > > > > > > > > > >
