Forem: Gerbrand van Dieyen

Back and forth from Scala to Java

Gerbrand van Dieyen — Thu, 07 Nov 2019 10:47:13 +0000

For over two years I've programmed nearly exclusively in Scala on the backend, while using mostly JavaScript and TypeScript on the frontend. Before that I mostly used Java for over 15 years, as well as a few other programming languages
Since a month I use Java, Java 8 even, on an assignment, and I thought I shared my experience.
The reason I use Java again, because the client uses Java and more broadly, I wondered how easy it would be to switch back if needed. After all I claim to be programming-language agnostic

First, going back wasn't as hard as I thought it was, it all came back to me pretty quickly. Of course I'd need to add ; and some more superfluous code, but that's doable.

Lambda's

I use Java 8, which is the first Java version to feature lambda's. I don't think I could bear a language without. I use lambda's heavily, probably more than people who'd never used a programming language.
Scala uses =>, Java uses ->, but that's ok.

Mutable data

Just as in Scala, mutable data-structures can lead to unpredictable behavior. In the Scala world people are by now pretty used to using immutable data-structures.
In the Java world, rather then thinking about how to transform data correctly, people still deliberate about anthropomorphic questions like what responsibilities an object has and how a Employee class relates to an employee in the real world.

Option

Java 8 introduced the Optional class, so there's no excuse for having NullPointerExceptions in your code (well, except when using older code and libraries).
Java 8 Optional has a map method. Annoyingly, it's orElse method of Option returns the actual value type instead of the value wrapped in an Optional, so you can't chain an orElse. I have no idea what the language designers were thinking. Well, as alternative I could use map, but that's a bit less readable:

      Optional<String>  firstName=Optional.of("John");
      Optional<String>  lastName=Optional.empty();
      Optional<String> name = firstName.map(Optional::of).orElse(lastName);

Fortunately, Java 9 introduced or.

Optional and streams

Also, Java's Optional can't be used as Iterable, while Scala's Option can. Allowing to treat Option as a collection of zero or one values helped me better understanding what an Option is and how you could use it beyond the isPresent() method.
Converting an Option to a Stream shouldn't be too hard:

    public static <T> Stream<T> stream(Optional<T> option) {
        return option.map(Stream::of).orElse(Stream.empty());
    }

Which will then allow me to write:

      Optional<String>  firstName=Optional.of("John");
      Optional<String> middleName=Optional.empty();
      Optional<String>  lastName=Optional.of("Doe");

      ...
   private String toName(Optional<String> firstName, Optional<String> middleName, Optional<String> lastName) {
      return Stream.of(
              stream(firstName),
              stream(middleName),
              stream(lastName))
              .flatMap(Function.identity())
              .collect(Collectors.joining(" "));
   }

That doesn't look so concise anymore, but arguably better than nested if else blocks.

Try catch finally and Either

In Java 8, when you use a resource that implements the Closeable interface working, a finally block to close the resource is no longer necessary. That's pretty nice:

    public String readMe() throws IOException {
        try(BufferedReader in = new BufferedReader(new FileReader("some file.txt"))) {
            return in.readLine();
        }
    }

At least when an exception is thrown, the resource is closed. What I greatly miss, is a Try class, Either or something similar so no exception is thrown by the method at all. There are a few libraries that do add something like Either, like functionalj, but of course these are non-standard so a bit harder to introduce at project.

Beyond the limits of imperative OO: annotations, aspects and reflection.

As is pretty common, Spring is also used to extend Java. Spring is based on the principle of aspect- or plugin-oriented programming and heavily relies on bytecode-enhancement and reflection to extend the language Java. In practice this means you use either annotations or config files.
The biggest disadvantage: everything is applied at runtime, e.g., when your application runs.
In Scala, the language itself is flexible enough using pattern matching, implicits, macros and other language constructs.
Scala pattern matching does use reflection in some cases, but most errors are catched compile time rather then runtime. And despite people complaining about implicit, having an error during compilation because you forgot to import an implicit is a lot easier to handle than an error that occurs when running your software because some configuration is wrong, or something fails during reflection.

Spring will give you pretty good errors when having a wrongly applied annotation, and IntelliJ does have good support for Spring. So most of the times you'll get reasonable descriptive warnings or errors for missing beans, wrong spring-configuration, etc, which makes Spring almost feel being part of the language. And it still feels cumbersome, if only because your code is cluttered with annotations.

Lombok, case classes

Scala introduced case classes, which allows you to write value based classes without a lot of boilerplate - or mistakes like accidentally committing a property in equals or hashCode.

