JShell: upcoming Java REPL, packed into JDK9

Hack the Tower, Hack the OpenJDK

Hack the Tower is a monthly developer meetup in Heron Tower on the 26th floor with stunning view to London. There are two communities behind this hackathon:

London Java Community

London Scala Users’ Group

Adopt OpenJDK team is a regular member of the hackathon, leaded by Mani.

I had a chance to play with JShell, the upcoming Java REPL.

First steps with JShell

Here is a well-written introduction how you can install JShell, currently it’s Kulla Project but I believe it’s going to be a command under JDK’s bin folder, called jshell. Quick bypass: I researched for JShell and found some existing implementations of it. Geophil, for instance, is a shell implementation that was in use with JDK 1.1.

One of the major points of developing JShell is to reduce the learning curve, eliminate boilerplate codes and focuse on the exact solution. You don’t need a main class to print out something, you can do that with System.out.println(“Hello JShell”) only. If you’re writing a command, semicolon is optional. It would be nice in real Java code as well.

My favourite features list

1. eliminating checked exceptions

You don’t need to be worried about try-catch blocks, JShell pushes checked exceptions behind the curtain so you can just write a code like this:

-> Integer testInt = Integer.parseInt("1")

2. saving the workspace into a file

You can create your own methods:

-> Integer myIntegerParser(String number){ return Integer.parseInt("1");  }

Be careful, semicolon is not optional within a function!

Now you can use your function:

-> Integer testTwo = myIntegerParser("2")

Without semicolon, of course, because REPL is about doing things quickly.

Now you can save your workspace as workspace1:

-> /save workspace1

If you look into the workspace1 file, there are all of your commands, you can reload it with /open workspace1 anytime or just edit that file manually and carefully.

Missing features

It’s out of scope but a marriage with Maven and Gradle would be really useful. Just imagine, you would run jshell in your project’s root, jshell would parse pom.xml, deal with dependencies and load classes automatically. Wow, that would be really nice.

Circular queues in Java

I’d like to see how deep the rabbit’s hole is, starting it with a quick round of Java queues. The most important one in low latency application context is the circular queues or ring buffers. These are the same. It’s a fixed size data buffer, connecting the end to the beginning creating a nice infinitive data ring, so your hamster could easily run around and around and around…

Another important architectural point of circular buffer is that it’s a FIFO (First In First Out) construction, easy data piping.

Major points of a low latency application:

  1. Lock Free
  2. Wait Free
Circular Buffer

Some major implementations

  • Fast Flow: FastFlow is a parallel programming framework for multicore platforms, which uses hybrid single-producer/single-consumer queues as a base underlying component for inter-thread communication
  • Thompson queue
  • Lamport queue: http://en.wikipedia.org/wiki/Lamport’s_bakery_algorithm

Basic Implementation

A possible implementation of this queue in Java is using an array based solution. It needs to enqueue the new items into the structure and to dequeue from there. It also needs to shift the data to the dequeued space in the array. Because it has always a fixed array size, it needs a starting array size and the implementation must be able to expand the size if it’s necessary.

Building a Trade Exchange site – phase one: check-list of a low-latency applications

I’m thinking about building a demo TX site, playing around low-latency problems with Java. I need to make some researches for this journey so I decided to create a development check-list what are the main points of a low-latency web application. I won’t really deal with front-end side, I’ll create a RESTful API, that will be enough. It should be a websocket driven communication form.


  • using non blocking multi-threaded technologies
  • avoid the complex and unnecessary frameworks (plain jdbc vs JPA?)
  • reducing memory usage
  • check java 8 related parts
  • using a highly responsive server (Netty)

Be Reactive

I’m not sure which one was the first when I met this reactive idea. Maybe Odersky’s Principles of Reactive Programming was that. It’s a really great but not too easy Coursera session with Scala, of course. And there is the core, The reactive manifesto. You can signed it if agree with this. Yes, I signed it.

It’s all about the standard vertical and horizontal scaling stuff. The main idea contains 4 points:

  1. react to events (Event driven programming)
  2. react to load (scalability)
  3. react to failure (resilient systems)
  4. react to users (responsive)

Best implementation of Reactive manifesto is Akka toolkit.

Be Reactive.

Scala Meetup: an open source event analytics platform

It was a crackin’ meetup. Alex Dean talked about an open source event analytics platform. It’s built on Scalding as a MapReducer with Scalaz, Spray and ScalaCheck. These are the main scala technologies in the project. Alex talked about the business model. So it’s an open source project and as usual there is a business support on the Snosplow’s side.

There is the GitHub page: https://github.com/snowplow/snowplow

I have to paste the scalding’s logo, because that’s really cool: