Java

During maintenance of the legacy projects, I sometimes see constructions like: void appendFooter(Report report); or void populate(Data data); I even saw something like this: void populate(Source source, Target target); What is wrong with these statements? They’re using so called output argument. In the examples above, we’re passing a report or data variable, which usually are going to be global variables available in the scope of the whole class. These methods takes them as an argument and modify them. This idea comes from pre-OOP times and could be applied in programs written in C. Nevertheless, in Java, this technique should be avoided and is considered as a bad practice. ...

During development of the legacy Java applications, we still have to deal with null. It’s possible to avoid it completly when we’re designing application from the scratch, applying proper code constructions, static code analysis and we’re consistent during code reviews. Nevertheless in majority of the cases we will encounter null in daily projects. We may even expect them in the method inputs and we have to be prepared for it. With the functional programming in Java we can deal with them in quite elegant way, but I often see people are not using features available nowadays. ...

In my previous article I published information about publishing JAR/AAR library to the Maven Central Repository. A few steps of that process were automated, but a few of them were still manual. I mean closing and release process which had to be done by manual clicking on the Sonatype website. Fortunately, it’s possible to automate it. In order to do that, I used gradle-nexus-staging-plugin developed by Codearte. Thanks to this plugin I could get rid of the remaining manual steps left in the release process. ...

Introduction As a Java/JVM/Android developers we rely on the work of other people through frameworks and libraries. Many of them are open-source. Most of the developers are consumers of such projects. What if we would like to create our own library and distribute it to other developers? We can always create it and share a *.jar or *.aar file with others. Drawback of such solution is the fact that source of distribution may not be trusted. We also have problems with versioning. Consumers of the library have to constantly download and update their files. It’s much better to publish our library to Maven Central Repository and allow others to easily and seamlessly add it as an external dependency to pom.xml file (in case of Maven) or build.gradle file (in case of Gradle). In such case, dependency is managed by the appropriate build system and distributed via trusted source. This may be not easy for the first time that’s why I decided to collect information related to this topic in a single article. Let’s see how to do this. ...

I recently wrote a new library called NeuroSky Android SDK. It’s used for writing Android apps using signals of the brain waves received from the NeuroSky MindWave Mobile headsets. Probably I’ll write a separate article about it because it’s quite interesting topic. This library uses ThinkGear library, which is distributed by the NeuroSky as a *.jar file, so I couldn’t use it as a Gradle or Maven dependency in my project and I had to put this *.jar file into the lib directory and link it in the build.gradle file. Moreover, I wanted to create a library, which can be added to the project as a single Gradle dependency without messing around with additional *.jar files or custom configuration. Due to this fact, I decided to create a fat *.aar file and deploy it to the Maven Central repository. For those who are not familar with Android, *.aar is an Android version or *.jar file, which can be used as library in the project. I didn’t want to reinvent the wheel, so I searched for the different solutions. Unfortunatey, a few of them didn’t work, but luckilly I’ve found what I wanted. It’s fat AAR Gradle Plugin developed by Mobbeel company. ...