Category Archives: Uncategorized

JShell with IntelliJ

Java 9 introduced the JShell: an interactive programming shell that can speed development.

With an IDE in hand, the obvious thing to do would be to wrap JShell so that it is available as a console window. Fortunately, IntelliJ does just that! The next obvious thing to do is to make your project code available to JShell so that you can reference classes and methods you’ve already defined. This is not as easy from purely the command line, but fortunately IntelliJ does allow us to reference code in our current project with just a couple steps

There are however a few gotchas when attempting this in IntelliJ. The rest of this post applies to IntelliJ 17.3 and later, which has direct Java 9 support.

(An aside to Gradle users, if you are using IntelliJ to create a new Java 9 project, the default version of Gradle that IntelliJ 17.3 pulls down for you is 4.0, which has known issues with Java 9. It’s best to have an existing installation of Gradle 4.3 or later when creating the project, and specify that Gradle location.)

First, when you use the menu item (“Tools” -> “JShell Console…”), type some code like “1+1”, and press the “play” button, the output console doesn’t always appear, bringing confusion about where the output is. I think sometimes you need to click the the tools menu item more than once, or use CTRL-Enter to execute your code to make the output window appear. However, once it appears, it has always been visible for me even after restarts. It just caused some initial confusion to me and others who have tried it.

Next, with the JShell console visible, Java 9 needs to be available. You don’t need to run IntelliJ on Java 9 and the project doesn’t even need to be a Java 9 project, but the Java 9 installation needs to be available to IntelliJ, and you’ll need to set the JRE of the JShell from the JRE dropdown in the JShell console. Otherwise you will get a warning that “JDK 9 or higher is needed to run JShell.”

Now, adding “1+1”, and assigning “int x=0;” is fun and everything, but JShell becomes a lot more practical when you can reference classes and methods in an existing project. The libraries that your project depends on are available to JShell if you use the default setting (at the top of the JShell console) of “Use Classpath of:” [Whole Project]. But what is REALLY useful is to reference the classes and methods defined by your actual project. To do this, you need to make the output of your project available to IntelliJ as a Library. Go to “File > Project Structure”, then in the dialog “Project Settings > Libraries” add the location of the output classes of your project as a Library. For a maven project, this might look like “project/target/classes.” With this addition in place, you should be able to import and reference the classes that your project defines, enabling you to explore your code much faster than even with TDD.

Hopefully you will enjoy using JShell in your project, whether you are on Java 9 or not!


Leave a comment

Filed under Uncategorized

Move Deliberately and Don’t Break Anything

Move Fast and Break Things was first coined at Facebook, and has since become a startup mantra. The idea is that if you’re not occasionally breaking things, you’re not moving fast enough. And of course as a business if you’re not moving fast enough you’ll die.

I recently watch a talk by Brian Goetz (Java Language Architect at Oracle) called “Move Deliberately and Don’t Break Anything.” This post is a recap of that talk and what I thought were important points.

As with most things, Move Fast and Break Things does not apply to everything. Success comes at a price and that price is you have to stop breaking things. At a certain scale (millions of users? billions?) the cost of breaking something is higher than the cost of not moving at a particular speed. Facebook, the originator of the idea, has realized this too and had to modify their philosophy accordingly.

So what does this mean for the Java language?

In Java, there is a tension between Progress and Preservation. Pushing for progress are developers who tend to overestimate the value of code and underestimate the value of working software. Pushing for preservation are the decision makers of the business who need software to not break, period. Some people would like to change the Java language more quickly, but changes can play out in unpredictable ways. A feature is not just a feature, it’s the interaction with every future feature… forever! You are really locked into your decisions if you need to preserve, which you have to do if you are successful and have a billion users.

So the designers and maintainers of the Java language have to move carefully and deliberately. According to Brian Goetz, if you don’t yet know what is the right thing to do, don’t do anything. Just don’t do the wrong thing. This gives you a chance to still do the right thing in the future! I think he makes a good argument for why you can’t have that language feature you really want. 🙂

