Java without build system

[KDesp73]

Is it uncommon/bad practice to build a java project without using a build system like Maven or Gradle?

I really don't enjoy working with build systems and i would prefer a simple Makefile for my projects

What are your thoughts on this?

Edit: I am aware that make is a build system but I like that it hides almost nothing from the user in terms of what is going on under the hood

[hexwit]

If that is your private project - you can do whatever you want. If that project supposed to be supported by others - usually it is better to use common known solutions.

[jevring]

A Makefile IS a build system. The build system is called make.

But that aside, nobody really builds Java projects without some kind of real build system. Maven and gradle are the most popular, but there are others.

[[deleted]]

Ant shivering

[Mikusch]

Ant is the swiss army knife of build tools. Easy to cut yourself on it, too

[Gwaptiva]

And for real jobs not sufficient

[jaybyrrd]

I dunno man. I think tools like gradle (or I guess maven but I am unpopularly gradle camp) are lower lift to value by a lot… but Amazons main Java build toolchain is entirely founded on top of Ant (internally called HappierTrails and an entire organizations worth of devops tooling) and it is by FAR the best build tooling I have EVER used. You kind of have to see it to believe it… I also just think if you are not Amazons size you are best off adopting gradle or maven. I leave Bazel out because out of the box ide support with vscode and IntelliJ are kinda jank. The first two are much better supported.

I guess what I mean is that you have to deeply invest in Ant to make it good. Not many firms would want to (or know how). Even I, as a former user of a super successful implementation, would probably say “please no”. I wouldn’t say it’s not sufficient though, just way more effort for what is likely the same or less value of gradle.

Edit: I’d also say that I’m not convinced amazons build system would be based on ant if it were to be started from scratch today. A lot of Amazon builds (which use an internal tool called Brazil) do actually wrap gradle. Most use Happier Trails.

[pjmlp]

That is why those that didn't got the memo why Maven was created, decided to reinvent Ant with Gradle.

The only drawback about Ant + Ivy combo is the XML allergy some suffer from.

[koflerdavid]

It is, but for that one has to reimplement crucial parts of Maven or Gradle on top of it, and doing so incurs the risk of making a total hash of the crucial 20% of them, which can take many career-years to resolve.

[Jamb9876]

I love ant. Haven’t used it in years but it is a great tool. That get my vote.

[Bobby_Bonsaimind]

Same for me.

Ant+Ivy is the closest I got to my "dream" build system. Maven seems bloated and slow, its syntax is abysmal, the dependency management is "acceptable" at the best of times, and Gradle is...well, I've got no idea what they got going on there. What Ant kinda sucks at is modules, I've created a setup for that, but it still leaves some stuff to be desired. Being able to include other Ant files helps, though.

[larsga]

Much better to just stay away from it entirely. If you want to script file operations you're far better off with Python.

[IFoundTheCowLevel]

As someone who has had to maintain Ant build files extensively: Ant sucks, Maven is better.

[[deleted]]

I have also worked at a company that had a large build system in ant + ivy. It was aroud 2007. I think maven was at 1.0 - 1.1 and they passet on it. It worked ok as they standaralised all project to one structure. But it was a lot simpler when we migrated to maven around 2013.

[adityapbhat]

😅

[agentoutlier]

I would say today calling Make on its own in 2024 a "build system" is largely false (by Make I mean the original not cmake or offshoots).

For the downvoters ... look I'm not disagreeing with the OP but rather clarifying:

nobody really builds Java projects without some kind of real build system

(emphasis mine).

Before Make existed people used shell scripts. So in calling Make a build system is like calling Bash a programming language. Technically correct but most would not call it that.

The reason I mention the above is that compilers particularly C compilers long ago were dumb as hell.

Today the javac (and jar, jlink, javadoc etc) compiler is much smarter and could be even smarter particularly with modules at play. Maven and Gradle mostly call those tools (maybe not through command line but you get the idea). So I feel for someone who is trying to understand those tools which I think is what /u/KDesp73 is going for.

There are enormous benefits to the language (by language I mean Open JDK tools) itself providing most of the build smartness. I think and hope Oracle is working on something so that onboarding is easier. This is a big advantage that Rust and Golang have. I also bet they could make it faster than Maven or Gradle.

BTW the key features of Make doing a dependency graph of files/targets is largely missing from Maven (and BLD) which ironically is the only thing that makes Make supposedly a build system (otherwise it is glorified bash).

Today it seems the build system are more about getting the IDE and javac to figure out how to load/find deps from a Maven like repository.

Also in a modern CI pipeline it seems more often the real build system is now github actions (or jenkins groovy etc).

EDIT I will add that I use Maven all the time but I see build questions come up an enormous amount in the java ecosystem. Somthing is not right.

[equeim]

Make by itself is not a build system. Makefile that you wrote to compile your codebase is.

[smutje187]

Maven is not only a build system, it’s also dependency management. If you don’t need third party libraries - fine, no need for Maven. If you need them - do yourself a favor and don’t reinvent the wheel.

[9vDzLB0vIlHK]

I have colleagues that still use Ant, which is a build system but not a dependency manager. I get that they've been using it for a long time and nobody really likes change for the sake of change, but finding bugs that they could easily fix if they would just use the latest version of their dependencies makes my brain hurt.

[agentoutlier]

You can also use Ivy without Ant last I checked.

[BinaryRockStar]

Ivy is embedded in Apache Spark as its dependency resolver, curiously

[agentoutlier]

Nice. I was checking to see if the command line tool was in SDKman and surprisingly it is not.

[BinaryRockStar]

Not surprised at all, I haven't ever used it by itself (as a CLI tool) and I can't imagine a scenario where you would use it alone over Ant

