Java

Creating a Docker container with Alpine Linux including Java 8 and 9

2017-12-27 Docker, Java, Linux No comments

Recently, I’ve decided to refresh my knowledge regarding Docker and created an image with Alpine Linux and Java 9, which can be a useful base for the future projects. I used Alpine as a base image because it became quite popular in the Docker world due to its simplicity and the fact that it’s pretty lightweight when we compare it to containers based on other Linux distributions. Pure Alpine Docker container has about 4.144 MB, what is really impressing.

Container with Java 9

My Dockerfile looks pretty simple:

FROM alpine:latest
MAINTAINER pwittchen
USER root

RUN wget http://download.java.net/java/jdk9-alpine/archive/181/binaries/jdk-9-ea+181_linux-x64-musl_bin.tar.gz
RUN tar -xzvf *.tar.gz
RUN chmod +x jdk-9
RUN mv jdk-9 /usr/local/share
ENV JAVA_HOME=/usr/local/share/jdk-9
ENV PATH="$JAVA_HOME/bin:${PATH}"
RUN rm -rf *.tar.gz

We’re downloading JDK, unpacking it, moving to /usr/local/share directory, creating $JAVA_HOME environmental variable and adding $JAVA_HOME/bin to the $PATH. After that, we’re removing downloaded *.tar.gz file.

Repository with this project is available at: https://github.com/pwittchen/docker-alpine-java9
We can also find it on Docker Hub: https://hub.docker.com/r/pwittchen/alpine-java9/

To pull the image from Docker Hub, just type:

sudo docker pull pwittchen/alpine-java9

To run it with CLI, type:

sudo docker run -i -t pwittchen/alpine-java9

Then, we can play around with jshell inside the container:

/ # jshell
Dec 27, 2017 1:18:10 PM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
|  Welcome to JShell -- Version 9-ea
|  For an introduction type: /help intro

jshell> System.out.println("hello from docker!")
hello from docker!

This container is not so small and has about 919.2 MB. It contains whole JDK, so probably this size could be reduced.

Container with Java 8

I’ve also created another image with Java 8 (just in case):

FROM alpine:latest
MAINTAINER pwittchen
USER root

RUN apk update
RUN apk fetch openjdk8
RUN apk add openjdk8

We can also find it on the web:
GitHub: https://github.com/pwittchen/docker-alpine-java8
Docker Hub: https://hub.docker.com/r/pwittchen/alpine-java8/

and pull it from the Docker Hub:

sudo docker pull pwittchen/alpine-java8

and run it with CLI as follows:

sudo docker run -i -t pwittchen/alpine-java8

In this case, container has 118.5 MB, which is better result than for the previous container. In this case, we’re installing Java 8 for Alpine from official repository, so probably it’s already optimized.

I hope, you’ll find it useful while developing your projects in Java 8 or Java 9.

Simple reactive HTTP client & server with RxJava, Vert.x and Android

2017-11-09 Android, Java, RxJava, Vert.x No comments

During Hack Your Career event at the Silesian University of Technology, I’ve prepared a presentation titled Reactive Programming – Efficient Server Applications with a colleague from work. Arek told about theory of Reactive Programming, shown basic concepts, data types and a few examples in the code. During my part of the presentation, I’ve wrote a very simple server and client in Java (9 on the server, 7 on the client) with Vert.x (Core and Rx), RxJava 2, OkHttp 3, Android and RxAndroid. Presentation was targeted mainly to the university students with no experience with reactive programming, but it was an open event and anyone could attend it.

Below, we can see a very simple code snippet showing how to create a reactive HTTP server with Vert.x. We can create a stream of requests, make Flowable out of it, apply any kind of RxJava 2 operator including backpressure handling and subscribe the stream. Moreover, we can also reactively start the server with rxListen(int port) method. This is just a basic example, where will be sending request to the only one endpoint. In the case, when we want to handle more endpoints, we can use vertx-web library and design REST API.

final HttpServer server = Vertx
    .vertx()
    .createHttpServer();

