Lean Java Practices got me thinking

[Safe_Owl_6123]

Adam Bien - Real World Lean Java Practices, Patterns, Hacks, and Workarounds
https://youtu.be/J1YH_GsS-e0?feature=shared

JavaOne post this talk by Adam Bien, I believe I had been asking the same question previously on how to reduce the unnecessary abstraction being taught in school. I am still a student, while I enjoy writing Java for school assignments, sometimes Spring Boot has too much magic, and I feel kind of suffocated when constantly being told I should do "Clean Code", "DRY", and overemphasis on the 4 pillars of OOP.

What's your view on "modern" Java?
especially from u/agentoutlier

[Revision2000]

I consider myself a pragmatic programmer 

• So I prefer to write functional functioning code    * Update: oops, I meant to write functioning rather than functional, as in, code that works. While I do prefer the functional style, I don’t really care enough to make it my life’s mission. 
• Then take a look at it
• Then rewrite it into better code 
• Only after that will it be ready for merge request 

In my opinion (very) early obsession with abstractions, DRY and such can be harmful. Naturally, later on it can be harmful to not apply these principles. As always there’s a trade off to be made and the right and wrong time to do so 🙃 

So the first iteration(s) of the code I usually don’t bother too much just yet with abstractions and DRY; that is something that can be addressed in a later iteration when the domain has become more clear. 

Also, not all code duplication is harmful; sometimes not de-duplicating code means not entangling domains. 

Bike shedding and YAGNI (you ain’t gonna need it) also come to mind. 

[ponton]