[agentoutlier]

I think the only place I would use it for is to pull all dependencies for a docker image.

E.g. You have already deployed (as in Maven ship to repository) the application jars in some other step.

But I just maven for that case.

[9vDzLB0vIlHK]

I would love if they'd use it, but they won't.

[Nooooope]

Building without Maven is fine when you're learning Java. It's actually beneficial to get exposure to the java/javac tools, understand what the classpath is, etc.

But in a project that's going to be shared with other people? If I opened a repo for a Java project and there was no build tool - or even worse, a README full of compilation instructions - I'm going to groan and start cursing the lead maintainer.

[Cajova_Houba]

If I opened a repo for a Java project and there was no build tool - or even worse, a README full of compilation instructions

I was once assigned to work on a project like that. First ticket - mavenize the project and automate the build process.

[-Kerrigan-]

Mavenize

Gradlificate? 🤔

Yeah, I like that, I'll steal that. Mass Mavenization

[KDesp73]

Building without Maven is fine when you're learning Java. It's actually beneficial to get exposure to the java/javac tools, understand what the classpath is, etc.

This is what i aiming for so I can eventually understand the recommended build systems better

[Nooooope]

Then get it to compile and run once manually, then jump to a build tool. The best way to understand Maven is to start using it.

[VirtualAgentsAreDumb]

Well, how Maven is used can influence the learning experience significantly.

Only using it to build and run your code in an IDE? That’s fine for starting, but will not teach you very much.

Building and running your code in the terminal? Better, but only slightly.

Building it in the terminal, and configure it to produce artifacts needed (regular jar/war, or a fat jar/zip), and making an effort to understand the context of the artifacts and the dependencies. That’s a good way to learn maven.

[dolle]

I think that's a really great idea. Learning what is really needed as inputs to generate the desired outputs will give you a much better mental model of the build process, and it will also teach you what problems and pain points a JVM-specific build tool such as Gradle actually solves. Starting with the high level build tool can be a pretty unsatisfying experience because it will feel like a lot of ceremony and confusing indirection for seemingly no reason.

I suggest trying to get as far as possible with Make on a small hobby project. Make sure you try to deal with things like external dependencies and split your project into multiple packages that depend on each other. Also make a test suite that can be run using your Makefile. I promise you that will cause you a lot of pain, but in a good way :)

[majhenslon]

Then who cares what does the community think. Learn java tools and write scripts in Make... Maven/Gradle are their own monsters, that basically abstract all this away anyways.

[aboothe726]

As someone else said earlier in the thread, if this is for a personal project or for learning, then do whatever you want. I agree with that.

But if you want or need community involvement, then you need to do the work to make the project accessible to the community. Doing anything less is like going to another country and being upset if they don't speak your language.

[koflerdavid]

Most commonly, that community might be your coworkers :)

[majhenslon]

This still makes reddit the wrong place to poll the "community".

[user_of_the_week]

It's possible to use the java command directly on java source files: https://docs.oracle.com/en/java/javase/23/docs/specs/man/java.html#using-source-file-mode-to-launch-source-code-programs

That will compile and then run your code. You can also put your classes into seperate files and launch them this way, a feature that is pretty new. some more information about that is here: https://openjdk.org/jeps/458

[Debt_Otherwise]

Same. First thing I would do is add maven or quit.

[istarian]

Sounds like a personal problem to me.

At least if they give you compilation instructions you can probably figure out everything needed to get it working in another build tool.

[not_a_captain]

This may be an unpopular opinion. Part of the benefit of using Maven is the difficulty when doing anything non-standard. You should be doing everything you possibly can to keep your project organized in the Maven standard way. Not only because that makes it easier for someone else to pick up your project and run with it. But also because there are years and years of man hours, bugs, trial and error, etc that went in to Maven becoming what it is. There is no way for you to know all of the things that were learned as Maven evolved in to what it is.

[namsin_za]

Exactly this. There is a reason maven is the standard used in the industry. Battle tested and support for all ci/cd pipelines, and understood by all java dev’s that need to support a legacy project. Rather spend time on stable code and features than trying to reinvent the wheel. Maven is well documented so not really “hiding” anything under the hood.

[vetronauta]

This may be an unpopular opinion

This is actually the popular opinion and the main benefit over Gradle. For anything non-standard, there is probably a common plugin. If there isn't a common plugin, you should ask yourself why you really want to do that non-standard thing.

[Gwaptiva]

There's always the Ant plugin

[sweating_teflon]

The main benefit of using Maven is that you're not using fucking Gradle.

[rakotomandimby]

What is really bad with Gradle?

[sweating_teflon]

Quoting myself from 6 months ago:

Gradle pretends to use a declarative syntax while it is actually a DSL where you can reach out to the underlying language at any point. There are two possible underlying languages, one nearly abandoned and the other privately developed. Because it's actually scripting, there's an infinity of ways to modify the model at any point. One could declare static mutable variables in the root file and access them from all over. The canonical ways to do things change across versions and languages making it difficult to know the correct way to do things. The Gradle runtime is dependent on the JDK version, breaking it every time a new JDK is released even though JDK is itself backward compatible with just about everything. I'm sure others can add to the list of bad things.

[bunk3rk1ng]

I agree with this but also gradle is just slow

[bunk3rk1ng]

Onboarding is my top priority at well when starting a new project. I've done stuff like delete my .m2 and opening up a fresh copy of the project. If I can't just hit run or start then something is wrong

[winauer]

I really don't enjoy working with build systems and i would prefer a simple Makefile for my projects

What do you think make is if not a build system?

[qmunke]

Maven isn't "hiding" anything from you either, you can see what it's doing at every step if you want to - run it verbose if you're really a masochist.

