Why no package manager for Kotlin (or java)?

Hello guys,

I’ve just started to learn Kotlin from PHP community with no Java background. I’m trying to find out something like composer in PHP or npm or yarn in NodeJS, those packages dependency management tool in Kotlin (or java, actually I don’t care about java…).
I found a post in StackOverflow, it seems such tool in java world is maven. But I can not figure out what it really does, without saying they use gradle nowadays.
I mean I want a tool:
<Tool> search <keyword> can list me libraries contains <keyword>
<Tool> show <package> can show me the <package> details with versions list
<Tool> install <package>@<version> can check dependencies and install the <package> automatically for the specified <version>

And for now it seems in Java world (Kotlin), I should write down:

dependencies {
    compile "org.jetbrains.anko:anko:$anko_version"

by hand, and try to figure out $anko_version by myself. I don’t see it is wisdom (or maybe I don’t know the convenient way.)

It seems I didn’t get the point.


Sorry, WAT?
Java packaging and dependency management is two orders wuperior to anything you can find for JavaScript (I don’t know about PHP, but I think that situation there is not better). Kotlin mostly uses gradle as a build and dependency management tool (you can also use maven, but it is not recommended if you are not forced to do so).

In Java you do not have local environment where you can install packages, you use packages directly and they are downloaded on-demand, so install action does not make sense. For the rest see maven central.

The example you have shown is taken from gradle build script and version could be ommited. In this case the latest available version will be used, but of course it is not recommended since in that case you can’t control what version you use.


I actually try to understand why there’s the difference. I mean, Ex.:
Ubuntu linux package: apt-get install
Python lib: pip install
Golang lib: go get
PHP lib: composer require
NodeJs lib: npm or yarn add

Maybe because java needs to compile the code. (But then I thought golang also need to do compiling…)
So maybe java has a lot and large libraries? (So that’s why it requires downloaded on-demand)

Not quite sure…

I am not sure where your problem is. If you want to know the build/dependency tool for kotlin, it is gradle. The reason for maven support or just some basic build system in IDEs is simple. Maven is supported to make switching from java possible as a lot of Java projects are build using maven. And basic build systems in IDEs just make sense as it makes it a lot easier for people to learn programming without having to learn an entire build system as well.

1 Like

I think that that misunderstanding comes from the fact that Java does have dependency management and build system while JS, Python, etc do not.

Just believe me that after java, JS or Python “environment” looks like stone hammer. In gradle/maven you con not only have different dependency versions for different projects, but in fact different transitive dependency versions in the same project. And you do not need to think about “installing” packages at all. Just download the code and the build system manages dependencies itself.

1 Like

Java/Kotlin get compiled into packages (JARs, WARs, etc.). The build tools, like Gradle, do dependency management. You use versions in dependencies to prevent version updates from breaking your code. When you do a build, your dependencies get downloaded into a shared repository directory (~/.m2/repository by default). When you package up the build for deployment to a server, those dependencies get copied into the package, making it a stand-alone deployment.

1 Like

I think it’s probably because Kotlin takes itself as wrapper of java or js, and it’s not a script language. As more and more pure Kotlin packages come up, we probably need a package manager. I expect Kotlin could have OS/Platform agnostic packages. It may have platform specific implementations, but from user api perspective, it suppose to be same.

Kotlin utilizes maven/gradle as a package manager. It works quite well for any type of module.


Up. Would be nice to have a good package manager for Kotlin.

Both Maven and Gradle are total garbage.

1 Like

That’s not a very constructive comment, can you mention what would a nice package manager do that gradle/maven don’t?


The JS package manager or even the Dart (Flutter) package manager looks more clean to me.
Gradle has plenty of “plugins” which do lots of magic stuff.

For example js:

  • package.json
  • package-lock.json
  • node-modules

That’s all. It makes the Dockerization process so flawless and easy because you know what to cache.
And I am not even a js fan. I prefer Kotlin server side.

Now gradle:

  • build.gradle.kts
  • gradlew
  • (gradlew.bat)
  • .gradle/
  • gradle/
  • settings.gradle.kts
  • (gradle.properties)
  • packages are stored somewhere in the home folder

At least the Gradle script looks somehow clean.

Now how to initialize:
npm init

Just use the IDE
install gradle cli (which only a few people do)
gradle init

NPM has many limitations, from the non cached libraries that are duplicated for each project, to almost no complex customization. No wonder why the Angular team had to create an entire new ecosystem above it (the @angular/cli).

Indeed Gradle is more complex at first glance, but whatever NPM can do, Gradle can do it better and in a more scalable manner.

With Gradle you can stop replying on unmaintainable shell scripts and centralize the building logic of your project even when it goes polyglot (dont’t forget Kotlin is multiplatform).

Also if you have Gradle installed, a mere build.gradle.kts Is enough, the wrapper stuff is needed to install and cache Gradle, mostly for CI/CD.

Furthermore Kotlin had JVM interoperability in mind as first (now largely achieved) objective and it made sense to use the same tools to avoid conflicts for developers migrating from Java/Scala/Groovy to Kotlin.

Last but not least, Gradle is a free, scalable, production ready, general purpose, multiplatform automation tool. Why build a new one from scratch when the customization degree of the Gradle Plugion API is literally limitless?


I’d add a question mark or two to Gradle being ‘production ready’… We’ve been using it for many of our projects, and while it’s powerful and concise, it causes us a lot of headaches.

I don’t know whether it’s Gradle itself, or how IDEA interacts with it, but as compared with Maven it seems to need much longer build times and much more frequent re-indexing and other housekeeping tasks that slow or freeze the IDE.

Even worse, several of us have had big problems with it not picking up dependencies and/or their updates. Telling Gradle to reload its dependencies doesn’t help; the only solutions we’ve found involve deleting the build folder and/or the .idea folder, restarting IDEA, and rebuilding everything from scratch.

I’ve also had trouble with it persisting in trying to build modules I’ve removed from IDEA (and refusing to remove them from the Gradle pane), and several similar issues. All told, it’s probably cost me many hours of time this year.

Maven may be limited and verbose, but it’s been much more stable in my experience. (And you need a Maven repo anyway, as Gradle just sits on top of that.)

1 Like

My biggest 2 problems with Gradle:

  1. All tutorials about it expect people to already know maven, ant or what ever

  2. The Kotlin version is the obviously better choice if you also program in Kotlin but you will often only find groovy explanations. There is this rule that is sometimes useful “only one way to do a thing” well Gradle haves two different languages.

I’m trying to like Gradle because I understand that it’s powerful but I can do so much with Java /Kotlin and it feels easy, Gradle on the other hand just turns my code into jars and it feels so complicated (I don’t say that any alternative is better, don’t get me wrong, atleast it’s not ugly xml).

It’s also not helpful that it haves second class support by intelij, the default is the own project type of intelij, not Gradle. I would like to see Intelij suggesting to create a project with Gradle (Kotlin version) for atleast Kotlin projects (maybe it happen with newer updates, I didn’t create a new project for a while).

1 Like

Yes, that is a real big issue. I do remember the headaches of my first approaches to Gradle, especially in Groovy.

Kotlin helps a lot to understand the way Gradle works, but most of the time you end up with examples in Groovy and you want to use the Kotlin DSL!

Also IntelliJ allows to create Gradle projects in Kotlin DSL both from the Gradle section or the Kotlin section in the new project wizard. Check them out!


Those problems are unfortunately related to IntelliJ, but I must say that have been solved few months ago.
Update if you haven’t!

Also maybe you are using Android Studio which is a little behind IntelliJ. It take a little more more time for AS to get the latest IntelliJ features and bug fixes.

1 Like

Why I don’t like Gradle.

  1. brew install gradle - it installs openjdk as a dependency, even though I already had HotSpot JDK installed, but ok, whatever.

  2. gradle init - and my project is polluted with garbage - gradle.build (ok that one is expected) and also - gradlew, gradlew.bat, gradle/wrapper, config.something.gradle, properties.gradle, .gitattributes. WTF is that? Tiny build utility the whole point of which is to sit somewhere in background and don’t interrupt me - that utility with the very first step - init - put tons of garbage in my project, and not in some dark corner of the project in hidden directory, but at the very top?!

  3. Ok, I manually removed all that garbage, leaving only gradle.build, trying gradle run from the console - all good.

  4. Time to connect with Intelij IDEA, creating/importing project. IDEA slowly thinking for a minute, then - regenerates all that gradle garbage again. All the gradle files I manually deleted - are now again in the project. IDEA re-generates that gradle garbage every time I manually delete it.

  5. Ok after asking - some people told me that I need to change setting in IDEA so it will take gradle from predefined location. I changed - and it worked, for couple of minutes, until I updated gradle.build - and suddenly it became red in IDEA, all sorts of errors (still works fine from console).

So I’m using old Maven, it’s also bad, but not as bad as Gradle.

1 Like

Oh, it is brilliant. Why I do not like system:

  1. I do not understand how it works.
  2. I cut pieces from it randomly.
  3. It does not work the way I think it should.


You can run kotlin from a command line compiler. Please stick to it, you can do everything with simple make file.


If I see a car that looks bad and can barely move - I don’t need to understand how its engine works to decide that I don’t want it.

I know Java/Kotlin, Ruby, TypeScript, Elixir, Julia.

Gradle and Maven are one of the worst tools I ever saw. I know Maven of course, it’s impossible to avoid it if you work with Java, but thankfully it’s possible to avoid Gradle.

If you can do everything with a simple makefile, then you don’t need Gradle!

But if you have multiple, versioned projects with interdependencies, if you have your own repository (or multiple ones for snapshots, releases, &c), if you want to build ‘fat’ jars or wars, if you generate docs and other artefacts, if you have test-only dependencies or partial exclusions, or any of a huge range of requirements more complex than just ‘compile these classes into a jar’, then you’re either going to need some not-at-all-simple makefiles and scripts, or you’re going to need an automation tool such as Maven or Gradle.

The needs that they fulfil are real and important for medium- or large-scale development. They could arguably be much more stable, reliable, elegant, comprehensible, discoverable, and inconspicuous… but they’re popular because they fulfil a need, and there’s no obvious better solution. (Unfortunately.)

Though I do wonder whether the problem is that they try to do too much. For example, from my limited understanding of Maven, I wonder whether it might be better if the versioning/dependency/repository side of things were split into a separate tool from the build/automation/plugin/execution side.