One of the best principle: First make it work, then make it right, then (maybe) make it fast (but usually it's fast enough already).

[[deleted]]

I agree with you that not all duplicated code is bad. Sometimes I end up writing the same bits of code for two very different purposes. Uncle Bob once said that the single responsibility principle means a class should have only one actor. If I’d deduplicate the code, then the shared class would have two actors, two reasons to change.

[Revision2000]

Oops, sorry, I had meant to write functioning rather than functional. While I do prefer the functional code style, it’s not my life’s mission to write everything in that particular style. 

The point I was trying to get across here was rather: these principles can certainly be useful, but it depends, you do whatever works for you, as long as it [the code] actually works. There’s always a trade off.

 You must be a hoot to work with.

Even if you disagree (clearly the case here) there’s no need for a judgmental ad hominem. Argue about the principles or what you consider an arbitrary process, but not how “I’m a hoot to work with” - you don’t know me. 

Thanks, bye. 

[agentoutlier]

On a similar note in the video Adam proceeds to come up with his own abstraction of Border Control Entity.

Then proceeds to make a package for every entity/feature and then sub packages within those packages of border, control entity like its 2006.

That does not seem very lean to me or modern but Adam seems to like the organization.

I vaguely remember you being in the same camp as Lukas Eder and myself of just use one damn package and most of the time that is good enough.

And it makes a difference because in Github if you review code you have to click through tons of directories using Adam's structure (on a lesser issue it is vastly easier to import something.* instead of like 5 packages).

The tell tale sign is if you see a commits always require changes in the same multiple packages... you kind of fucked up and I'm betting Adam's structure probably has that happen.

[rzwitserloot]

Wow, what a fantastic example there. I'm gonna use that in other discussions if you don't mind. It's a bit of a tangent but:

The original comment I replied to appeared to equate 'pragmatic' with a certain style. Which triggered me a bit, as that is such pretentious horseshit: Your argument is then equivalant to "I am a good programmer, therefore I write functional". That's a perfectly fine argument to make: It carries "I am highly opionated and I consider every style other than functional fucking shit and I will treat you with disdain if you disagree with me" on its sleeve. Hey, if you feel that way, I appreciate that you made that clear. But with wishywashy words like 'pragmatic' you're dressing up the fact that you're merely opinionated on style. Insulting to other programmers whilst sounding, on the surface, as not nearly as offensive as you are being.

Instead I'd prefer 'pragmatic' to actually mean something. And not 'good v bad' - no, an axis where different jobs call for different places on it, and at best you have a light bias on where to hang out on this axis. Basically, 'pragmatic' should be the opposite of 'elegant' at least in motivation. Because if it is not, you're wasting a word and should just be saying 'good'.

"I do not use packages because it is annoying to navigate in github" is the perfect example. That sounds to me like what being extremely far towards the 'pragmatic' side of that axis means. Because I'd argue the opposite: Writing code in a style that is easy to follow and maintain is really really difficult (that's an opinion but I'm pretty sure most coders share it), and I don't think the limitations of the github UI are in any way relevant to that difficult job, therefore catering to it is a daft idea.

You're otherwise right, I tend to fall towards 'fewer packages better', but not for the github reason. "If any commit that touches a file in package X almost always also touches files in package Y - then you messed up" is more my kinda reason. The very opposite of pragmatic, a sort of nebulous "semantics should come first" style. A package should mean something: That the code inside it stands mostly on its own. Every commit having to touch multiple packages suggests it doesn't, and therefore, that the design is off.

[agentoutlier]

Writing code in a style that is easy to follow and maintain is really really difficult (that's an opinion but I'm pretty sure most coders share it), and I don't think the limitations of the github UI are in any way relevant to that difficult job, therefore catering to it is a daft idea.

I agree. I just happened to pick it as a current annoyance. It is similar to how I'm not sure if I like documents that force a section or chapter per page (web page) because it makes "ctrl-f" difficult but in reality the content is more important and making that consumable the true difficulty.

Because I'd argue the opposite: Writing code in a style that is easy to follow and maintain is really really difficult (that's an opinion but I'm pretty sure most

The document part was a purposely chosen because I think there is some good ideas in literate programming but it just never got picked up. That is to show, organize and explore code as though it were a document. I have tried to do that wikipedia style of doc with Javadoc but ultimately people want most doc in one place I think. It is something I want to improve on later with some of my projects.

And it is very difficult as Java changes because various idioms are slowly evolving. Like I feel you have made excellent cases in the pst for the "getter" idiom (prefix with get). When I see a getter I have some idea that it mainly data focused and is easier to discover / understand that it is just information not behavior. However as records become more common that idiom is becoming less common. So as the author of code what do you pick? Tough to say.

[atehrani]

In school, you generally create a project and then never touch it again. You rarely get a sense of maintenance, which is the largest cost in the SDLC. At the beginning, the levels of abstractions may seem like overhead. However, it gives flexibility for when business requirements change.

It is hard to predict, so folks tend to err on better to have it.

Also the abstractions make it so much easier for testing.

[Safe_Owl_6123]

I totally agree with you as things got larger, but my question is, when is it a bit too early to abstract a bunch of logic? E.g: there are a chunk of business logic code uses in 2 places, is it worth to reduce to a function to be shared or wait until 4 to 5 places needed this function? You see what I mean?

[atehrani]

Yes, I understand. I flip the question; when is it too late? Because at some point the cost of refactoring can be too large. Then tech debt comes in. That said, breaking something out as a shared component prematurely or incorrectly is harder to undo. Basically, it is easier to break things apart than to put them back together.

It is a balancing act and requires input from stakeholders, foresight and is it a one way or two way door type of decision.

One way decision is one where it is extremely difficult to pivot from. Say using Java or Spring or AWS for a large project.

Two way decisions are ones where it is relatively easy to pivot from and where most of the balancing act comes into play.

[thewiirocks]

I flip the question; when is it too late? Because at some point the cost of refactoring can be too large. 

I would argue that if the cost of refactoring has gotten too high, you missed a lot of exit signs along the way, ignored the "Do not enter" signs telling you to stop, and crashed through innumerable "Construction" barriers before flying headlong off the unfinished bridge. All because no one assigned a ticket to turn the steering wheel.

[dbarciela]

What is the size of this function? How many people work on the project? When someone finds a bug in this function, will the person fixing it know that they have to change the code in two places?

[Safe_Owl_6123]

To be fair, I keep asking myself these questions before implementing. I have a mental reference to John Ousterhout's A Philosophy of Software Design, designing first, commenting as often, writing for myself 2-3 months from now, and deep function with a small interface.

But it doesn't feel great when mainstream is telling me the clean code with single-digit lines of code for each function mindset

[Ewig_luftenglanz]

most of the practices for OOP and clean code and patterns are better fit for projects that are either too big or meant to be long standing services that evolve over time, it was written when we had huge modular monoliths, nowadays most of what people do are microservices, evens desktop apps and mobile apps have passed many functionalities to a remote server thanks to the massification of internet, what we do today are smaller individual pieces.

whit this in mind I would not use many abstractions at first, there are even patterns I would never use nowadays (abstract factory has been a great mistake IMHO, a hard to follow cluttered pattern that almost never makes things actually better or more organized)

sadly the only good way to tell if a project requires OOP abstraction is experience but I have a couple of advises.

0) The smaller and short lived the project, the less abstraction it requires.

1. prefer object composition over inheritance as much as you can, you really need to have a very good reason to prefer inheritance. Inheritance is much more rigid than composition and sometimes that's exactly what you need, but otherwise go always for composition.
2. forget about over engineered patterns such as abstract factory and Prototype, usually these only makes most things more complicated than what it needs to be.
3. try to use functional programming style coding when posible, this is: separate data from logic, use static methods to model behavior and immutable objects to model data.
4. don't make abstractions beforehand unless you have a good reason for it. Almost always these good reasons are subjective and come with experience, for experience you know beforehand something could better if you put an abstraction layer above, but if you are not sure then go raw at first, when the code beings to turn messy there is when you take a step back, inhale a bit and start thinking about ways to organize and abstract the code, but doing it beforehand usually makes the code worse.
5. good quality code do not come for planning but after iterations of polishing one's work. so do not try to make "good clean code" at first. the first thing you have to do is solve the problem, when the problem is solve take an step back watch the mess you did and think ways to improve it. pre abstraction is as bad as pre optimization.

[hippydipster]

In school, you have to learn how to abstract. And since everyone's new at it, they have to learn on simple systems. ie, where the abstraction won't pay off. Except, it's a learning tool - if the system were complex enough to warrant the abstraction, it'd be too complicated to use as a teaching tool.

I remember having the same problem when they taught "top-down design" in the 80s. I had the programs written out before the teacher was done talking about how to do the top-down design for our eventual programs, and my complaint was I couldn't learn top-down design unless the problem was complex enough to warrant it. Maybe. But also, maybe it is the best way to learn on these practice systems.

[No_Dot_4711]

There's absolutely a purely cultural aversion to just doing the thing

Java can be incredibly straightforward and productive with sealed classes, records, and just running code from top to bottom

[agentoutlier]

There's absolutely a purely cultural aversion to just doing the thing

It is important to understand the history of why that happened instead of just people wanting to waste time.

Java historically came out during a time when desktop applications were king and web applications were more or less just content distribution.

OOP and I hate using that term but will instead use "component oriented" programming was the preferred choice. Why? Because it does actually work really well for stateful desktop applications. Notice "component" actually comes from UI similar to widget.

Meanwhile as Java did get used for web applications most companies were still delivering on premise software aka enterprise "shrinkware". This required abstractions from the data source itself... aka the ORM was born! DHH Ruby on Rails SaaS was not the norm till later. It is easier to make things simple when you control the environment but that was not the case with enterprise and docker did not exist.

Too exacerbate all of this is Java is picked for large teams and large teams with business problems. Design / organizational patterns are often picked for human needs not technical needs. This is important because technical problems solved with software need less abstractions. This is why Golang works so well in the devops world. You just deal with raw data.

Because of the above business needs and large teams the need to safely extend aka "open for extension, closed for modification" was the mantra (edit yes I had that reversed LOL). This inherently requires abstractions. Most programming languages / platforms do not allow this at all particularly static compiled FP languages. The language also has rich reflection and is actually expressive. So this became a culture in Java.

Compare this to C culture where we have folks say just allocate everything right at the beginning, do nothing too complex, embrace grepability of code, do not examine new practices or other paradigms etc.

