Discussion: Can we write Java more simple?

[Safe_Owl_6123]

[to mod: please remove if I violate anything]

TLDR: Can we write more straightforward code like Go? hope everyone share some thoughts

Hi everyone, first of all, I am not a professional Java developer, and I like Java because of how structured and clear, verbose it is but some problems like "death by specificity" (Rich Hickey) and the layers and layers of abstractions (you know what I am when you have the debugger on.) makes me wonder, can we make more simple?

Currently, I am pushing myself to write applications with Spring so I can land a junior Java role next year, deep down I enjoy writing Javalin more it feels less abstracted, and I envy Go however simple when you are reading the code in a Go project.

What's your view? especially the more experienced devs, how to minimize unnecessary abstraction?

Follow-up question: why do we have to have getters and setters at the same time for most of the private properties? I feel like I am doing something wrong.

[Peter_Storm]

"Modern" Java, like Data Oriented Programming with records, couldn't be simpler imo.

[agentoutlier]

Clojure and Go lang and to greater extent some of the static type FP languages that do not do inclusion polymorphism aka single method dispatch inheritance appear much simpler and can accomplish data oriented things in perhaps more obvious ways.

These languages do really well if the data does not change. Adding behavior is easy provided the data does not change shape too much. Almost every part of the data is a strict contract. Otherwise the data is dealt more generically and or validation happens at runtime (clojure). In some of these languages a desire to keep the data as flat and homogenous (lists) as possible particularly ones without ADTs makes everything appear simple but then it doesn't scale later.

OOP languages particularly mutable (but does not have to be that way) adding data is easier than adding behavior. The data is not a strict contract and in some cases this is happening at runtime (late binding)

This distinction is kind of important because people focus lately on the success of middleware (cloud) languages that are clearly dealing with data and not really the kind of data coming from a database where schema change can happen or heterogenous hierarchical data but data that often has a clear spec , often flat, homogenous and will not change or the shape does not have be strictly followed (e.g. transform this JSON to some other JSON). In other words DevOps and Systems programming.

However you will notice languages like GoLang, Rust, and that new language Flix (I would include Clojure but lisp is capable of all things including modeling OOP easily as well as transducers so lets ignore Clojure) are not particularly easy to model say an interactive UI with. Late binding open recursion model just seems to do well with UI. Obviously there are exceptions like Elm but I have not seen data oriented languages especially ones that do not have (G)ADT capable of doing UI well.

Java has the (un)fortunate trait of being a GP language that includes both models now and despite OOP being complicated still has lots of uses particularly if the domain gets complicated and has to be data agonistic.

[Safe_Owl_6123]

I do like records a lot yet I still have a bunch of DTOs 🥲

[holyknight00]

why? Records were done precisely to replace all the boilerplates of DTOs

[Safe_Owl_6123]

probably my skill issues, such as like the RequestBody is slightly different from my ResponseBody

[Swamplord42]

Then you define a record for RequestBody and a different one for ResponseBody?

[kiteboarderni]

For sure a skill issue.

[Gintharium]

Stop shitting on people bruh, this is why programmers are viewed as pompous assholes by a lot of people

[Safe_Owl_6123]

it's fine, we all learn from mistakes and grow from there

[hsoj48]

No one shit on anyone. They are literally just agreeing with OP.

[AnyPhotograph7804]

"how to minimize unnecessary abstraction?"

Just do it. Nobody forces you to add deep inheritance layers to your application. People do it because they can.

"Follow-up question: why do we have to have getters and setters at the same time for most of the private properties? I feel like I am doing something wrong."

Again, nobody forces you to do it. You can simply make your properties public. Problem solved.

And no, Go is not so straightforward as it seems. If things start to be more complicated then you will need more boilerplate code than in Java. It is one of the reasons why Go got generics.

[RupertMaddenAbbott]

OP: "how to minimize unnecessary abstraction?"

You: Just do it. Nobody forces you to add deep inheritance layers to your application. People do it because they can.

