Good Java Fish

If you run your Gradle builds under Java 10 - forget about your environment variables. Anything you set is just ignored. The only cure I found so far is disabling Gradle daemon with export GRADLE_OPTS='-Dorg.gradle.daemon=false'

It's been a few tough years. A new job. A new role. Trying thing I never did before. Doing infrastructure as code. Going reactive. Giving talks at major conferences. Time to take a short break, breath in, breath out and try to summarize the experience. Stay tuned.

I just realized why what I don't like about Spring Framework. Don't get me wrong. I love Spring Framework. I use it daily. In fact, I am a huge fan of it. But there is a constant "something is wrong" buzz in the corner of my mind. And I finally caught it. The name is Obscurity Yes, all the Spring annotation fairy dust magic just works. It is great. It removes boilerplate code. It is supposed to make your code easier to read and maintain. And it does - to a point when it doesn't. A simple example: @Scheduled(fixedDelayString="${execution.delay_ms}") public void scheduledJob(){ // your code goes here } Easy, right? A few lines of code, a configurable property to define a delay between runs, what can be more simple? A few questions: How do you know what threadpool this scheduled job used? How do you to configure the threadpool? How do you test the scheduling part of your code? Ouch, painful!

Goal : To determine the most efficient way to perform high-volume sampling. Set-up : The sampler's goal is to give permission to sample use a given sampling rate; (approximately) each 1000th request should result in actual sampling. There are several samplers: AtomicSampler: uses AtomicInteger to keep track of sampling attempts;  RandomSampler: uses an instance-wide Random instance to determine if a sample should be taken.  RandomSampler2: uses a local Random instance to determine if a sample should be taken, which is initialized each time.  XorShiftSampler: uses a XOR-Shift algorithm to produce psedo-random numbers ( http://www.javamex.com/tutorials/random_numbers/xorshift.shtml )  Before actual measurement each sampler is called 50K times to warm it up and give a hot-spot compiler a chance to compile the samplers' bytecode into a native high-performance code. Then 10 runs are performed, using a variety of scenarios. 10M sampling attempts are performed d...

A while ago I mentioned the possible need of brushing up our multi-threading skills. Having said that, I cannot but share the post I came across a few years ago in the RSDN.ru forum . Disclaimer: I am not the author of the original post, I merely translated it, hoping its content can be useful. Lately, many Java Developer job openings started to include Java concurrency/multi-threading as one of the requirements. As a response, many developers immediately added the corresponding line to their resumes. Being the one who runs interviews, I'd like to dispel some of the misunderstanding that is related to the term. I'd like to split all multi-threading-related projects into 3 levels: the ones that use multi-threading; the ones that are based upon multi-threading and the ones which are multi-threading itself. The first level ("the ones that use") includes projects that are meant to run in the multi-threaded enviroment. E.g., there is BlahBlahFactory class and you ...

Herb Sutter has a great, albeit lengthy article about future of computing .   Five years from now we want to be delivering apps that run well on an isolated device, and then just run faster or better when they are in WiFi range and have dynamic access to many more cores. The makers of our operating systems, runtimes, libraries, programming languages, and tools need to get us to a place where we can create compute-bound applications that run well in isolation on disconnected devices with 1,000-way local parallelism… and when the device is in WiFi range just run faster, handle much larger data sets, and/or light up with additional capabilities. I cannot but agree with him. We already feel the need to think in multi-threaded way even when we design trivial things. And we already cloud-bound - think iCloud, Gmail or any other of dozens of cloud services out there that we use daily. So maybe it is a time to brush up the multi-threading skills and/or get hands-on experience ...

Not all of us like doing pair programming with junior developers. It can be hard to explain some concepts that are obvious to you, your short-term productivity can suffer, they can be too irritating with their stupid questions and so on. However, pair programming is one of the best ways to learn and teach and to spread knowledge among team members. After all, if you have to rely on that junior (or not-so-junior) developer, you want him to be as smart and competent as possible, don't you? Here is a couple of tricks that help me make the process more efficient and less painful for me.

Why? Because Agile methodologies have their boundaries. Let's take a look at the following part of the Agile manifesto: “Responding to change over following a plan”. It sounds nice and very often it works just fine. The reason behind this principle is simple: changing a few lines of code should be simple if the process is right. After all, it is just code and to change it you don't have to move mountains. But sometimes it isn't true. Sometimes changes can be too expensive to allow them. Imagine development of an embedded device. It includes both software and hardware development. Yes, you can write code for the software part in an Agile style. You can change that code, but if you ever need a change in the already designed and produced hardware – you're in trouble. It isn't easy to change hardware. In fact, it can cost you millions in R&D and manufacturing if you haven't done extensive planning before you even started the development. And that fact contradict...

After writing this post about user stories , I found another fine article at Java Code Geeks about processing a backlog. I strongly recommend reading it. It has a very helpful and concrete advice on how to process your project's backlog and create the better user stories. Here's the link: Breaking Down an Agile process Backlog Enjoy!

I've seen a number of Agile adopters who thought that switching from traditional requirements specifications to user stories can make their life easier in some magical way.   - Come on! User stories ARE simple. Write three lines of plain text and off you go!   Yes, sometimes that's a fine way to go - if you have deep understanding of the subject in question, and your vision matches the customer's vision. But this requires having a long and successful history of communication and collaboration with your customer , which a quite rare situation. Your customer should be technical-savvy to understand the decisions you make, or he has to trust your decisions completely. On the other hand, YOU have to have a deep understanding of the customer's business, you have to predict his needs - and that's not easy to do. If you don't have this kind of relationship, you risk hearing from your customer something along the lines: "That's NOT what I wanted!" aft...