server
    .requestStream()
    .toFlowable()
    .onBackpressureDrop()
    .subscribe(request -> {
      logger.info("{} {}", request.rawMethod(), request.absoluteURI());
      request.response().end("request received");
    });

server
    .rxListen(8080)
    .subscribe(httpServer -> logger.info("server is running at port 8080..."));

We can build this server with Gradle as follows:

./gradlew shadowJar

and then, we can run it:

java -jar build/libs/server-fat.jar

Our client will be an Android application, which will read data from the accelerometer sensor, send it to the server and display it in the TextView on a mobile device. We will use ReactiveSensors library (which was recently migrated to RxJava 2) for getting sensor readings as a Flowable data stream. Next, we will apply backpressure DROP strategy, filter only events of changing sensors (we neglect changing of the accuracy), read only one event per one second with throttleLast(int, TimeUnit) operator and map event to a String with device coordinates. Next, we are ready to send data with Completable performRequest(String), which we created earlier. Sensors readings are acquired in the computation() scheduler, send to the server with io() scheduler and passed to the UI thread on Android with AndroidSchedulers.mainThread(). Distributing operations to the different schedulers is made with subscribeOn(Scheduler) and observeOn(Scheduler).

reactiveSensors
    .observeSensor(Sensor.TYPE_ACCELEROMETER)
    .onBackpressureDrop()
    .filter(ReactiveSensorFilter.filterSensorChanged())
    .throttleLast(1, TimeUnit.SECONDS)
    .map(this::getSensorReading)
    .doOnNext(event -> performRequest(event)
        .subscribeOn(Schedulers.io())
        .subscribe())
    .subscribeOn(Schedulers.computation())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(event -> tvReadings.setText(event));

It’s worth noticing that Completable performRequest(String) is using OkHttp 3 under the hood as a HTTP client, because it’s very simple example with one endpoint. In the case, we want to handle more endpoints on the client-side, it’s better to use Retrofit library.

It’s also interesting that in our case, we can simulate behavior of the accelerometer and other sensors with the latest Android device emulator available in the Android SDK. It works surprisingly smooth.

Complete working example can be found at: https://github.com/pwittchen/reactive-client-server.

Later, I’ve also shown, how to use RxJava to distribute computational operations to a different threads of the CPU cores, but I’ll probably publish a separate article about that on this blog. It was the same example I shown during my JDD presentation this year.

Slides from my part of the presentation are available below.

JDD 2017: Get ready for java.util.concurrent.Flow! – slides, code and recap

2017-10-05 Conferences, Java, RxJava 2 comments

Recently on the JDD 2017 conference, I gave a presentation regarding introduction to Reactive Streams standard in Java 9. I also talked about existing implementations of this standard with the strongest focus on RxJava2 and created simple Reactive Streams implementation in pure Java 9 during the presentation. Below, you can find slides from this talk.

Code snippets shown during this presentation are available at https://github.com/pwittchen/java-flow-experiments.
I have done a tiny live coding session during this talk. Luckily, everything went fine, the code was compiled and executed without errors. Everything I’ve done during this presentation and additional exploratory unit tests could be found in this repository so you can check it out if you’re interested.

There were also tweets made by the audience just before the presentation.

I can say that conference room was full. There were even people sitting on the floor due to lack of free chairs what really surprised me. In the Eventory app, more than 85 people joined the lecture, but in reality, there could be about 100 people or more. It was really flattering that such huge and great audience decided to listen to my talk. In fact, that was the biggest audience I have ever had during the public presentation so far. Moreover, people were asking many interesting questions during Q&A session and after the presentation, so it means they were interested in this topic and they wanted to learn more, understand it and apply it in their projects. If you haven’t had the opportunity to see this presentation, but you would like to, JDD organizers will provide video recordings from the sessions. In addition, you can monitor Talks page on this blog, where I publish my past and upcoming sessions. Probably, I’ll present this topic again during one or two meetups because people are interested in it.

Joining JDD 2017 as a speaker was a great experience. It cost me an additional work and effort after hours, but at the end of the day, it was totally worth it and it was much easier to establish contacts and meet new people as a speaker than as an attendee, what is important for me. Moreover, I could learn new things from other people as well because general level of the conference presentations was pretty high.

