7 ms·

What is wrong with Java's tooling?

xmcqdpt2 3y ago
Too much XML? Seriously though what's a decent Java build tool? Hacking on Gradle means having to learn another PL entirely. Maven? Then say I want to publish a library for others to use from their own java project, how do I do that? I've never actually done it, but that page https://maven.apache.org/repository/guide-central-repository-upload.html https://maven.apache.org/repository/guide-central-repository... seems awfully complicated compared to say https://doc.rust-lang.org/cargo/reference/publishing.html https://doc.rust-lang.org/cargo/reference/publishing.html or even the pip equivalent. Granted, working on a well set up java project is nice, but the setup process is not simple.
- paulddraper 3y ago
  So you don't like a config language like XML because _____ and you don't like a DSL like Groovy because _____. What is acceptable? P.S. For easier publishing, use a different repo e.g. Artifactory instead of Maven Central.
- pjmlp 3y ago
  Not only do Maven and Gradle support binary libraries (including native code) instead of waiting to build the whole universe on each checkout, their plugins for mixed language development are way better than writing build.rs scripts.
- alex_smart 3y ago
  That maven link is perhaps not the most useful, but it is not hard to find better-written articles. For example- https://docs.github.com/en/actions/publishing-packages/publishing-java-packages-with-maven https://docs.github.com/en/actions/publishing-packages/publi... The steps are roughly: 1. Configure the repository you want to push to. 2. Set up your account with the repository. 3. Configure your credentials. 4. Deploy.
- chriswarbo 3y ago
  I actually prefer using Maven and its giant XML files: at least they're declarative, and are easily parsed, transformed, generated, etc. by scripts. Most attempted replacements (Gradle, SBT, etc.) stick with largely the same model (i.e. no extra functionality) but use a full programming language for their "config" (Groovy, Scala, etc.). The latter gives us a "config" that's subject to Rice's theorem: it's essentially opaque, with no way of knowing what it will do other than executing it. An example I ran into at work: there's no way to list the dependencies of an SBT project (in order to set up an offline sandbox, in our case for reproducible building with Nix). SBT provides commands which claim to do that, but config files often append dependencies based on arbitrary logic; e.g. we had some like "when running unit tests, add this mocking plugin"; since "list dependencies" doesn't run the unit tests, that plugin dependency was missing from the sandbox. I can't speak to the "publishing" situation for Java, I don't have any experience with it. All of our projects transparently pushed/pulled via a Nix cache, whether we used Java, Scala, Python, NodeJS, etc.
  - Tainnor 3y ago
    > there's no way to list the dependencies of an SBT project (in order to set up an offline sandbox, in our case for reproducible building with Nix) Well, the same is true for Maven. I know because I've tried. Plugins can download arbitrary dependencies at execution time. That's where the point about Rice's theorem falls apart: it applies as much to maven as to Gradle because maven plugins can do whatever they want.
    - chopin 3y ago
      But that can't be runtime dependencies to your code? I've written a couple of Maven plugins and you must declare your dependencies explicitely even for those. Pulling in stuff dynamically would be possible but not very clever.
      - Tainnor 3y ago
        The maven surefire plugin downloads dependencies dynamically depending on the kind of tests it finds. Is it not very clever? I agree. But it's one of the most popular maven plugins.
- gmfawcett 3y ago
  Yes, Maven. Just embrace it, and move on: the decision will pay dividends.
pyrale 3y ago
If you ask for my personal experience: - The community leans a lot on configuration over code, and that's annoying. Sometimes, a hardcoded string in your conf could have been a hardcoded string directly in the code. - Sometimes, dependency injection systems are so abstract that knowing which class is depended on in a specific runtime instance becomes a pain in the ass. - Your idea just won't load class x, the obvious "clean cache" doesn't work as advertised, and you're back to stack overflow to know which couple of file you need to get rid of. That stuff happens just often enough for you to have a lingering feeling of annoyance, but not often enough for you to remember the exact files. - Sure, idea is great. But in <other language> I was fine with just vim. The LSP was a great help, not a lifesaver. - Unit testing is great. Annotations are great. Don't you enjoy that unit test class with a dozen annotations spanning 20 lines just above? - Hibernate. Spring too, while we're at it. Not sure whether you consider this one squarely fits the tooling box.
- systems_glitch 3y ago
  These are job security features :P Seriously though, the hours spent fighting dependency injection and Hibernate issues alone, when working on a really big Java project, could've been a full-time job. For maximum fun, I once worked on a large ERP system that started out as a Struts 2/Hibernate 3/Jetty project and had an entire Rails app bolted on using JRuby. Some of the stuff in the JRuby side was injected thru Spring. ActiveRecord had to talk through Hibernate.
  - patmorgan23 3y ago
    Gross
    - systems_glitch 3y ago
      I know, right? Hundreds of millions of dollars flowed through that system every year. I got the ball rolling on killing that design with fire after we hit one of the pathological limits in IIRC Hibernate 3 and thread safety.
