3 ms·

> Can you elaborate on why you think the roller skate is squeaky and about to topple? Maybe 'topple' is taking things a bit too far since Java works far more o

> Can you elaborate on why you think the roller skate is squeaky and about to topple? Maybe 'topple' is taking things a bit too far since Java works far more often than it doesn't. How about 'teetering'? But the roller skate is most definitely squeaky, and that's mainly because of the lack of help and organization that the built-in java systems give. I can reference two incompatible versions of libraries and the classloader will blithely load from both of them. You can claim "pilot error", but I reply that it's 2017 and we have huge memories and processors that we aren't using effectively to abstract the problem. Why are we allowed to slam together these huge, sloppy code edifices atop a system that otherwise puts so much focus on security and safety? Along with the standard "jar hell" arguments, I've got problems mixing cantankerous legacy spring and pre-spring era jars with post Java 8, CDI, JavaEE, etc jars. I need to containerize/componentize these assets and keep them separate from one another because they don't play nice nice with each other. Sure, I can roll my own JarClassLoaders and build a separation between groups of jars by-hand, but I never would because I want the computer to do that work for me - hence "modules". In my opinion, if tools like Maven don't solve anything related to classloading in your book, then you are either: 1) off in your own corner rolling classpaths by hand and checking your .jar files into Git, or 2) you aren't working effectively at-scale on large software projects with groups of other people In my case, Gradle was a revelation - it is a Groovy DSL veneer over Ant and Ivy, and it makes rolling custom classloaders extremely pleasant. Maven is very unpleasant because of its declarative XML language, but the Maven artifact coordinate scheme was a brillant stroke. I'm happy the Gradle folks were so successful in melding the platform compatibility tools of Ant, the artifacts of Maven, and the expressiveness of Groovy into a build system that even a dummy like me can grok and use effectively.

vorg 9y ago
> Maven is very unpleasant because of its declarative XML language Maven was intended to be configured via a GUI. If you want to configure it directly, try Polyglot Maven at https://github.com/takari/polyglot-maven https://github.com/takari/polyglot-maven which is a very light wrapper around Maven enabling you to use many other languages instead, e.g. Scala, Clojure, and Ruby as well as Apache Groovy. The Gradle people marketed their product by slagging the XML which was never intended to be directly manipulated by humans. If you really want to use Gradle (and get a coffee whenever it builds something), it also lets you use Kotlin for writing build files.
- EdSharkey 9y ago
  > Maven was intended to be configured via a GUI. This is something I didn't know. Did the maven company, Sonatype, ever produce such a tool? It seemed to take years for Java IDE's to finally interoperate seamlessly with maven (was it 10 years for Eclipse?), and by then Gradle was popular and set to unseat it. I use Gradle daemon when performance becomes an issue, and Gradle is fast enough with that. Maven is no performance superstar. The maven plugin ecosystem also seemed impenetrable, whereas Gradle promoted plugin development and, lo and behold, they have a vibrant plugin ecosystem! The Maven XML language deserves to be slagged, it seemed designed to frustrate and hamstring the developer.
cocoapocoa 9y ago
No... maven has little to do with classloaders which are primarily a runtime concern.
- EdSharkey 9y ago
  The classloader at runtime has to get its configuration from somewhere; that configuration is usually a static list of jars in a folder. That long list jars in the WEB-INF/lib folder doesn't magically appear. Maven and Gradle have everything to do with runtime classloaders working properly and at-scale. Most developers don't know (or care) about all their transitive dependencies that get slurped into their projects.
  - cocoapocoa 9y ago
    What you've described is just one way a classloader can work, however, they can be implemented or hacked upon in a variety of ways. Sure - maven does the work of resolving/flattening the dependency graph and downloading the libs - but it simply isn't a classloader. That said, it might be possible to write a custom classloader which uses some bits of maven internally (provided there is a package to GAV index somewhere).
    - EdSharkey 9y ago
      > Sure - maven does the work of resolving/flattening the dependency graph and downloading the libs - but it simply isn't a classloader. Well, of course, but when was the last time you manually configured your classloader? How divorced are your classloaders from Maven, practically speaking? (That's what I was getting at - I wasn't trying for some pedantic sort of "maven constructs my java.lang.ClassLoader objects"-type thing.) By manually, I mean supplying a list of .jar files and folders, or writing code that pumped classes into a custom classloader? Practically speaking, for any non-toy-sized project most people don't bother with that business anymore. They make deployment units, uber/shadow jars, or launch from a tool like Gradle that rolls their classloader for them from a Maven repository. > That said, it might be possible to write a custom classloader which uses some bits of maven internally (provided there is a package to GAV index somewhere). Ant, Gradle, and to a lesser extent, Maven serve as fine Java application launchers in that their dependency resolution engines can be targeted at the classpath-related arguments on the java and javac command lines.
