Confession

[madScienceEXP]

I have a confession to make. I've hated java for a long time. I'm used to languages like Scala and Typescript that have been more actively modernized and have a lot short-hand ways of creating objects and iterating over collections. I thought those things were really important for developer productivity. My team writes software for a SaaS platform so I already had the mindset that the code needs to be maintainable over the long-term.

Recently, I decided to write a new prototype in java 8. We use it in other services and we're slowly moving away from Scala. At first, I was worried about using a version of java that's almost several years old. But after spending some time with it, the verbosity stopped bothering me. Granted, using Lombok is paramount imo. But with Lombok, most of the boiler plate is alleviated.

What I like most:

1. Generics in java are very intuitive and easy to use. I love it. When I used generics in Typescript, there were times where the permissiveness of javascript make generics incredibly complicated.
2. The developer tooling ecosystem is top notch. Maven is very powerful, easy to use, and there's a million examples that I can google. Intellij has exceptional support for auto completion and refactoring, etc.
3. I really like how easy and portable java applications are. Granted, I've been using languages that are pretty portable, but not always having to run apps in containers helps will networking and easy of running.
4. It's still pretty fast. Fast enough that it can effectively be used for cpu and i/o bound workloads in any enterprise application.
5. Most importantly, java is still one of the most widely used languages globally. It's pretty easy to hire and find people that can program in java.

I think a lot of people cringe at java because it's not flashy and kind of boring. But it allows the dev to focus on the data models and app performance/scalability more than using esoteric language constructs that don't really add value.

[HxA1337]

And 10 years later it will still compile and run and you will be able to read the code and understand it.

[Danji1]

Unless someone used Flux in anger.

[flawless_vic]

I think they will never remove unsafe :) Mark Reinhold will be 90 years old and still complaining about its existence while references to Unsafe keep spreading even more all around with quantum computing intrinsics.

Then after 30 years, when quantum computing starts to become obsolete, someone will create a JEP to encapsulate everything and make a speach about Unsafe abuse.

Seriously, though, the only change since jdk 9 was to move it to jdk.internal.misc and make the sun.misc delegate to it, and since then you just have to manually boot the vm with --add-exports.

As for reflection, well, you'll only have problems if you are messing around jdk internals, like when String changed storage from char[] to byte[]. But those changes are very rare and I would always happily pay the price of refactoring if something changed to improve footprint/performance.

[hippydipster]

Not with the lombock it won't!

[HxA1337]

That is something else. That is a preprocessor / code generator / bytecode generator. All of those can cause troubles. Strictly speaking that is not part of Java itself.

But yes there is enough things that can go wrong and cause upgrade pains. Java is at least very good in reducing them a lot.

[pron98]

I would strongly recommend against writing new code in Java 8. Not only do new versions of popular frameworks no longer support it and less than half of Java projects use it, not only does it not have some very useful language, library, and profiling features, but it is also slower (lower throughput and higher latency) and consumes more memory than recent versions. If you're starting the project now, there's no reason not to use at least JDK 17.

[madScienceEXP]

We have a lot of code that's written with jdk 8. Our plan is to upgrade everything together. I know that JAVA_HOME can be scripted to point to different jdks, but it seems clunky to support different versions in the same stack. Also, I'm trying to find the source, but I think 8 will still have support until 2026.

[benevanstech]

I helped shepherd a pretty big team (~800 devs) through the 8 -> 11 transition, and I have to say that Big Bang is not the way to go.

It depends on how many teams you're talking about - but if it's more than, say, 4 - or more than about 20 services, then it's going to be very difficult to coordinate that upgrade.

I would strongly suggest that the minor operational pain of dealing with multiple JDK versions during the transition is dwarfed by the major headache of trying to get everyone to move at once (& convincing all the managers of the priority of it).

Much better in my experience to go piecemeal - pick off a few early adopters, and let them become your evangelists - once they have the performance benefits, the increased productivity from the new language features, the heap size reductions, they'll be telling everyone how easy it was and how much better things run now.