- Tainnor 3y ago
layer8 3y ago
Maven is awfully slow and awfully stateful (plugins or multiple executions interfering with each other), has too many quirks, and documentation is lacking. Gradle is imperative and also stateful. Dependency injection and annotation-driven development is “magic happens here” that is hard to analyze when something doesn’t work, and hard to reason about in the sense of building a proof that it will always behave in the correct and intended way.
- grumpyprole 3y ago
  Don't forget Scala's SBT, an awful design with lots of additional bad taste added on top.
- alex_smart 3y ago
  > Dependency injection and annotation-driven development is “magic happens here” that is hard to analyze when something doesn’t work I don't quite get the criticism against annotations. Metaprogramming and code as data seem to get a lot of love in the context of lisp, python or ruby, but a lot of hate when it happens to be done in Java. I absolutely love the powers that reflection, annotations etc give me. The difficulty of analyzing dependency injection and "magic happens here" is overstated. Just run the code in the debugger. And if you are having problems with the auto-configuration stuff, you can always selectively disable it and explicitly define the beans you need.
  - layer8 3y ago
    > Just run the code in the debugger. How do you set a breakpoint on an annotation? You can’t, and that’s the issue. You can’t reason about annotations in the precise way you can reason about library calls.
    - alex_smart 3y ago
      > How do you set a breakpoint on an annotation? You can’t, and that’s the issue. You can set a breakpoint on your normal method and you can see if any proxy object was introduced by the annotation in the call stack and set a breakpoint there. You can also just see the usages of the annotation to see where and how it is being used and set a breakpoint there. Anyway, going back to my original question, similar criticism is equally valid when you do metaprogramming in lisp/python/ruby. Why are these concerns only raised in the context of Java?

Too much XML? Seriously though what's a decent Java build tool? Hacking on Gradle means having to learn another PL entirely. Maven? Then say I want to publish a library for others to use from their own java project, how do I do that? I've never actually done it, but that page https://maven.apache.org/repository/guide-central-repository-upload.html https://maven.apache.org/repository/guide-central-repository... seems awfully complicated compared to say https://doc.rust-lang.org/cargo/reference/publishing.html https://doc.rust-lang.org/cargo/reference/publishing.html or even the pip equivalent. Granted, working on a well set up java project is nice, but the setup process is not simple.

paulddraper 3y ago
So you don't like a config language like XML because _____ and you don't like a DSL like Groovy because _____. What is acceptable? P.S. For easier publishing, use a different repo e.g. Artifactory instead of Maven Central.
pjmlp 3y ago
Not only do Maven and Gradle support binary libraries (including native code) instead of waiting to build the whole universe on each checkout, their plugins for mixed language development are way better than writing build.rs scripts.
alex_smart 3y ago
That maven link is perhaps not the most useful, but it is not hard to find better-written articles. For example- https://docs.github.com/en/actions/publishing-packages/publishing-java-packages-with-maven https://docs.github.com/en/actions/publishing-packages/publi... The steps are roughly: 1. Configure the repository you want to push to. 2. Set up your account with the repository. 3. Configure your credentials. 4. Deploy.
chriswarbo 3y ago
I actually prefer using Maven and its giant XML files: at least they're declarative, and are easily parsed, transformed, generated, etc. by scripts. Most attempted replacements (Gradle, SBT, etc.) stick with largely the same model (i.e. no extra functionality) but use a full programming language for their "config" (Groovy, Scala, etc.). The latter gives us a "config" that's subject to Rice's theorem: it's essentially opaque, with no way of knowing what it will do other than executing it. An example I ran into at work: there's no way to list the dependencies of an SBT project (in order to set up an offline sandbox, in our case for reproducible building with Nix). SBT provides commands which claim to do that, but config files often append dependencies based on arbitrary logic; e.g. we had some like "when running unit tests, add this mocking plugin"; since "list dependencies" doesn't run the unit tests, that plugin dependency was missing from the sandbox. I can't speak to the "publishing" situation for Java, I don't have any experience with it. All of our projects transparently pushed/pulled via a Nix cache, whether we used Java, Scala, Python, NodeJS, etc.
- Tainnor 3y ago
  > there's no way to list the dependencies of an SBT project (in order to set up an offline sandbox, in our case for reproducible building with Nix) Well, the same is true for Maven. I know because I've tried. Plugins can download arbitrary dependencies at execution time. That's where the point about Rice's theorem falls apart: it applies as much to maven as to Gradle because maven plugins can do whatever they want.
  - chopin 3y ago
    But that can't be runtime dependencies to your code? I've written a couple of Maven plugins and you must declare your dependencies explicitely even for those. Pulling in stuff dynamically would be possible but not very clever.
    - Tainnor 3y ago
      The maven surefire plugin downloads dependencies dynamically depending on the kind of tests it finds. Is it not very clever? I agree. But it's one of the most popular maven plugins.