Java by default doesn't. I'm very glad someone created Lombok and it seems well accepted.

import lombok.Value;

@Value
public class Employee {
    String firstName;
    String middleName;
    String lastName;
    long employNumber;
}

You can't do everything you could do in Scala, like pattern matching on a case class, and unlike Scala there's still a difference between methods and properties in Java.
But it's a whole lot better then generated equals, toString and get'ter methods.

IDE support for Lombok is very good, so you hardly notice you're using language extensions.

Conclusion

Switching back and forth from Scala to Java is doable, but I certainly wouldn't want to go back indefinitely. The Scala world is still thriving. Java is bearable, but Scala makes programming doable.

Encrypt your disks

Gerbrand van Dieyen — Thu, 20 Dec 2018 15:01:00 +0000

If you have a laptop, you should always encrypt your harddisk. If you have not already done, make this your new year’s resolution - better yet, do it today.

Loosing your laptop sucks, but it sucks a lot more if you have to fear if someone else somehow gets access to all your data. Even if you have a login-password and have all your data in the cloud, you data could still be a at rest in the temporary folder. And a potential thief could access all your ‘saved passwords’.

Microsoft Windows and Apple’s OS X and most Linux distribution like Ubuntu make disk encryption very easy - it’s hopefully the default on any new laptop. If you want to encrypt your disk after installation, I’d refer to the documentation of your operation system: Windows, OS X, search the web or ask a colleague or family-member.

On the operation system I am using, Kubuntu Linux, disk encryption can be chosen during installation and contrary to Linux’ reputation that’s very easy. My laptop has an SSD as main-disk containing the root dir, and an additional disk of 2TB for all other data that doesn’t fit on my SSD. Of course it’s encrypted too.At first, my configuration required me to enter a passphrase twice, once for the SSD and a second time for the additional disk. Bit of a nuisance. Thanks to this wonderful howto, I have a set-up that’s hardly less secury, but easier to use: HOWTO: Automatically Unlock LUKS Encrypted Drives With A Keyfile

The encryption key is stored on my main SSD, so I only have to enter the passphrase for that SSD. After that, the key that’s stored on the SSD is used to decrypt the second disk. As mentioned in the howto, if people get access to your root dir all is lost anyway.

Using Swagger to access your secured api

Gerbrand van Dieyen — Tue, 18 Apr 2017 21:01:00 +0000

Swagger, http://swagger.io/ is a great way make your api accessible. Not only documentation is provided, but your users, your co-developers or your self can try out your api. But what if your API is secured using a token based security system like webtokens?

Well, it’s quite easy to modify your swagger frontend to allow adding any token to requests.

First somewhere in your swagger template file, add the following:

<form onsubmit="addApiKeyAuthorization()">
                <div class="input">
                    <input placeholder="access_token" id="input_apiKey" name="input_apiKey" type="text">
                    <input type="submit" value="Authenticate"/>
                </div>
            </form>

Then in the header add the following Javascript

<script>
    function addApiKeyAuthorization(){
        var apiKey = getUrlVars().input_apiKey;

        if (apiKey && apiKey.trim() != "") {
            console.log("initialzing oauth via api-key")
            var apiKeyAuth = new SwaggerClient.ApiKeyAuthorization("Authorization", "Bearer " + apiKey, "header");
            window.swaggerUi.api.clientAuthorizations.add("bearer", apiKeyAuth );
            //For clarity, also add in the input field
            $('#input_apiKey')[0].value=apiKey
        }
    }

</script>

Purging files from Git history

Gerbrand van Dieyen — Fri, 14 Oct 2016 16:01:00 +0000

Most developers, like me, use Git for versioning. Even for personal projects, it’s great to have a history of files available. Deleting a file in git will cause it to remove from your working directory, while the file is still present in the history. Usually this is what you want, but sometimes you might want to remove a file completely including it’s history.

There’s a command for that but typically for git it’s not exactly intuitive. To alter history, you can use the filter-branch command. Filter branch can be supplied with a filter, which is a shell command that’s executed on each commit.

To purge a file from history, as if it never existed execute:

git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch MYFILE public' HEAD

Where you can replace MYFILE with one or more files you want to delete.

If you want to purge a whole directory, including it’s content, add the -r switch:

git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch MYDIRECTORY public' HEAD

Great if you checked in a large file, or file in a public repository that shouldn’t be public. For more information, read the git manual or the numerous tutorials that exist. For example, git-filter can also be used to move a file from one repository to another while preserving history.