[davidjfelix]

* Use SDKMan for runtime and sdk management https://sdkman.io/

* Try to use Kotlin where allowed (Maybe unpopular and bad faith response given that you asked about Java, but I don't care -- kotlin's Java interop is way more seamless than Scala or Clojure to the point that its often not even noticable) https://kotlinlang.org/

* IntelliJ

* Spring is pretty popular, I've seen a lot of people using Vertx

* Square libraries like Okio, okhttp, retrofit, wire https://github.com/square

* If you're not using spring, use Dagger for DI https://dagger.dev/dev-guide/

* Overlook netflix abandonware (another unpopular opinion, I'm sure)

* Use gradle, not maven. Use kotlinscript as the config language, not groovy

[jillesvangurp]

I'd suggest using koin instead of Dagger. Dagger is alright but mainly popular in the Android world where Koin is the main alternative. However, Koin is native to Kotlin and a kotlin multiplatform project. So you can use it on Android, server development, IOS native, kotlin-js, etc.

[davidjfelix]

Nice, I haven't seen this one. We've been using Dagger to get people off of runtime DI for migrating to serverless, but I'll take a look. I assume it's compile-time DI?

[jillesvangurp]

Koin is a kotlin DSL. So no annotations, reflection, or compiler magic are needed. Basically it just instantiates things for you on demand and uses normal kotlin features like lambda functions, receiver objects, and property delegation.

You can inject a property by defining it as a koin injected property:

  class SomeClass {
    val foo by koinContext.inject<Foo>()
  }

And this is how you could create your koin context:

  class Bar()
  class Foo(bar: Bar)

  val myModule = module { 
    single { Bar() } 
    // get() knows the type from the argument position at compile time
    // and it looks the object from the context by type
    single { Foo(get()) }
  }

  // trigger this in your main or at application startup
  startKoin {
    modules(myModule)
  }

  // if you want to use inject, you can use a global variable for getting at the context
  val koinContext by lazy { GlobalContext.get() }

Modules can be tied to life cycles on Android and there are a few more features like being clever about co-routine scopes. But there's not a lot more to it in terms to using it. Very simple code to write. Low overhead. It's all just function calls.

Spring has a similar kotlin bean dsl that was added a while ago that you can use as an alternative to annotation processing (which is much slower).

[ditn]

It's not, it's a runtime service locator. In my experience it doesn't scale terribly well.

[sk5t]

Okio is very nice, and Okhttp is quite ergonoic, but I can't recommend Okhttp if true async is on the table (it's just blocking and threadpools under the covers).

[throwaway889900]

And Kotlin's coroutines are also "just blocking and threadpools under the covers", but people will still sing their praises. It's really not a killer for most people using it.

[davidjfelix]

Admittedly it's been awhile since I've written Java, so most of this is what I remember and what I've seen successful teams using -- got any links to a "true async" in Java? I was under the impression that all Java async work was backed by thread pools.

[sk5t]

Yes, anything that uses NIO / Netty / epoll / io_uring / etc. under the covers will do. There are several options--IIRC at least five choices are available, but these are the ones that come to mind:

https://openjdk.java.net/jeps/321

https://github.com/AsyncHttpClient/async-http-client

https://hc.apache.org/httpcomponents-client-5.1.x/examples-a...

[davidjfelix]

Thanks! I did a little research and it seems like there are some Kotlin coroutine to nio mappings (it looked like some were experimental though) and that OkHTTP is aiming to use coroutines, so I wonder if these will converge in the future.

What wasn't clear to me was if the coroutine/nio mashup still used threadpools because coroutines do.

[oauea]

> Try to use Kotlin where allowed

If you want a slow build and code that is fun to write but hell to read, that is good advice.

> Use kotlinscript as the config language

Extremely slow, that is.

[davidjfelix]

I disagree that it's easier to write than read. I tend to think Kotlin is much easier to read than java but harder to write because it tries to enforce good Java patterns at a language level.

I agree that these will slow down your build, but not significantly, and at the benefit of developer comfort to make changes. Incremental compilation largely erases these slowdowns.

[oauea]

Extension methods? Aliases? Countless more features that are designed to make your code hard to read & understand.

Build scripts are generally written once and executed hundreds or thousands of times. It makes far more sense to optimize their performance rather than ease of writing.

[davidjfelix]

It's okay to have a different opinion, but personally I'd never work at a place that did that. Java is already on thin ice and this is simply how I tolerate it and how I've seen successful java teams operate in cloud environments. If you are really seeing dramatic build times, I don't blame you for investigating them, but I'm not going to forgo years of DX improvements just because I heard on the internet one time that it's slower. I'm not going to keep arguing against your Kotlin vendetta, just don't use it, I don't care.

[oauea]

Java is on thin ice? It's the most popular business language, for good reason. You seem to have some very odd opinions, but that's fine. Bit rude to call people other people their opinions a "vendetta", though.

[davidjfelix]

The reason I'm being terse with you and perhaps a bit rude is that you started this reply thread by insulting my opinions for no reason and then continued to reply with what I believe to be both bad faith readings of my comments and naturally argumentative. I know HN values skepticism, but honestly it's tiresome. Anyways, here's my clarifying my previous comment. Please keep in mind that I fully expect you to read this in bad faith, so I've added sarcasm overtly.

Java, for me, personally, in my opinion, is on thin ice. I personally, in my opinion, would never work at a "Java shop" because in my opinion, personally, it conveys a disregard for technical suitability and individuality and supports the idea that engineers should be expendable. I believe, in my opinion, personally, that Java is, as you say, "popular" because it's forced on many workplaces by management. I don't think, in my opinion, personally, that it's a "bad" language, but its heavy use is not proportional to how "good" it is. I don't think my willingness to respond but refusal to be berated by an internet stranger is rude, and yes, I believe you have a vendetta, just like I have a vendetta against Java. If you have to use it, fine -- the above will insulate you from the really terrible things java does, in my opinion, personally. My real advice is don't use java, but see how that's a bad faith response? That's why I kept it to myself.

[Spooky23]

Java is the COBOL of the 21st century, in both the best and worst sense.

Java stacks will be running major companies long after everyone posting in HN today is dead and gone.

[tralarpa]

I agree. Build process with Kotlin feels slower. And the many features in Kotlin tempt me to write "syntactically clever" code that is harder to read later than plain stupid Java. Still love some of them :) although Java is catching up.