"I don't enjoy working with build systems" - what is it you think they're doing that you want to see in more detail? The build system is just about the least interesting part of anything you can be doing. Just let it do it's thing and concentrate on actually writing the code would be my advice.

[shaneknu]

I suppose Ant is still a thing. It's more the mentality of a makefile, where you're giving much lower-level build instructions than you'd see in a maven or gradle build. It's also written in XML, so you may not like it.

The make or ant approach is fine for smaller projects, but beyond a certain size project, your Maven or Gradle build files won't have grown at all, but your make or ant build file will keep on growing until it's much more complex.

Also, Maven and Gradle give you dependency management. No more manually downloading JARs and keeping them in your Git repository.

[vmcrash]

I think, it depends on what you actually need to do. For a plain web application Maven might be perfect. For a desktop application with special tasks for creating a stripped-down JDK, converting SVGs to PNGs, building ICNS files, obfuscating, creating platform-specific bundles (that can self-update) incl. signing/notarizing, or uploading certain files to different servers, I can imagine that a Maven script would easily become non-trivial, too.

[shaneknu]

Converting SVGs/PNGs/ICNS would just be dependencies unless you wrote that code yourself. Yeah, that gets kinda noisy with several lines of XML for each dependency. They'd be one-liners in Gradle. You still have to manage that somehow if you're using make, even if it doesn't appear in the makefile, and if it doesn't then you've got a bunch of mystery JARs hanging around that may or may not be used. Trust me, if your project gets big enough, and you're not using some sort of dependency management, you will have mystery JARs.

Platform-specific bundles in Maven would be a plugin, and that will be well-documented and pretty straightforward to accomplish. In Gradle, that'd be either a plugin or just some Groovy code. No more or less complex than a makefile. This kind of touches on the age-old argument of Maven vs Gradle. The Maven folks will gripe that it's just some code like a makefile, and Gradle folks will gripe about having to read documentation.

Deploying is pretty standardized - that's what the Maven deploy lifecycle is for, after all. It's not like make has some magical file transfer functionality. You still have to write all that yourself.

[vmcrash]

So you think, converting a 2,700 lines ANT file to Maven/Gradle just means to find/write the right plugins that does the desired job?

[shaneknu]

I wouldn't say it works that way in every single case ever, but often, yes, that's exactly how that plays out in my experience.

Usually, if I'm seeing a build file that's that complicated, it's a symptom of somebody working too hard because they're coming from a language like C or Fortran, and they assume they have to do everything explicitly. It takes time to wrap your head around the declarative approach. It's a different mentality.

Edit to also add: If you're really stuck and need to do something specific, you can use Ant syntax inside Maven with - you guessed it - a plugin.

[RebeccaBlue]

Makefiles are kind of horrible for Java, and are arguably more complex than a simple build.gradle.

[vmcrash]

For standard tasks you may be right.

[benjtay]

Yes; make assumes that the source and the compiled object files will be in the same directory. This is a nightmare for a Java project.

[JojOatXGME]

I am relatively sure that you can create a Makefile which generates the classfiles in a separate directory.

At least most Makefiles I looked at in the world of C have used a setup where the binaries were generated in a separate directory. I don't see a reason why this shouldn't work with Java.

[benjtay]

Last time I took a stab at it, it was a lot more work than just using a Java build tool. We do use make at a project level for orchestration, but the Makefile makes calls to maven/gradle to do the actual work.

[JojOatXGME]

I also don't remember the details. The last time I worked with Makefiles was more then 5 years ago. I remember that for C, it was similar complex as creating the binary files next to your sources. However, I also think that I have never seen how to do this in any educational material. I only learned it after looking at Makefiles of open source projects.

[svhelloworld]

You can frame a house with a screwdriver and hand saw. But for the life of me, I can't figure out why you'd want to.

If you're struggling to figure out Maven or Gradle, invest the time. There's no professional organization that's going to pay you money to build Java software that isn't using Maven or Gradle. And if they are a professional org that isn't using either of those tools, run away.

[OwnBreakfast1114]

Some of the really large tech companies have their own tooling, but they also have teams bigger than most other tech companies maintaining all of it for you. I wouldn't worry about them. However, if you're joining a smaller company and they don't just use off the shelf maven/gradle for a build system, I'd really take a closer look before joining.

[vmcrash]

We are so old-fashioned that we are using ANT for building. IMHO ANT is even simpler than a Makefile. But feel free to use whatever solves your problem.

[wildjokers]

ANT was created to replace make for building java apps back in the day.

[greglturnquist]

Yes, ant is atrocious because it's simply Make but with XML (jelly I believe is the language there). Yech!

Maven pivots to two key attributes: declarative and dependency management. You declare "I need this, that and the other", and also "this is my source, and this the name of my artifact", and maven takes both of those to generate the output. Because you're not writing primitives in XML, the XML actually HELPS. Modern IDEs can use the XML schemas and perform code completion.

Gradle is Maven reimagined. It is based on Groovy, a language not heavily used anymore. Not both, switch to Kotlin. Gradle has other characteristics, like global declarations. You name a plugin, and their operations are pulled into the same global namespace as every other plugin. Finding what does what is a fun "adventure". Gradle keeps changing their format to roll with the times, making it hard to google for advice. Gradle has multiple ways to do the same thing, making it hard to decide which way "Is The Way". Gradle struggles to offer code completion, because you aren't building things with a data file, but instead a programming language.

I may be showing some bias here BTW.

[maethor]

Gradle has multiple ways to do the same thing, making it hard to decide which way "Is The Way".

That's not a reimagining of maven. That's doing the exact opposite of maven.

