Forem: Yuri Mednikov

How to deploy Vert.x applications with Docker

Yuri Mednikov — Wed, 19 Oct 2022 10:09:19 +0000

The most common approach is to deploy Vertx applications as fat jars - this means that we rely on build tools to generate a "fat jar" project (the application that includes built code, configurations alongside with bundled external dependencies). This app is ready to be executed on local systems as any normal jar project or could be deployed to popular platform as a service cloud providers that support deployments of fat jar apps (examples include Heroku, Clever Cloud, Microsoft Azure, Amazon among others). In addition, when we talk about microservices, it is a common practice to deploy them inside containers in order to improve their portability.

Object level permissions with Hibernate Reactive and Vertx

Yuri Mednikov — Sat, 24 Sep 2022 21:00:58 +0000

In the 5th part of the Hibernate Reactive with Eclipse Vertx tutorial we observe the topic of object level permissions. It is our duty as software engineers to implement strong protection of applications. We need to verify that secured APIs are accessed by authenticated users and also that they could modify only those records that are owned by such users. In order to this we make use of the concept of object level permissions. Object level permissions are used to verify if a user should be allowed to act on a particular object, which will typically be a model instance. This type of protection could be accessed in many popular web frameworks, such as Django , Laravel , Spring Security etc. Vertx does not provide such tool, and in this tutorial we research how to build such functionality.

Relationships with Hibernate Reactive and Vertx

Yuri Mednikov — Sat, 24 Sep 2022 20:59:10 +0000

In the 4th part of my Hibernate Reactive & Eclipse Vertx tutorial, we cover an important topic of relationships. Relational databases, as PostgreSQL or MySQL make use of table relationships in order to store complex data structures. We talk about common types of relationships (one to one, one to many, many to one) and how they are implemented with JPA and Hibernate. We add a new data model to our application and finally we create an integration test to verify that our code does work correctly.

Logging Patterns with Hibernate Reactive and Vertx

Yuri Mednikov — Mon, 19 Sep 2022 09:24:37 +0000

No views 19 Sept 2022 In this video we continue with the tutorial on how to use Hibernate Reactive with Eclipse Vert.x 4.x. In particular, we cover the topic of logging.

CRUD Repository with Hibernate Reactive and Eclipse Vertx

Yuri Mednikov — Thu, 15 Sep 2022 09:54:36 +0000

This video continues the topic of development Vertx applications that make use of the Hibernate Reactive ORM library.

In this Part 2 of the tutorial we will explore how to implement a CRUD repository with the aforesaid tech stack. Additionally, we will introduce the TestContainers library that simplifies the process of writing integration tests.

How to configure Hibernate Reactive with Eclipse Vertx 4 (Without XML)

Yuri Mednikov — Wed, 14 Sep 2022 19:24:11 +0000

The usage of traditional Java ORM frameworks with Eclipse Vertx is a complicated process, due to the fact that these technologies rely under the hood on the synchronous JDBC API. On the other hand, Vertx is based around the reactive programming model and if software developers would like to use blocking libraries, that are required to perform extra steps. Hibernate Reactive is the first Java ORM solution that natively makes use of Vertx reactive clients and combines advantages of ORM libraries with reactivity and non-blocking patterns.

Typically, Hibernate is configured with XML configuration. This approach is also demonstrated by Hibernate Reactive docs and Vertx How-to website. However, XML configuration should be avoided. In this tutorial I will demonstrate essential patterns of using Hibernate Reactive with Eclipse Vertx 4.x.

The first part demonstrates how to configure Hibernate Reactive with Vertx 4.x programmatically (without any XML).

Vertx, Guice and Config Retriever: Dependency Injection in Vertx 4.x

Yuri Mednikov — Wed, 23 Jun 2021 10:23:33 +0000