gmfawcett 3y ago
Yes, Maven. Just embrace it, and move on: the decision will pay dividends.

pyrale 3y ago

If you ask for my personal experience: - The community leans a lot on configuration over code, and that's annoying. Sometimes, a hardcoded string in your conf could have been a hardcoded string directly in the code. - Sometimes, dependency injection systems are so abstract that knowing which class is depended on in a specific runtime instance becomes a pain in the ass. - Your idea just won't load class x, the obvious "clean cache" doesn't work as advertised, and you're back to stack overflow to know which couple of file you need to get rid of. That stuff happens just often enough for you to have a lingering feeling of annoyance, but not often enough for you to remember the exact files. - Sure, idea is great. But in <other language> I was fine with just vim. The LSP was a great help, not a lifesaver. - Unit testing is great. Annotations are great. Don't you enjoy that unit test class with a dozen annotations spanning 20 lines just above? - Hibernate. Spring too, while we're at it. Not sure whether you consider this one squarely fits the tooling box.

systems_glitch 3y ago
These are job security features :P Seriously though, the hours spent fighting dependency injection and Hibernate issues alone, when working on a really big Java project, could've been a full-time job. For maximum fun, I once worked on a large ERP system that started out as a Struts 2/Hibernate 3/Jetty project and had an entire Rails app bolted on using JRuby. Some of the stuff in the JRuby side was injected thru Spring. ActiveRecord had to talk through Hibernate.
- patmorgan23 3y ago
  Gross
  - systems_glitch 3y ago
    I know, right? Hundreds of millions of dollars flowed through that system every year. I got the ball rolling on killing that design with fire after we hit one of the pathological limits in IIRC Hibernate 3 and thread safety.
Tainnor 3y ago

layer8 3y ago

Maven is awfully slow and awfully stateful (plugins or multiple executions interfering with each other), has too many quirks, and documentation is lacking. Gradle is imperative and also stateful. Dependency injection and annotation-driven development is “magic happens here” that is hard to analyze when something doesn’t work, and hard to reason about in the sense of building a proof that it will always behave in the correct and intended way.

grumpyprole 3y ago
Don't forget Scala's SBT, an awful design with lots of additional bad taste added on top.
alex_smart 3y ago
> Dependency injection and annotation-driven development is “magic happens here” that is hard to analyze when something doesn’t work I don't quite get the criticism against annotations. Metaprogramming and code as data seem to get a lot of love in the context of lisp, python or ruby, but a lot of hate when it happens to be done in Java. I absolutely love the powers that reflection, annotations etc give me. The difficulty of analyzing dependency injection and "magic happens here" is overstated. Just run the code in the debugger. And if you are having problems with the auto-configuration stuff, you can always selectively disable it and explicitly define the beans you need.
- layer8 3y ago
  > Just run the code in the debugger. How do you set a breakpoint on an annotation? You can’t, and that’s the issue. You can’t reason about annotations in the precise way you can reason about library calls.
  - alex_smart 3y ago
    > How do you set a breakpoint on an annotation? You can’t, and that’s the issue. You can set a breakpoint on your normal method and you can see if any proxy object was introduced by the annotation in the call stack and set a breakpoint there. You can also just see the usages of the annotation to see where and how it is being used and set a breakpoint there. Anyway, going back to my original question, similar criticism is equally valid when you do metaprogramming in lisp/python/ruby. Why are these concerns only raised in the context of Java?