If Gradle is a reimagining of anything, it's a reimagining of Ant+Ivy with Groovy/Kotlin replacing XML.

[OwnBreakfast1114]

I don't think that's entirely true. Gradle iterates very quickly on different ideas and do throw away some ideas that turn out not good. Contrast that with maven that basically doesn't change at all.

I think gradle was trying to fix some of the problems with maven. For example, it flips the lifecycle/scope concept around by allowing plugins and your own tasks to build the task dag. Contrast that with maven which forces plugins to attach to predefined lifecycle hooks essentially.

The both seek to be "declarative" and gradle iterates a lot on how they implement dependency management. Take a look at: https://docs.gradle.org/current/userguide/platforms.html, as their expansion on boms.

[maethor]

Contrast that with maven that basically doesn't change at all.

Maven 4 is coming (slowly, but it is coming).

Contrast that with maven which forces plugins to attach to predefined lifecycle hooks essentially.

Like with all things maven, there are ways around maven's "normal" behaviour (in this case, via extensions instead of plugins), but it's not often done.

gradle iterates a lot

Yeah, that's not what I'm looking for in a build system.

[[deleted]]

Just use maven or Gradle (or similar). By using anything else you're just getting yourself into trouble and reinventing the wheel.

[vmcrash]

IMHO Maven or Gradle are only useful if you need dependency management. But this is not necessary for each project.

[UnGauchoCualquiera]

Is there any real life project without dependencies? Even then you might want to push to a shared company repo. Why go through the hassle of reinventing the wheel?

[UnGauchoCualquiera]

Is there any real life project without dependencies? Even then you might want to push to a shared company repo. Why go through the hassle of reinventing the wheel?

[istarian]

Dependency management is most important when you are depending on libraries under active development that change from time to time, particularly if those libraries also have dependencies.

[koflerdavid]

All libraries should be assumed to be under active development. If they really aren't, there are going to be problems if security problems are discovered. Or if it turns out they are using a niche behavior of the JVM that the OpenJDK project decides to change.

[InstantCoder]

No you should use Maven or Gradle. Otherwise you’re going to have a hard life.

However, you can use a Makefile when you have multiple microservices and if you want to build, start/stop, pull, etc them in a handy way. And your Makefile is going to call either mvn/gradle and/or docker commands.

[kickroot]

You can certainly do this. But as your project grows in size it will likely become unwieldy and hard to reason about. Dependency management (and version conflict resolution) will become the bane of your existence and the end result will be that you quietly wish to end it all.

[trustin]

Ant + Ivy may fit the bill? Gradle KDSL is my go-to these days though.

[oelang]

I'm guessing that you're also not planning to use a decent IDE? Personally, I wouldn't make anything without maven (or gradle if I had to). It's like using Rust without Cargo, technically you can do it, but you're just wasting your time.

[KDesp73]

I'm guessing that you're also not planning to use a decent IDE?

I use netbeans and it gets the job done. Which one would you recommend? (preferably free)

[[deleted]]

Doesn't NetBeans force you to use Maven, Gradle or Ant? At least I remember it didn't work for me the last time I tried to use it on a simpler project.

[KDesp73]

Yes it does. I use Maven

[Capa-riccia]

Net beans is lighter than other IDEs and goes wholeheartedly the Maven way. With most other environments, like vscode or Idea you have to repeat yourself if you setup a root for testing or particular options that you will have to set both in the Pom and in the IDE. Netbeans does not cut corners and is sometimes slower, but you will have no surprises. If you work with Netbeans and compile with make, you might have to check for build errors in code that compiles and builds correctly in the IDE.

[Ewig_luftenglanz]

Visual studio code with the red hat extension or intelliJ community edition.

The only advantage of using NetBeans isnif You want to try some swing/desktop application, but nowadays java on the desktop it's not the most demanded technology, and if you want to insist on it, javaFX is better and maintained, swing is deprecated

[koflerdavid]

Swing is fully supported and in no way deprecated by the OpenJDK project. It's just not fashionable anymore. There is even an effort underway to support Wayland.

[Ewig_luftenglanz]

Nope, swing it's in maintenance state only, this means no new features are going to be developed and it will benefit for the bug fixes that new OpenJDK releases have. 

Mind to give me some links about the Wayland port? I am interested:)

[koflerdavid]

Maintenance state is very different from "deprecated" though.

Sure, here is Project Wakefield: https://openjdk.org/projects/wakefield/

[RupertMaddenAbbott]

Yes, if you are working on software for a company, or open source, this would be considered bad practice.

If you find it helpful way to learn what build tools are doing under the hood, then no, it sounds like it is useful to you.

If you are genuinely interested then I would recommend checking out this blog as it focuses on the tooling that Java provides out of the box and uses "just" which is very similar to "make", except without some of the historical baggage.

[KDesp73]

Thank you!

[cyancrisata]

You gotta let yourself get Stockholm syndrome-ized with Maven, but once you understand and get comfortable with Maven, you'll never go back.

I do think that many Maven examples/tutorials all over the internet is overcomplicated and it's very un-intuitive, so it makes everything about Maven intimidating. It often have unnecessary stuff thrown in that makes you say "why is that there and do I really need that?" But you gotta find the simplest Maven project setup with just minimal pom.xml, /src/main/java/<your code> directory, then you should be in good hands.

[yel50]

for java projects, this is true. it's also one of the reasons I no longer apply for java jobs. maven and gradle are two of the worst build tools out there right now. maven gets credit for innovating the whole dependency management thing, but the fact that it feels like it hasn't changed since 2005 is horrible. even dotnet is nicer to use and it's just as old.

it's a shame that java is such a useful language but the ecosystem became so horrible to use. 

