Simple problems, simple solutions, great joy

  • Post category:JavaUI

I’ve been coding for many, many years. I started when I was 13, and that is decades ago. Software development was different back then; programs ran on a single PC, claiming it completely, with text based interfaces (windows were drawn with characters), and maybe, just maybe, there was a shared storage, because some PC had it’s drive shared.

It was also the time when there were not many existing software systems. You had WordPerfect (no WYSIWYG), I remember some kind of simple spreadsheet, and basic bookkeeping software. But that was about it. The world, and all the potential software had, was wide open.

So in the years that followed I wrote many systems. Small ones, to solve small but real problems; an address register for myself, a CRM tool for the local gym, a similar one for the dance school. What a time! It was not much work, especially after MSAcesss was introduced, you got a lot of functionality for the amount of effort you had put in.

(more…)

Continue ReadingSimple problems, simple solutions, great joy

Records instead of named parameters

  • Post category:Java

Actually there is an existing agreement that renaming of method parameters is without consequence. Specific transforms are called out in JLS as binary compatible.

Brian Goetz

I had already mentioned my concern about the strong coupling that named parameters introduce in the first revisited post. Even though the coupling is just a strong as when a custom class is used as a parameter, developers simply do not expected this coupling on named parameters. But the fact that the specification defines that renaming parameters names are to be without consequence, makes named parameters a dead end.

And also because something else has changed since 2013… IDE’s:

And that makes the price to pay for adding named parameters not worth it.

That said, it still was fun to let the idea run through one’s head. And likewise it also is fun to see if there is a way to make this work without renaming parameters… What about using the recently added record classes? Consider this a little creative piece of code (aka it will not compile):