In computer science, the dependency injection is defined as a pattern, whereby one component gets other components (dependencies) from outside. Numerous posts were written about various implementations of a dependency injection in Vertx using Google Guice library. All of them are good and I do not want to reinvent a bicycle here and to repeat same things again. However, in my opinion, it is a good idea to give a bit more systematic approach to this topic. In my experience, in most cases, for developers is not a big deal to implement a basic DI with Vertx, rather it seems hard to incorporate Vertx components into the DI pipeline. In this post we will review how to do a dependency injection in Vertx with Google Guice and how to to build a basic injection that has the ConfigRetriever component (Vertx's way to obtain an application configuration). Please note, that in this article we use Futures API, so it is focused on Vertx 4.x developers.

Basic DI with Google Guice

Google Guice is an established solution to implement a dependency injection technique in Java applications. Like most established libraries, it is quite simple to use, yet it does not mean that it is limited in any way. This is very flexible and powerful solution. Main building blocks of the framework are modules and injectors. The module is used to define how to get dependencies. The injector serves as a main entry point of an application and is used for an actual component initialization. Let have a quick example, that uses a constructor injection technique. Imagine, that you develop a verticle, that has two external dependencies - a client class (that performes HTTP calls) and a repository class (that does database operations). For sure, we will not do here their precise implementations, because it is out of the scope of the post. In order to specify these dependencies classes inside the verticle we need to use an @Inject annotation. If you are familiar with the Spring framework, you would find a process familiar. Basically, we need to create fields to keep references for components, define a constructor and annotate it with the @Inject, so Guice will know that we use a constructor injection.

Take a look on the following code snippet below:

class ProjectVerticle extends AbstractVerticle {

    private ProjectClient client;
    private ProjectRepository repository;

    @Inject
    ProjectVerticle(ProjectClient client, ProjectRepository repository){
        this.client = client;
        this.repository = repository;
    }

    // ...

Another step is to tell Guice how these classes are created. For that, we need to create a module. Keeping simple, this component define what is called bindings (again, if you are an experienced Spring developer, you call this wiring). Modules extend an AbstractModule class, provided by Guice, and override the configure() method, which is utilized for bindings. For our example, we will make it simple:

class ProjectVerticleModule extends AbstractModule {

    @Override
    protected void configure() {
        bind(ProjectClient.class).to(ProjectClientImpl.class);
        bind(ProjectRepository.class).to(ProjectRepositoryImpl.class);
    }
}

You can note, that we bind types (interfaces) to instances. There are several types of bindings, that are available in Guice:

Instance binding = we map a dependency to the specific instance; this is a good choice for simple dependencies, but for bigger it should be avoid, as it will slow down a start up time. We use it in the next section
Linked binding = we map a dependency to its implementation, and Guice creates an instance for us; this is what we used here
Provider binding = we provide an own implementation of the Provider interface, that is used to create dependencies; this is a case for complex dependencies; in this post we will omit it

Once we have created a module, we can use it in order to create components. For that we need to use an injector, which is defined as a class, that builds graphs of objects that make up our application. An injector takes one or many modules, and uses them to understand how actually to provide requested dependencies and to create an instance of the component. Take a look on the following example:

@Test
void injectTest(Vertx vertx, VertxTestContext context){
    // create a module
    ProjectVerticleModule module = new ProjectVerticleModule();

    // create an injector
    Injector injector = Guice.createInjector(module);

    // get an instance of verticle
    ProjectVerticle verticle = injector.getInstance(ProjectVerticle.class);

    // deploy the ProjectVerticle
    Future<String> deploy = vertx.deployVerticle(verticle);
    deploy.onComplete(id -> {
        context.verify(() -> {
            String client = verticle.getProjectClientName();
            String repository = verticle.getProjectRepositoryName();

            Assertions.assertThat(client).isEqualTo("ProjectClientImpl");
            Assertions.assertThat(repository).isEqualTo("ProjectRepositoryImpl");

            context.completeNow();
        });
    }).onFailure(err -> context.failNow(err));
}

You can note, that we use an injector to initialize the ProjectVerticle component, instead of using the new keyword. In other words, we can say, that we "out source" the initialization process to Guice. We could verify that dependencies were created correctly, by validating their names. This is an easy example. Now, let move to more practical topic - how we can incorporate actual Vertx components in the DI pipeline.

Adding ConfigRetriever

In this subsection we will review a bit more complex (and real life) example. Often (if not always) you need to create components, that use configurations from the outer world. A naive example, is a repository, that listens database credentials, or an http client, that need requires API tokens. In the Vertx world, in order to read a configuration we use the vertx config library. We will not cover all aspects of its usage; I recommend you to review my ebook Principles of Vertx, where I cover it in details. For the purpose of this post, you just need to remember, that the key component that does this job is called ConfigRetriever. This class abstracts particular configuration types and provides a single entry point (and also it allows to listen of configuration updates; but this is out of the scope of this article). In order to initialize it, we use a static factory method, that requires a reference to the Vertx object:

private ConfigRetriever configRetriever;

AppVerticleModule(Vertx vertx){
    configRetriever = ConfigRetriever.create(vertx);
}

@Override
protected void configure() {
    bind(ConfigRetriever.class)
        .annotatedWith(Names.named("ConfigRetriever"))
        .toInstance(configRetriever);
}

Here we define a dependency using the familiar instance binding. Note, we also use an optional naming binding here: in the consumer class (verticle) we provide a @Named annotation with the constructor dependency injection.

@Inject
AppVerticle(@Named("ConfigRetriever") ConfigRetriever configRetriever){
    this.configRetriever = configRetriever;
}

The config retriever component is used in order to get a configuration for the application. This is done using the getConfig method. In this post we use Futures API (Vertx 4.x) instead of callbacks (Vertx 3.x + Vertx 4.x):

Future<JsonObject> cr = configRetriever.getConfig();

Future<ProjectVerticle> vert = cr.map(c -> {
    logger.info("Configuration obtained successfully");
    Injector injector = Guice.createInjector(new ProjectVerticleModule(vertx, c));
    ProjectVerticle verticle = injector.getInstance(ProjectVerticle.class);
    return verticle;
}).onFailure(err -> {
    logger.warning("Unable to obtain configuration");
    startPromise.fail(err);
});

Let review this code snippet. The first step is to obtain a future of the configuration reading. Then we map the result in order to create an injector and to initailize the ProjectVerticle. We also provide config to the module in order to use them in dependency buildings (like credentials, tokens etc). If the config retriever fails to get a configuration, we fail the whole start( process of the AppVerticle.

The next stage is to deploy the project verticle. Take a look on the following implementation:

Future<String> dr = vert.compose(v -> vertx.deployVerticle(v));

dr.onSuccess(id -> {
    logger.info("ProjectVerticle deployed");
    startPromise.complete();
}).onFailure(err -> {
    logger.warning("Unable to deploy ProjectVerticle");
    logger.warning(err.getMessage());
    startPromise.fail(err);
});

The future composition allows to connect two futures (configuration and deployment). The lambda parameter v here is the verticle, created inside the map() method in the previous step. The topic of using Futures API is out of the scope of this post, so we will not cover things in details here. Basically, we have two outcomes:

onSuccess = the verticle is successfully deployed and we complete the AppVerticle starting process
onFailure = something went wrong! We fail the AppVerticle starting process

Let put everyting together. Inside the main method of our fictional application we create a module and an injector for the AppVerticle and deploys it. Here we do not need to deploy other verticles, because the AppVerticle serves as an entry point of our app and does this job:

public static void main(String[] args) {
    Vertx vertx = Vertx.vertx();
    Injector injector = Guice.createInjector(new AppVerticleModule(vertx));

    AppVerticle appVerticle = injector.getInstance(AppVerticle.class);
    Future<String> dr = vertx.deployVerticle(appVerticle);

    dr.onSuccess(id -> logger.info("AppVerticle started..."))
    .onFailure(err -> {
        logger.warning("Unable to start AppVerticle");
        logger.warning(err.getMessage());
    })
    .onComplete(r -> {
        vertx.close();
        logger.info("Vertx closed");
    });

}

Source code

If you would like to get full source code used in examples in this post, you can find it in this github repository. Feel free to explore it!

Conslusion

Simply speaking, the dependency injection is a pattern that allows to "outsource" the creation of components. There are several proven solutions to implement this architecture in Java apps and the Google Guice library is one of them. It is simple, but in the same time powerful. In this post we reviewed how to implement dependency injection in Vertx 4.x applications. We did two examples: one is a simple demonstration of essential Guice methods. The second uses an actual Vertx component - the ConfigRetriever, that reads a configuration and provides it to other components (that in their turn is also used to create other dependencies). If you have questions regarding this topic, please feel free to contact me or drop a comment below.

Vehicle mode for FPS games with Godot

Yuri Mednikov — Fri, 14 May 2021 16:56:48 +0000

From all FPS games, my favorite titles are those with vehicle mode, like Battlefield series. Therefore, when I started to work on my own FPS prototype with Godot Engine, I decided to introduce something similar. Surely, I do not pretend to create a complete simulation of battle vehicles; only essential functionality with primitive arcade-like physics. That is how I ended with the following solution. I am still on very early stages in game development, so I admit that my idea is not perfect and maybe I brought concepts from web development, that should be avoided in game programming. However, it is a working concept, and due to the fact, that existing Godot tutorials on vehicle mode are not complete, let me present you my own.

Player vs. vehicle mode

The first thing first is to distinguish between two main game modes: player mode (this is a first-person mode, where you control the character) and vehicle mode (this is a third-person view, where vehicle is controlled). What I found out during my research, that some Godot tutorials treat both modes as a single and just switch cameras views. I don't think it is correct at all, as the whole idea of a vehicle mode in the game like the mentioned Battlefield is to be able to pick up a vehicle. Therefore, if you "carry" vehicle always with player you can't do embark/disembark and also it will be complicated to introduce more than one vehicle. I even don't mention different type of vehicles that can be available in your game - ground vehicles, air vehicles, ships (ships?) and so on.

In my prototype I have a quite naive first person controller, that is placed inside the Player.gd script. This component can move around, rotate camera, fire etc - in other words it is responsible for the player mode. There is a state variable is_active, which defines, if the mode is active. If it is not active, the controller will not work. Take a look on the physics_process() implementation:

func _physics_process(delta):

    if is_active:

        var direction = Vector3()
        var head_basis = head.global_transform.basis

        if Input.is_action_pressed("move_forward"):
            direction -= head_basis.z
        elif Input.is_action_pressed("move_backward"):
            direction += head_basis.z

        if Input.is_action_pressed("move_left"):
            direction -= head_basis.x
        elif Input.is_action_pressed("move_right"):
            direction += head_basis.x

        direction = direction.normalized()

        # gravity
        apply_gravity()

        # switch weapons
        switch_weapons()

        if Input.is_action_just_pressed("primary_fire"):
            if active_weapon.is_possible_shoot:
                active_weapon.shoot()

        if Input.is_action_pressed("reload"):
            active_weapon.reload()

        # switch weapons with two buttons (to test gamepad without gamepad):
        if Input.is_action_just_pressed("weapon_switch_up"):
            weapon_switch_up()
        elif Input.is_action_just_pressed("weapon_switch_down"):
            weapon_switch_down()

        # jump
        jump()

        var speed = run_speed if Input.is_action_pressed("move_run") else normal_speed

        velocity = velocity.linear_interpolate(direction * speed, acceleration * delta)

        velocity = move_and_slide(velocity, Vector3.UP)

        update_ui()

When the value of the variable is_active is false, this code snippet will not be executed. I introduced two other helper methods, to trigger the player mode, e.g. to enable it, when the player disembarks a vehicle and to disable it, when the player is inside a vehicle. These two methods are called enable_player() and disable_player() respectively. What they do is to turn on or to turn off following aspects of the player controller:

The value of the is_active variable
Visibility of the player controller
Enabling/disenabling of the collision body
First person camera
Interaction raycast (we will talk about it later on)

My sample implementations of these methods are presented below:

func enable_player():
    is_active = true
    visible = true
    camera.current = true
    interaction_raycast.enable()
    collision_shape.disabled = false


func disable_player():
    is_active = false
    visible = false
    camera.current = false
    interaction_raycast.disable()
    collision_shape.disabled = true

On the other hand I have the Vehicle.gd class which serves as a parent class for all vehicle types. It is responsible for the vehicle mode. There are two helper methods, that are used to trigger the mode: use_vehicle() and drop_vehicle(). The vehicle entity also has it is own variable to keep an active stay - is_activated Also these methods are used to switch camera and to notify the player controller to enable or disable the player mode.

Take a look on the sample implementation below:

func use_vehicle():
    print('Use vehicle')
    is_activated = true
    camera.current = true
    do_on_embark()
    get_tree().call_group('Player', 'disable_player')
    get_tree().call_group('UI', 'activate_vehicle_ui', true)


func drop_vehicle():
    print('Drop vehicle')
    is_activated = false
    camera.current = false
    do_on_disembark()
    get_tree().call_group('Player', 'enable_player')
    get_tree().call_group('UI', 'activate_vehicle_ui', false)

You may notice here two callback methods do_on_embark() and do_on_disembark(). We will return to them later. Before, I would like to talk about how to interact with a vehicle.

How to embark and to disembark

In the previous subsection, I mentioned an interaction raycast. This component is used by the player controller to interact with various game objects, such as doors, locks, light switches etc. It is decomposed from the main Player.gd script and is placed into the Interaction.gd class. By default, the idea is following: when a player interacts with an interactable object, a hint is shown and a player can use that object. For vehicle it means to embark.

So, we can embark the car by pressing the E button. In this situation we call the use_vehicle method to activate the vehicle mode. This works as following:

func _process(delta):
    var collider = get_collider()

    if is_colliding():
        if current_collider != collider:
            current_collider = collider
            if collider is Vehicle:
                var text = 'use vehicle'
                set_interaction_text(text)

        if Input.is_action_just_pressed('interact'):
            if collider is Vehicle:
                var vehicle = collider as Vehicle
                vehicle.use_vehicle()

Please note, that this is short form of the original code, because it also deals with Interactable objects, that are out of the scope of this post; so I limited it to interactions with Vehicle only. With all this logic we now can interact with vehicles and switch between two game modes.

I have mentioned already what I call callback functions. Being mainly web developer, I took that idea from there, so I admit it may be not good for video games. Because we have a parent class Vehicle that encapsulates core embark/disembark functionality, we may need to do something when use_vehicle and drop_vehicle functions are called without overriding them. That way I introduced two callbacks do_on_embark and do_on_disembark, where concrete implementations can put own logic without overriding of parent implementations. There is another callback do_movement, but this is a separate story, that we will discover in the next subsection.

How vehicles do move

Same way as with the first person controller, we have the variable that keeps if the current state is active. For vehicles it is called is_activated and is placed inside the parent class. It is also utilized in the physics_process() function that listens game updates. Once the vehicle mode is activated, the function will call the do_movement callback, which is used to move the vehicle. As there are different types, it can't be implemented in the core class.

func _physics_process(delta):
    if is_activated:
        if Input.is_action_just_pressed("interact"):
            drop_vehicle()
        do_movement(delta)

My sandbox project, that you can find on github, contains a sample vehicle implementation - a police car. It is not a perfect simulation of a car behaviour (if at all), and I took concrete logic from this wonderful kinematic car tutorial from KidsCanCode. You can find explanations there, because I could not copy-paste it and claim that the solution is mine, of course, it is not. What I want to show you instead, is how it is organized.

All moving logic of the police car is placed inside the overriden do_movement callback. Due to the fact, that the parent Vehicle class passes the delta value to the callback, we can use it to perform movements of vehicles. For my police car, I did it as following:

func do_movement(delta):
    if is_on_floor():
        handle_input()
        handle_friction(delta)
        handle_steering(delta)
    car_acceleration.y = gravity
    velocity += car_acceleration * delta
    velocity = move_and_slide_with_snap(velocity, -transform.basis.y, Vector3.UP, true)

The whole movement implementation is taken from the KidsCanCode, so I would not stop on it. What is crucial here, is that we can use do_movement callback to implement moving of any type of vehicles; not limited to cars, but also helicopters, aircrafts, space ships etc.

Source code

This post is based on my FPS sandbox project. It available in this github repository and has much more, than just the vehicle mode. Feel free to fork it and experiment with it. If you have questions or suggestions or any valuable feedback, don't hesitate to contact me or drop a comment.

Conclusion

That is the way I used to implement the vehicle mode for FPS game with Godot. I admit that is not the best one, and I excited to listen your solutions, admitting the fact, that I am quite new to Godot Engine and game dev in general. However, this code does its job and provides the complete experience - both interaction and movements and it separates two modes, and provides a possibility to extend the original functionality for any type of vehicles.

How to solve Jackson InvalidDefinitionException on immutable objects

Yuri Mednikov — Fri, 05 Feb 2021 18:01:21 +0000

In my practice, I faced an issue, when while I was working with the Spring framework and I have an immutable object, I got InvalidDefinitionException during web layer tests. That is due to tge fact, that Jackson by default uses a no-args constructor and setters to deserialize an entity from a JSON payload. And surely, this practice leads to bad software design. So, if you also want to solve this problem, let me provide you my solution.

To start, let take a look on my entity model. Observe the following code snippet below:

@Value
@Document(collection = "customers")
public class CustomerModel {
    @Id String customerId;
    String companyName;
    String companyEmail;
    String taxId;
    AddressModel billingAddress;
    AddressModel shippingAddress;

}

Here, you can note, that I use the @Value annotation here in order to get:

All arguments constructor
All fields are private and final
No setters

Using this entity class within a web layer of the application does not lead to problems, and a serialization works as expected when you call the API, for instance, with an external client. However, when I write tests to assert the web layer, I will end with an exception, because, as I have said already, Jackson can not deserialize JSON without a no-args constructor and setters:

The first solution, that I have found on Stackoverflow is to create a lombok.config file in the root of my project with following parameters:

lombok.anyConstructor.addConstructorProperties=true

Although, this did not solve the issue. And if you are still reading this post, that means, that this solution also fails for you. What I found as a working approach is to create manually an all-args constructor and annotate it for Jackson, like it is shown in the code snippet below:

@Value
@Document(collection = "customers")
public class CustomerModel {

    @Id String customerId;
    String companyName;
    String companyEmail;
    String taxId;
    AddressModel billingAddress;
    AddressModel shippingAddress;

    @JsonCreator
    public CustomerModel(
            @JsonProperty("customerId") String customerId, 
            @JsonProperty("companyName") String companyName, 
            @JsonProperty("companyEmail") String companyEmail, 
            @JsonProperty("taxId") String taxId, 
            @JsonProperty("billingAddress") AddressModel billingAddress, 
            @JsonProperty("shippingAddress") AddressModel shippingAddress) {
        this.customerId = customerId;
        this.companyName = companyName;
        this.companyEmail = companyEmail;
        this.taxId = taxId;
        this.billingAddress = billingAddress;
        this.shippingAddress = shippingAddress;
    }

}

Basically, I use here two annotations:

@JsonCreator marks a constructor to be explicitly used by Jackson for deserialization
@JsonProperty is used on constructor's arguments to help Jackson access concrete fields in runtime

This code perfectly works for me. By the way, don't forget to follow these steps on your nested objects too, if you have them. And I hope, it will help you too.

If you have issues with the Spring Boot that you don't know how to overcome, don't hesitate to contact me.

Iterators in Java

Yuri Mednikov — Mon, 20 Jul 2020 06:38:44 +0000

The iterator pattern is one of approaches to access elements of a collection, alongside with streams. From a technical point of view, the iterator traverses elements in a sequential and predictable order. In Java the behaviour of iterators is defined in java.util.Iterator contract, which is a member of Java Collections Framework.

Iterators are similar to enumerators, but there are differences between these concepts too. The enumerator provides inderect and iterative access to each element of a data structure exactly once. From the other side, iterators does the same task, but the traversal order is predictable. With this abstraction a caller can work with collection elements, without a direct access to them. Also, iterators allow to delete values from a collection during the iteration.

Access elements of a collection

As it was mentioned before, the order of accessing elements is predictable, which means that the iterator traverses elements sequentialy. Therefore, the general Java contract does not allow to access the particular element (however, that is possible using Commons Collections, even this violates the idea). In order to access the next element, use next() method. It returns an element or throws NoSuchElementException, when the iterator does not contain more elements.

In order to prevent this unchecked exception, you should call the hasNext() method prior to accessing an element.

List<Integer> numbers = List.of(1, 2, 3, 4, 5, 6);
Iterator<Integer> iterator = numbers.iterator();
while (iterator.hasNext()) {
    int x = iterator.next() * 2;
    System.out.println(x);
}

This code snippet demonstrates the usage of the iterator for sequential retrieving of elements and the printing of double value of each element.

The important thing to note here, is that once elements are consumed, the iterator can not be used. That means, that calling the iterator after traversing will lead to an exception:

List<Integer> numbers = List.of(1, 2, 3, 4, 5, 6);
Iterator<Integer> iterator = numbers.iterator();
while (iterator.hasNext()) {
    int x = iterator.next() * 2;
    System.out.println(x);
}
int value = iterator.next();

The execution of the above code snippet will lead to the following result:

I already mentioned Apache Commons Collections. This library contains a helper class IteratorUtils, which has a number of static utility methods to work with iterators. While some of them violate the core pattern, they can be useful. So, alongside with a sequential access, it possible to access a particular element by its index, as well there is a wrapper method to get the first element.

List<Integer> numbers = List.of(1, 2, 3, 4, 5, 6);
Iterator<Integer> iterator = numbers.iterator();
int first = IteratorUtils.first(iterator);
Assertions.assertThat(first).isEqualTo(1);

Consuming an element

Since Java 8 iterators permit also to specify a consumer function, which can be performed on each element. This is a shortcut of what we can do using a while block. Let consider the first example implemented with the forEachRemaining() method. Take a look on the code snippet below:

List<Integer> numbers = List.of(1, 2, 3, 4, 5, 6);
Iterator<Integer> iterator = numbers.iterator();
iterator.forEachRemaining(number -> System.out.printf("This is a consumer. Value: %d \n", number*2));

This program listing produces the following result:

It is possible to perform such behavior with IteratorUtils. It has two static methods:

forEach() = applies the function to each element of the provided iterator.
forEachButLast() = executes the defined function on each but the last element in the iterator

Both methods accept two arguments: an iterator instance and a closure function. The second concept defines a block of code which is executed from inside some block, function or iteration. Technically, it is a same thing as a consumer functional interface. The example of using this helper method is below:

List<Integer> numbers = List.of(1, 2, 3, 4, 5, 6);
Iterator<Integer> iterator = numbers.iterator();
IteratorUtils.forEach(iterator, number -> System.out.printf("This is a closure. Value: %d \n", number*2));

The output of this snippet is:

Remove elements

Finally, we need to observe how to use an iterator to delete elements. The java.util.Iterator interface defines the remove() method. It deletes from the underlying collection the last element returned by the iterator. This method can be called only once per call of the next() function. Note, that this operation is optional.

List<Integer> numbers = new ArrayList<>();
numbers.add(1);
numbers.add(2);
numbers.add(3);
numbers.add(4);
numbers.add(5);
System.out.println("Initial list: ");
numbers.stream().forEach(System.out::println);
Iterator<Integer> iterator = numbers.iterator();
while(iterator.hasNext()) {
    iterator.next();
    iterator.remove();
}
System.out.println("Modified list: ");
numbers.stream().forEach(System.out::println);

This code snippet executes and prints elements of the array list before and after removing elements, like it is snown on the screenshot below:

There are things to remember, when you use iterator.remove():

As this operation is optional, it can throw the UnsupportedOperationException, if a collection does not have an implementation of this method (that is why I used an array list and not a generic list)
You must call the next() method BEFORE calling the remove() method, otherwise it will lead to the IllegalStateException to be thrown

That is how you can utilize an iterator in order to access elements of a collection, to perform an action on each element or to remove elements from a collection. These are general considerations. If you want to learn how to use iterators with concrete types of collections (lists, sets, queues) and to learn more advanced iterator patterns - check my book on Java Collections Framework.

How to check if a list contains a value in Clojure

Yuri Mednikov — Mon, 06 Jul 2020 06:50:48 +0000

Recently I started to learn Clojure, and usually, my first phase is to complete small programming exercises. To practice Clojure I decided to solve some CodingBat problems. A common task here is to check, if an array does contain some value. The expected result should be a boolean value. When I moved to practical implementations, I realized how tricky can be a simple thing in Clojure.

In this post I would like to share with you some thoughts on how to check, that a list contains an element in Clojure. As almost any beginner I have started with contains? method, however it may not be your best option. I will explain to you several solutions, including ones, that come from Java.

What is wrong with contains? function?

This is an expected question. To explain it, let me take a simple exercise from CodingBat. For example, array-1/has23. The problem statement asks us to return a boolean value, which reflects if the given array contains 2 or 3. Pretty simple, isn't it? Let start with contains? function. Take a look on the following code snippet below:

(defn has23 [numbers]
    (or (contains? numbers 2) (contains? numbers 3))
)

(println (has23 [2 5]))
(println (has23 [4 5]))
(println (has23 [1 3]))

What is wrong with this code? When you will execute it you will receive an output, similar to this:

false
false
false

But there are values - the first list has 2 and the last one has 3, why it is false? The answer is in the purpose of this method. contains? returns a boolean value, which represents if a data structure contains a key. So, it works for associative data structures (like maps). For lists a key is an index of an element. Because we have an array of 2 elements, it can't have an index 2 and moreover 3! As a result, this approach would not work. Hopefully, there are others.

Using some

When you will search for the solution, most probably you will find recommendations to use some. It works fine with sequential data structures, like lists. This function takes two arguments: a predicate (logical condition) and a data structure itself. The return is a first matching element.

Let try it with an another exercise - warmup-2/arrayFront9. The task here demands us to return true, if there is 9 in first 4 elements. Note, that I use take function to get first 4 elements:

(defn arrayFront9 [numbers]
    (some #{9} (take 4 numbers))
)

(println (arrayFront9 [1 2 9 3 4]))

The output of the code listing above is

Now we will check result with a list, which does not have 9 among first four elements:

(defn arrayFront9 [numbers]
    (some #{9} (take 4 numbers))
)

(println (arrayFront9 [1 2 3 4 9]))

In this case, the output is nil. This may lead to an error, if another logic relies on this function, which can return a null value. Furthermore, we need to get a boolean result. Let refactor our solution:

(defn arrayFront9 [numbers]
    (not= (some #{9} (take 4 numbers)) nil)
)

(println (arrayFront9 [1 2 9 3 4]))
(println (arrayFront9 [1 2 3 4 9]))

I added an assertion to check if the element is not null. In other words, if 9 does exist among first subsequence, it will be returned, otherwise the result will be null. So, I wrapped it around logical validation to return a boolean value. The output of this code is:

true
false

As expected!

Go Java

In my previous post on Clojure exception handling, I stated that as Clojure runs on JVM it inherits a lot of from Java. That leads us to an another soltuion - using Java methods to work with collections. If you have read my article on Java collections, you may remember that we have two methods in our disposal:

contains = returns true if an element is presented in a collection
indexOf = returns an index of an element, or -1 in case of its absence

In this section we will observe, how to use them both.

Contains

Let take the exercise called array-1/no23. It is a mirror to what we have already solved in in a has23 example, but now we need to assure, that the list does not contain 2 or 3. In order to call Java methods in Clojure we utilize a concept of dot notation:

(defn no23 [numbers]
    (not (or (.contains numbers 2) (.contains numbers 3)))
)

(println (no23 [5 4]))
(println (no23 [2 1]))
(println (no23 [4 3]))

When you will run this code snippet, you will receive an output like that:

true
false
false

Remember, that we are expected to find an absence of 2 and 3 in a list. This means, we need to negate a result of calling .contains function.

IndexOf

While looking for a solution, I have found an interesting approach. It is based on using indexOf method. As you remember, this function checks for an element and returns its index or -1 (when an element is not in a list).

To illustrate this point let take again arrayFront9 exercise, but not we will refactor it to use indexOf. Take a look on my implementation below:

(defn arrayFront9IndexOf [numbers]
    (not= (.indexOf (take 4 numbers) 9) -1)
)

(println (arrayFront9IndexOf [1 2 9 3 4]))
(println (arrayFront9IndexOf [1 2 3 4 9]))

The result of an execution will be following:

true
false

We use negation not= in a similar way, like with some. We need to validate, that a result from calling indexOf function is not equal to -1 (that means an absense of 9). Any other value corresponds to a presence.

That is all for this post. Hope, that it helped you in a some manner. If you have questions regarding a topic of how to check if a list contains a value in Clojure, you can ask them in comments below or contact me.

How to handle exceptions in Clojure

Yuri Mednikov — Thu, 02 Jul 2020 11:15:11 +0000

In some form or another, but exceptions exist in almost any languages. Due to the fact, that Clojure actually runs on JVM, it inherits its exception system from Java. From a technical point of view, the exception concept stands for unwanted or unexpected event, which occurs during the execution of a program i.e at run time, that disrupts the normal flow of the program’s instructions.

The hierarchy of exceptions in Clojure is similar to the one in Java and includes: checked exceptions, runtime exceptions and errors. Their relationship is presented on the diagram below:

All exceptions subclass Throwable class. Runtime exceptions correspond to a separate group, because technically, a recovery from these exceptions are may still be possible. This group is not checked in a compilation time. Contrary to this, checked exceptions should be explicitly handled.

Errors are placed separately. The concept of error is quite tricky. Often, this due to the fact that there is nothing that a program can do to recover from the error, because it indicates serious problems that a reasonable application should not even try to catch. Let think about the memory error - java.lang.VirtualMachineError. Such error indicates that the Java Virtual Machine is broken or has run out of resources necessary for it to continue operating. Or in other words, an app goes out of memory, it simply can't allocate additional memory resources. Surely, if a failure is a result of holding a lot of memory that should be made free, an exception handler could attempt to free it (not directly itself, but call JVM to do it). And even such handler may be useful in this context, such attempt might not be successful.

There are different points of view on exception handling in functional languages. Nevertheless, exception do exist in Clojure and can not be avoided, so they should be handled.

Standard approach

This section presents a standard (or general) error handling approach in Clojure. If you have an experience programming in Java, you will find it familiar, because in a similar way with Java, Clojure utilizes try-catch blocks.

Try-catch block

As it was mentioned, Clojure provides a same way to handle exceptions as Java. The code, that causes an exception is placed inside try block and you also can provide a functionality, that will be triggered, when exception would be caught. It is placed inside catch block. Take a look on the code snippet below:

(defn DangerFunction [number]
    (+ number 10)
)

(defn ExceptionHandler []
    (DangerFunction "1")
)

Here we have two functions. The first one - DangerFunction accepts a number and returns its sum with 10. Inside the second one - ExceptionHandler - we call it, but instead of a number we brings a string value as an argument. In a run time it will cause ClassCastException. Technically, it is a runtime exception, so it is not checked in a compilation time. But, when the ExceptionHandler will be called, it will result in the following result:

To avoid this, we implement an exception handling mechanism:

(defn ExceptionHandler []
    (try 
        (DangerFunction "1")
        (catch ClassCastException ex
            (println "I catched the excepiton!")
        )
    )
)

Now, the call of DangerFunction with an invalid argument will be caught. This allows to recover from the exception situation:

Finally

The catch block represents a sutuation, which will exist only when an exception will occur. In that way, the normal program flow will be interrupted. The finally block allows to provide a functionality, that will be triggered anyway. It is used in a similar way as in Java:

(defn ExceptionHandler []
    (try 
        (DangerFunction "1")

        (catch ClassCastException ex
            (println "I catched the excepiton!")
        )

        (finally 
            (println "I am executed anyway!")
        )
    )
)

As it was mentioned, the logic placed inside finally will be executed in any case, even the exception will not be thrown. We can prove it by passing a valid number to the function:

Multiple catch

Potentially, a code block may throw more than one exception type. Certainly, you can just catch a generic Exception. But usually you need to determine what it was exactly, because it will execute a different logic afterwards. So, Clojure, like Java, provides an opportunity to have multiple catch blocks.

For example let take the following program. It handles two operations: sums the argument with 10 and the divides it by zero. Of course, the last action will cause an ArithmeticException, but it could be not triggered, if we will provide a bad argument (not a number). So, consider this code snippet:

(defn MultipleExceptionHanlder [x]
    (try
        (def result (+ x 10))
        (/ result 0)

        (catch ClassCastException c
            (println "This is ClassCastException")
        )
        (catch ArithmeticException a
            (println "This is ArithmeticException ")
        )
    )
)

(println "Multiple exception: bad input")
(MultipleExceptionHanlder "100")

(println "MultipleException: divide by 0")
(MultipleExceptionHanlder 100)

Let call this function with two scenarios: a string argument and a number argument, like it is demonstrated below:

What do you need to remember here? Generally, we assume in this code that exceptions are at same level. But you have to order catch blocks from most specific to most general. In other words, catch for ArithmeticException must come before catch for Exception.

That is all for this post. If you have questions regarding an exception handling in Clojure, you can write them in comments below or contact me directly.