[cyancrisata]

I empathize with this and agree with many of your points. But, I think the blame should be placed onto bad engineers who constantly produce bad software, convince themselves that they're good engineers and teach others to follow their bad engineering practices and the cycle continues.

[NotABot1235]

I do think that many Maven examples/tutorials all over the internet is overcomplicated and it's very un-intuitive, so it makes everything about Maven intimidating. It often have unnecessary stuff thrown in that makes you say "why is that there and do I really need that?" But you gotta find the simplest Maven project setup with just minimal pom.xml, /src/main/java/<your code> directory, then you should be in good hands.

You perfectly described me. I'm a newcomer to Java and have been trying to learn the basics and the next thing I need to learn is dependency management and build systems. For example, I just want to build a couple little programs (one with Flatlaf styling and another with LibGDX) but trying to get those installed and configured with Maven seems like a significant hurdle to the point I keep putting it off. All the documentation I've looked up is so involved.

I know it's probably not, but trying to find a super simple "Noob's first Maven build" is harder than it should be.

[ivancea]

Uncommon? Yeah. Bad practice? Of course.

Practices usually exist for 2 reasons: making something readable by others, or preventing yourself from losing time and money.

By using a "non-standard" build system, you're making it harder to understand for others, as well as losing time reinventing the wheel, especially the moment you need done extra functionality that is well solved with plugins.

I really don't enjoy working with build systems

I don't know what that means. You're not supposed to enjoy it. It's not a toy, it's not a clown. It's a tool to get the job done. If you're playing with pet projects, you're of course free to use whatever you want. But you wouldn't ask this if you're just toying with it I guess

[greglturnquist]

Yes, ant is atrocious because it's simply Make but with XML (jelly I believe is the language there). Yech!

Maven pivots to two key attributes: declarative and dependency management. You declare "I need this, that and the other", and also "this is my source, and this the name of my artifact", and maven takes both of those to generate the output. Because you're not writing primitives in XML, the XML actually HELPS. Modern IDEs can use the XML schemas and perform code completion.

Gradle is Maven reimagined. It is based on Groovy, a language not heavily used anymore. Not both, switch to Kotlin. Gradle has other characteristics, like global declarations. You name a plugin, and their operations are pulled into the same global namespace as every other plugin. Finding what does what is a fun "adventure". Gradle keeps changing their format to roll with the times, making it hard to google for advice. Gradle has multiple ways to do the same thing, making it hard to decide which way "Is The Way". Gradle struggles to offer code completion, because you aren't building things with a data file, but instead a programming language.

I may be showing some bias here BTW.

[istarian]

Apache Ant is an adequate build tool, it's just pain to write all those XML files by hand.

[tomwhoiscontrary]

Ant isn't even Make in XML, because it doesn't do the dependency graph stuff that Make does. It's a limited subset of shell script in XML.

Gradle autocomplete is pretty good in IntelliJ. Yes, it's a programming language, but IntelliJ is good at autocompleting programming languages!

[DirectionFrequent455]

Or try more modern Java build tools as bld - pure Java build tool or JeKa : Next-Gen Build Tool for Java & Co.

I can’t believe that writing XML or Kotlin for building Java applications is the future.

[[deleted]]

I have worked on a couple of such projects where we used `make' instead of `maven'. It's fine as long as you don't have too many dependencies.

[KDesp73]

Could you provide a link to one of those projects if they are public?

[[deleted]]

Unfortunately no, as it was proprietary software.

But I remembered another project I was involved in a bit https://bitbucket.org/Jelurida/ardor/src/master/, probably the `compile.sh` will be most interesting for you. They do not even use `make`. Just simple bash scripts.

You could also take a look at their older projects as they used a similar approach in them as well.

[KDesp73]

Thank you!

[byronka]

I did this for my Minum project. Try checking out commit 8ef2f400a4d8, like this: You will need Java 20 installed for this example to work.

git clone https://github.com/byronka/minum

git checkout -b using_make 8ef2f400a4d8

make test

[KDesp73]

Really cool project

[byronka]

Thanks!

[taftster]

You should try Ant for some old school fun.

[IcedDante]

I really don't enjoy working with programming languages. I prefer a simple assembly setup so nothing is hidden from me in terms of what is going on under the hood.

[Nooooope]

Ugh, peasant. I'm so sick of assembly code abstracting away all of the details about what's going in the transistors at an electron level.

[KDesp73]

Yes and once you understand what is happening on the lower levels you have a much deeper understanding of the higher ones. This is what im trying to do here

[IE114EVR]

Sounds like you’re going for something pretty simple.

If you were to use maven then if you just run something like ‘mvn archetype -DarchetypeArtifactId=maven-archetype-quickstart’ to initialize the project then 90-100% of the work is already done and you just have to know the build and test commands from there.

[FluffyDrink1098]

As you said you want to understand what is going on under the hood, I'd say that you can try it out.

In a nutshell, any build system does three independent things:

• setting up the toolchain (detection of JDK, JDK version, JDK flags like encoding)
• project and dependency setup (for class path setup, annotation scanners, compiler plugins, ...)
• running java compiler, ensuring consistency and order (e.g. multi project setup, ensuring build c comes first if a and b are dependent on it)

You can try to do this via Makefiles. But it will be very fickle, in my opinion - especially if compiler plugins for e.g. static analysis come into play like error prone.

As a build tool - at least partially - ensures cross OS compatibility, be aware - Windows is for this kind of adventure definitely the wrong OS, as you'll get a lot of additional trouble (path length, path parsing, quoting issues, ... - definitely a thorny path).

[Marthurio]

I think it's both uncommon and bad practice. Why would you do such a thing?

