Where have you put your Curly Braces.

Most holy wars are fought over the placement of the curlies '{}', and in some cases other brackets [] or parenthesis () and <> too. In particular: Put them at the beginning of the line or at the end. The Java Style Guide is quite clear about that: Braces.

My personal motivation would be: If your understand that C and Java are block oriented languages, then you immediately will understand that placing a brace at the beginning of a line can only mean that you start a new block. This allows you to define a local scope. This is what you already know from for loops. Well the loop need not be there to allow yourselves to have some very local variables, like in the example below.

If you understand this block aspect of the K&R style, you know that you do not have to search for the name of a method, a class start or anything else. The block is just a block with local scope. It helps readability, because you can define your local variables at the place your need them and confine them there, without having the locals interfere with anything else in the method or class.

        {
            int i=0;
            // do something with i
        }

This often overlooked feature can help big time to help improve the readability of your code, in particular when the method is getting big. But since having big methods is a bit of a no go area in a modern programming style.[1], your rarely see it in practice.

In Java there is also another reason. You can have blocks at the class level, which allow you to define some kind of anonymous constructor. Remember Anonymous Inner Classes? Well, sometimes you want to have a constructor, just to initialise things. Here is an examples from the Java FX binding chapter.

    public static void main( String[] args ) {

        final DoubleProperty a = new SimpleDoubleProperty( 1 );
        final DoubleProperty b = new SimpleDoubleProperty( 2 );
        final DoubleProperty c = new SimpleDoubleProperty( 3 );
        final DoubleProperty d = new SimpleDoubleProperty( 4 );

        DoubleBinding db = new DoubleBinding() {

            { 1
                super.bind( a, b, c, d );
            } 2

            @Override
            protected double computeValue() {
                return ( a.get() * b.get() ) + ( c.get() * d.get() );
            }
        };

        System.out.println( db.get() );
        b.set( 3 );
        System.err.println( db.get() );
    }

Javadoc style

See Javadoc style guide and How to write doc comments.

Not only does Java code have a proper style, the same applies to java-doc.

You can skip on documentation if * The member is not public or protected * For methods: it overwrites a method in a (documented) interface or super class.

Javadoc starts with /** and ends with */

 * <p>A {@code String} represents a string in the UTF-16 format
 * in which <em>supplementary characters</em> are represented by <em>surrogate
 * pairs</em> (see the section <a href="Character.html#unicode">Unicode
 * Character Representations</a> in the {@code Character} class for
 * more information).
 * Index values refer to {@code char} code units, so a supplementary
 * character uses two positions in a {@code String}.
 * <p>The {@code String} class provides methods for dealing with
 * Unicode code points (i.e., characters), in addition to those for
 * dealing with Unicode code units (i.e., {@code char} values).
 *
 * @author  Lee Boynton
 * @author  Arthur van Hoff
 * @author  Martin Buchholz
 * @author  Ulf Zibis
 * @see     java.lang.Object#toString()
 * @see     java.lang.StringBuffer
 * @see     java.lang.StringBuilder
 * @see     java.nio.charset.Charset
 * @since   JDK1.0

/**
 * Friendly and well known program.
 *
 * @author John Doe
 * @author Jane Doe
 */
 public class HelloWorld {
   public static void main(String... args){
     /// wot goes here should be obvious.
   }

 }

Maven Repositories

A maven repository is a server that provides ready built maven 'artifacts', such as (binary) jar files containing libraries, frameworks or APIs and in many (but not all) companion jar files containing the javadoc (often) and sources of the same binary. A maven repository is NOT a source code management system (CMS),[3] although it typically holds several versions of a binary, and there are tools, such as Nexus Repository Manager.

There is a default repository, called maven central. You (as a team or company) can have your own repository.

If you look at a maven repository you will see that it is organized along the three axes: groupId, artifactId and version. We have published our Fontys Venlo informatics pom under groupId io.github.fontysvenlo, artifactId informaticspom and current (February 2024) 1.2.

Maven on Steroids or: use it properly

Sometimes you think, maven is not your thing because it is slowing you down, certainly if you are trying to work your way through your code TDD style: Write test, run test red, implement code, run test green, be happy.

But reconsider: Maven takes it’s job very serious, but since it is a computer program it is stubbornly stupid, so it might be that you are using it in the wrong way.

Let me explain what maven does:

Packaging (which is what you do when you click build in the IDE) the application and
is only useful when your are really done: all tests are complete and the code turns them a nice green.

So if you are in the habit of clicking build and then run your tests, you might want to change your habit.

Maven Modules

Many projects will have more than just one component (jar or war file). Think of the parallel project project 2.

It is a good idea to reflect this design in the way you structure your source code: use multiple modules.

Module

A Maven module is just a maven project, that has a pom.xml which defines the relation with other modules.

As you see in the figure, the parent lists its children. The children may have inter-dependencies. Otherwise it is just plain maven.

    <<parent>
      <groupId>io.github.fontysvenlo</groupId>
      <artifactId>informaticspom</artifactId>
      <version>1.2</version>
      <relativePath/>
    </parent>
    groupId>nl.fontys.sebivenlo</groupId>
    <artifactId>parentpom</artifactId>
    <version>1.0</version>
    <packaging>pom</packaging>
    <properties>
      <version>1.0</version>
    </properties>
    <modules>
        <module>entities</module>
        <module>db</module>
        <module>app-logic</module>
        <module>ui</module>
        <module>restserver</module>
    </modules>

As is usual between parents and children, there is an inheritance relationship. The children inherit setting and groupid, and version, if defined as a property. Note that thare is a a "grand"parent here too, the informaticspom, so you can apply all the good things you learned in PRC2 to your project as well.

Warning:

Do not declare dependencies of the children in the parent pom, because that introduces a cycle in the dependencies: parent depends on child, which depends on parent, which depend …​. etc.

The parent pom can declare all external dependencies, that are shared between the children, such as the testing frameworks, any other external dependencies. The parent can declare its own parent, allowing it to inherit and pass on anything that inherits from such parent.

Putting things in modules has the following advantages:

• It promotes loose coupling.
• It can avoid the chicken and egg problem: In a normal build, it wants all tests to pass, to be able to continue. For business code that is correct, but things like integration tests need a built war file, which cannot be built with failing tests.
  Solution: Put the integration tests in a separate module of its own, which can be run at any time and will not slow you down or worse, disable testing or not having any tests.

Concepts used

The whole operation involves three modifications:

Setting in startup script

## DEFAULT IS JAVA 21 HERE
export JAVA_HOME=/usr/lib/jvm/jdk-21.0.1+12
export PATH=${JAVA_HOME}/bin:$PATH

Switching to other Java version

#!/bin/bash

## This script assumes that the JAVA_HOME environment variable is set
##   and that the PATH contains ${JAVA_HOME}/bin
## The java variant that is to be put in JAVA_HOME and PATH is determined
##   by how what this script is called.
## J8 for Java 8, J11 for Java 11 and J12 for Java 12. It could easily be
##   extended to include Java 9 and 10 too, buy at the time of writing I see
##   little point because 12 is the current open JDK and 11 the LTS version.
##   J8 is in because it is the default for many still.
##
## You typically have (sym) links pointing to this script, so it appears
##   to have different names, changing its meaning.
##
## Usage: eval $(scriptname) e.g. eval $(J12)
## By using  bash aliases, such as alias j8='eval $(J8)' the use of
##   this script will become a feast.


## get this script name
thisname=$(basename $0)
## get the current path setting
OPATH=${PATH}

## Let my name do the choosing
case ${thisname} in
    J8)
	NJAVA_HOME=/usr/lib/jvm/java-8-oracle;;
    J11)
	NJAVA_HOME=/usr/lib/jvm/jdk-11.0.2;;
    J17)
	NJAVA_HOME=/usr/lib/jvm/jdk-17.0.5+8;;
    J21)
	NJAVA_HOME=/usr/lib/jvm/jdk-21.0.2+13;;
    *)
	echo call me as 'eval $(J8)', 'eval $(J11)' or 'eval $(J12)'
	exit 1
	;;
esac

## edit path to use the new java_home
p=$(echo ${OPATH} | sed -e "s@${JAVA_HOME}/bin@${NJAVA_HOME}/bin@")

##
echo export JAVA_HOME=${NJAVA_HOME}
echo export PATH=${p}

All made simple with aliases

You can tie this all together with some aliases which classically are stored in a file called ${HOME}/.bash_aliases and are loaded on login and each time you open a terminal.

alias j8='eval $(J8)'
alias j12='eval $(J17)'
alias j11='eval $(J11)'
alias j21='eval $(J21)'

As you will notice, switching Java versions in this way is very fast.