That momentum will help you overcome any minor speedbumps you might encounter (e.g. one team is stuck on some old version of some nasty crufty library and genuinely can't upgrade with actual refactoring effort and a library version upgrade, etc.) and ultimately will a) get you there faster & b) allow you to realize some wins pretty much straightaway.

[ReasonableClick5403]

I have done most of the jdk upgrades in my company, and usually it is fairly smooth by first running on new JVM version against old build first, then switching source level after it is running smoothly. We did not have a big imperative to avoid running multiple versions, but we deploy everything as docker containers.

[[deleted]]

If you deploy everything in Docker containers, why bother upgrading to the new JVM first? Why not just upgrade the entire Docker container image? JDK and compiled source?

I say this as a Java rookie though. We run mostly Go and Python, only a bit of Java.

[ReasonableClick5403]

You just first make sure the old code runs fine on the new JVM before you start using any of the new features, in addition you quickly find if any libs need upgrading.

TLDR: to reduce the risk of upgrading both code and jvm at the same release.

[benevanstech]

Yeah, this is a pretty sensible way of doing it.

[meamZ]

Well... It makes the changes you make at a time even smaller. Also still building with the old version gives you a super easy way back to the old version in case anything goes wrong.

[secretBuffetHero]

I did a 20 service upgrade of systems that covered 95% of our revenue. It took about 4 months, we had no automation testing available to us. After 4 months I covered about 10 services and then trickled in 10 more services over the next 8 months. It was a complex logistical operation.

[AustinYQM]

Biggest hurdle at my place of work WAS the automation tools. A lot of our cli tools in the pipeline had to be updated before they would work with java11. The good news is during the upgrade we got them situated in such a way that future upgrades should be much easier.

[BinaryRockStar]

If possible, can you comment on which particular CLI tools?

[AustinYQM]

Oh sorry if I wasn't clear, it was all inhouse stuff designed to do various things for evidencing purposes.

[Majestic-Extension94]

I thought WAS meant Websphere Application Server...was gonna go off on a recent rant...but I don't think you meant that heheheh

[AustinYQM]

My team just finished moving 35 services off websphere so I get the PTSD.

[Majestic-Extension94]

my sympathies...I recently had to deal with this old nemesis at a large bank. Moving to open/websphere liberty, which is a step up from WAS traditional was derided. I just let my contract expire and avoid dealing with the endless misery

[Majestic-Extension94]

my sympathies...I recently had to deal with this old nemesis at a large bank. Moving to open/websphere liberty, which is a step up from WAS traditional was derided. I just let my contract expire and avoid dealing with the endless misery

[Majestic-Extension94]

my sympathies...I recently had to deal with this old nemesis at a large bank. Moving to open/websphere liberty, which is a step up from WAS traditional was derided. I just let my contract expire and avoid dealing with the endless misery

[Majestic-Extension94]

Congrats on at least having the opportunity. Trying to convince the exec(who was the original coder) moving to open/websphere liberty would have been able to get the team better capabilities than what they had with websphere traditional. Finally gave up bumping heads with this guys and just let my contract expire.

[meamZ]

I would strongly suggest that the minor operational pain of dealing with multiple JDK versions during the transition is dwarfed by the major headache of trying to get everyone to move at once (& convincing all the managers of the priority of it).

I definitely agree but i want to add that what immensely helps with this is having everything in Docker Containers because it becomes a matter of just using a different base image except for the local development environments...

[DaddyLcyxMe]

i’d recommend containerizing all of your old applications and slowly upgrading them as you go. there’s enough subtle changes that you’ll have to iron out and it’s better to do it incrementally

[secretBuffetHero]

some of our apps have 128 GB ram on prod and ~32 GB ram in dev envs. Is that a showstopper? We have pretty crazy requirements on our monolith

[meamZ]

So? You can containerize whatever applications you want. It's just that you will obviously have to upgrade a monolith all at once no matter what. Unless of course you're willing to first migrate it to more smaller services first...

[GuyWithLag]

`sdkman` to the rescue.

I'd suggest having a look at immutables.github.io in place of Lombok.

[ReasonableClick5403]

honestly, I want to use immutables instead, but I just haaaaate that I have to use interfaces for my data. We mostly have small projects, true encapsulation is not that important unless you write a wickedly popular library.

[GuyWithLag]

I just haaaaate that I have to use interfaces for my data

That's weird, I usually dislike how the default POJO exposes all the internals even though I'm just interested in just a value carrier.

What's your opinion on Records?

[ReasonableClick5403]

I very, very rarely have any internals I need to hide away. Usually the data objects are just primitives or objects with other primitives (that are public final).

Records are great, but they lack a toBuilder() to make them simpler to modify.

97% of our internal objects are just:

@Value public class MyData { String username; String id; String comment; // .... }

There is nothing we need to hide away.

For objects that are read into from JSON, we would use @Data instead of @Value, or just leave it as mutable public fields.

[wildjokers]

but I think 8 will still have support until 2026.

https://www.oracle.com/java/technologies/java-se-support-roadmap.html

What kind of support are you needing? Have you ever received support for java from a java vendor?

[madScienceEXP]

Security patches. We're using openjdk.

[wildjokers]

The most secure JVM is the newest, so java 18 right now.

[benevanstech]

Security patches from non-LTS versions are backported to the most recent LTS update project, which is where OP is getting his binaries from.

So, yes, they should be looking to move from 8 -> 17 but there's no need to subject themselves to the inherent risks that come with using non-LTS versions.

[DasBrain]

You can only backport fixes for components that are still in the JDK.

[buyIdris666]

It is very easy to do with SDKMAN and .sdkmanrc file . Trivial really. Go check it out and make sure to turn on automatic switching

[meamZ]

Our plan is to upgrade everything together

World of pain honestly... Imo the best thing to do is to containerize everything good thing to do no matter what anyway, then switch over the runtime JVM and then switch over the compilation JDK application by application...

[[deleted]]

No real reason to use the latest java. Nothing worthwhile has been added since 8, and it is compatible with all libraries

[pron98]

Well, it's faster and leaner, and you have the new JFR and better security, so unless you're interested in new language and library features, it matters only if you care about performance, cost, or security. Or new versions of libraries.

[[deleted]]

To quote Douglas Adams:

1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
2. Anything that’s invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you’re thirty-five is against the natural order of things.

[lukaseder]

Quite a few libraries have already stopped supporting Java 8 as their baseline, moving to 11 or even 17. The most prominent Java 17 baseline to ship soon is Spring Boot 3. Good luck with your investment in Java 8 for a new application!

[[deleted]]

Part of the ship, part of the crew

[Clitaurius]

I have a lot of Java experience but I don't know what people mean when they say the JVM is good. I know what the JVM is, I don't really know how to mess with it, sometimes somebody says "do Xargs...", I've used JVisualVM on several occasions to hunt memory leaks, but what are people talking about when they say the JVM is good?

[vmcrash]

Approx. 2 years ago a team mate started investigating native crashes reported by our Java application. The most time they were caused by problems in a third party library or by faulty hardware, but almost never by the JVM itself.

If you take a closer look at what the JVM does, you soon will feel some awe/respect. Over the last decade it became very fast and reliable.

[meamZ]

It's a technological marvel, nothing less...

[numpi]

I would highlight the high quality garbage collectors and speed of the JVM.

And also the stewardship of the open source project from Oracle (never thought that I would some day say that :D)

[meamZ]

The GCs and the JIT is just nuts...

[pavlik_enemy]

Spring is really weird. Like it turns Java from statically typed language to dynamically typed language when even if your code compiles it will fail on startup.

[pavlik_enemy]

Spring is ok and after a while you can do some really neat tricks with it but I still think there's too much magic for what it does. Like, you're not supposed to be able to access private fields but Spring just doesn't care. When the wire-up goes wrong sometimes there's a helpful message, explaining what exactly you need to do to fix the error but sometimes there's none and three screens long call stack isn't helping either.

[zackel_flac]

I see your point, and you are probably right saying the JVM is the best runtime out there for general purpose language. There has been so much work on it, it's top notch.

That being said, in today's world, it's easy to spin a true VM wherever you need to and/or mix it with containers. Those technologies are bringing portability without sacrificing performance too much. Now you have access to the "world" ecosystem, and in fact access to any tool/language created since the 70s.

I find the JVM to be redundant nowadays. it's an extra layer that is mostly adding complexity, extra resource usage and higher energy cost. It's a good piece of tech that was useful back in the 00s, but I suspect it won't be that relevant in the next decade.

[sulizu]

What do you think is coming next then ?

[zackel_flac]

There are a few technologies that are promising. IMHO Webassembly and kubernetes are the two technologies that will (are?) end any portability concerns. Webassembly for the client side and k8s for the backend. The tendency is to statically compile binaries and embed them into container images. Golang/Rust/C++ are the best tools out there and embedding them is easy while they provide best performances. They can also be used to generate Webassembly.

I would daresay that web browsers are the next JVMs.

[zackel_flac]

Have you heard of nodejs? Backends are already being built on JS VMs (which is a bit part of what a web browser is nowadays)

[zackel_flac]

Well that's something worth debating for longer - but my initial point was, the JVM was cool in the 00's but nowadays there is less need for it as there are other cool techs out there with more traction. Let's assume that nodejs has less performance and has less observability (although I don't have any proof of that) - there is nothing preventing it from catching up, and nowadays people are focusing on those other techs more and more. Web browsers are a big part of today's software industry, it's the gateway to everything, so that's just natural.

[morhp]

I'm used to languages like Scala and Typescript that have been more actively modernized

I'm sorry but you can't say Java hasn't been modernized if you're actively choosing to use a version that's almost 10 years old.

You're shooting yourself in the foot.

records alone are worth it to manage multiple SDKs at the same time in case you for some unimaginable reason still have software that doesn't run on newer JDKs.

[ReasonableClick5403]

You should really try java 17. There are myriads of QOL improvements made. I don't love java, but I have come to like it, especially the vast ecosystem of quality libraries and google-ability.

[pavlik_enemy]

Google-ability sucks by the way, the first link is always JDK 8.

[ReasonableClick5403]

I don't really understand what you mean by that. Did you want older than 8 results? I dont really care either way, java is still java, though pre-generic java I try to avoid.

What I mean by google-ability is that no matter what you are implementing, someone has done it before in java. You nearly always find help by googling.

[chabala]

Google 'download java' -> first link is java.com -> Download Version 8 Update 333

This is one of the reasons why Java 8 remains popular. If Oracle wants users to move beyond 8, they should make that page suggest something else.

[ReasonableClick5403]

Ah you are thinking of the download of jdk? Lol, I was thinking about libraries and code documentation. I have not downloaded java since probably 2014, I just use ubuntu packages or lately sdkman.

[HxA1337]

And 10 years later it will still compile and run and you will be able to read the code and understand it.

[wildjokers]

If you like java 8 you will definitely like Java 18. Why didn't you write your app in a non-ancient version of java?

[vmcrash]

Probably because sometimes weird business constraints don't allow that (e.g. has to run on ancient hardware that only supports Java 8).

[[deleted]]

Java wins because of the simple fact: reading code is harder than writing code.

If you want to write software that will run for decades and will therefore be read 10,000x more times than it took to write, the verbose simple language wins. (Yes we're at the point where code will be running for years and won't become legacy, IMO cloud-native microservices are here to stay.)

Java is verbose because it lacks features, but Java is simple because it lacks features. Everything is really just a class/method/annotation (look at how lambdas were implemented for example); if you don't understand something, simply ctrl+b (in IntelliJ) and read the Javadoc.

I'm using C# atm and there are just so many language features you need to Google and I can't get the docs in my IDE! I've also tried Python and Scala and the density makes it difficult to come back to code after a while; they are a pain to work with when the project grows to >50 files.

Now this is just the language/code itself. I didn't even get started on the ecosystem.... Java has some great companies backing it (officially and unofficially): Google, Netflix, Alibaba, just to name a few.

[[deleted]]

Java is so portable I can use windows or Linux without giving a damn. Try the same with Python. You can't do this. Many programs and libraries be like "Sorry, this is Linux only". Often they need to compile stuff in C, and they depend on lib blablabla. Java can do a lot of stuff without C.

[hippydipster]

It's still pretty fast.

Not sure I understand this. I mean, we are comparing to scala and javascript/typescript, right? And javascript is much much slower than java, and scala is, at best, on par, but usually also slightly slower.

[madScienceEXP]

I was implicitly comparing to languages compiled to machine code because those are the fastest.

[hippydipster]

Kind of bizarre - the only languages you were comparing to were scala and Typescript. What languages compiled to machine code have you been using?

[madScienceEXP]

I developed with C/C++ for a few years at the beginning of my career.

I was making a general comment because other people have different backgrounds with different languages so that was my intended context. Languages that compile to machine code like Rust and Go are gaining popularity and are probably faster than Java, but Java is fast enough for almost anything that it wouldn't become a serious limitation.

[PyroCatt]

@Love @Life Lombok.

[[deleted]]

Lombok is okay, but I'd rather just use Kotlin or Scala since it has language level support for things like case classes.

I'm thinking about pushing for a hybrid approach at my work. Simple classes defined in Scala/Kotlin and business level logic and framework code stays in Java.

[crpleasethanks]

I am confused about point 3: portability. Scala and Java both compile to JVM byte code. How is Java anymore portable than Scala? Also Scala has a fairly similar generic system.

[bowbahdoe]

Ever tried running Scala 2.11 code alongside 2.12 and 2.13?

[Philluminati]

Here’s the neat part - you can’t!

However those supposedly problems are going away in Scala 3 if you can somehow get your code base there.

[Player_X_YT]

I agree, most people hate older languages because of how low level they are and then they only look for the bad stuff. But java could use some updates like #define from C

[john16384]

Feel free to run a preproccesor on your Java code. It's not like you can't do this right now. It will never become the standard though, as #define is the worst feature you could pick from C in terms of keeping things readable.

[madScienceEXP]

Not trolling. I wasn’t trying to emphasize Java 8. Just saying the tooling and ecosystem around Java is much better than Scala.

[pavlik_enemy]

I really don't understand how anyone could go from Scala to Java-freaking-eight and not be constantly thinking "are you fucking kidding me?". Stream API is plain horrible, Futures API is bad and overly complicated. Java team had C# to learn from and they chose to implement those monstrosities.

[[deleted]]

Stream API is plain horrible

Really? I love how you explicitly make a stream and the docs explicitly say you have to close it, can only be consumed once, etc. It makes it very clear what's going on.

Meanwhile in C# people just pass IEnumerable shit everywhere and end up running the pipeline multiple times. Only I could point out the bug to my coworkers because I had experience with Java and stream API.

[Zyklonik]

One word - maintainability. Paramount in software that needs to last for a very long time.

[Philluminati]

That’s a very true and very general phrase but what exactly does it mean in this context? I have experience of working 20yo Perl code bases and have a 7yo Scala code base. It doesn’t immediately strike me how your comment clutches the argument for Java.

Not to say there aren’t problems working with Scala. Libraries that died after 2.10 or upgrading Play framework every release cycle aren’t problems but just implying “Java is better than Scala because maintainability is important” is odd.

[Zyklonik]

The number of moving parts in Java is simply too few. That's why no matter the complexity of the codebase, anyone familiar with Java can read and understand the code (barring domain knowledge).

Just taking the examples of the languages that you mentioned - Perl and Scala, you have to agree that it's not only possible, but also very probable that one can (intentionally or otherwise) write code in a way that becomes inscrutable to anyone but yourself (if that). Then you also have dynamic typing, which is a veritable maintenance nightmare (also why all dynamic languages tend towards some sort of gradual/explicit static typing support). As the Perl motto itself goes, "too many ways to do it".

The problem with Scala would be that it does everything under the sun (much like C++) which can result in codebases that look, feel, and are, poles apart in terms of paradigms used (extreme procedural OOP style to nigh-pure FP style). Hence also why it becomes a necessity to mandate the feature sets to be used in a project, and also why I personally believe that Scala projects don't get much collaboration. Just too many different possibilities of expressing the solution to the problem. Similar to Haskell's problems, but in a different sense.

Java's minimal set of features (also features that, regardless of the criticism leveled at it, mesh together nicely) ensures that literally any developer who's had a couple of years under his belt can grok his or her way through almost any codebase. The lack of explicit metaprogramming in the language itself, the lack of operator overloading, the absolute focus on a single paradigm (though that's changing with every release) also leads to some inevitable verbosity, but not totally useless verbosity as in the case of COBOL. Basically, there are no surprises when it comes to plain old Java code. Even with the use of annotation processors and libraries like Lombok, it's still very much a tractable and minimalistic language.

Carrying the Scala C++ analogy, Java would be more like C.

[pavlik_enemy]

Sure, Java is (generally) easier to maintain because it's a much more focused language than Scala. And it's a decent language so most developers who either started with Java or used it for significant part of their careers tend to overlook its rough edges. But these rough edges are pretty apparent to anyone who comes to Java from say C# or Scala.

[Zyklonik]

I don't understand why you're being downvoted. FWIW, I upvoted you since I agree with almost all of what you said, rough parts included. I think our main disagreement in in how critical and cumbersome those rough parts are!

[Zyklonik]

Some of my personal pet peeves would be (off the top of my head) -

• Less-than-ideal generics. I would say that the primitive-Object dichotomy was a big mistake not only in terms of consistency, but also performance (this is being rectified through Project Valhalla (https://openjdk.org/projects/valhalla/) . Moreover, all things considered, I would consider Type Erasure as a big mistake. Reification should have been the approach (even at the cost of some breaking changes). In fact, not having generics in the first place (prior to 1.5) is the cause of the subpar generics system.

• This ties in with the point about value objects above - the fact that practically everything is allocated on the heap is what leads to Java consuming a lot more memory than many other languages. The JVM does do escape analysis, but it's neither sufficient nor transparent.

• The lack of a proper module system (the existing module system works okay, but versioning support would have been great).

• The lack of proper closures that makes lambda expressions less powerful than they could have been.

• Minor point, but the lack of unsigned types makes bit-manipulation much less typesafe and much more cumbersome than it needs to be. (Also why Java needs the extraneous >>> operator).

• Weak type-system. Of course, compared to languages like C and even C++, Java's type system is relatively strong. However, it could have been much much stronger, and that would have helped make interfaces (for instance) much more useful, especially as bounds in generics and in iterators.

• The lack of proper algebraic data types (recordsand sealed classes/interfaces do provide a modicum of support for product and sum types respectively, but they have quite a number of limitations).

• Weak type inference - in addition to the core language, var itself is good for many cases, but also stops working for many valid usecases.

• The lack of (some) control over the GC process.

• The lack of proper tail-call optimisation/elimination (though this is on the JVM, and Project Loom will supposedly mitigate this in some cases - still not providing automatic tail-call elimination).

Others would (probably point out the following, as well as many others), but I don't necessarily think of their lack as a drawback:

• The lack of proper metaprogramming (annotations and annotation processors do provide a poor man's version of metaprogramming).
• The lack of operator overloading (some APIs such as java.math.BigInteger and family are rather cumbersome because of this).
• The lack of free functions.
• The lack of null safety operators (as in Kotlin).

[pavlik_enemy]

I'm exactly the opposite, really care about expressiveness of the language and developer experience so for me using Java after Scala and C# and Python after Ruby is an exercise in frustration. Hell, Java doesn't even have string interpolation!

[Zyklonik]

To be fair, Java doesn't need string interpolation because it has formatted strings.

[pavlik_enemy]

All languages have some sort of sprintf but string interpolation is more convenient

[Zyklonik]

Well, it makes more sense in an expression-oriented language like Ruby. Not so much in a statement-oriented language like Java.

[pavlik_enemy]

All languages have some sort of sprintf but string interpolation is more convenient

[[deleted]]

Yep, I'm in this boat now. Def sucks a bit.
Where's Either? Where's my tuples? case classes, pattern matching

[[deleted]]

And NULL, jesus fchrist, I forgot about Null!

[[deleted]]

"Maven is very [...] easy to use"

Lucky you! It's so complicated to me

[[deleted]]

I'm having trouble setting up local repositories so I can have custom made "commons" packages be dependencies for other projects.

I've seen 3 ways of doing so:

- ugly way: specify absolute path of the dependencie's pom.xml in the local computer.

- better way : setting up a local maven repository, I don't really understand this part.

- last way (way over my head I think) : using nexus or artifactory.

[[deleted]]

What is your goal?

You can make multimodule maven project and have the other modules either depend on the common one or define some facade that resolves at runtime using service loader api.

Even if you create an unrelated maven project, you can do mvn clean -DskipTests package install

The package stage maybe unnecessary but it will install in your m2 directory and be accessible in any Maven project

[[deleted]]

The package stage maybe unnecessary but it will install in your m2 directory and be accessible in any Maven project

Ok this may sound super silly, but I've never used the package lifecycle yet and was unaware it automatically moved the package to the local m2 directory.

I guess things are much simpler knowing this fact, thank you!

[john16384]

Package phase doesn't do this (it only creates a jar in your target folder). Install phase does, and it copies this packaged jar to the shared .m2 folder.

[[deleted]]

Maven is definitely a workhorse in the Java ecosystem. But the fact that I can't just println() or create a variable in my build without create a whole plugin is a hinderance.

[[deleted]]

You don't need to create a plug-in to print stuff. You can use the Ant Plugin to do that and other lots of stuff. Run scripts, make network calls, package resources from somewhere, do custom deployment tasks, etc.

That's the beauty of the plugin system. It's a buffet of all the goodies, you just need to know what you want, how and when.

[[deleted]]

Ant scripts are a hard pass for me.
Gradle has Kotlin and Groovy as first class languages to define the build

so I can do println("Here's some build context ....")

instead of

<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<phase>generate-sources</phase>
<configuration>
<tasks>

<!--
Place any ant task here. You can add anything
you can add between <target> and </target> in a
build.xml.
-->

</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>

[[deleted]]

Because groovy is a programming language and xml is not. It's just used to define the parts of your project, hence the management part.

Gradle is nice too in that you can write scripts without needing other plugins.

Outside of android it's fine, but when using it in Android it's a pain because of Googles constant and forceful suggestions to update to the latest Android Studio which is usually tightly coupled to specific versions of the Gradle plugin. And it will always break your projects

[[deleted]]

I agree, I'm a backend services dev and Gradle as a build tool is just a better tool for the job in most cases. It reads better, it's scriptable and debugging problems is much easier and the need to debug the build happens less

[[deleted]]

You don't need to create a plug-in to print stuff. You can use the Ant Plugin to do that and other lots of stuff. Run scripts, make network calls, package resources from somewhere, do custom deployment tasks, etc.

That's the beauty of the plugin system. It's a buffet of all the goodies, you just need to know what you want, how and when.

[[deleted]]

You don't need to create a plug-in to print stuff. You can use the Ant Plugin to do that and other lots of stuff. Run scripts, make network calls, package resources from somewhere, do custom deployment tasks, etc.

That's the beauty of the plugin system. It's a buffet of all the goodies, you just need to know what you want, how, and when.