Thanks for the interesting questions, discussions, other good presentations and support before the talk!

Below you can find two pictures from this talk made by JDD 2017 photographers.

JDD 2017: Get ready for java.util.concurrent.Flow!

2017-10-02 Conferences, Java, Po polsku, RxJava No comments

Get ready for java.util.concurrent.Flow!

On the 3rd of October 2017 I will be giving a talk titled “Get ready for java.util.concurrent.Flow! at JDD 2017 Conference in beautiful Kraków, Poland.
The talk will be in Polish and you can find a short Polish description of it below.


W Javie 9 otrzymamy do dyspozycji nową klasę z pakietu java.util.concurrent o nazwie Flow. Idea stojąca za tym rozwiązaniem wywodzi się z projektu Reactive Streams. W związku z tym, najnowsza wersja Javy będzie posiadała natywne wsparcie dla tworzenia reaktywnych aplikacji zgodnych ze wspomnianym standardem. Już dziś możemy z tego standardu korzystać i warto się z nim zapoznać wcześniej. Co więcej, od jakiegoś czasu mamy do dyspozycji istniejące implementacje Reactive Streams, które są sprawdzone i gotowe do użycia w projektach na platformę JVM. Wszystkie biblioteki implementujące ten standard mogą ze sobą współpracować dzięki wspólnemu API. Programowanie reaktywne pozwala na pisanie wydajnych aplikacji, które optymalnie wykorzystują zasoby sprzętowe. To podejście pozwala również na dodanie czytelnej warstwy abstrakcji dla aplikacji wielowątkowych oraz wygodne zarządzanie strumieniem danych bez utraty czytelności kodu. Warto dodać, że programowanie reaktywne sprawdza się zarówno na serwerach obsługujących dużą liczbę żądań, jak i na urządzeniach mobilnych, gdzie większość operacji musi być wykonywanych asynchronicznie bez blokowania głównego wątku. Podczas prezentacji chciałbym przedstawić na przykładach popularne implementacje standardu Reactive Streams w Javie 8 takie jak RxJava2 i Project Reactor oraz przykładową, prostą implementację tego samego standardu w Javie 9 z wykorzystaniem klasy java.util.concurrent.Flow.


Date and time of the talk: Day 1, Track 4, Oct 3rd 3:00pm – 3:45pm

This will my very first talk on the JDD conference. I’ve attended this conference a few times as a participant in the past and now it’s time to give a talk as a speaker. I warmly invite everyone who is going to join JDD this year to attend my talk. I’ll try to do my best to keep you interested. There will be an overview of reactive programming, reactive libraries and reactive streams interfaces in Java 9. To keep you awake, we’ll do some live coding and demos on stage.

Recommendations

Due to the fact, I will be speaking on the JDD for the first time, and I’m participating in JUGmajster competition representing SJUG team with two of my colleagues Daniel Pokusa and Grzegorz Gajos. Check out their talks too!

You should also view complete conference schedule. In addition, don’t forget to visit main page of the conference at https://jdd.org.pl.

If you would like to have a discussion, ask a question or just have a beer together, don’t hesitate to reach me! 🙂

See you in Kraków!

Integrating ErrorProne and NullAway with an Android project

2017-09-15 Android, Gradle, Java, Static Code Analysis No comments

Recently, with the remote help of guys from Uber in California, I integrated NullAway and ErrorProne with the one of my open-source Android projects.

What is NullAway?

Basically, it’s a tool to help eliminate NullPointerExceptions (NPEs) in your Java code. It detects situations where NPE could occur at the compile time.

Let’s have a look at the following code:

static void log(Object x) {
    System.out.println(x.toString());
}
static void foo() {
    log(null);
}

NullAway will find out that we’re passing null and we’ll get appropriate error message:

warning: [NullAway] passing @Nullable parameter 'null' where @NonNull is required
    log(null);
        ^

It’s good to have checks like that because they eliminate possible bugs in advance and follows Clean Code principles.

A few words about ErrorProne

