Lazy Loading and Caching via Sticky Cactoos Primitives

-
You obviously know what lazy loading is, right? And you no doubt know about caching. To my knowledge, there is no elegant way in Java to implement either of them. Here is what I found out for myself with the help of Cactoos primitives.
 
Let’s say we need an object that will encrypt some text. Speaking in a more object-oriented way, it will encapsulate the text and become its encrypted form. Here is how we will use it (let’s create tests first):
1interface Encrypted {
2  String asString() throws IOException;
3}
4Encrypted enc = new EncryptedX("Hello, world!");
5System.out.println(enc.asString());
Now let’s implement it, in a very primitive way, with one primary constructor. The encryption mechanism will just add +1 to each byte in the incoming data, and will assume that the encryption won’t break anything (a very stupid assumption, but for the sake of this example it will work):
01class Encrypted1 implements Encrypted {
02  private final String text;
03  Encrypted1(String txt) {
04    this.data = txt;
05  }
06  @Override
07  public String asString() {
08    final byte in = this.text.getBytes();
09    final byte[] out = new byte[in.length];
10    for (int i = 0; i < in.length; ++i) {
11      out[i] = (byte) (in[i] + 1);
12    }
13    return new String(out);
14  }
15}
Looks correct so far? I tested it and it works. If the input is "Hello, world!", the output will be "Ifmmp-!xpsme\"".
Next, let’s say that we want our class to accept an InputStream as well as a String. We want to call it like this, for example:
1Encrypted enc = new Encrypted2(
2  new FileInputStream("/tmp/hello.txt")
3);
4System.out.println(enc.toString());
Here is the most obvious implementation, with two primary constructors (again, the implementation is primitive, but works):
01class Encrypted2 implements Encrypted {
02  private final String text;
03  Encrypted2(InputStream input) throws IOException {
04    ByteArrayOutputStream baos =
05      new ByteArrayOutputStream();
06    while (true) {
07      int one = input.read();
08      if (one < 0) {
09        break;
10      }
11      baos.write(one);
12    }
13    this.data = new String(baos.toByteArray());
14  }
15  Encrypted2(String txt) {
16    this.text = txt;
17  }
18  // asString() is exactly the same as in Encrypted1
19}
Technically it works, but stream reading is right inside the constructor, which is bad practice. Primary constructors must not do anything but attribute assignments, while secondary ones may only create new objects.
Let’s try to refactor and introduce lazy loading:
01class Encrypted3 {
02  private String text;
03  private final InputStream input;
04  Encrypted3(InputStream stream) {
05    this.text = null;
06    this.input = stream;
07  }
08  Encrypted3(String txt) {
09    this.text = txt;
10    this.input = null;
11  }
12  @Override
13  public String asString() throws IOException {
14    if (this.text == null) {
15      ByteArrayOutputStream baos =
16        new ByteArrayOutputStream();
17      while (true) {
18        int one = input.read();
19        if (one < 0) {
20          break;
21        }
22        baos.write(one);
23      }
24      this.text = new String(baos.toByteArray());
25    }
26    final byte in = this.text.getBytes();
27    final byte[] out = new byte[in.length];
28    for (int i = 0; i < in.length; ++i) {
29      out[i] = (byte) (in[i] + 1);
30    }
31    return new String(out);
32  }
33}
Works great, but looks ugly. The ugliest part is these two lines of course:
1this.text = null;
2this.input = null;
They make the object mutable and they’re using NULL. It’s ugly, trust me. Unfortunately, lazy loading and NULL references always come together in classic examples. However there is a better way to implement it. Let’s refactor our class, this time using Scalar from Cactoos:
01class Encrypted4 implements Encrypted {
02  private final IoCheckedScalar<String> text;
03  Encrypted4(InputStream stream) {
04    this(
05      () -> {
06        ByteArrayOutputStream baos =
07          new ByteArrayOutputStream();
08        while (true) {
09          int one = stream.read();
10          if (one < 0) {
11            break;
12          }
13          baos.write(one);
14        }
15        return new String(baos.toByteArray());
16      }
17    );
18  }
19  Encrypted4(String txt) {
20    this(() -> txt);
21  }
22  Encrypted4(Scalar<String> source) {
23    this.text = new IoCheckedScalar<>(source);
24  }
25  @Override
26  public String asString() throws IOException {
27    final byte[] in = this.text.value().getBytes();
28    final byte[] out = new byte[in.length];
29    for (int i = 0; i < in.length; ++i) {
30      out[i] = (byte) (in[i] + 1);
31    }
32    return new String(out);
33  }
Now it looks way better. First of all, there is only one primary constructor and two secondary ones. Second, the object is immutable. Third, there is still a lot of room for improvement: we can add more constructors which will accept other sources of data, for example File or a byte array.
In a nutshell, the attribute that is supposed to be loaded in a “lazy” way is represented inside an object as a “function” (lambda expression in Java 8). Until we touch that attribute, it’s not loaded. Once we need to work with it, the function gets executed and we have the result.
There is one problem with this code though. It will read the input stream every time we call asString(), which will obviously not work, since only the first time will the stream have the data. On every subsequent call the stream will simply be empty. Thus, we need to make sure that this.text.value() executes the encapsulated Scalar only once. All later calls must return the previously calculated value. So we need to cache it. Here is how:
1class Encrypted5 implements Encrypted {
2  private final IoCheckedScalar<String> text;
3  // same as above in Encrypted4
4  Encrypted5(Scalar<String> source) {
5    this.data = new IoCheckedScalar<>(
6      new StickyScalar<>(source)
7    );
8  }
9  // same as above in Encrypted4
This StickyScalar will make sure that only the first call to its method value() will go through to the encapsulated Scalar. All other calls will receive the result of the first call.
The last problem to solve is about concurrency. The code we have above is not thread safe. If I create an instance of Encrypted5 and pass it to two threads, which call asString() simultaneously, the result will be unpredictable, simply because StickyScalar is not thread-safe. There is another primitive to help us out though, called SyncScalar:
01class Encrypted5 implements Encrypted {
02  private final IoCheckedScalar<String> text;
03  // same as above in Encrypted4
04  Encrypted5(Scalar<String> source) {
05    this.data = new IoCheckedScalar<>(
06      new SyncScalar<>(
07        new StickyScalar<>(source)
08      )
09    );
10  }
11  // same as above in Encrypted4
Now we’re safe and the design is elegant. It includes lazy loading and caching.
I’m using this approach in many projects now and it seems convenient, clear, and object-oriented.

Comments

Post a Comment

Popular posts from this blog

Java – HashMap in-detail explanation

-
Image
HashMap works based on hashing algorithm, As per Java doc HashMap has below four constructors, Constructor Description HashMap ​() Constructs an empty HashMap  with the default initial capacity (16) and the default load factor (0.75). HashMap ​(int initialCapacity) Constructs an empty HashMap  with the specified initial capacity and the default load factor (0.75). HashMap ​(int initialCapacity, float loadFactor) Constructs an empty HashMap  with the specified initial capacity and load factor. HashMap ​( Map <? extends  K ,? extends  V > m) Constructs a new HashMap  with the same mappings as the specified Map . Let’s write simple java program, to examine how Map works internally Create a simple Map and add one key and value to it 1 public   static   void   main(String[] args) { 2   3 Map<Integer, String> map =  new   HashMap<>(); 4   ...
Read more

Secure Spring Boot REST API using Basic Authentication

-
This is the third post of my Spring Boot Blog post series. In the very first post, I talked about my experience with creating RESTFul Services using Spring Boot. Then I have expanded the sample to integrate with Swagger documentation. In this post, I am going to expand above sample with security aspect. What is API Security API Security is a wide area with many different definitions, meanings, and solutions. The main key terms in API security are Authorization, Authentication, Encryption, Federation, and Delegation. However, I am not going to talk about each of them here. What is Authentication Authentication is used to reliably determine the identity of an end user and give access to the resources based on the correctly identified user. What is Basic Authentication Basic Authentication is the simplest way to enforce access controling to resources. Here, the HTTP user agent provides the username and the password when making a request. The string containing t...
Read more