What do you think? Is the Java language moving too slowly to compete in the modern software engineering world, or moving at the just the right speed to ensure our critical systems stay up and running?


Leave a comment

Filed under Uncategorized

Lagom Is Coming For Your Monolith

The Philly JUG had another successful meetup, this time about Lightbend’s new open source project Lagom. It was a timely presentation, as Lagom 1.0 had just been released the day before (on July 26, 2016).

The Lagom website has much better descriptions of what it’s all about, but I’ll give you my first impressions.

Lagom is a microservices framework which is designed from the ground up to be reactive, resilient, and elastic. Event Sourcing and CQRS are implemented as first class citizens, and all calls are asynchronous with first class support for streaming of request and response. It’s easy to see that Lagom is positioned as a high-throughput framework.

Besides the design for high performance, the big advantages I saw were that service registration and location are built in. The framework is designed to work with sets of services at once, which is a plus when dealing with a large project composed of many services.

The downside is that this framework is very new and there is a lot of work to be done. For instance, it only builds with SBT (not Maven or Gradle), and there is no security model.

One thing that is confusing at first is that it builds with SBT and runs with Akka and Play, implying this is a Scala framework. But the only way to use it is via a Java API, and if you dig in you’ll find there is no Scala API. So where is the Scala API? A Scala enthusiast might say “Where is it indeed?!?”  A quick conversation with the Lagom presenters revealed that – to the chagrin of the Scala base – Lightbend has decided that it wants to be involved in the enterprise space, and the opportunity for adoption there lies with producing a Java API first. So although that’s good news for Java developers, Scala developers will unfortunately have to wait.

Give Lagom a try, and let me know what you think in the comments!

1 Comment

Filed under Uncategorized

Java’s Anonymous Inner Classes: Proceed With Caution

Java’s anonymous inner classes can be useful, but you must take care when using them. In particular: A memory leak will occur if an instance of an inner class survives longer than its containing outer class because the inner class maintains a reference to its outer class.

This is not a merely academic concern, this comes up in Android development when we use inner classes to encapsulate and pass around some code, and instances of an outer class (Activities) can be constantly created and destroyed.

Concrete Example

Sometimes we want a quick Set with some elements, and can accomplish this with a one-liner:

Set<String> strings = new HashSet<String>() {{   add("a"); add("b");  }};

Admittedly there are better ways to accomplish this, but this construct is possible and is used from time to time. What is not obvious is that this is actually an instantiation of an anonymous inner class that maintains a reference to its enclosing class, and so is subject to the potential memory leak situation described above.

In full context, here is some code that may look innocent enough (contrived though it may be)

public class Application {