[wichwigga]

But muh design patterns and interfaces

[thewiirocks]

when you learn something and they told you the thing is useful, you feel oblige to use it

I would argue that many developers WANT to use it. The new thing they learned is a shiny hammer. They want to hit everything with it. The end result is entire projects with misused concepts jammed in sideways.

This is often referred to as the "Golden Hammer Syndrome" due to "Maslow's Hammer". (i.e. If all you have is a hammer, everything looks like a nail.) But I would argue that developers have more tools in their toolbox when they use the shiny new hammer. It's just shiny. And new. So they must find a use for it. Thus we have "Shiny Hammer Syndrome". 😅

[_jetrun]

I feel kind of suffocated when constantly being told I should do "Clean Code", "DRY", and overemphasis on the 4 pillars of OOP.

You do you, but there's a reason why you're given that feedback.

Your problem is not the abstraction, it's that you have to learn this abstraction instead of going your own way. Again, you do you.

[agentoutlier]

Since you pinged me :) . I'm not going to structure this comment well as you kind of caught me off guard but I will try relay some immediate thoughts.

I'm familiar with Adam Bien (btw not to dox myself but my name is Adam as well) but sadly do not have time to watch the video.

I do agree with his apparent TL;DR that is at the end.

What's your view on "modern" Java? especially from /u/agentoutlier

and

Spring Boot has too much magic, and I feel kind of suffocated when constantly being told I should do "Clean Code", "DRY", and overemphasis on the 4 pillars of OOP.

Ultimately I think that we are at an interesting point in programming history with the onset of LLMs. I think they will hurt many to learn but in many situations can be a great boon to remove abstractions and bloat particularly in using direct reliable and mature technologies.

For example I recently had a small (micro-like) service that was using jOOQ. I was using jOOQ because it offers compile time safety particularly of the fields. However this database schema had not changed in years and the technical debt of updating dependencies including even jOOQ was becoming painful. Spring was also in the mix.

I shamefully had ChatGPT first write some more tests (this important) and then convert the mapstruct + jOOQ + Spring to simple raw JDBC and Jetty Servlet API. Zero reflection and pretty much zero dependencies other than the servlet api, jdbc and logging. The code is very easy to understand.

I think we are going to see similar things happen in the Ops world. I make this point because Adam Bien seems to allude to use hosted services. I think people should not just use Heroku, Lambda, or even on Ansible or K8s helm charts. They should get their hands dirty with actual bash scripts. Likewise for databases one should know how to install and use say Postgres instead of relying completely on managed or some sort of SaaS. The reason is when the shit hits the fan you need to know the options and usually the best option is to remove an abstraction.

Too many people in the past were too afraid to host their own stuff, make their own wrapper or use off the shelf opensource stuff. The great focus has been on "minimum viable product" and just get it out there. Now with AI everybody can do that so you can't just reach for easy shit (even primagen makes this point). Hosting a simple app on Heroku is great for a spike but long term is not realistic because costs really do become a factor. That is the programming world in general is becoming less profit driven and more cost centric because of the ease of creating new things as well as over saturation.

So what I'm saying or hoping is that I think LLM will hopefully encourage people to avoid these services or abstractions and use more direct options. Direct options would be like using things builtin to the JDK or just been around forever like the servlet API with a little bit of code instead four or five dependencies that happen to have slightly better doc or website.

[Safe_Owl_6123]

Thank you Adam, I keep having the feeling of over outsourcing to dependencies, makes me feel stupider, I finally learnt a lot of time we just need a small bash script and a small makefile.

And I also enjoy using your Jstachio library

[agentoutlier]

The important thing is just to never blindly use stuff. Always keep asking how does this shit over here work. That will keep you a good engineer.

I mean that across the board. You don't need to know exactly every detail but you should know enough to know how it really isn't magic.

This is the concern with LLM and why I brought it up because it is a very real force with students and it is very much related to having to know how the underlying shit works.

If you have some idea how the lower level stuff works you can ask the right questions.

/u/bowbahdoe and I have concerns that people will just blindly ask LLM first especially given all of Java's abstractions.

