DEV Community: Layla

Records and data transfer

Layla — Thu, 07 Dec 2023 16:08:49 +0000

2023-12-07

So… transferring data

Transferring data! It’s one of the most common practices in development! It’s almost as if one of the most important applications of development is to store and process unfathomable amounts of information. Now one of my colleagues was curious about DTOs and specifically Records in Java, so I thought I would write a bit about the topic. Data flows to and fro. APIs have to talk to each other, but… well… each API has their own representations of data, their own rules for data being the way it is and their own reasons for changing the data… Now, if there is one thing we don’t like in development, it’s having to be dependant on something. When building our applications, our own APIs, we don’t want to become dependant on the way data is structured at any moment in time. This is where the Data Transfer Object comes in. Data Transfer Objects, or DTOs, represent a design pattern that serves one purpose and one purpose only: they are there to store relevant data, which allows us to decouple our internal structure from external applications. They also provide a single point of change when it comes to the nuances of data serialisation. They’re essential!

Structure and Encapsulation

Now, there is a certain structure to a Data Transfer Object. It is necessary to properly encapsulate data, as we need to ensure the validity of the data without doing any sort of synchronization. Again, the idea is to decouple the data structure from any external applications, so the data we get in has to be immutable. We don’t want our data to be altered after instantiation, as that would void the validity and accuracy of the data that we just transferred. We also naturally have to be able to see the content of our DTO as well as compare two DTOs with each other based on their content! This means that, in Java at least, the structure of a DTO tends to look a lot like this:

Every field corresponding to a piece of data has to be private and final.
Each field needs a getter.
We need a public constructor with a corresponding argument for each field
There needs to be an equals method (method to test equality)
There needs to be a hashCode method that returns the same value when all fields match
we need a toString method that includes the name of the class, the name of each field and its corresponding value.

Okay, so how does it look like?

Well, lets take an OMDB movie object in JSON. It looks like so:

{"Title":"Blade Runner",
 "Year":"1982",
 "Rated":"R",
 "Released":"25 Jun 1982",
 "Runtime":"117 min",
 "Genre":"Action, Drama, Sci-Fi",
 "Director":"Ridley Scott",
 "Writer":"Hampton Fancher, David Webb Peoples, Philip K. Dick",
 "Actors":"Harrison Ford, Rutger Hauer, Sean Young",
 "Plot":"A blade runner must pursue and terminate four replicants who stole a ship in space and have returned to Earth to find their creator.",
 "Language":"English, German, Cantonese, Japanese, Hungarian, Arabic, Korean",
 "Country":"United States, United Kingdom",
 "Awards":"Nominated for 2 Oscars. 13 wins & 21 nominations total",
 "Poster":"https://m.media-amazon.com/images/M/MV5BNzQzMzJhZTEtOWM4NS00MTdhLTg0YjgtMjM4MDRkZjUwZDBlXkEyXkFqcGdeQXVyNjU0OTQ0OTY@._V1_SX300.jpg",
 "Ratings":[
         {"Source":"Internet Movie Database",
            "Value":"8.1/10"},
         {"Source":"Rotten Tomatoes",
                    "Value":"88%"},
          {"Source":"Metacritic",
           "Value":"84/100"}],
 "Metascore":"84",
 "imdbRating":"8.1",
 "imdbVotes":"807,587",
 "imdbID":"tt0083658",
 "Type":"movie",
 "DVD":"09 Jun 2013",
 "BoxOffice":"$32,914,489",
 "Production":"N/A",
 "Website":"N/A",
 "Response":"True"}

That’s a lot of stuff! Now, I don’t need all that. In my application, I can whittle it down a bit. Lets write a Java DTO!

@JsonIgnoreProperties(ignoreUnknown = true)  
public class ExampleDTO {  
    @JsonProperty("Title")  
    private final String title;  

    @JsonProperty("Year")  
    private final String year;  

    @JsonProperty("Rated")  
    private final String rated;  

    @JsonProperty("Released")  
    private final String released;  

    @JsonProperty("Runtime")  
    private final String runtime;  