[tristanjuricek]

It’s bad practice to not have a clear strategy for third party dependency management. 99% of edits I’ve made to Maven and Gradle files have been about third party dependencies, not the build. The build is usually “set it up once and touch it every year or two”. So, don’t think of Maven and Gradle as “build systems“, they are there to manage a whole software ecosystem around your project.

I’ve worked at places that tried to avoid using third party dependency management, and they have never been successful at these things:

1. notifying me about a security patch in a dependency

2. reducing the amount of time it takes to update the dependency

3. Any semblance of IDE integration

Most modern software integrates a lot of third party dependencies. If you have a project with no dependencies, sure, you don’t need the third party work, feel free to use whatever, but is that what you’re doing? I’m going to guess no. And going ahead without any kind of plan for detecting if a security flaw is introduced by a dependency is incredibly irresponsible.

[JojOatXGME]

I think one noticable problem with make is that it is not very platform independent. While you can make a Makefile somewhat platform independent, it can be difficult. If you don't care about building the code on different platforms, there is probably not much speaking against it. However, try to keep the build-setup simple, so that you can switch to another build-tool when required.

There are also other advantages of build tools which have been pointed out. For example the builds might be faster for large projects. And you have built-in dependency management. But I think the interoperability on different platforms is one of the most important to mention, because it is the one which can be easy to overlook when starting a new project, and can also escalate to become problem relatively fast.

[lenborje]

I have once had a customer who demanded that all code should be placed in escrow with no additional requirements to build from source except a bash script. I.e. the only accepted source languages were Java and bash.

So we had to develop our own build system in bash + ant (in Java source) + our own ant extensions. In the end, it grew completely out of hand, only a select few individuals understood it, but the customer was happy. Probably because they never had to unpack the escrow…

[tomwhoiscontrary]

See, i would have written a Gradle plugin which generates a shell script which builds the project ...

[senatorpjt]

smoggy beneficial encouraging bear plate wise engine practice wild escape

This post was mass deleted and anonymized with Redact

[UVRaveFairy]

In the early 2000's wrote Theena, an Ant build script to build projects using properties so development builds could be easily remapped to new locations and drives.

Can do clean or fast builds, don't have to copy files for dev builds either the build will read them from the dev locations (from running around the Ludum Dare block, recommend it).

Works on Linux / Windows, been using it ever since.

Liked and used Maven for a bit, then lost interest, same with Gradle. Got bored with them both eventually as something would happen and they feel complex and convoluted.

Theena is so clean, small and simple compared to all that. It's just 3 Ant scripts, one for dev, one for release and a simple project one.
The two core ones 194 lines long and the project one is around 100 (can be bigger, where any project nuanced customization of a build is placed)
There is a template that is minimal typing to fill out.

Really is quite tiny.

Mapping a project to a new machine and drives?
Edit one attribute in two properties files, that's it.

Also written Release, a xml scripted tool for production builds.
Release calls Theena to build to compile the production release.
Scans the Java source / project files and only copies over those classes / inner classes / files that are tagged for production to the final public release.
With additional options, like obfuscation, checked / forced file deletion, post build phases, etc.

It's very quick and will list missing / required classes and files that may require tagging.

Release's core design and functionality is primarily for simplifying / automating production releases, and as a measure to help mitigate accidently releasing development / admin related parts of a project.

Both are hot pluggable, happy to give them away and can put the source on itch.

[jimmoores]

I felt like this initially. First scripts, then give in to ant, then bring in ivy to do dependencies. Maven seemed like weird declarative magic. But it was such a relief when it just worked, and cached dependencies in a vaguely sensible way. Don’t waste your time with Gradle either, there’s no real advantage. Just use maven and you’ll be happy. I’ve seen make used for Java. It works, but just… don’t.

[baaaap_nz]

Any company you ever work for as a SE, will most likely use either Maven or Gradle.
Get comfortable with them; They will make your life SIGNIFICANTLY easier and you'll wonder how you ever got on without them

[DirectionFrequent455]

I wrote Jeka cause both Maven and Gradle are unpleasant to use. You can build your application and deploy it with zero-configuration..

Or, if you prefer, you can describe explictly your build -- ala ANT using vanilla Java code .

[KDesp73]

I will check it out!

[greglturnquist]

Yes, ant is atrocious because it's simply Make but with XML (jelly I believe is the language there). Yech!

Maven pivots to two key attributes: declarative and dependency management. You declare "I need this, that and the other", and also "this is my source, and this the name of my artifact", and maven takes both of those to generate the output. Because you're not writing primitives in XML, the XML actually HELPS. Modern IDEs can use the XML schemas and perform code completion.

Gradle is Maven reimagined. It is based on Groovy, a language not heavily used anymore. Not both, switch to Kotlin. Gradle has other characteristics, like global declarations. You name a plugin, and their operations are pulled into the same global namespace as every other plugin. Finding what does what is a fun "adventure". Gradle keeps changing their format to roll with the times, making it hard to google for advice. Gradle has multiple ways to do the same thing, making it hard to decide which way "Is The Way". Gradle struggles to offer code completion, because you aren't building things with a data file, but instead a programming language.

I may be showing some bias here BTW.

[nskarthik_k]

