Brian Hannaway

Yes, you can indeed. I covered this approach in an older post

https://www.briansdevblog.com/2016/07/docker-spring-boot/

As you say, a Spring Boot executable Jar encapsulates the app and Tomcat. However, the Docker image in this post takes things further by encapsulating the app, maven and a Java runtime. This means you can build and run your Boot app and the only thing you need on the target machine is Docker...everything else is wrapped in the Docker image. If you were to build and run the same Boot app outside of Docker you'd need to make sure Maven and a JRE was already installed on the target machine.

No problem Guido, glad you got sorted.

ImplicitLockingTest.testSynchronizedBankAccount() consistently finishes with an account balance of zero. The debit and credit methods on SynchronizedBankAccount are both synchronised and therefore atomic. The same number of credit and debit operations are always called which means that the final balance will always be zero. If you're seeing a non zero final balance are you sure you haven't removed the synchronised keyword from credit or synchronised block from debit?

I can't see any good reasons for invoking System.gc() in your code. If memory isn't being reclaimed by the GC automatically then the code is fundamentally broken.

The example you mentioned about the airline app taking nodes out of the load balancer to run a manually GC, sounds like a hack. If you're having to manually GC once a day then there's clearly a fundamental issue with the app. I'd focus on getting to the root cause rather than building elaborate workarounds.

Great article, Brian. One point that might be worth adding to the list of best practices, is a focus on testing a components API rather than its implementation. I find tests that focus on the behaviour of a class rather than its implementation tend to be less brittle. I often find myself refactoring code without changing its behaviour. In cases like this, unit tests that focus on the API don't need to be refactored as they're not tightly coupled to the implementation.

Excellent article, Lindsay. A lot of ground covered in one article.

ok, I see where you're coming from. So where you have multiple consumers of your message and need a response from only one (or perhaps none at all), then this async model works well. As you say, it depends on the specific use case.

Hey Petr - I'm not sure what the benefit is of pushing a message to a queue from a web endpoint, then blocking to wait on a response. Because your blocking, the async task essentially becomes pseudo-synchronous. In that case, you're no better off than if you made a simple synchronous web call to the downstream service.

Great post Andy. I wasn't aware of random.org or the API they expose. This looks like a really useful service. I worked on a project a few years back that generated a large number of GUIDs in a multi-threaded environment. Generating GUIDs became a real bottleneck for us as the operating systems entropy pool wasn't replenished quickly enough. The random.org API would have been a nice way to off load GUID generation.

Thats right Jamie, I should have mentioned that in the post.

That’s a good point. Lower maintenance overhead as value objects evolve over time.

I get your point that too much magic isn't a good thing, but I don't think that's an issue with Lombok. Most of the boilerplate code Lombok generates is straight forward and could be implemented yourself with ease or generated by the IDE. I'd be concerned if the code generated under the hood was complex and not easily understood, but that's not the case with Lombok. As long as you understand what Lombok is generating for you, I think it's a safe enough bet.

Spring Boot is a whole different conversation, but I agree that there's a lot going on under the hood. Starter POMs and auto configuration are great for getting things up and running quickly, but all that magic can leave you worrying that you don't fully understand what's being wired up in the background. I suppose that's a price you pay for greater productivity.

Hi Gokul - good spot. The Lombok annotataion is @NonNull as you say. @NotNull is part of JSR-380. I'll get that amended.

Thanks Zoltan, good to know. I've never tried loading yaml with @PropertySource as I use .properties for config.

There's a simpler way to read an externalised properties file from your Boot app. I use the @PropertySource annotation along with an env variable like this.

@PropertySource(value = { "file:${APP_PROPERTIES_FOLDER}/config/application.properties"})

"you're putting up a strawman argument that somehow the reduction was too far and produced a different undesirable effect" - no, I certainly wasn't suggesting the reduction was too far. I haven't seen the code, so I wouldn’t know :) I said reducing 10 lines to one wasn't always a good thing. I wasn't saying that in your particular case it was a bad thing.

I agree that reducing the volume of code that has to be written and maintained is a good thing for sure. I find Java 8 a big improvement over Java 7 in that respect. As you say, it doesn’t address areas like equals and hashcode but using Lombok you can help on that front.

Jim, I agree Java can be quite verbose and that reducing unnecessary boilerplate is a positive move. However, I don't think reducing 10 lines down to one line is always a good thing. Readability is mighty important and in my humble opinion should take precedence over the number of lines of code it takes to accomplish a task. Too often readability is sacrificed in the pursuit of the reducing code to the fewest lines possible. Like most things, it's about finding a happy medium.

Thanks Drago, I'll get that amended.