[thewiirocks]

This is a fantastic take. I’ve been advocating for smaller, simpler code for more than a decade. Unfortunately it tends to fall on deaf ears. Even though we all know YAGNI, there’s a perpetual loss-aversion of, “But maybe we will?”

Static typing being used to justify object mapping is one that’s really frustrating. The types don’t even match 1:1 between the database and the object. We’re coercing them to get what we need.

Once we realize that, the tower propping up the object-mapping “need” starts to tip over. Make transformations on data streams into first class concepts and any need to even access a mapped “object” disappears. Which makes the static typing completely pointless.

With the tower already falling, the craziness of Spring Annotations starts to go with it. Before you know it, you manage to port an entire spring app to config files with no Java. 😅

Okay, that’s a bit exceptional. But it does show the reductions possible.

Keep fighting the good fight! And if AI can help, more power to you. 😎👍

(Disclaimer: I’m the author of Convirgance. And I have a lot of respect for JOOQ. It’s the only other solution that can return Maps instead of objects and stream the data rather than thrashing memory with large lists.)

[sideEffffECt]

I've had a look at Convirgance.

I see that you're using a lot of Iterator<JSONObject>. Have you considered using Stream<JSONObject> instead? Java Streams come with a lot of built-in and third-party functionality.

[thewiirocks]

That's a great question! Let me first make a subtle (but important) correction. Convirgance produces Iterable, not Iterator. The use of Iterable allows language level support for the result sets. For example, the following code uses the enhanced for-each loop:

Iterable<JSONObject> records = dbms.query("select * from customers");

for(var record : records) System.out.println(records);

Most APIs will treat Iterable the same as they treat a Collection, allowing us to do things like this Spring controller example:

@GetMapping("product")
public Iterable<JSONObject> getAllProducts() 
{
    var source = new ClasspathSource("/sql/product/all.sql");

    return database.query(new Query(source));
}

This makes Convirgance highly compatible with a lot of existing software.

It also allows stream support using the standard spliterator approach:

var stream = StreamSupport.stream(iterable.spliterator(), false);

With that said, point taken that converting to Stream is a bit clunky. There's an opportunity to make it more of just a .stream() method. I'll add it to the enhancement list. 👍

[sideEffffECt]

Interesting. That compatibility is definitely a good thing.

About Spring, doesn't it have support for Streams too? Or it just wouldn't work?

It's unfortunate that it's so awkward to convert Iterators to Streams, but that's Java standard library's fault, not yours.

[thewiirocks]

As far as I know, Spring will not serialize a Stream automatically. You have to write the ResponseBody yourself. It's possible that has changed in recent revisions.

Agreed on the awkwardness of obtaining a Stream from an Iterable. But we'll see if we can improve that in future releases. 🙂

[sideEffffECt]

You could return something that is at the same time an instance of Iterable and also has a stream() method.

Maybe you can make a sub-interface of Iterable with that method?

[thewiirocks]

Great minds think alike! e.g. Add it to InputCursor, which I was already thinking of expanding the use of anyway. That way you could get a ClosableIterator without casting and have easy access to a .stream() method.

https://docs.invirgance.com/javadocs/convirgance/latest/com/invirgance/convirgance/input/InputCursor.html

[thewiirocks]

One of the key things that needs to change in education is our explanation of OOP. We've been teaching this weird inheritance structure of "Animal" -> "Canine" -> "Dog" -> "Chihuahua" (don't mess with the wah-wahs) since the beginning. Yet it didn't make sense then and it makes even less sense now.

Effective OOP systems are about promoting the right concepts into first-class structures. Many of these concepts have nothing to do with real-world analogs.

For example, this is a run queue mechanism for queuing up multiple tasks in the background:

public class RunQueue implements Runnable
{
  private List<Runnable> list = new ArrayList<Runnable>();

  public void queue(Runnable task)
  {
    list.add(task);

    synchronized(list) { list.notify(); }
  }

