Entity-Relationship Diagrams

I tend to forget what the arrows mean in an entity-relationship diagram.

Example

	@startuml
	' hide the spot
	hide circle
	' avoid problems with angled crows feet
	skinparam linetype ortho
	entity "Guild" as Guild {
	*guildnr : number <<generated>>
	--
	*guildname : text
	description : text
	}
	entity "GuildRank" as GuildRank {
	*ranknr : number <<generated>>
	--
	*guildnr : number <<FK>>
	title : text
	}
	entity "GuildMember" as GuildMember {
	*membernr : number <<generated>>
	--
	guildnr : number <<FK>>
	ranknr : number <<FK>>
	personnr : number <<FK>>
	premissions : text
	}
	entity "Person" as Person {
	*personnr : number <<generated>>
	--
	name : text
	}
	Guild ||..o{ GuildRank
	Guild ||..o{ GuildMember
	GuildRank |o..o{ GuildMember
	GuildMember }o..|| Person
	@enduml

view raw plantuml hosted with ❤ by GitHub

In the diagram above, there's strong limitations on the values possible in the GuildMember table. Unfortunately, these cannot be expressed in Foreign Key Relationships.

For example:

• a Person can hold only one rank in a Guild.
• a Person can only be a GuildMember in a Guild once.

The way to fascilitate this, is to put a unique index on GuildMember regarding the columns GUILDNR and PERSONNR.

References

PlantUML - Entity Relationship Diagram

https://plantuml.com/ie-diagram

LucidChart - Wat is een Entity Relationship Diagram?

https://www.lucidchart.com/pages/nl/wat-is-een-entity-relationship-diagram

Renewing LetsEncrypt SSL Certificates automatically

I found a little script (that I changed a little) to accomodate me in automating SSL certificate renewals.

First of all, the script is executed using a crontab, every 73 days. Why every 73 days? Because that is 5 times a year. Any less, and we (just) go past the 90 days validation period¹. (365/4 = 91.25)

	# Example of job definition:
	# .---------------- minute (0 - 59)
	# | .------------- hour (0 - 23)
	# | | .---------- day of month (1 - 31)
	# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
	# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
	# | | | | |
	# * * * * * user-name command to be executed
	0 0 14 03 * /home/jelastic/crontabs/certificate_renew.sh
	0 0 26 05 * /home/jelastic/crontabs/certificate_renew.sh
	0 0 07 08 * /home/jelastic/crontabs/certificate_renew.sh
	0 0 20 10 * /home/jelastic/crontabs/certificate_renew.sh
	0 0 31 12 * /home/jelastic/crontabs/certificate_renew.sh

view raw crontab.txt hosted with ❤ by GitHub

The script that basically delegates everything to either other scripts or is dependent of other scripts:

	#!/bin/bash
	timevar=`date +%Y-%m-%d_%H.%M.%S`
	process_name='java'
	echo "$timevar Renew certificates" >> /home/jelastic/crontabs/log.txt
	certbot renew
	cd /home/jelastic
	echo "$timevar Import new certificates" >> /home/jelastic/crontabs/log.txt
	./letsencrypt_certificate.sh
	cd /home/jelastic/crontabs
	process_id=`ps acx | grep -i $process_name | awk {'print $1'}`
	echo "$timevar Killing process id $process_id" >> /home/jelastic/crontabs/log.txt
	kill -9 $process_id
	echo "$timevar Renew certificates done" >> /home/jelastic/crontabs/log.txt

view raw certificate_renew.sh hosted with ❤ by GitHub

For the script that automatically imports into keystore, see [2].

References

[1] FAQ - Let's Encrypt

https://letsencrypt.org/docs/faq/

[2] LetsEncrypt with Webroot

https://randomthoughtsonjavaprogramming.blogspot.com/2021/11/letsencrypt-with-webroot.html

Why don't record classes follow the Java Bean conventions?

Records are named tuples¹.

Notice that the name of the field accessors does not start with get and, therefore, does not conform to the JavaBeans conventions.

We can declare getter methods if we really want to, and let them refer to the record method, but I'd opt not to if possible. We can do it, for a little while, until frameworks catch up to the new code convention, which will be pretty quick.

As Brian Goetz wrote in an online thread²:

“. . . the language has a responsibility to look forward as well as backward, and balance the needs of existing code with the needs of new code. Taking a bad library naming convention and burning it into the language forever would have been the worse choice.”

Builders

We can create builders for Records, if we like. See [3] for instance, but I'm not a fan of automatic code generation.

FreeMarker

The reason I started on this blog, is because there's a plethora of different frameworks/tools/what-have-you available that all center around the Java Beans conventions.

In most cases, records are not a good fit for these, as those frameworks and tools operate on the notion that these are mutable data classes.

But sometimes, there are definitely simple use cases where it would come in handy.

For example with the use of Freemarker⁴, a templating engine that converts your templates and Java POJOs to nice html pages (or other kinds of pages, there's no limit really).

And these follow the getX() convention.

So, one way would be to create the blasted getter methods in the Record class, but then you're adding boilerplate again, and I feel uncomfortable with that.

Perhaps an idea is to create my own DefaultObjectWrapper⁵.

So, Freemarker will need some changes to support record classes⁶. Something like automatically generating a hashmap of all the methods that have no arguments, yet return something... and preferable do not start with get?

References

[1] Data Classes and Sealed Types for Java - Brian Goetz February 2019

https://openjdk.java.net/projects/amber/design-notes/records-and-sealed-classes

[2] ForumPost - Feedback for records: Accessors name() vs. getName()

https://mail.openjdk.java.net/pipermail/amber-dev/2020-August/006414.html

[3] GitHub - RecordBuilder

https://github.com/Randgalt/record-builder

[4] FreeMarker

https://freemarker.apache.org/

[5] FreeMarker - Object wrappers

https://freemarker.apache.org/docs/pgui_datamodel_objectWrapper.html#pgui_datamodel_defaultObjectWrapper

[6] Apache JIRA - FREEMARKER-183

https://issues.apache.org/jira/browse/FREEMARKER-183

JLS - 8.10. Record Classes

https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#jls-8.10

JavaMagazine - Records Come to Java

https://blogs.oracle.com/javamagazine/post/records-come-to-java

JavaMagazine - Java records: Serialization, marshaling, and bean state validation

https://blogs.oracle.com/javamagazine/post/diving-into-java-records-serialization-marshaling-and-bean-state-validation

Paving the on-ramp

Brian Goetz wrote an interesting article¹ about what Java could do to lessen the big bulk of context needed for first-timers to write a simple Hello-World program in java. The whole "public static void main(String[] args)" conundrum.

I especially like the following quote (out of context) in de article:

“We will never be able to satisfy programmers’ insatiable appetite for typing fewer keystrokes, and we shouldn’t try, because the goal of programming is to write programs that are easy to read and are clearly correct, not programs that were easy to type.”

So I went and tried to see what's the absolute minimum that still compiles in Java. Of course, the "real" main method is hidden in the Main class. And the class below is in the nameless package.

class MyProgram extends Main {
  void main() {
    println("Hello, world.");
  }
}

The hidden "Main" class looks like this, and can be safely ignored (for now) by new programmers:

/**
 * Hello world!
 */
public class Main {

  public void println(Object x) {
    System.out.println(x);
  }

  public static void main(String[] args) {
    new MyProgram().main();
  }
}

Added benefit, you can simply "run" this class, as its parent class has a "public static void main(String[] args)".

Also, the parent class has a "println" method, so we do not need to import System.out.println as well.

Admittedly, this is all a bit "hacky", where we just hide what we don't want beginning programmers to know in another class. But hey, hiding implementation details that are not important to the current "thing", is one of the core principles of Software Design, isn't it?

Updated 2023/04/17

An example in JDK 21

The reference [1] is implemented in JDK 21, using reference [2].

A simple program can now look like this:

void main() {
    System.out.println("Hello, World!");
}

Updated 2024/02/20

References

[1] Paving the on-ramp (Brian Goetz September 2022)

https://openjdk.org/projects/amber/design-notes/on-ramp

[2] JEP 445: Unnamed Classes and Instance Main Methods (Preview)

https://openjdk.org/jeps/445