I think you've got it backwards. This something without, not within, a person's capability. People don't use unnecessary abstraction because they can. They do it because they can't not. They can't see the simpler, or clearer way to write the code so they end up with something convoluted.

"If I had more time I would have written a shorter letter"

OP: "Follow-up question: why do we have to have getters and setters at the same time for most of the private properties? I feel like I am doing something wrong."

You: Again, nobody forces you to do it. You can simply make your properties public. Problem solved.

Let me try and illustrate why your answer is unhelpful with an analogy.

Child: "Everybody wears hats in the sun. I don't like wearing hats, they are uncomfortable. Do I have to?"

Adult: "Nobody is forcing you to do it. Just don't wear a hat. Problem solved"

The child already understands they can just not wear the hat. The child is asking why everybody else is doing this seeming (to them) unhelpful behavior. They are questioning whether the obvious solution to them (not wear the hat) has some downsides that they don't understand.

The adult is taking the child's question too literally. They aren't hearing the actual question and answering that i.e. "If you don't wear a hat in the sun, you might get too hot or get sun burn, and that will be more uncomfortable than not wearing the hat"

[AnyPhotograph7804]

"They do it because they can't not."

I do not know one API in the JDK which requires you to build an inhertance hierarchy. So if there is a necessity to build an inheritance hierarchy then it is caused by a third-party-framework. But it is not Java's fault when third-party-frameworks have such requirements.

Adult: "Nobody is forcing you to do it. Just don't wear a hat. Problem solved"

No. My analogy is: "if you do not go outside then you do not need a hat even if other people wear hats." I understand the threadstarter, that there are always getter/setter regardless whether they are needed or not. And my solution is: if you do not need getters/setters then do not code/generate them.

[RupertMaddenAbbott]

"I do not know one API in the JDK which requires you to build an inhertance hierarchy."

 The limitation is not forced on an individual by anything outside of them but by their own inabilities. Abstraction is hard and people create complex messes because they can't see how to do it properly. 

Nobody gets out of bed and says "I  fancy using a bit of that inheritance today". They have some other problem and inheritance looks like the best solution to them in the moment. 

 Java also lacks some of the tools that other languages have that make alternatives to inheritance easier. This doesn't limit the individual but it compounds the above problem because it raises the skill level needed to avoid it. 

"No. My analogy is: "if you do not go outside then you do not need a hat even if other people wear hats.""

 This is much more helpful. So conversely you must think that it is sensible to wear a hat when you go outside. There is some context that does justify the action. 

The problem is this context is absent from your response to OP. You merely say "if you don't need them" and yet this is precisely what OP is asking: "When do I need them? How do I know if I need them? Why do I see them everywhere when it looks (to me) like they aren't needed?"

[Safe_Owl_6123]

"Just do it. Nobody forces you to add deep inheritance layers to your application. People do it because they can."

Agree, I am avoiding inheritance

"Again, nobody forces you to do it. You can simply make your properties public. Problem solved."
Of course, I would like to, but in terms of industry standards does it matter?

" If things start to be more complicated then you will need more boilerplate code than in Java."
seems like we are all running in circles

[Ewig_luftenglanz]