In addition to these posts ( Code review vs. static code audits , Code review vs. static code audits-2 ) I would like to recommend a very insightful paper published by SmartBear Software: 11 Best Practices for Peer Code Review . It has a lot of useful information both for beginners and experienced developers. On top of that, it provides statistics that helps you to understand why you have to implement these practices and what benefits they provide. (Nice thing to have if you have to confront your management about implementing new practices!) I don't have much to say: just go and read it, guys and gals. It's totally worth it.

After discussing this post with colleagues, I was pointed to one more reason to not neglect code reviews. The reason is that after a code review there are two people who know how the piece of code is written, not just the original developer, who wrote it. They know how it works. And, more importantly, they know what it was written for, be it fixing a bug, implementing a new feature or just getting rid of a piece of technical debt. The code review makes people share knowledge - not just some technical tricks, but a deep understanding of the project's requirements, architecture and code base. And it is hard to think of anything more important.

Yesterday I watched Mike Rozlog's presentation at Code PaLOUsa about Static Code Audits. I really enjoyed it. He gave a great motivational speech, advocating the use of static code audits, describing their benefits. I don't agree with Mr. Rozlog's attack at peer code reviews, though. He believes them to be inferior in efficacy to static code audits and he makes his point by bringing in statistics you can't fight. I, personally, think you should not compare these things at all. Yes, static code audits can find hidden bugs and code smells, they can check your code style etc. But, in my opinion, a peer code review is not about finding all bugs. It's about developer interaction, it's about exchange of knowledge. A static code audit can point out the bugs in your code but it cannot tell you how to make your code better (except for the most obvious things). It cannot teach you how to use your tools better. It doesn't teach you how to think and plan. It does...

It was one of those simple-but-nasty bugs that make you cry over them for several hours. The perfectly valid project just refused to start. I've got an error ( see the stacktrace below ): "com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! D:\ (The system cannot find the path specified)". I didn't know why on earth JSF wanted to read the configuration from the drive's root instead of using existing, perfectly legitimate configuration file until I started debugging the Mojarra's sources itself. Then it struck me - I put the project in the "D:\!eclipse\projectname" folder (note the exclamation mark!) and Mojarra just couldn't handle the exclamation mark because of the following code in the getAlternativeJarFile method of the com.sun.faces.facelets.util.Classpath :

- And how long do you guys think it will take us to develop this user story? (The little yellow post-it boasted a proud title of "Synchronization of labile subkernel optimizers") - 5 hours. - No, 7! 12! 3! 48! 20! After about 15 minutes of heated discussion the estimate section was filled with a fresh inscription: “16hrs.” The two-week work schedule had 8 similar tasks, and each of the 5 developers was sure that the team would meet the deadline. - All tasks? By October 18? Consider it done. Naturally, two weeks later it turned out that the project was nowhere near the done stage. The code lacked both "lability" and "subkernelness". There were "optimizers", at times even "synchronized", but the general picture was inauspicious – the plan was foiled, the story was not ready, the product could not be released. Other stories did not fare much better. The Product Owner plunged into silent panic, vividly picturing the visit to Big...

My very first encounter with Agile-methodology can be traced back to 1999. Like many others before and after me, I was left with a peculiar, not exactly pleasant aftertaste. Furthermore, this subjective impression pretty much proved to reflect objective reality with its many hidden traps. At that time the relatively tranquil life of our close-knit outsourcing team was disturbed by a delegation from a metallurgical plant. The messengers wanted us to develop specific software, since their in-house solution had almost given up the ghost. When faced with real production volumes, the program buzzed, glitched, went bananas and croaked, which finally pushed the plant management to the realization that their tasks needed a more adequate solution.

When one starts using Javamail library, the inevitable problem will arise. Unit-testing. Testing Javamail -related functionality can be a major pain. You want to test how your messages are created, what contents and headers they have, whom they are addressed to, when they are sent etc., and this is where the problems start. Personally, I don't understand why I have to have a Session initialized and passed as a constructor parameter when I have to create a MimeMessage instance. Why on Earth do I need this Session to be created, especially in test environment? What point does it serve?

The Agile Manifesto states that you have to value individuals and interactions over processes. I'm pretty sure that when a customer repeatedly fails to arrange a meeting to discuss basic things, then using Agile actually ensures faster failure of the project. I am also sure that it is a good thing. The faster you admit that a doomed project is a failure, the less time you spend actually failing. As a result, you'll have more time to do something really good and useful.

Recently I have stumbled upon a "floating" (randomly appearing and disappearing, the nastiest kind) bug in the legacy code of an in-house financial system: a pie chart, drawn by Google Chart API, sometimes disappeared from the report. After a quick investigation I found out that requests URLs to the API were too long. First, I thought about converting request to POST. Thanks to the Good Empire, they added the POST support to their Chart API.

The JSR-303 validation is great. Yes, really. But sometimes it is just too great. Imagine yourself having to do some complex validation on a single data-transfer POJO. Maybe you are collecting the data from a web-form and you need to show an error somewhere, but the default validation rules just don't fit, your to-be-enforced constraints are just too complex to be enforced using default constraints. It can be as simple as having to check for a string to be submitted, if, and only if, a checkbox is selected, but yet it is too complex to achieve using the default rules. Yes, you can define a custom annotation, write a validator, a unit-test for validator, then define a message for the validation error in your Validation.properties file and so on. Do you really have to do all that? If you are going to reuse the code – yes. But if it is really just a one-time shot? Then a simple short-cut can do the trick: just define a method in your POJO class that will do the validation, then an...