NullAway is built as a plugin to ErrorProne and can run on every single build of our code. Moreover, ErrorProne can perform other checks on our code, which can find out commonly people mistakes. E.g. it can detect a situation, where programmer forgot to add @Test annotation in the unit test method in a test suite and other things. It has built-in bug patterns, which are used during code analysis.

Integration with the Android project

I’ve integrated ErrorProne and NullAway with ReactiveNetwork Android library.

First, in the main build.gradle file, I’ve added the following lines:

ext.deps = [
            ...
            nullaway          : 'com.uber.nullaway:nullaway:0.1.2',
            errorprone        : 'com.google.errorprone:error_prone_core:2.1.1',
            ...
            ]

buildscript {
  repositories {
    jcenter()
    maven {
      url 'https://plugins.gradle.org/m2/'
    }
  }
  dependencies {
    ...
    classpath 'net.ltgt.gradle:gradle-errorprone-plugin:0.0.11'
    classpath 'net.ltgt.gradle:gradle-apt-plugin:0.11'
    // NOTE: Do not place your application dependencies here; they belong
    // in the individual module build.gradle files
  }
}

Next, in the library/build.gradle file, I’ve added appropriate plugins in the top:

apply plugin: 'net.ltgt.errorprone'
apply plugin: 'net.ltgt.apt'

Afterwards, I could add dependencies:

dependencies {
  ...

  annotationProcessor deps.nullaway
  errorprone deps.errorprone
}

The last thing to do, is the task responsible for running analysis during project compilation:

tasks.withType(JavaCompile) {
  if (!name.toLowerCase().contains("test")) {
    options.compilerArgs += ["-Xep:NullAway:ERROR", "-XepOpt:NullAway:AnnotatedPackages=com.github.pwittchen.reactivenetwork"]
  }
}

That’s it! Now, I could run analysis by typing:

./gradlew check

and fix the issues.

I think, a quite similar approach and configuration could be applied to a regular, pure Java project built with Gradle.

If you’re interested in the complete configurations, check it out in my project at: https://github.com/pwittchen/ReactiveNetwork.
You can also view Pull Request #226 made by @msridhar (kudos for him!).

Building and running SAP Hybris Commerce Platform via Gradle

2017-09-01 Gradle, Hybris 1 comment

Introduction

I really like Gradle build system for JVM apps. It has flexibility like Ant and great dependency management capabilities like Maven. It addition, it doesn’t use XML notation, but Groovy programming language, so builds configurations are simple, concise, easier to read and easier to create. In my opinion, Gradle is truly modern build system for JVM apps. Nevertheless, there are projects, which are pretty old and use older systems like Ant. For example, all Hybris projects are based on Ant. Moreover, they have their custom setup and configurations, internal extensions system, etc. I was wondering if it’s possible to migrate Hybris Platform build from Ant to Gradle. That’s why I created a simple Proof of Concept.

Migrating from Ant to Gradle

If we want to use Gradle, we need to install it first.

sudo apt-get install gradle         # if we're on Ubuntu Linux
brew install gradle                 # if we're on macOS

For more details and instructions for other systems, check official Gradle installation guide.

Then, we need to go to our Hybris platform directory and navigate to hybris/bin/platform

After that, we need to initialize gradle inside this directory by running gradle command.
Next, we need to create gradle wrapper by running gradle wrapper command.
Now we should have the following elements in our directory:

  • .gradle (directory)
  • graldew (wrapper file for Unix)
  • gradlew.bat (wrapper file for Windows)

Afterwards, we can create build.gradle configuration file.

It should have the following contents:

ant.importBuild 'build.xml'
apply plugin: 'java'

repositories {
  jcenter()
}

task run() {
  doLast {
     exec {
          executable "./hybrisserver.sh"
      }
  }
}

task cleanGeneratedDirs(type: Delete) {
  delete "../../data"
  delete "../../log"
  delete "../../roles"
  delete "../../temp"
}

task cleanConfig(type: Delete) {
  delete "../../config"
}

dependencies {
  compile fileTree(dir: 'lib', include: ['*.jar'])
}

Now, we can execute the following command:

./gradlew clean build

and platform will be built.

In order to initialize the platform, we can call:

./gradlew initialize

If we want to start the Hybris server, we can simply call:

./gradlew run

To clear directories generated during build and initialization, we can run:

./gradlew cleanGeneratedDirs

I tried to make clean task dependent on this one, but I got a few errors and didn’t spend too much time on investigating them.

As you probably noticed, this solution is just a wrapper around Ant build defined in build.xml file and it’s not pure Gradle build configuration. Nevertheless, these tips may be useful for the people who need to have custom build configurations and dependencies. There’s no doubt that creating and maintaining configurations via Gradle is much easier and more convenient than doing the same job via Ant.

Summary

As we can see, it’s possible to migrate Hybris build from Ant to Gradle, but please remember that Hybris has a custom setup and it may not be the best decision in each case. We should always consider pros and cons of such solution and adjust it to our needs. In legacy systems, we often have to stick to existing setups because making “revolution” may be a huge overhead and doesn’t have to pay off. Moreover, all Hybris extensions also have build configurations based on Ant. On the other hand, I can highly recommend Gradle for greenfield JVM projects.

References

There’s another nice, short article describing migrating Java projects from Ant to Gradle: Easily Convert from Ant to Gradle (objectpartners.com).

Introducing ReactiveAirplaneMode

2017-08-15 Android, Open source, RxJava No comments

I’m continuing Rxfication of the Android. Recently I released brand new library called ReactiveAirplaneMode. As you may guess, it allows listening Airplane mode on Android device with RxJava observables. A usual I’ve hidden all implementation details, BroadcastReceivers and rest of the Android related stuff behind RxJava abstraction layer, so API is really simple. Just take a look on that:

ReactiveAirplaneMode.create()
    .observe(context)
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(isOn -> textView.setText(String.format("Airplane mode on: %s", isOn.toString())));

In the code above subscriber will be notified only when airplane mode changes.

If you want to read airplane mode and then listen to it, you can use the following method:

ReactiveAirplaneMode.create()
    .getAndObserve(context)
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(isOn -> textView.setText(String.format("Airplane mode on: %s", isOn.toString())));

If you want to check airplane mode only once, you can use get(context) method, which returns Single<Boolean> value:

ReactiveAirplaneMode.create()
    .get(context)
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(isOn -> textView.setText(String.format("Airplane mode on: %s", isOn.toString())));

If you want to check airplane mode only once without using Reactive Streams, just call isAirplaneModeOn(context) method:

boolean isOn = ReactiveAirplaneMode.create().isAirplaneModeOn(context);

You can add this library to your project via Gradle:

dependencies {
  compile 'com.github.pwittchen:reactiveairplanemode:0.0.1'
}

If you want to know more details, see sample app, documentation & tests, check repository with the source code at: https://github.com/pwittchen/ReactiveAirplaneMode.

Releasing ReactiveNetwork v. 0.11.0 with Walled Garden AKA Great Firewall support

2017-08-06 Android, Java, Open source No comments

In the latest release of ReactiveNetwork library, I focused on Walled Garden AKA Great Firewall support during checking Internet connectivity. There are countries with limited Internet access like China and in such cases, pinging commonly known host like www.google.com may have different results than in other countries because it may be blocked. We may get false positive results because users will generally have an access to the Internet, but they don’t have access only to several websites. To solve that problem, I created WalledGardenInternetObservingStrategy and made it default strategy for checking Internet connectivity inside the library. Of course, you can still use SocketInternetObservingStrategy if you want to.

Detailed release notes are as follows:

RxJava1.x

  • added WalledGardenInternetObservingStrategy – fixes #116
  • made WalledGardenInternetObservingStrategy a default strategy for checking Internet connectivity
  • added documentation for NetworkObservingStrategy – solves #197
  • added documentation for InternetObservingStrategy – solves #198
  • bumped Kotlin version to 1.1.3-2
  • bumped Gradle Android Tools version to 2.3.3
  • bumped Retrolambda to 3.7.0