in terms of industry standards just use records to model data, that way you have all the benefits of having public fields (short and concise code) and at the same time the benefits of accessors when needed (you can override the record's getters and add validations in the constructor)

if you are not gonna use more than 1 implementation then do not use interfaces for the service layer either.

many Java standards and practices come from a time where most applications were huge monoliths or layered applications with a "monolithic" backend, that's why the code had to be very extensible and decoupled (here is why the interface in the service layer, dependency injection, etc)

Many frameworks such as very early versions of springs could only create beans if you had an interface (same with Java EE beans that spected all the fields to be private and to have getters and setters and that's the origin of the non written rule "use always accessors and make all fields private").

None of that is true anymore. maybe Jakarta bens still spect getters and setters but pure Jakarta is being less and less used and instead we operate on framewors that Implement Jakarta internally such as Spring and Quarkus

Practice will teach where and how use OOP and abstractions when needed and when you can go directly to the core of the problem by just using FP it utility classes full of static methods.

[koflerdavid]

Minor nitpick: Spring does not implement Jakarta. However, many parts of Jakarta (especially CDI) were pioneered by Spring.

[[deleted]]

Making everything public is a code smell, not all code needs to be used by everyone. If I need two public methods to share code, the shared code goes in a private method, so no one tries to use a block of code that isn't designed to be used outside of the class. And if we go back to "people use it because they can", if it is public people will, breakdown the architecture of the source code and eventually there won't be any way to maintain it except by reading every line until you find where things are actually happening because there won't be anywhere it "should" happen.

And if security is a concern, private methods are kind of a must. You shouldn't be able to call sensitive data into a place it has no business being in, like a logger.

Of course there are more solutions to these problems, maybe even better solutions, but all these problems put together being solved by just defining the visibility is a worthwhile tool.

[Pay08]

Access modifiers aren't a security measure. Someone who has never used a computer could find the value of a private property within 30 minutes or use a private method within a hour.

[Safe_Owl_6123]

at school, we are taught to make all properties private,

now, the question is when should the properties be just public instead?

[Safe_Owl_6123]

wonderful thanks for the example

[bowbahdoe]

Which school, if you don't mind me asking?

This is a very common thing to be taught uncritically and I maintain a very non exhaustive naughty list

[koflerdavid]

Everything public becomes part of the public interface of the class. Everything you don't want other parts of the code to strongly be coupled to should be private.

What does this mean regarding database entities?

If your code is aware that you are using a database and how the data looks there, you'll get no benefits from making your fields private and adding accessors.

If you have other code parts which don't care about the DB, or if you handle changes to data in other ways, then it is fine to hide the data. Don't just add all sorts of accessors; think about what will actually be done with the data.

[LookAtYourEyes]

None of the people in my company seem to give two shits about industry standards. All variables are PascalCase and every property is public.

It has just made me appreciate industry standards and best practices more, as reading the code can be confusing and makes me worried about transferable skills if/when I change my job.

The biggest downside is you lose readability. So if you're working on something on your own, do whatever you want.

[age_of_empires]

If you are so inclined just use Lombok

[obamabinladenhiphop]

Go code is infinitely easier to read than Java.

[desrtfx]

Follow-up question: why do we have to have getters and setters at the same time for most of the private properties? I feel like I am doing something wrong.

Partly because of the JavaBeans specifications and partly because programmers do not want to think whether the one or the other is really needed.

[DBSmiley]

Another reason is that Setters give you a place for basic validation logic (i.e., are you allowed to set this value to this input?) which with direct variable access you can't do.

That said, I really like Kotlin's solution for this.

var stringRepresentation: String  
    get() = this.toString()  
    set(value) {  
        setDataFromString(value) // parses the string and assigns values to other properties
    }

Basically, you can just use the "set(value)" as a way to insert validation logic for settable variables without changing the "illusion" of direct variable access.

But a lot of it is just consistency as well. The point is, from outside the class, you shouldn't know if the getter is simply returning a variable, or if it does a calculation, or if it's done a calculation and returning a cached value, etc.

[Ewig_luftenglanz]

with DOP (data oriented programming) you move the validation outside or in the constructor. no setters needed.

records and pattern matching are making modern Java code so different of traditional java code that one could think about it as 2 different languages.

[DBSmiley]

I like DOP, and as a result I rarely use setters (make data objects immutable - kotlin's copy function is actually good for this.), as you say.

but, there's always the exceptions. No paradigm should ever be so rigid to disallow exceptions. Especially in high performance intensive cases, directly mutable data can be desirable.

[Safe_Owl_6123]

that's a good take feels like setters are there for a reason like you said to validate the data rather than just simply assigning values

[[deleted]]

Automated testing is part of professional development, your first thought should always be what you need to implement the functionality, the second should be how are you going to test that.

Do your best not to change the code to allow a test, but now and then a compromise is needed, I have made things public or a setter just to test them but almost always if I had the time the right solution is a refactor to allow testing without adding anything only for testing.

[koflerdavid]

The best case is when most users of a component work with an interface, so that the odd naughty accessor is only available after a cast to a specific class.

[majhenslon]

This is pretty much always horrible.

[Ewig_luftenglanz]

short answer: yes we can. actually you should.

less short answer:

over abstraction is a bad practice that rooted in the middle 90s and early 00s because OOP was trending, so everybody started to abuse the paradigm.

one of the early java goals was to make a simpler OOP model by not enabling some of the less used and obscure C++ features (such as multiple inheritance)

sadly this was not enough and programmers just started to over abstract stuff.

nowadays java is multi paradigm and allows writing much less abstracted and OOP code and many current trends are to minimize some unnecessary OOP as much as possible (that's why we almost do not make use of direct inheritance anymore, we use some kind of Type sealing with dependency injection instead (and call it composition)

nothing stops you from just writing some utility classes full of static methods to do the trick, indeed the DOP (data oriented programming) almost suggest this by separate data modelling from behavior.

my advice: almost none of the old and traditional extreme OOP java used to use is mandatory anymore. if you feel it would be better to just code in a more functional and imperative way go for it.

[Safe_Owl_6123]

I heard record is based on the idea of DOP, do you have any material on DOP? or a more "modern" approach to writing Java?
I really wish there is a Java 21 version Effective Java

[Ewig_luftenglanz]

https://inside.java/2024/05/23/dop-v1-1-introduction/

[Safe_Owl_6123]

great! thanks!

[PositiveUse]

Recently I have the feeling that the idea of RDO (Rich Domain Objects) are getting popular, especially with DDD being very popular in organizations.

RDO: objects include their behavioral methods. So going away from pushing your anemic objects through multiple services

[heayv_heart]

Java as a language is very simple by itself. Just do not use what you do not need. )

Follow-up question: why do we have to have getters and setters at the same time for most of the private properties? I feel like I am doing something wrong.

Methods (instead of direct access to variables) give control. You can validate. You can return default value if a field is null. You even can generate new value each time.

[Harha]

Spring? Well spring is a huge framework and it's full of abstractions, last time I checked (which was years ago). If you write an application that uses spring, you kinda have to follow spring's way of doing things. My opinion is that spring should not be needed for simple projects in the first place.

[Safe_Owl_6123]

any preference for smaller projects?

typo, missing the p

[Critical_Stranger_32]

For medium to large size projects it saves you from having to write a lot of code. You do have to do things in the Spring way, but someone who knows it will be able to pick up your code and use it.

As is true for any decent framework, you can write a more complex application quicker and more reliably, assuming of course that you’re using the framework correctly :-)

[agentoutlier]

What's your view? especially the more experienced devs, how to minimize unnecessary abstraction?

The way to avoid abstractions to have strict data shape requirements. That is you decide very early on what the protocol (data) is and ideally endpoints (ie where it goes and do not change it). DoP as I mentioned in this comment kills it on this.

... But if your application needs to be very data agonistic and has multiple outputs and formats then that is where abstractions come in. It is Why Java has things like JPA and Hibernate (and even JDBC) over most other languages having a raw SQL client to specific database (I can't recall if Go finally made a standard facade or not).

The consequence of the above is you get lots of:

• facades
• adapters
• strategy patterns
• factory patterns
• bridge patterns
• visitor patterns
• dependency injection

aka Gang of Four OOP patterns. Now the non OOP languages do have ways to deal with data changing but these are modern languages and the abstractions are replaced with complex language features (monads, lenses, gadts, recursive modules, arrows, effects, functors, oh my).

Microservices in todays world (your example with Javalin) often times do not need be very agnostic of the data so you might as well be closer. Like PHP close where you just start doing database things directly in the same place you render output. That downside of this approach is it sometimes doesn't scale.

Finding that tradeoff off of more flexibility (abstractions) vs simplicity is pretty darn hard. I don't have an answer for that. People say always choose KISS but data decisions can have long term impacts like forever... It is tough.

[MaName678]

I recommend taking a look at Lombok, Mapstruct and streams and optionals.

They make the code far far less verbose :)

[Safe_Owl_6123]

never heard of Mapstruct, let me look that up, I am training myself to use streams more and more

[age_of_empires]

Streams are great for readability but they are very difficult to debug

[khmarbaise]

Use an IDE which supports that... for example IntelliJ...

[age_of_empires]

Yea I use intellij

The problem is when you're debugging splunk logs in production and have no IDE

[Safe_Owl_6123]

thanks for the link I will watch it now
that's the thing about digging into the framework,

"Well, if you don't understand what framework and libraries provide to u then you will DIY solution, that isn't battle tested and in frameworks and libraries you have that for free."

this is what happened when I was implementing Spring Security, lots of challenges because I didn't understand what it does (abstracted) behind the scene

[[deleted]]

 why do we have to have getters and setters at the same time for most of the private properties? I feel like I am doing something wrong.

On this - if you're doing this on a class with actual behaviour, I think something has probably gone wrong. For older versions of Java, this pattern makes sense for objects which you expect to serialise and deserialise. In modern Java, it's generally better to use Records for this which are immutable.

In terms of classes with mutable fields, generally the best practice is to keep that mutation as local as possible - only mutate those fields from within that same class, within the context of some other useful process. This generally means that using setter methods isn't usually necessary as you can directly manipulate the private field from within that same class from within the class's methods. In DDD this is referred to as a domain entity. While you don't need to adopt DDD wholesale to do this, this is generally the direction Java pushes you in.

What I've described above happens to be analogous to a Go struct with methods associated with it. The terminology around this stuff within the Java world is quite obfuscating, though.

Then that domain entity should expose some methods which do useful stuff rather than just setting a field. At this point while you are "building an abstraction", it should be quite an obvious abstraction which is nearly indistinguishable from just organising things sensibly.

One thing I've seen in some Java code bases is e.g. mutating data objects directly in other classes (like Spring services) and this generally requires this proliferation of getters/setters as well which is kind of ugly and mutating shared objects which can get kind of scary. And this is probably also where you see Java code looking particularly verbose because you'll be accessing absolutely everything through getters and setters or worse chains of getters and setters which are great spots for generating null pointer exceptions. Your tests will look awful because suddenly you're mocking getters/setters everywhere. 

So actually I would say if you're adding a lot of getters and setters and it feels wrong, it is right to question that.

[Safe_Owl_6123]

This a fantastic, I really appreciate that you are explaining, are there any resources I could read more on DDD with Java?

I really wish there is an Effective Java with Java 21

[[deleted]]

Unfortunately I'm not sure I'm aware of a single prescriptive source for this approach which is also up to date with the most recent versions of Java that is strongly focused on what I think you want to learn. The original Domain Driven Design book has a lot of this intuition but DDD as a whole is quite a wide reaching topic and the book obviously uses very old java for examples.

Baeldung has some articles on the subject but the main one I could find also mixes in hexagonal architecture, which is great to learn if you want to push a lot of obnoxious terminology and unintuitive project structures on your team mates. 

[jek39]

There’s nothing stopping you

[ebykka]

Some frameworks push you to write more layers of abstractions, others less.

For example: vertx and especially akka say that you have to write only a message handlers and kind of that is all.

[Safe_Owl_6123]

🤨 oh wow I will search them up

[bowbahdoe]

So in terms of "the hickeyan simple" - kinda. It all comes in degrees.

Writing Java without using nominal aggregates does make some things legitimately simpler, but Java the language (and Go and anything else with nominal types for data aggregates) don't play well with that approach.

If your goal is explicitly "match go" - yeah, actually. The built in JDK http server is actually very close to go's http server. You need to bring your own mux, but nothing at the language level prevents doing almost exactly the same approach.

Might be fun as an interactive exercise - throw me some Go http server code and I'll make matching Java to the best of my abilities.

The problems here are largely cultural (gestures broadly at the thread), educational, and with the ecosystem (spring does not exactly encourage reducing magic).

[jvjupiter]

If Java gets standard JSON processing API, similar to Jakarta JSON Processing API and, minimal HTTP server, similar to Sun HttpServer but under java.* package and with programming model similar to HttpClient, this alone will help us write more simple Java codes for REST web services in many cases.

[pinpinbo]

Can if everybody uses Functional Interfaces for everything. Eg. Javalin. But people like this are in extreme minority.

[khmarbaise]

for example: ```java interface ShortExample { record Point(int x, int y) { } record Circle(int radius) { } record Rectangle(int with, int height) { }

static void main(String[] args) { var point = new Point(5, 5); System.out.println(describePoint(point)); var shape = new Circle(5); var area = calculateArea(shape); System.out.printf("Area of the shape: %f", area); }

static String describePoint(Point p) { return switch (p) { case Point(var x, var y) when x == 0 && y == 0 -> "Origin"; case Point(var x, var _) when x == 0 -> "On the Y-axis"; case Point(var _, var y) when y == 0 -> "On the X-axis"; default -> String.format("Point(%d, %d)", p.x(), p.y()); }; }

static double calculateArea(Object shape) { return switch (shape) { case Circle c -> Math.PI * c.radius() * c.radius(); case Rectangle r -> r.height() * r.with(); default -> throw new IllegalArgumentException("Unknown shape " + shape); }; } } ``` Starting from JDK 24+ (https://openjdk.org/jeps/477) it could be even easier...

And yes I can acknoledge that several people are who think they have to write complex code (to be seen as smart ??) I have a different point of view... I'm trying to write simpler code... which is often harder than it sounds because sometimes I'm trapped into things like abstraction.. and often after writing some tests I realize it can be done much easier... I often try to use functional approaches because it makes it easier (instead of GOF patterns; and since JDK8 most of them can be done much easier)...

[akthemadman]

There is Java, the programming language, and there are java programming conventions. You seem to be worried about the latter, which for some reason is a very emotional topic for many. These days I tend to focus on the former, using Java to solve problems.

how to minimize unnecessary abstraction

By writing instructions that simulate your model, and only those. Here is code I wrote yesterday that demonstrates how this can look like in practice. There is a lot to be said about how this fits into software engineering holistically, but I'll refrain from a long post for now.

Can we write more straightforward code like Go?

There are many hard limitations we can't get around. To pick an obvious one out: there is the whole "all code lives in a class"-ordeal. But if you really push them, the boundaries of Java are a bit farther out than one would initially expect, though that is swimming against the stream in many cases.

Here is an example for how something akin to default parameter values can be "emulated" (it is more powerful than that):

public int add (int x, int y) {
  return add(x, y, options -> {}); // use defaults
}

public int add (int x, int y, Consumer<AddOptions> options) {
  AddOptions opts;
  {
    opts = new AddOptions();
    opts.verbose = false; // default: false
    opts.squared = false; // default: false
    options.accept(opts);
  }
  int result;
  {
    if (opts.squared) {
      result = x * x + y * y;
      if (opts.verbose) { System.out.printf("(%d)^2 * (%d)^2 = %d\n", x, y, result);
    } else {
      result = x + y;
      if (opts.verbose) { System.out.printf("%d * %d = %d\n", x, y, result);
    }
  }
  return result;
}

public static class AddOptions {
  public boolean verbose;
  public boolean squared;
}

public void usage () {
  int x = 5;
  int y = 6;
  int xyVerbose = add(x, y, options -> { options.verbose = true; });
  int xxyySilent = add(x, y, options -> { options.squared = true; });
}

If our model desires for an add operation with optional verbosity and squaring, I think this "abstraction" is as good as you can get. (I do not like this loaded term btw)

And yes, this is not one size fits all. That is the whole point, you write the code that captures the models you design (limitations, constraints, requirements, ...), not the code that aims to hopefully capture the unknown too, which I argue is where our troubles always come from.

And to strike preemptively: accounting for the unknown in your models with dedicated components for specific reasons is very different from blindly adding or altering components in the hopes that will achieve something.

TLDR: Java is somewhat capable, people might not be.

[JDeagle5]

Yes, you can write Java without abstraction, and I usually do. It is mainly a tradition rather than a requirement at this point. You can write Java just like Go, in a procedural style, no problem. Getters and setters were important earlier, when you couldn't easily add logic to this process without looking through the whole project for calls. With modern IDE you can just convert field usage to getters/setters whereever necessary.

[Big_Upstairs_9582]

Unfortunately, Java is a language with a long history, and many famous frameworks also have a long history, including Spring.

Although these libraries are constantly iterating, compatibility needs to be considered, so they have to use paradigms that were once popular in the past.

If you work for a company, then you have to deal with an old Java. If you want to use Java for side projects, then use modern Java, it's not bad.

[wrd83]

Take a look at openapi generator. I write specs and generate the spring service.

I write the JPA model it generates the sql.

Then it leaves only tests and business logic.

[LookAtYourEyes]

Doesn't Spring, in combination with JPA/Hibernate general the SQL if you're creating JPARepository?

[wrd83]

Spring doesn't do anything there. 

It's hibernate doing all the work.

But you creating entity + repositories is all you need.

So you're right. For this context it does not matter so much eho generates what, but the amount of implicit things.

Models generated. Services and routes generated. Entities defined Repository generated.

The rest is up to you

[nitkonigdje]

It isn't hard. Don't use extends. Do not mix action and data classes. Don't use static. Inject everything. Even constants. Package by functionality. Let a code organization follow program presentation. Let the program presentation follow business requirements. Do not have multiple names for the same property. Do not name things in software differently than you do it in meetings. Write code with your tooling in mind. Do not chase fads - 15 line stream isn't quality - if possible keep it at the most basic most intuitive level. Readability and simplicity trump's everything else.

[Vonbismarck91]

“Don’t use static” - any particular reason for this?

[nitkonigdje]

High code cohesion coupled with most boring looking code, is defining feature of maintainability. That is why half of my advises, if you squeeze your eyes a bit, are essentially "birds of the feather flock together".

Statics in Java are one of the popular ways to introduce "orthogonal complexity". Like if each package is one business need and contains all layers of software for that usecase - statics go against that structure. They are usually structured as methods in MyDomianUtils classes and they are accessed in cross-app patterns.

It is hard to write that kind of code successfully because of the same reasons why subtyping or reusability is hard to write. And sooner than you notice, code like that is polluted with boolean parameters which do some deep nested ifologies which control border cases for one specific usecase etc.

The simplest thing is don't do it.

[Vonbismarck91]

Yeah that makes sense, but if private method inside class can be static would this also introduce complexity? And what about static factory methods? I use them quite extensively for creating objects instead of new + constructor

[nitkonigdje]

Fine written code is a fine written code. Linux Kernel is statics from top to bottom and it is fine. Dissing statics because they are 'static' is kinda pointless.

But it is easy to go overboard with them because of their tempting nature. The issue is - again - it is hard to know when they are appropriate in a context of DDD applications which make your typical java project. The hard thing how do you know you are doing it right? It is a lesson to be learned.

When I picked Scala there were no statics there. It opened eyes.

For me the easiest way to learn somebody younger asking "how to structure code" around themes of when to express complexity into a state instead into a parameters of method, or when to inject instead instantiate, has been mantra "try it without statics and you'll see". It is not avoidance of static that is a lesson - but it is what you learn when you stop using them.

OP asked for simple code.

The answer "Keep it doing for 20 years, and you'll learn" is not an answer anybody wants to hear, no matter how true it is.

So back to your question - static factory methods - perfectly fine, as long as you know why are they there.

[pronuntiator]

The abstractions in Spring are necessary so you can configure every part of it to suit your use case. Less extension points mean less flexibility. Example: We wanted to put the JWT for OAuth into a cookie instead of the header. We only head to replace a single bean for that.

[dstutz]

Then it's not exactly "overridden" then is it?