public Rectangle(record Parameters(int width, int height) p) {
    this(p.width(), p.height();
}

new Rectangle(new Parameters(100, 200));
(more…)

Continue ReadingRecords instead of named parameters

Java named parameters re-revisited

  • Post category:Java

Ah! Mr Goetz has kindly reacted on Twitter to the previous blog post, and lifted a piece of the curtain.

You’re mostly focusing on a non-problem; reordering can be done statically without any runtime performance cost (or semi-statically, if linkage is done with Indy.). That’s not any of the issues.

Developer blindness; focusing on part of one problem and not seeing the rest. Yes. I’m very good at developer blindness, that is why I always ask: “Did I miss anything?”. But that reordering can be done totally statically amazes me. As far as I know going from B-A (order of evaluation) to A-B (order of parameters) takes at least some CPU power. But hey, at no performance cost is good news.

But, spend some time thinking about overload selection and binary compatibility, and when that voice in your head says “we can just disallow that” when you get to the hard bits, recognize that is the siren singing to you.

Overload selection. Of course! The minute you start reordering arguments there may be multiple methods that may fit. For which one are you reordering? Consider the following two overloaded methods.

void go(int a, String b, double c);
void go(String b, int a, double c);

Now, if one would write:

go(c=1.0, b="foo", a=2);

Then this call could match any of the two methods, and the compiler would not know for which to reorder the arguments.

(more…)

Continue ReadingJava named parameters re-revisited

Java named parameters revisited

  • Post category:Java

TL;DR named parameters seems to be possible with only a few additional in-memory copies and a bit of stack pointer manipulation. But what will it mean for debugging?

Okay, let me give this another go. In my previous post about named parameters from 2013 I think I made clear why named parameters are a good idea from the perspective of readability. And readability is the second most important aspect of source code, the first being that it should work of course. However I have not been able to convince mr Goetz to add it to Java. And I really tried a few times, ranging from online to face-to-face discussion. His argumentation every time is that it is way more complex than it seems, but unfortunately he never got around to explaining this.

Once you start with named parameters, they have a tendency to attract more and more functionality, so let’s break down what is possible in increasing complexity:

  1. Documentation; the fact that for each argument you can put the name of the associated parameter in the calling statement instead of in a comment (see the 2013 post), makes the call more readable.
  2. Validation; by naming the arguments in the calling statement, the compiler can check if they match the called method’s parameters. It can validate if the intention of the coder matches what is happening.
  3. Ordering; if the order of the names in the call deviate from the method’s signature, the compiler could reorder the arguments to match.
  4. Defaults; when named arguments can be matched to their parameter counterparts, any omissions can be filled with defaults.
void rectangle(int height = 0, int width = 0) { // these parameters have defaults
     // ...
}

void use() {
    rectangle(100, 200); // only from the call it is not obvious what this really defines
    rectangle(height=100, width=200); // better readable, and the compiler can validate
    rectangle(width=200, height=100); // the compiler could fail on this, or reorder based on the signature
    rectangle(width=200); // since all arguments are named, the compiler can infer the value for missing ones
}
(more…)

Continue ReadingJava named parameters revisited

A case for a sealed jar-of-jars

  • Post category:Java

Since last week everyone in the Java developer community has been stumbling over themselves because of the Log4j vulnerability. Once word got out, the log4j maintainers quickly released a fix. So if you were fairly up to date, all you had to do was upgrade a dependency and redeploy. (My project was still using log4j 1.x, so it took just a tad more effort, but that is on me.) Unless you were of course one of the people who were actually using the functionality used by the exploit, but I wager chances are small that is the case.

What I have been pondering about is if the root cause of the vulnerability is in essence really a log4j issue. Yes, log4j made it easily accessible, but the core of the issue is the fact that the JRE is completely based on dynamically loading executable code. It does so via the JNDI method which is used in the log4j vulnerability, but also simply because classes are always loaded from the file system for all Java applications. Basically moving all security constraints onto the system it runs on.

(more…)

Continue ReadingA case for a sealed jar-of-jars

I need help

One of the defining qualities of a good developer, in my opinion, is to know when to ask for help. And I’ve been battling this issue for way to longer than I should have. But since this is a solo open source project, it is a bit of special circumstance, normally I would have asked a colleague to have a look with me ages ago. Anyhow, if any Java developer with a Tesla wants to help out, that would be highly appreciated!

2021-10-04: it turns out Tesla has added a Google recaptcha to the login procedure, which is loaded with a delay, making it impossible to monitor on the web. This missing recaptcha probably is what is triggering the HTTP 500.

(more…)

Continue ReadingI need help

Naming Docker container images

  • Post category:dockerJava

This is something I’ve needed to get off my chest; I really and truly don’t understand the logic behind the scheme of Docker container image names. The first time I tried to grasp it, I got mentally stuck, because it feels to me it blatant ignores any convention. At the moment it is a matter of accepting that this it how it works, but my neurotic side keeps protesting every time I tag an image. Let me explain the beef I have, and then maybe someone can enlighten me.

(N.B. I’m using “docker” in this post, but I actually am using “podman”. But their APIs are identical, so because docker is better known, I’m typing “docker” in this post.)

When you create a new image using the “docker build” command, the newly created image is uniquely identified by a hash, something in the line of 21df6af2a82e0135661ce18a621112450992914e1fcfc0edb285c332318e3e23. This id is totally impossible to convey to other people, so Docker has the possibility to add tags to images. A typical build command looks like

$ docker build --tag my-tag .

This is will use the Dockerfile (Containerfile for podman) to generate an image and add it to the local registry. You can see this by executing a list command:

$ docker images

REPOSITORY        TAG             IMAGE ID      CREATED         SIZE
localhost/my-tag  latest          99bd5445f871  22 minutes ago  280 MB

Wait! What? What is the localhost doing there? And latest?

(more…)

Continue ReadingNaming Docker container images

The default verb

  • Post category:JavaOOP

Naming things in coding is always something of great debate, and important to give appropriate consideration, because it greatly influences readability. And readability -as we all know- is the second most important aspect of source code, the most important one being that it should work of course 🙂

There are competing naming styles; camelcase starting with or without a capital, underscores, all caps, etc. But I do not want to get into that, to each his own. Or her own. Personally I prefer the Java style, with the difference in naming between classes (CamelCase) and methods (camelCase), so I’m going to use that for the examples here.

What I would like to talk about is the concept of a “default verb”. As a rule of thumb class names are nouns; they’re a Factory, or a Singleton, or Person. And methods perform actions on classes, so their name should start with a verb; getName, createInstance, build, walk, …, they do something.

(more…)

Continue ReadingThe default verb

The YAML threshold

  • Post category:JavaXMLYAML

I’m not using YAML a lot. If I need an easy-to-read configuration file, I’m using TECL, but usually XML serves me fine. It is a one-stop-shop for a lot of stuff; anything not code usually can be done nicely with XML. And its verbosity is not really a problem with the current bandwidths, unless you need to send a lot of data. And it is easy enough to read for a human.

(more…)

Continue ReadingThe YAML threshold

Time travel 101

  • Post category:icalJava

Suppose you take 2:30 AM at some random day in the year, and add 366 times one day to it, when do you end up? Yes… 367 times if it’s a leap year, wise guys. But still, when do you end up?

Calendar cal = new GregorianCalendar(2020, 11-1, 1, 2, 30);
cal.setTimeZone(TimeZone.getTimeZone("Europe/Rome"));
ZonedDateTime zdt = ZonedDateTime.of(2020, 11, 1, 2, 30, 00, 00, ZoneId.of("Europe/Rome"));
for (int i = 0; i < 366; i++) {
	System.out.println(cal.toInstant() + "   " + zdt);
			
	cal.add(Calendar.DATE, 1);
	zdt = zdt.plusDays(1);
}

Take a guess before reading on!

(more…)

Continue ReadingTime travel 101