    public ExampleDTO(String title, 
                                        String year, 
                                        String rated, 
                                        String released, 
                                        String runtime) {  
        this.title = title;  
        this.year = year;  
        this.rated = rated;  
        this.released = released;  
        this.runtime = runtime;  
    }  
    public String getTitle() {  
        return title;  
    }  

    public String getYear() {  
        return year;  
    }  

    public String getRated() {  
        return rated;  
    }  

    public String getReleased() {  
        return released;  
    }  

    public String getRuntime() {  
        return runtime;  
    }  

    @Override  
    public boolean equals(Object o) {  
        if (this == o) return true;  
        if (o == null || getClass() != o.getClass()) return false;  
        ExampleDTO that = (ExampleDTO) o;  
        return Objects.equals(getTitle(), that.getTitle())   
                             && Objects.equals(getYear(), that.getYear())   
                             && Objects.equals(getRated(), that.getRated())   
                           && Objects.equals(getReleased(), that.getReleased())   
                             && Objects.equals(getRuntime(), that.getRuntime());  
    }  

    @Override  
    public int hashCode() {  
        return Objects.hash(getTitle(), 
                                                getYear(), 
                                                getRated(), 
                                                getReleased(), 
                                                getRuntime());  
    }  

    @Override  
    public String toString() {  
        return new StringJoiner(", ", ExampleDTO.class.getSimpleName() + "[", "]")  
                .add("title='" + title + "'")  
                .add("year='" + year + "'")  
                .add("rated='" + rated + "'")  
                .add("released='" + released + "'")  
                .add("runtime='" + runtime + "'")  
                .toString();  
    }

Well… there you have it. This object gives me everything I want, ignores everything that I don’t define and is then essentially immutable after instantiation. A classic java DTO… but isn’t it maybe a bit… much?

Records

Well, a lot of people considered all the boilerplate code involved in creating a DTO in Java to be a bit much for what is ultimately just a class that is there to store information. It can get so supremely wordy! And while DTOs provide a single point of change… Well, imagine I wanted to scale my movie project and add a few more fields to my DTO. Suddenly, I wouldn’t just have to write the fields, I would have to change the constructor, the equals method, the hashCode method and the toString method. That seems like an unnecessary amount of work for what is ultimately just the addition of two fields. Other languages tried to rectify this problem with the addition of special data carrier classes… like Kotlin’s data class. Java followed suit in Java 17 with the Record class. So what are records, you might ask?

Well, what if we want to have a class that has all of those things I mentioned before, with a focus on conciseness and readability, without all the mess? That is what a record is. Lets refactor that unwieldy example dto by turning it into a record!

Here we go:

@JsonIgnoreProperties(ignoreUnknown = true)  
public record ExampleDTO(  
        @JsonProperty("Title")  
        String title,  

        @JsonProperty("Year")  
        String year,  

        @JsonProperty("Rated")  
        String rated,  

        @JsonProperty("Released")  
        String released,  

        @JsonProperty("Runtime")  
        String runtime  

) {  
}

Wow! That’s a lot shorter, and while it’s not explicit, it retains all the functionality that was there before! Under the hood, this class has all the accessor methods we want, has all private, final fields and has a constructor with all the necessary arguments. It is a class that is focused on, as mentioned, conciseness and readability. The released accessor isn’t called getReleased() like it normally would be, but simply released(), almost as if you were invoking the field itself. This breaks with the usual convention, but it improves readability and intuitiveness. It even has a special sort of constructor, called a compact constructor that takes no explicit arguments. Lets add the fields we want an play with that constructor for a moment!

@JsonIgnoreProperties(ignoreUnknown = true)  
public record ExampleDTO(  
        @JsonProperty("Title")  
        String title,  

        @JsonProperty("Year")  
        String year,  

        @JsonProperty("Rated")  
        String rated,  

        @JsonProperty("Released")  
        String released,  

        @JsonProperty("Runtime")  
        String runtime,  

        @JsonProperty("Director")  
        String director,  

        @JsonProperty("Writer")  
        String writer  

) {  

    public ExampleDTO {  
        boolean isValidYear = 
                Pattern.compile("^(19|2[0-9])\\d{2}$").matcher(year).matches();  
        if (!isValidYear) {  
            throw new RuntimeException(
            "Year needs to be a valid year between 1900 and 2099"
            );  
            }  
        }  
    }

We just added two fields and some slight validation to our constructor, without needing to do a lot in terms of writing out boilerplate. Quite nice, I would say. I hope this informed you a bit about the usage of DTOs and records in Java! May this knowledge prove useful to you in your programming efforts. Let me know if there is anything else you would like me to expand on! I am always curious to learn and to share what I know. Write something beautiful!

Virtual Threads and Structured Concurrency in Java

Layla — Fri, 01 Dec 2023 20:22:30 +0000

2023-12-01

So what is concurrency? And why is it?

Concurrency is a complicated, but important, subject when it comes to programming, and as our industry and demands advance, so do our tools. You might be wondering, then, what is concurrency exactly and how does it differ from something like asynchronicity? The answer can be broken down to a simple difference: concurrency is the process of multiple things happening at once, whereas asynchronicity involves asking for something to happen and getting notified when it finishes, while doing something else in the meanwhile. In concurrency multiple processes at least have the appearance of happening at once, whereas with asynchronicity a process is ‘waiting’ for something to occur.

In Java, concurrency involves making use of multiple system threads to handle different processes at the same time, attempting to make full use of a computer’s power. While threads have been an element of Java since Java 1.5, the needs of developers and the evolving tech landscape required it to evolve over time. Creating threads is easy, but managing them? That is a whole different beast. For this purpose, the Executor Service was introduced in Java 5, with the process being further simplified by the addition of the ForkJoinPool and CompletableFutures in Java 8. These features were very useful at the time, and are still powerful, but as demands have increased, this model has started to lag behind. Java Concurrency’s problems can be summed up in two words: cost and ignorance.

Like renting a room at the Hilton

So what do I mean when I say that threads are costly? Well, you see, starting up a thread costs a lot in terms of system resources. It has a startup time of around 1 millisecond, takes up about 2 megabytes of memory (on the stack) and you need to switch contexts, which takes about 100 nanoseconds (dependant on your OS). Now one thread? Seems small enough, but when you’re talking about processes that take up thousands of threads at a time, you are starting to notice significant slowdown, which is of course a bit counterproductive. This also means that it is simply impossible to have something in the scale of a million threads, as it would require about 15 minutes of time and 2 terabytes of memory. This might seem like a lot, but consider how intense our computer use is nowadays and it starts making sense that maybe we would want to be able to do more things at the same time.

Furthermore, if you have such an expensive resource, you want to make use of it as much as possible, but trying to keep your system busy is not easy. An idle thread still takes up resources, but if you’re not careful, a thread might be idle for almost the entirety of its lifetime. When you use a single thread, for example, to handle things for which it has to wait, it simply waits, and all threads wait at the same speed. The Executor Service, ForkJoinPool and CompletableFuture were introduced to handle this problem, introducing tools that manage pools of threads for you and facilitate asynchronous code. Lets write some code for reference.

Lets take a common example of something that usually requires asynchronicity: an api call! For purposes of illustration and mutually assured destruction, I will be using the DadJokes API. Our calling function looks something like this:

private DadJoke callApi() {  
ResponseEntity<DadJoke> response =    
        template.getForEntity("https://icanhazdadjoke.com/", DadJoke.class);

    if (response.getStatusCode() != HttpStatus.OK){  
        throw new ConnectionException(response.getStatusCode());  
    }  
    return response.getBody();  
}

Say, I want to return an entity that contains an array of three dad jokes. If I were to write this in a synchronous, somewhat naive and inefficient way, I could do so as follows:

public DadJoke[] getDadJokes(){  
    DadJoke[] jokes = new DadJoke[3];  

    jokes[0] = callApi();  
    jokes[1] = callApi();  
    jokes[2] = callApi();  

    return jokes;  
}

I call the API three times, I receive three random dad jokes, I put them in an array and I send that array back. Relatively simple. Now, every call to the API is blocking. The next function waits for the previous to finish. It’s an issue, as it slows things down. Of course, it’s not a big issue for a single call, but what if we had more? What if we had hundreds? Well, lets use completable futures to make the three calls happen at the same time:

private CompletableFuture<DadJoke> getDadJokeFuture(){  
    return CompletableFuture  
            .supplyAsync(this::callApi)  
            .exceptionally(ex -> new DadJoke("error", ex.getMessage(),
                         HttpStatus.BAD_REQUEST.value()));  
}

public DadJoke[] getDadJokes() {   
    CompletableFuture<DadJoke> future1 = getDadJokeFuture();  
    CompletableFuture<DadJoke> future2 = getDadJokeFuture();  
    CompletableFuture<DadJoke> future3 = getDadJokeFuture();  

    return Stream.of(future1, future2, future3)  
            .map(CompletableFuture::join)  
            .toArray(DadJoke[]::new);  

}

I make a little helper function which simply gives me a CompletableFuture that calls the api. I then run the completable futures in parallel and join the results together, forming the array. The completable future uses system threads, by default as many threads as your system has cores. This works! But it’s taxing… and looks a bit confusing. Furthermore, you can only deal with exceptions when tasks are finished. Threads are ignorant of each other and if one task fails, the others will unnecessarily continue their work, even though our code will fail anyway. Furthermore, if a thread gets interrupted or throws an exception somehow, neither will spread to subtasks. All of this is, of course, a waste of very precious resources! It’s like renting a room in the Hilton for five days but only staying there for one!

Weaving a tapestry

Technology keeps moving and our use of computers is through the roof. The above model of concurrency was a solution to problems that appeared almost ten years ago as of the date of writing, but it is becoming increasingly problematic. How do we deal with this issue? Enter Virtual Threads and Structured Concurrency. To explain how virtual threads and structured concurrency tackle the problems of cost and ignorance, let me first explain what virtual threads are.

Let me just give you a small code snippet of how to instantiate a virtual thread. Virtual threads have various factory methods that one can use to instantiate them. Let us compare the output of virtual threads with system threads.

public static void main(String[] args) throws InterruptedException {  
    Thread platformThread = Thread.ofPlatform()  
            .name("system-", 0)  
            .start(() -> {  
                System.out.println(String.format("system %s", Thread.currentThread()));  
            });  

    platformThread.join();  

    Thread virtualThread = Thread.ofVirtual()  
            .name("virtual-", 0)  
            .start(() -> {  
                System.out.println(String.format("virtual %s", Thread.currentThread()));  
            });  
    virtualThread.join();  
}

Here you can see how to instantiate the two different kinds of thread. They output the following:

system Thread[#21,system-0,5,main]
virtual VirtualThread[#22,virtual-0]/runnable@ForkJoinPool-1-worker-1

Interestingly, the virtual thread seems to have a bit more going on. What is all this text after the slash supposed to indicate? Well you see, virtual threads are special, lightweight threads that run on top of system threads. They are managed by the JVM and are detachable. This means that one does not need to make special system calls to create them, the JVM is aware of their functioning and they can be detached and reattached on demand, meaning that the system threads are free to work on other things while the virtual threads are idle. They are cheap and that means you can make a million of them. Observe:

public static void main(String[] args) throws InterruptedException {  
    var threads =  
            IntStream.range(0, 1_000_000)  
                    .mapToObj(index ->  
                            Thread.ofVirtual()  
                                    .name("virtual-", index)  
                                    .unstarted(() -> {  
                                        try {  
                                            System.out.printf("virtual %s%n", Thread.currentThread());  
                                            Thread.sleep(2_000);  
                                        } catch (InterruptedException e) {  
                                            throw new RuntimeException(e);  
                                        }  
                                    }))  
                    .toList();  

    Instant begin = Instant.now();  
    threads.forEach(Thread::start);  
    for (Thread thread : threads) {  
        thread.join();  
    }  
    Instant end = Instant.now();  
    System.out.println("Duration = " + Duration.between(begin, end).toSeconds());  
}

One. Million. Threads.

So…. what? How does it work then? How fast is it? Lets see a part of the output.

virtual VirtualThread[#1000017,virtual-999989]/runnable@ForkJoinPool-1-worker-3
virtual VirtualThread[#999940,virtual-999912]/runnable@ForkJoinPool-1-worker-6
virtual VirtualThread[#1000018,virtual-999990]/runnable@ForkJoinPool-1-worker-6
virtual VirtualThread[#1000019,virtual-999991]/runnable@ForkJoinPool-1-worker-6
virtual VirtualThread[#1000010,virtual-999982]/runnable@ForkJoinPool-1-worker-6
virtual VirtualThread[#1000024,virtual-999996]/runnable@ForkJoinPool-1-worker-1
virtual VirtualThread[#1000025,virtual-999997]/runnable@ForkJoinPool-1-worker-1
virtual VirtualThread[#1000026,virtual-999998]/runnable@ForkJoinPool-1-worker-1
virtual VirtualThread[#1000027,virtual-999999]/runnable@ForkJoinPool-1-worker-2
virtual VirtualThread[#1000022,virtual-999994]/runnable@ForkJoinPool-1-worker-2
virtual VirtualThread[#1000000,virtual-999972]/runnable@ForkJoinPool-1-worker-2
virtual VirtualThread[#1000021,virtual-999993]/runnable@ForkJoinPool-1-worker-2
virtual VirtualThread[#1000020,virtual-999992]/runnable@ForkJoinPool-1-worker-2
virtual VirtualThread[#999999,virtual-999971]/runnable@ForkJoinPool-1-worker-2
Duration = 19

What this block of code shows is that there are actually… a lot of threads. More than that, these threads only really use a limited amount of system threads! I can inform you that the max system threads used was actually 8. It wasn’t instantaneous, naturally. The duration at the end indicates that 19 seconds passed between start and finish, but that’s a whole lot better than impossible, right? Not to mention that it doesn’t eat memory like skittles. It can also carry multiple threads on a single system thread. Now that’s what I call multithreading.

In essence, starting up virtual threads up is cheap as dirt and means that starting up and managing virtual threads is a lot less of an issue. That said, managing a bunch of threads probably still seems like a big headache. Well, you could still make use of the Executor Services like before to build pools of virtual threads, or, well, there is structured concurrency. It is comparable to Kotlin coroutines or Go’s goroutines.

Note that as of Java 21, Structured Concurrency is still a preview feature so things are bound to change and functionality is still limited. Now without further ado, lets rewrite our api call using Structured Concurrency.

public DadJoke[] getDadJokes(){  

    try (StructuredTaskScope<DadJoke> scope = new StructuredTaskScope<>()) {  

        Subtask<DadJoke> fork1 = scope.fork(this::callApi);  
        Subtask<DadJoke> fork2 = scope.fork(this::callApi);  
        Subtask<DadJoke> fork3 = scope.fork(this::callApi);  

        scope.join();  

        if (forkIsUnsuccessful(fork1, fork2, fork3)){  

            throw new StructuredConcurrencyException("A thread failed");  
        }  

        return new DadJoke[]{fork1.get(), fork2.get(), fork3.get()};  

    } catch (InterruptedException e) {  
        e.printStackTrace();   
    }  
}

@SafeVarargs  
private <T> boolean forkIsUnsuccessful(Subtask<T>... tasks){  

    return Arrays  
            .stream(tasks)  
            .anyMatch(task -> task.state() == State.FAILED);  
};

First we instantiate our scope in a try-with-resources statement. What is that, a scope? Well, it is an object that allows us to perform structured concurrency. It supports cases where a task is split up into several subtasks that are all performed… concurrently. The life of the concurrent operation is confined to its syntax block, like a sequential operation. It works a lot like an Executor Service in that you supply it with tasks. The fork method defines the subtasks to perform. A subtask holds a value, as well as a State. This state can be used to check whether a task was successful or not. The join method is blocking and waits until all subtasks are done, after which the value and state of the subtasks can be extracted. Each subtask runs on a separate virtual thread, and it’s fine to block these as they are just so much cheaper than system threads. Importantly, for this to work, the values within the scope are immutable, but can be shared between threads.

In this above code, all the checking and so forth is done manually, but there are special factory methods of the StructuredStaskScope that allow it to shutdown on success and failure. The ShutdownOnSuccess scope simply shuts down the scope after the first subtask is successful. The ShutdownOnFailure scope, of course, does the opposite, and you can follow this up by throwing an exception.

Something like this


public DadJoke[] getDadJokes(){  

    try (StructuredTaskScope.ShutdownOnFailure scope = new
                    StructuredTaskScope.ShutdownOnFailure()) {  

        Subtask<DadJoke> fork1 = scope.fork(this::callApi);  
        Subtask<DadJoke> fork2 = scope.fork(this::callApi);  
        Subtask<DadJoke> fork3 = scope.fork(this::callApi);  

        scope.join();  
        scope.throwIfFailed(ex -> new
                StructuredConcurrencyException(ex.getMessage()));  
                // it throws an Execution Exception by default,
                // which is a checked exception.

        return new DadJoke[]{fork1.get(), fork2.get(), fork3.get()};  

    } catch (InterruptedException e) {  
        e.printStackTrace();  
    }  
}

That was virtual threads and structured concurrency in java in a shellnut! I hope it informed you a bit about how you can weave your own multithreaded code tapestry. It is there to allow you to boost performance of certain tasks within a specific scope. This allows you to apply readily evident control flow to your multithreaded processes as all threads complete their tasks before exit. Let me know if there is anything I missed or anything I didn’t focus on which you would like more clarity on. I’d also love to know whether there are any specific topics you would like to see me expand on! Write something beautiful.

Functional Interfaces, Lambdas and Generics, oh my!

Layla — Fri, 24 Nov 2023 13:00:35 +0000

So what is all this then?

A colleague of mine, after showing him some of what I had written, seemed befuddled by all that was going on. "What is all this mess? The heck? 'Functional interface'? Java is an object-oriented language you know'. Well, that is true for the most part, but well, sometimes you just want to write some damn functionality, and so in Java 8, Oracle introduced some functional programming into what was (and is) a language known for being rigidly object-oriented. Lambdas are very commonly used in the Streams API, among others, but you can build your own! Very useful, to be sure, as they can make your code much more streamlined and svelte.

Okay, sunshine, so what is a Lambda exactly?

I'm glad you asked! So a lambda, in computer science, is essentially an "anonymous function". All functionality, no preamble, lambdas are simple, short and disposable. They have their origin in the Functional programming world, but most languages implement them in some form or another nowadays. They can be assigned to variables or used as arguments, which allows for sleek, reusable code.

In Java, one can express them as follows:

argument -> argument.startsWith("Ms");
(String argument) -> { return argument.startsWith("Ms") };

Okay, that seems cool, but what are generics?

So generics are parameterized types. What is a parameterized type? Well, it means that the type is itself an argument of sorts. This means that one does not have to specify the specific type of an object to build something and that one only has to specify on initialization or invocation what that type is. But what does that mean, exactly? Alright, so allow me to illustrate using a simple object that simply stores another object... A box, if you will.

public class Box<T> {

  private T content;

  public Box(T content){
    this.content = content;
  }

  public void set(T content){
    this.content = content;
  }

  public T get(){
    return content;
  }
}

What the heck? What is that mysterious 'T' that is used everywhere? Well you see, that is the generic. It is there to indicate a malleable type. The letter can be any letter. I could change it to 'A' for argument if I felt like it, but T for type is commonly handled. Other letters you might see used are S, U, V (2nd, 3rd, 4th argument and so forth), R (return type), E (element), K (key), and V (Value). Now, what is this supposed to do? Well it means that when we create a new Box, we specify the type and all the Ts in the Box will conform to that type. For example if we now create a Box as follows:

Box<Integer> box = new Box<>(5);

(starting from Java 7, one can leave the second pair of diamond brackets empty as long as the left side is filled in.)

The box will, essentially, turn into something like this:

public class Box {

  private Integer content;

  public Box(Integer content){
    this.content = content;
  }

  public void set(Integer content){
    this.content = content;
  }

  public Integer get(){
    return content;
  }
}

As you can see, this allows for more malleable configurations. Generics can also be used in methods, which I will go into further down.

Cool, so lets put it all together! How can I make my own lambdas!

Yes! Let's get to it. To build our own lambda functions, first we have to start with a functional interface. What is a functional interface? Well, it's an interface with only one abstract method in it! This is known as the Single Abstract Method (SAM) principle. Any interface with a single abstract method qualifies as a functional interface. One can even define default or private methods in the interface or have static variables! As long as there is only one abstract method, you're good.

Lets make a lambda function that tests whether something is true. It returns a boolean but can take any sort of argument. I will call it... TruthChecker.

@FunctionalInterface
public interface TruthChecker<T> {
    boolean test(T t);
}

(The annotation is optional but highly recommended. It functions like @Override in the sense that it clearly communicates what it is and checks whether it meets all criteria.)

Alright, so here we have it. Pretty simple right? Okay so... what now? How do I actually implement this thing?

Lets make a main somewhere, and implement the function! Here we go!

    public static void main(String[] args) {

        TruthChecker<String> checker = 
          argument -> argument.startsWith("Ms");

        System.out.println(checker.test("Mrs. E")); //false
        System.out.println(checker.test("Mr. E")); //false
        System.out.println(checker.test("Ms Demeanour")); //true
  }

Interesting, right? we can just... use the test method inside the class. The method will correspond to the functionality we passed in! We can create multiple instances of the TruthChecker with different types and functionality, as long as it still returns a boolean, it will work:

    public static void main(String[] args) {

        TruthChecker<Integer> checker = 
          argument -> argument > 5;

        System.out.println(checker.test(5)); //false
        System.out.println(checker.test(10)); //true
  }

Of course, savvy Java users will have cottoned onto the fact that I simply recreated the Predicate functional interface for illustration. Now I hear some of you ask: "what is a Predicate?". Well, A predicate is a type of function that returns a boolean, and in Java, a predicate is one of several prefab functional interfaces that one has access to! You don't need to build your own. Most of the time there is already a functional interface out there in the base language that you can implement!

For example, instead of our TruthChecker, we could simple do:

    public static void main(String[] args) {

        Predicate<Integer> checker = 
          argument -> argument > 5;

        System.out.println(checker.test(5)); //false
        System.out.println(checker.test(10)); //true
  }

It even has a test function, like our TruthChecker, and more functionality besides!

Of course, being variables, some of their real power comes from being used as arguments! Observe:

    private static <T> boolean check(T t, Predicate<T> checker){
        return checker.test(t);
    }

Using the power of generics, I have created a generalized and reusable check function! Here you can see the use of generics in methods in action. I can pass in a variable and functionality, and then the method will make use of the functionality passed in.

Lets return to our main to demonstrate:

    public static void main(String[] args) {

      System.out.println(check(5, integer -> integer > 5)); 
//false
      System.out.println(check(10, integer -> integer > 5));
 //true
      System.out.println(check("Ms de Mineur", 
        string -> string.startsWith("Ms"))); 
//true
    }

Witchcraft! I use a single method to check various different types of objects! But this is the power of lamdas. Being variables, they can be passed as arguments. This also means one can be a return value!

    private static Function<Integer, Integer> multiplication(Function<Integer, Integer> func, Integer number){
        return integer -> integer * func.apply(number);
    }

Now things are getting a bit funny, but stick with me. In this function, I am using the Function functional interface, which takes an argument and returns a value. The value I am returning, however, is another Function, which makes use of the result of the function I passed in!

Lets return to our main for a moment:

    public static void main(String[] args) {

        Function<Integer, Integer> multiplier = multiplication(number -> number * 5, 5); //A function that stores 5 * 5 = 25; 

        System.out.println(multiplier.apply(5)); //5*25 = 125
    }

As you can see, this allows me to chain functionality into other functionality! The initial argument is loaded into a function and then functionality is returned which uses the result as an argument. Passing another argument into this returned functionality finally returns a value.

That was it for now! I hope that this has helped you better understand lambdas and generics in Java and how to apply them! They are a powerful tool that will allow you to write succinct, reusable and malleable code without losing type safety. Write something beautiful!