    public static void main(String[] args) throws IOException {

        List<Set<String>> stringList = new ArrayList<>();
        for(int i=0; i < 100; i++) {
            Generator gen = new Generator();
        System.out.print("press Enter to continue:");;

    public static class Generator {
        private byte[] lotsOfHiddenStuff = new byte[5_000_000];
        public Set<String> createStringsInnerClass() {
            Set<String> strings = new HashSet<String>() {{
                add("a"); add("b");
            return strings;

        public Set<String> createStringsNormally() {
            Set<String> strings = new HashSet<String>();
            return strings;

Analyze This

If we run the above application and monitor it with jconsole, this is what we see:

inner class after gc

It is using over 500MB of memory! This is because the Sets maintain references to their outer classes (which themselves take up a lot of memory) and it is not obvious that the outer class instances are not being properly disposed of.

After switching to use Generator.createStringsNormally(), jconsole looks like this:

non inner class after gc

It is using just over 5MB, as we would hope!


Remember that a memory leak will occur if an instance of an inner class survives longer than its containing outer class. And maybe avoid the “{{ }}” construct because it kind of masks the anonymous-inner-class-ness of your code.

Leave a comment

Filed under Uncategorized

You Don’t Have To REST

This is the last of my thoughts on REST (for the time being) after spending a few weeks doing some research and giving it some thought. See the previous two posts for more background.

What About Change?

According to Fielding: “You can’t have evolvability if clients have their controls baked into their design at deployment. Controls have to be learned on the fly. That’s what hypermedia enables.”

I didn’t quite get this at first. That’s the whole point of versions: clients DO have their controls baked into their design at deployment time, and I don’t have any power over how users of my service are going to write their software.

Yes, We Can (Change)

So I did some more research, and found another discussion with Fielding. Take a look at the discussion, especially at comment 21 (trimmed here for brevity):

“Of course the client has prior knowledge. Every protocol constitutes prior knowledge that the client must know in order to make use of that knowledge. REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them. I have no problem with systems that are true to their own architectural style.”

As Usual: Do What Works For You

I think the idea here, and it’s starting to make more sense after digesting it, is that

  1. REST may still require a priori knowledge on the side of a client to use
  2. REST is not the end-all of API structures and not appropriate to all applications

It is cool, yes, and people like it. But you don’t have to sweat versioning, or sweat following every REST constraint. You can incorporate ideas you find useful, and mention which REST constraints you follow as a shorthand for communication about the architecture of your API.

Your API should do what works for your product. You should do what works for you.

Leave a comment

Filed under Uncategorized

Top Posts of 2014

It’s the end of the year, and as people are wont to do, it’s time for The Year In Review! And before I say anything else, I want to say a special thanks to my readers who are making this blog successful! I hope that everything I write about is fun and useful for you. Let’s review this blog for the year…

My most-viewed blog post of the year, weighing in at almost 3000 views, was Setting Up HTTPS For Spring Boot. At the time (almost a year ago!) Spring Boot was still relatively early in its development, and the documentation to set up HTTPS was meager at best. But I was eager to figure that configuration out, as were, apparently, many others. Fortunately the good folks working on Spring Boot recognized that need and it is way easier now. So that particular blog post probably won’t be getting a lot of traffic in the future, but it’s good to know it helped people out.

My personal favorite post of the year was Imposter Syndrome. It’s my favorite because I feel it speaks to many people at all levels. Various people told me verbally that they felt it was very helpful to them personally and appreciated it. This speaks to the need that this post really filled, and satisfying needs and helping people is really the goal of all this in the first place.

What was your favorite post of the year? What kind of post do you feel helps you the most, that you would like to see more of next year?

Leave a comment

Filed under Uncategorized

Front End Development with Apache

The Apache web server is the single most popular web server on the planet, serving more than half of all website across all domains. Think about that for a minute. Impressive.

Not only is Apache good for serving the world, it’s also good for serving your html files in your personal development environment. Let’s set up Apache!


This post only deals with Linux, sorry Mac/Windows folks! Many modern Linux distributions come bundled with Apache, but if it is not already installed already, it is easily installable with

sudo apt-get install apache2

When installed, it is also usually set up to run automatically. We can check to see if it’s running with

ps -ef | grep apache2

If we want to control this and actually start or stop it manually, we can cycle Apache with these commands:

/etc/init.d/apache2 start
/etc/init.d/apache2 stop
/etc/init.d/apache2 restart

Serving Content

OK, Apache is up and running. How can we edit html files and have them served locally by Apache?

On the local file system, files are usually served from /var/www/
HTML files and other static content in this location are immediately accessible on port 80 at http://localhost Apache only serves static content, but can forward requests for dynamic content to an application server or servlet container with a reverse proxy.

The big step here is to link our development folder (where all of our html/css/js files are stored and being edited) to the folder where apache can serve them. We can link apache to a development folder like so

sudo ln -s /home/username/path/to/project   /var/www

That’s it!

At this point, a file like /home/username/path/to/project/index.html will be accessible via local web server as http://localhost/index.html. Apache will immediately pick up any changes and immediately serve them with a page refresh.

Happy Front-End-Developing!

Leave a comment

Filed under Uncategorized