RxJava2.x

  • added WalledGardenInternetObservingStrategy – fixes #116
  • made WalledGardenInternetObservingStrategy a default strategy for checking Internet connectivity
  • added documentation for NetworkObservingStrategy – solves #197
  • added documentation for InternetObservingStrategy – solves #198
  • fixed package name in AndroidManifest.xml file – solves #195
  • bumped RxJava2 version to 2.1.2
  • bumped Kotlin version to 1.1.3-2
  • bumped Gradle Android Tools version to 2.3.3
  • bumped Retrolambda to 3.7.0
  • increased code coverage with unit tests

Repository address: https://github.com/pwittchen/ReactiveNetwork.

Happy coding!

Releasing ReactiveNetwork v. 0.10.0

2017-07-20 Android, Open source, RxJava No comments

I’ve recently released ReactiveNetwork library v. 0.10.0 for RxJava1.x and RxJava2.x.
ReactiveNetwork is an Android library listening network connection state and Internet connectivity with RxJava Observables, which I’m developing for approximately 2 years now.

In this version, I’ve done a few bug fixes and added new features for RxJava2.x version.

Below, you can find the release notes:

Release for RxJava1.x

  • bumped RxJava1 version to 1.3.0
  • bumped test dependencies
  • created Code of Conduct
  • updated Kotlin version in sample apps
  • added retrolambda to the sample Java app – issue #163
  • fixed behavior of network observing in disconnected state – issue #159

Release for RxJava2.x

  • bumped RxJava2 version to 2.1.1
  • bumped test dependencies
  • created Code of Conduct
  • updated unit tests
  • updated Kotlin version in sample apps
  • added retrolambda to the sample Java app – issue #163
  • fixed behavior of network observing in disconnected state – issue #159
  • added the following methods to ReactiveNetwork class:
    • Single<Boolean> checkInternetConnectivity()
    • Single<Boolean> checkInternetConnectivity(InternetObservingStrategy strategy)
    • Single<Boolean> checkInternetConnectivity(String host, int port, int timeoutInMs)
    • Single<Boolean> checkInternetConnectivity(String host, int port,
      int timeoutInMs, ErrorHandler errorHandler)
    • Single<Boolean> checkInternetConnectivity(InternetObservingStrategy strategy,
      String host, int port, int timeoutInMs,
      ErrorHandler errorHandler)

You can add it to your project via Gradle:

RxJava1.x:

dependencies {
  compile 'com.github.pwittchen:reactivenetwork:0.10.0'
}

RxJava2.x:

dependencies {
  compile 'com.github.pwittchen:reactivenetwork-rx2:0.10.0'
}

Now, in RxJava2.x version, we have the possibility to check Internet connectivity once without any pooling with new Single type. It may be helpful in the specific use-cases when we’re focusing on smaller battery usage, a smaller amount of data being sent over the network and lower number of network connections.

I’m planning to publish more real life usage examples of this library in the future articles on this blog.

I have plans for a few updates in the next version. If you’re interested in this project or you’re using it, please stay tuned and keep an eye on it at GitHub.

Release of prefser v. 2.1.0 with RxJava2 support

2017-06-19 Android, Java, Open source, RxJava 2 comments

I’ve recently released new version of prefser library for Android. In case you don’t know, it’s a wrapper for Android SharedPreferences with object serialization and RxJava Observables. This version has the new artifact, which has codebase migrated to RxJava2.x. As usual, I kept backward compatibility with RxJava1.x.

You can find more details about the project at https://github.com/pwittchen/prefser.

If you want to use it in your mobile project, you need the following dependencies in the build.gradle file:

dependencies {
  compile 'com.github.pwittchen:prefser-rx2:2.1.0'
  compile 'io.reactivex:rxandroid:2.0.1'
}

Short release notes can be found at https://github.com/pwittchen/prefser/releases.

This update was requested by at least two developers on GitHub and it’s my second most popular project, so I hope you’ll find it useful if you’re in the process of migrating from RxJava1.x to RxJava2.x. I still have 4 remaining RxJava1.x libraries waiting for the upgrade. If you want to perform any updates via Pull Requests, you’re more than welcome.