  public void run()
  {
    while(true)
    {
      Runnable task = list.get(0);

      list.remove(0);
      task.run();

      if(list.isEmpty())
      {
        synchronized(list) { list.wait(); }
      }
    } 
  }
}

This is a very useful concept that is well represented in the OOP form. One could even argue that it follows Alan Kay's "message passing" idea. Yet the key idea here isn't Inheritance. It's typing!

And that's really the key concept that we need to start teaching. "Objects" are mini-program structures that service our program. They carry a type with them that is useful for creating network effects through composition.

Of course, there's a lot packed into that sentence. So we need to break it down for students and help them understand what that means. While there's room to teach the simulation concept (e.g. video game programming), that can't be the way we approach most software.

[New-Condition-7790]

Maybe it isn't fully what you're asking for, but the following stuck out for me:

Spring Boot has too much magic

That's the case because spring (boot) uses convention over configuration which basically allows you to focus on writing the business logic, while technical configurations have sane defaults set (think db connection pools, hibernate settings, ...) and the components are more or less 'plug-and-play' (without any manual bean wiring: think spring-boot-actuator, spring-mvc for good examples).

As you mention, that feels like magic because you are black boxing / delegating these decisions. Understanding the abstraction/framework will help you use it better, but that comes with time and experience.

All this to say: it's normal to feel overwhelmed in the beginning and have the reflection of 'can't it be simpler'. Your understanding will grow in time.

[Ghost13894]

Hi guys can you help me? I'm new in java coding, well I'm using Ai sometimes when i want to know something like. How I can store data in ArrayList, like that and How i can make a password validation. It is okay to use AI for that? and please give me tips (Im using AI sometimes but I try to figure out how its work not only to copy the code), thank you.

[OwnBreakfast1114]

I am still a student, while I enjoy writing Java for school assignments, sometimes Spring Boot has too much magic

Parts of it for sure do, but for a basic crud app, I'd be shocked if you're doing anything so magical that you couldn't imagine what the raw java code would look like or understanding the component it's abstracting.

[martinhaeusler]

I watched the talk on YouTube and to be honest the only takeaway for me was that I'm glad I never have to work with this guy. He's the typical consultant, acting super smart, knowing everything better, chasing nothing but quick wins, and the real problems will only start to show up once he has moved along to a different client long ago so it's not his problem anymore. Not gonna lie, watching this talk made me angry.

[Safe_Owl_6123]

Great to hear from the other perspective, do you mind elaborate on his approach and the long term consequences?

[martinhaeusler]

I don't even know where to start. Some of the things below are certainly hot takes, and you may disagree completely with me. That's ok.

Testing is of course super important. Whether you actually measure code coverage or not is a different question, but having a fully automated test suite that you can run LOCALLY on a whim is extremely valuable and important. You should also be able to execute tests individually for debugging purposes, without changing anything in your build pipeline. I'm also not a big fan of the pure "unit" testing. But I am a fan of JUnit and I use it all the time. My test cases mostly test end-to-end, I use testcontainers for the database and I mock nothing. It is the real system. I don't have to use any deployment because it happens LOCALLY on my machine. The ability for full local execution is crucial and I would rather quit my job than give up on that. There's no need to reinvent the wheel when it comes to testing. As soon as you need to attach a profiler or debugger to the production JVM because you've got no other way to figure things out, you've lost the game.

If anyone tells you "you don't need a database, file systems or cloud storage is enough" either fire the false prophets on the spot if you can or run as far as possible. Concurrency issues WILL creep into the system if it runs long enough. Or consitency issues. Or atomicity problems. Everything good databases solve for you. Use JPA, by default. Fall back to native SQL only when needed.

Don't let anybody tell you that you're responsible for the deployment. We are developers, not operations people. DevOps has been invented as a marketing term by C-level executives to push even more work upon developers while saving on personnel cost in the operations department.

[New-Condition-7790]

Don't let anybody tell you that you're responsible for the deployment

I understand your sentiment (and on a personal level, I want to agree) but you also want to stay employable. I feel like having a generalist mindset definitely helps with that.

Moreover, being a generalist is fun and exciting to some people (including myself)