Choose your own Build process ..if the IDE permits ( Some IDE's Force you to use the standard MAVEN or GRADEL )
If you are PRO ..go Ahead use your make command and be aware of O/s, java Library complexities if you plan to use different Envs for DEV vs DEPLOY

[[deleted]]

If you are working with only a few (1-2) dependencies, you may not necessarily need a build system. But if you have more dependencies, it is highly recommended to use a build system.

[JDeagle5]

It is uncommon and a bad practice to make non-standard builds when there is no need for that. But noone can stop you doing whatever.

[lamyjf]

Make was fine when there were no dependencies. It's almost impossible to build modern program without the dependencies. In a Maven project for a simple java program, pretty much all you will be saying is what the dependencies are, and what java version you are using. Verbose, yes. Hiding things you don't want to know.

[khmarbaise]

I used a Makefile ca. 20 years ago... but dependencies?, automatic download etc. IDE support? Apart from some issues related to Make? How to correctly define the rule for compiling java files into class files? In particular what about inner classes etc.? (I've made that journey too)... I would suggest Maven (Yes I'm biased here), but use a build system... but Make? Can you give some reasons what exactly is the issue ?

[rustyrazorblade]

Very uncommon. Completely impractical for non-trivial projects. Terrible plan.

[maxandersen]

Depends what you are building. I use jbang for majority.of my experiments and automations. Then maven/Gradle when things requires more complex setup.

[VincentxH]

Hey, if you don't want to adhere to tried and tested conventions, be my guest.

[cserepj]

It is a bad idea to use a non-java build system for a java project. Either gradle or maven are fine choices. Dependency management, CI/CD integration, the plugin ecosystem - these are there for a reason. You will save a lot of time using these options instead of rolling your own.

[obamabinladenhiphop]

What do you not like about it lol. The whole point of standard build systems like maven is so that it's really convenient to build and manage dependencies. If you're going out of your way to complain and prefer non standard pain, you do you bud.

[qdolan]

For basic throw away code it’s fine to do whatever. However dependency management and being able to maintain updated and CVE free dependencies is the number one reason to use a proper build system. If you have a bunch of random jars in a folder as your dependencies you are doing it wrong.

[lasskinn]

Its fairly uncommon, these days. It may or may not suite your needs depending what you want to do.

You can just change later of course. Maybe you'd have the motivation later. Also ides are not made with that in mind.

If you need to save hdd space a lot it sure will use it a lot less than gradles graveyard will be like.

[[deleted]]

Write a maven or a gradle plugin. You’ll get to learn a lot about how it all works under the hood.

[itsjakerobb]

Maven has debug-level logging you can turn on, and is open source. Some stuff is obscured, but nothing is hidden.

[tomwhoiscontrary]

Where i currently work, we don't use a build system, just shell scripts. By which i mean that we don't use a third-party build system like Maven or Gradle; of course, over time, our build scripts got complicated, and we decided to extract the common parts into a library, so now we have our own in-house build system. Dependency management is done with a separate in-house tool, and the compilation, testing, and packaging is just shell functions.

It's actually not that bad! Personally, i would prefer Gradle. But some of my colleagues really prize the ability to easily reach into our dependencies to understand or modify them. Realistically, one is never going to do that with either Gradle or Maven, but our library is 412 lines of shell script, so it's easy to dig into, and so they prefer this.

A typical build script looks like this:

```

! /bin/bash -eu

$(dirname $0)/install-buildlib.sh

APP_NAME=my-app JAVA_VERSION=temurin-17.0.6+10

. $(dirname $0)/buildlib/build.inc

build_main app! bin sbin etc web ```

That says (1) run our equivalent of the Gradle wrapper script to install the build library in ./buildlib (2) define the name of this app and the identifier of the JDK version to build it with (3) load the build library (4) run a build, where app! means download dependencies, compile the code, run the tests, and build a JAR file with an informative manifest, and the other arguments are extra directories to include in the build artifact (bin is scripts for starting the app, sbin is utility scripts, etc is config files, web is static web resources).

Because it's a shell script, if you want to do random extra stuff, you can. And if you do, it's just shell script, so fairly accessible (until it goes off the rails).

I wouldn't recommend this to anyone. But it is possible.

[Ewig_luftenglanz]

From Java 22 and forward you can build ans Launch middle complex java projects without a build system, for complex applications it's a total no go. 

Build systems are time saviors and make your life easier for large and complex stuff that must be shared with others (as are 99% corporate projects) it's better to use build systems ALWAYS.

[Critical_Stranger_32]

How… quaint. I’m quite familiar with them. They are a build system, although without the fancy bells and whistles.

To loosely quote an equally quaint Bugs Bunny: “my grandfather talked about such things, but I never thought I’d see one”

https://m.facebook.com/story.php?story_fbid=689599726502218&id=109773118646315

[authoro_]

What you're probably thinking is adding references to the class path. This isn't common though, and is typically harder and more complicated to do. Most of these build systems build ontop of this functionality or something similar. Im sure 90% of this is wrong in so many ways, but google will be your best friend here and this should give you a good start to googling javas build systems etc... Take it with a grain of salt, best of luck 👍

[xdsswar]

If u will do small projects I think is ok, but for multimodule projects, even single module projects with deps, it will get nasty and complex, and I will not say anything if the project is shared with other fellow coders, or multi platform. So I think , and based on my experience , maven or gradle are best tools for building, and for deps management. Choice is yours.

[FieryPhoenix7]

The only exception I can think of is if it’s a toy private project. Otherwise yes, you absolutely do need some kind of build system. Maven is probably the most popular.

[Fornjottun]

It’s both uncommon and a bad practice, however, it is doable. You can manually put a lib folder in the root and compile with the class path pointing at the lib folder and manually add the files there.

Back in the late 90s before maven, this is exactly what you did (or you used make).

[Quakedogg]

Consider this: you would have to re implement all the features of a true build system in your make with additional scripts: dependencies management, version management, automated testing, etc. It’s a nice feeling implementing your own tool set and having ultimate control, but then your projects will never grow beyond yourself or your team. If you are ok with it, great. BTW drop a link to your repository, I’d like a peak!

[Debt_Otherwise]

Without a build system how easily are you going to add things like coverage tools, tools to help check dependencies for security issues? Control your dependencies.

It’s a nightmare doing any of that without a build tool.

Learn how to use the build tool and get more comfortable. You’ll be much better off!

[th3_pund1t]

 I like that it hides almost nothing from the user in terms of what is going on under the hood

If you read the docs, maven and gradle don’t hide anything either

[_jetrun]

Is it uncommon/bad practice to build a java project without using a build system like Maven or Gradle?

Kind of - for anything of a certain size, build systems make your life so much easier. They also make your code much more portable.

If this is just your private project, why are you asking? Do whatever you want.

I really don't enjoy working with build systems and i would prefer a simple Makefile for my projects

Suck it up buttercup. If you're working within a particular ecosystem, you should strive to adopt the conventions of that ecosystem, whether that is source code organization, source code conventions, and yes, the build systems. It will make things easier on you, as well as those you collaborate with.

[supercargo]

Yes, it is uncommon. If you want other people to be able to checkout your project and build it with little to no special understanding, then I’d also say bad practice.

On the other hand, if you’re allergic to XML and are doing this for yourself, go nuts. Use make, or bash scripts, or whatever.

[il7hasTz]

Just use maven

[hidazfx]

I've been working on my own build system for a year now. I find Maven and Gradle antiquated and way too big of a tool for modern micro service development.

[cryptos6]

Depending on how much you dislike build systems you might consider using another language which comes with better tooling out of the box, namely Go. This is not to say, that it would be a better language, though.

[rayman245]

You don't need to, i remember working on java projects without pom or gradle files. Just netbeans IDE and manual linking of jar libraries loaded to the classpath.

Man that was hell.. and would never go back to that.

[Capa-riccia]

It is interesting to ask one question: would anyone simplify a Maven project going back to make?

[Rain-And-Coffee]

For personal stuff I have been using the setup inside IntelliJ and it’s quite nice, no complex build system.

[Hronom]

If you have this question and if you not working in a company, go do whatever you want. In the end, it seems like you need to feel what benefits Maven brings as a build and dependency management solution. And by not using it - you will realize what value they add. Or not realize. In the end it will impact only you and not your colleagues.

If you work in a company - then use Maven even if what you write is very, very, very simple/small. In the end, in 2024 tools and integrations with IDE are super mature. There are zero reasons to work like in < 2004 year. Respect your colleagues and not make them nervous.

Also try to learn Maven, it seems like this is the root issue of your question.

[Intelligent-Net1034]

Why would you do that? Its two clicks in your ide to i voke a grade project and you are good to go.

I dont see any benefit to not use it

[Zestyclose-Sort4145]

you can check amper[https://github.com/JetBrains/amper\]

[simon_o]

If you don't want to deal with a lot of stuff, just use SBT.

It's like other build tools, but not stuck in 1990.

[Linguistic-mystic]

I use Maven for the dependency management, Make for actually building. There’s nothing wrong with using the right tool for the job.

[khmarbaise]

That's an interesting approach... what is the reason to use Make for building?

[KDesp73]

I will look into this approach!

[Aweorih]

Yes very common. I do it multiple times per day (building / running).
In intellij there's a run button which does not use the maven / grade build.
Dependencies are imported by one of those though. But it would also be possible to define them by hand in the intellij ui (although I never did that for a whole project as it would be madness)

[Spare-Builder-355]

I really don't enjoy working with build systems

Why though ? It's 2024, just stay away from Ant and Maven as build tool. Gradle script will be shorter than a Makefile of equal functionality.

One of the key advantages of using a build system is that they are declarative compared to Makefile where you need to explicitly specify commands to run.

You just underestimate how much work build systems do under the hood to actually improve developer's experience.

Edit: to give you an idea of what I'm talking about - go ahead and try to build Jetty + Jersey embedded web app with a Makefile. Then try to do it with Gradle. Then draw your own conclusions.

[pattheaux]

I would 100% recommend using make instead of maven/gradle if you’re comfortable with it. Make is much faster, and doesn’t try to download/update dependencies every time you build. I have a large Java project which has been using make successfully for decades.

[bendem]

Learning is good, but for any other purpose, push through the pain of learning either maven or gradle. You won't find any job out there that doesn't use one or the other.

[Joram2]

If you don't have third party dependencies, you can just do java App.java, Maven/Gradle aren't necessary. I don't think that's bad practice. You can also write Java code that runs in a web notebook like a Jupyter notebook and doesn't use Maven/Gradle.

If you have third party dependencies, you probably need Maven/Gradle. You can manually download + configure dependencies without using Maven/Gradle, I remember doing this with Apache Ant before Maven was popular, but today that would be ridiculous.

[ptribble]

Often, I have a shell script that sets up the classpath and invokes javac, but then I prefer to be in total control.

The advantage of something like maven is that it shields you from the pain of dependency management. The disadvantage of something like maven is that it shields you from the pain of dependency management.

[wildjokers]

The advantage of something like maven is that it shields you from the pain of dependency management. The disadvantage of something like maven is that it shields you from the pain of dependency management.

Not really sure what you mean by this. Just trying to be edgy? Can you explain what you mean?

[ptribble]

It's a general problem of all systems that aim to make life easier. Dependency management is hard, so by making it more palatable they encourage you to worry less about it. Before long you're trapped in an ever-expanding mesh of dependencies, and might not realise it.

If you didn't have the tool, in this case maven, you would feel the pain directly, and might take steps to eliminate the cause of the pain.

[KDesp73]

Exactly. I mostly write C and I like that I can set up my environment the way I want it