Tharkun 9y ago
I rather like the declarative style of Maven. Maybe I'm just resisting change, but I don't like gradle. It requires too much "programming" for a build tool. But I agree with your statement about Maven/Gradle's dependency resolution magic. The times where I've struggled with incompatible version conflicts and the like have not been numerous enough to count. A little bit of caution goes a long way, I think. Incidentally, the only times I have been affected by this were while using IBM or Oracle components which rely entirely too much on global and environment settings.

vorg 9y ago

> Maven is very unpleasant because of its declarative XML language Maven was intended to be configured via a GUI. If you want to configure it directly, try Polyglot Maven at https://github.com/takari/polyglot-maven https://github.com/takari/polyglot-maven which is a very light wrapper around Maven enabling you to use many other languages instead, e.g. Scala, Clojure, and Ruby as well as Apache Groovy. The Gradle people marketed their product by slagging the XML which was never intended to be directly manipulated by humans. If you really want to use Gradle (and get a coffee whenever it builds something), it also lets you use Kotlin for writing build files.

EdSharkey 9y ago
> Maven was intended to be configured via a GUI. This is something I didn't know. Did the maven company, Sonatype, ever produce such a tool? It seemed to take years for Java IDE's to finally interoperate seamlessly with maven (was it 10 years for Eclipse?), and by then Gradle was popular and set to unseat it. I use Gradle daemon when performance becomes an issue, and Gradle is fast enough with that. Maven is no performance superstar. The maven plugin ecosystem also seemed impenetrable, whereas Gradle promoted plugin development and, lo and behold, they have a vibrant plugin ecosystem! The Maven XML language deserves to be slagged, it seemed designed to frustrate and hamstring the developer.

cocoapocoa 9y ago

No... maven has little to do with classloaders which are primarily a runtime concern.

EdSharkey 9y ago
The classloader at runtime has to get its configuration from somewhere; that configuration is usually a static list of jars in a folder. That long list jars in the WEB-INF/lib folder doesn't magically appear. Maven and Gradle have everything to do with runtime classloaders working properly and at-scale. Most developers don't know (or care) about all their transitive dependencies that get slurped into their projects.
- cocoapocoa 9y ago
  What you've described is just one way a classloader can work, however, they can be implemented or hacked upon in a variety of ways. Sure - maven does the work of resolving/flattening the dependency graph and downloading the libs - but it simply isn't a classloader. That said, it might be possible to write a custom classloader which uses some bits of maven internally (provided there is a package to GAV index somewhere).
  - EdSharkey 9y ago
    > Sure - maven does the work of resolving/flattening the dependency graph and downloading the libs - but it simply isn't a classloader. Well, of course, but when was the last time you manually configured your classloader? How divorced are your classloaders from Maven, practically speaking? (That's what I was getting at - I wasn't trying for some pedantic sort of "maven constructs my java.lang.ClassLoader objects"-type thing.) By manually, I mean supplying a list of .jar files and folders, or writing code that pumped classes into a custom classloader? Practically speaking, for any non-toy-sized project most people don't bother with that business anymore. They make deployment units, uber/shadow jars, or launch from a tool like Gradle that rolls their classloader for them from a Maven repository. > That said, it might be possible to write a custom classloader which uses some bits of maven internally (provided there is a package to GAV index somewhere). Ant, Gradle, and to a lesser extent, Maven serve as fine Java application launchers in that their dependency resolution engines can be targeted at the classpath-related arguments on the java and javac command lines.

Tharkun 9y ago

I rather like the declarative style of Maven. Maybe I'm just resisting change, but I don't like gradle. It requires too much "programming" for a build tool. But I agree with your statement about Maven/Gradle's dependency resolution magic. The times where I've struggled with incompatible version conflicts and the like have not been numerous enough to count. A little bit of caution goes a long way, I think. Incidentally, the only times I have been affected by this were while using IBM or Oracle components which rely entirely too much on global and environment settings.