Interesting Links, 14 April 2016

  • Natty is a natural language date parser written in Java. The idea is that you feed it corpora like "1984/04/02", "february twenty-eighth", or "3 days from now", and get back a list of potential matching Date objects. It is not designed to pull dates out of natural language – for that you’d want something like OpenNLP – but it might be able to help convert the natural language dates you get from OpenNLP into Java’s Date representations.
  • Scriptus is a Maven plugin that writes the Git version into build properties. It’s not entirely well-documented, but that’s what open source might be able to fix, right?
  • In When Interviews Fail, Ted Neward deconstructs a DZone article (“Can You Call Non-Static Method From a Static?“). It’s not difficult to imagine the activity – after all, this site does it to authors all the time! – but Ted’s especially good at it. In this case, he’s actually trying to dig at the purpose of an interview in the first place – and closes with “what do you really interview for?”, because if you’re interviewing for some grunt who can answer the corner cases, that’s… all you’re going to get.
  • The jOOQ blog asks: “Would We Still Criticise Checked Exceptions, If Java had a Better try-catch Syntax?” History says that yes, people would criticize Java for pretty much anything they can think of, and a few things they can’t. But in this case, it’s talking about potential syntax where the try is optional. It’s not present in a real compiler, and it does have some syntactic clarity to it – but in this author’s opinion, it’s actually hiding some pretty important information (namely, that you’re entering a try/catch block, which is pretty relevant information.)
  • From DZone: Properly Shutting Down An ExecutorService shows us a Spring bean to manage an ExecutorService shutdown. This, in itself, is a good thing. However, the interesting thing is that he wrote this because Tomcat was failing to kill the ExecutorService itself – he’s basically illustrated why doing thread management in a web application is a bad idea. Let the container manage the threads, people. (This has always been in the specification – the apps are not supposed to start threads. Ever. Use message-driven beans, or timers, or a ManagedExecutorService.)

BTW, feel free to send me Java-related (or somewhat Java-related!) links you think are worth retaining!

Byte Order Marks (BOM)

The so-called Byte Order Mark is a special unicode character that has no visual representation. The point of it, is to start your text data with this pseudocharacter; it serves as a way to identify “Endianness” – that the text is encoded with UTF-16 (Little Endian), or UTF-16 (Big Endian), or UTF-8.
Java handles it kinda weirdly; this post describes how it works.
The BOM is the bytes: 0xFE 0xFF. That means:

Encoding First bytes in the stream
UTF-16, Little Endian FF FE
UTF-16, Big Endian FE FF
UTF-8 EF BB BF

You can use these to identify streams.
In Java, the BOM is left in the stream data. So, if you for example have a UTF-8 text file that starts with a BOM, and you read it into a String, your string starts with the BOM character. It doesn’t show up when you print it, but it still ‘counts’, in the sense that the .length() call on your string counts the BOM as 1 character, and a string that starts with a BOM is not equal to one that doesn’t start with it, even if they are otherwise the same. You probably want to filter it out!!
The only exception is the special encoding UTF-16. This encoding will, if it’s there, consume the BOM and use it to configure itself as Little Endian or Big Endian. If there is no BOM, it defaults to big endian. Note that this ‘consume the BOM’ behaviour does not apply to the encodings UTF-16LE and UTF-16BE. They read the BOM as normal.
NB: Esoteric note: The unicode character 0xFF 0xFE is intentionally defined as not valid, so that the BOM can be used unambiguously as indicating the endianness of a UTF-16 stream. However, in java, reading this special invalid character does not throw an exception. You can therefore read the byte data: FF FE 41 00, which is the string "A" encoded with a BOM as UTF-16 Little Endian using the encoding UTF-16BE. This produces garbage, but does not throw an exception.

Interesting Links, 28 Mar 2016

  • The Apache Foundation has announced the release of PDFBox 2.0. Apache PDFBox allows for the “creation of new PDF documents, manipulation, rendering, signing of existing documents and the ability to extract content from documents.”
  • TechEmpower‘s Web Framework Benchmarks features Rapidoid as the fastest web framework – and Rapidoid is written in Java. It’s worth noting that the benchmark, being a benchmark, isn’t exactly “real world” – and Rapidoid doesn’t win every category – but it’s still pretty impressive to see Java, with it’s (ancient and outmoded) reputation for lack of speed, featuring so highly here.
  • AngularBeans: A Fresh New Take on AngularJS and JavaEE discusses the use of the AngularBeans project to expose functionality from CDI beans.
  • Docker Commands and Best Practices Cheat Sheet, from our friends at ZeroTurnaround, is pretty useful.
  • Functional Programming: Concepts, Idioms and Philosophy is an attempt to sum up functional programming for people who might not be familiar with the idiom. Not bad, but if you want to really dig in deep, you might check Manning‘s Functional Programming in Scala, which does a fine job exposing you not only to the idea, but its strengths and weaknesses.
  • Chronicle Map is, according to the project site, an in-memory key-value store designed for low-latency and/or multi-process applications. Notably trading, financial market applications. Looks interesting – there are plenty of distributed key/value stores around, it might be interesting to see how this one compares to things like Apache Ignite, GigaSpaces’ community edition, Oracle Coherence, Terracotta DSO, and other such candidates.
  • Markov Chains explains, well, markov chains. Basically, markov chains are a state transition method that predicts the “next state” using probabilities – you can build conversations using markov chains to predict likely responses. (For example, “vote Trump for President” has likely responses of “Gosh, why” or “heck yeah, let’s build us a wall!”) The reference link is actually a really nice explanation.

Interesting Links, 17 Mar 2016

This list was originally supposed to be published over a week ago, but life’s been busy. Sorry, folks! Happy St. Patrick’s Day!

  • A succesful Git branching model considered harmful is a response to another article, A successful Git branching model. Both models can work; which one works better for you depends on a lot of factors that are likely to be unique to your development environment. (I’ve used both: I find the “cactus model” better, personally.)
  • The Four Software Engineering Personality Types describes four personalities (surprise) in development environment: Iron Man, Michaelangelo (the sculptor, not the Teenage Mutant Ninja Turtle), Yoda, and Captain America.
    • Iron Man is a tinkerer – get 90% of the project done, really quickly.
    • Michaelangelo is the detail-oriented, deep-diving programmer – the one who spends years on a given project, working out every detail. Michaelangelos’ projects tend to be unusable until they’re done – then they’re mission-critical and awesome.
    • Yoda is a teacher (or, if you like, a puppet with a hand up his… I mean, “a teacher.”) These are the guys who know tons of stuff, and show it to others, growing an organization and providing wisdom – and a great lever when they focus on doing specific tasks.
    • Captain America is the workhorse, the one who’ll roll up his sleeves and do the unpleasant work. Like in the comics, Captain America and Iron Man go well together; Iron Man rockets through the stratosphere, flashy and quick, and Captain America cleans everything up and makes it work well.
  • The Deep Roots of Javascript Fatigue goes into the rather chaotic waters of JavaScript development. Java’s in a great place: it’s dynamic enough that the community finds new and interesting ways to develop software all the time, but it’s also stable enough that you’re not having to relearn how to do everything every year, which is the situation you find in JavaScript. Excellent writeup, even if JavaScript development isn’t quite as dire as it might sound on the surface.
  • And now into our selection of excellent DZone content: Abstraction Considered Harmful..? has a bit to say about abstractions: they’re good, but sometimes they’re leaky (and therefore can be bad). But mostly they’re useful. From the article: “Abstraction, in and of itself, is not harmful. On the contrary, it’s necessary for progress. What’s harmful is relying on impenetrable barriers to protect our precious programmers from hard problems. After all, the 21st-century engineer understands that in order to play in the sand, we all need to be comfortable getting our feet a little wet from time to time.”
  • In Anatomy of a Good Java Test, Sam Atkinson (who will show up again in this same collection of interesting links) walks through a simple recipe for good testing. It looks like it’s based around JUnit4 and Hamcrest – hardly awful choices, but also not necessarily the state of the art (or the only way to write good tests). Good baseline, though.
  • In In Defense of the Fifth Year Developer, Matthew Casperson argues for some of the abstraction discussed earlier – the point’s not very clear, but complex code laden with abstractions is easier to test and verify, because it breaks problems down into identifiable units.
  • And back to Sam Atkinson: In Constructor vs. Getter: A Better Way he discusses the use of no-operation classes to wrap optional behavior (thus: NoOpNotifier, with methods that do nothing, instead of a null that has to be checked). This simplifies the code path (a good thing), and also helps with that pesky abstraction thing. Good article.

Interesting Links, 1 Mar 2016

Happy March 1, it’s April Fool’s Day! Oh, wait…

  • From ##java itself: Anthaas_> 99.7% of people who say C++ is faster are not capable of using the highly-skilled techniques required to make that true. Now, about how he collected the data to validate that statement…
  • Gradle.org posted “Gradle vs Maven Feature Comparison“, with a description of “At long last, a comprehensive feature comparison of Maven vs Gradle that shows in detail what Build Automation requires in the Age of Continuous Delivery.” Surprisingly – or not – Gradle comes out well ahead, but most of the features sound more useful than they actually are for most users. (Until, that is, you really need that feature.)
  • Maven Testing Module describes using a Maven module solely for holding resources used for testing. It’s a module that’s included in other project modules at test scope; it has the testing frameworks and other dependencies in it, so your other modules will no longer be cluttered by test resources or artifacts. Cool idea. (For example, you can put H2 in your test project, along with some stored procedures and a test schema for it, and import them into your application for validation… just kidding, avoid stored procedures unless they’re used for every last bit of your data manipulation. And don’t do that.)
  • Heinz Kabutz is back, with “Checking HashMaps with MapClashInspector” – which walks through some of the things you should, and could, think about when designing hash codes for your objects. Highly recommended. Precis: “Java 8 HashMap has been optimized to avoid denial of service attacks with many distinct keys containing identical hash codes. Unfortunately performance might degrade if you use your own keys. In this newsletter we show a tool that you can use to inspect your HashMap and view the key distribution within the buckets.”
  • Of course the announcement propagates right after the links get published… but Flyway 4.0 has been released. This is a database migration tool – if your schema changes during development (or for any other reason), tools like Flyway are beyond valuable in terms of keeping your schema versioned. Highly recommended. The main alternative to Flyway is Liquibase – that’s not an endorsement of either project, just a plea to save your devops people by using tools designed to help them, instead of making them issue manual SQL to update a schema.

External Program Invocation in Java

Users who wish to shell out a Java program may be tempted to use Runtime.exec(), which yields a Process. They probably should use zt-exec instead. However, for those who think that using a separate library for something so “simple” is overkill, please read on.

General Notes

Java does not invoke a shell – Java uses execve(). This means that variables like ~, %HOME%, and “$JAVA_HOME” will not be expanded, nor will you be able to use shell built-ins such as cd or while. However, Java can invoke a bash or cmd shell, which can then be fed input and output. For more information on shelling out to an actual shell, please see “Invoking A Shell.”

Invocation with Runtime

Runtime is the most accessible way to execute an external process. Processes are started with Runtime.exec(String), Runtime.exec(String[]), and variants based off of Runtime.exec(String) that accept an environment variable array and an optional directory. The only method that should be used from Runtime.exec() is the String[] variant. Each part of the String[] reflects a separate argument, with the 0th being the command to be run. For the functionality of an environment variable array and a directory, please see “Invocation with ProcessBuilder“.
No variant of Runtime.exec(String) should be used because Runtime.exec(String) splits the incoming string on spaces. This may not sound bad, as the shell also splits on spaces. Take the following:

sed 's/a b/c d/gi' "My Documents/foo.txt"

A shell would interpret this as ["sed", "s/a b/c d/gi", "My Documents/foo.txt"]
Runtime.exec(String) would interpret this as: ["sed", "'s/a", "b/c", "d/gi'", "\"My", "Documents/foo.txt\""]
Always use the Runtime.exec(String[]) variant.
After performing the invocation with Runtime, please see “Using Process“.

Invocation with Process Builder

ProcessBuilder takes a String... or a List<string> as its command argument. Each part of the String[] reflects a separate argument, with the 0th being the command to be run. In order to manipulate the environment, ProcessBuilder.environment() returns a mutable Map<String,String> of environment variables. This should be modified (it is not a read-only view, as pointed out by the summary javadoc). Setting the directory can be done with a .directory() call.
Other common operations are setting standard output to a file, with redirectOutput(File), and merging standard input and standard output, with redirectErrorStream(true). Starting the process can be done by calling .start().
After performing this invocation, please see “Using Process“.

Invoking a Shell

This must be done by actually starting the shell process, and then the shell will interpret variables as normal. Done with ProcessBuilder, with the following algorithm:

List<String> parameters = new ArrayList<>();
if(System.getProperty("os.name").toLowerCase().contains("windows")) {
    parameters.add("cmd");
    parameters.add("/C");
} else {
    parameters.add("/bin/bash");
    parameters.add("-c");
}

This will start the OS-specific shell: cmd.exe on Windows, bash on other systems. Other shells may be substituted on linux by changing “bash” to the appropriate shell in the above. Those familiar with cmd may want to switch /C to /X – this is improper unless streams are redirected, with ProcessBuilder.inheritIO().

Note that Windows’ PowerShell apparently introduces some difficulties. Apparently how it is invoked is different enough that these instructions aren’t enough.

Using Process

After a Process is obtained with either of the above methods, the process has been started and will run until its natural death. However, there are several common pitfalls.
You must cull the process with Process.waitFor(), even if you do not want all input and output from the process. Otherwise, the process will exist as a zombie until the parent process (the JVM) exits.
You do not have to read the output from the process, but if you read either stdout or stderr, you must read both. On some systems, if there is output in stderr, stdout is blocked until this output is consumed. This must be done in a multithreaded fashion if these streams are not joined.
If you want to terminate the process before finishing, you can call Process.destroy() – this sends the process-equivalent of the KILL signal to the process, not TERM, so use cautiously.
Putting it all together, the following is a sample of shelling out to an external process:

import java.io.IOException;
import java.io.InputStream;
import java.util.concurrent.Executors;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Future;
import java.util.concurrent.Callable;
public class Example {
    public static void main(String[] args) throws Exception {
        ExecutorService service = Executors.newSingleThreadExecutor();
        Process p = Runtime.getRuntime().exec(new String[]{"echo", "Hello world"});
        new Thread(new ErrorConsumer(p.getErrorStream())).start();
        //java is the center of the universe
        Future output = service.submit(new OutputConsumer(p.getInputStream()));
        p.waitFor();
        System.out.println(output.get());
    }
    private static class ErrorConsumer implements Runnable {
        private final InputStream toDiscard;
        public ErrorConsumer(final InputStream toDiscard) {
            this.toDiscard = toDiscard;
        }
        @Override
        public void run() {
            byte[] buf = new byte[1024];
            try {
                while (toDiscard.read(buf) != -1) ;
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }
    private static class OutputConsumer implements Callable</string><string> {
        private final InputStream toRead;
        public OutputConsumer(final InputStream toRead) {
            this.toRead = toRead;
        }
        @Override
        public String call() throws Exception {
            StringBuilder sb = new StringBuilder();
            byte[] buf = new byte[1024];
            int read;
            while ((read = toRead.read(buf)) != -1) {
                sb.append(new String(buf, 0, read));
            }
            return sb.toString();
        }
    }
}

Editor’s note: this code may or may not work as expected. It runs, but may block on some operations – consider yourself warned, prepare to hit ^C, and use it as a point of emphasis on why you should be using zt-exec, shown immediately below…

Or, with zt-exec:

import org.zeroturnaround.exec.ProcessExecutor;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
public class Example2 {
    public static void main(String[] args)
        throws InterruptedException, TimeoutException, IOException {
        String output = new ProcessExecutor()
                .command("echo", "Hello World")
                .readOutput(true)
                .execute()
                .outputUTF8();
        System.out.println(output);
    }
}

Interesting Links, 24 Feb 2016

It’s been a while, and I’m pretty sure I missed some fun stuff, but here goes with a few things:

  • Blogger Sam Atkinson has a few here, some good, some bad. I admire his proclivity.
    • Don’t Rewrite Your Old Application; Refactor!” has some advice for people migrating to new products. It’s got some good thinking in it (rewriting is going to miss stuff, it’s going to take longer than you think) but not a lot of deep reasoning (and misses some possible points, like the resentment from the original architects which has happened to me when I tried to rewrite rather than refactor). Good post.
    • Then there’s “Kill Your Dependencies: Java/Maven Edition“, which says not to introduce dependencies until you have no other choice. That’s not terrible advice on the surface, but … it’s terrible advice. Use what you need. If wasting 3MB of disk space gets you one method from a library that saves you time to write or think or test, well, that 3MB of space is cheaper than you are. YMMV, but it’s not good advice – worth reading, though.
  • jOOQ‘s “The Mute Design Pattern” shows how you can use Java 8’s lambdas to hide checked exceptions for situations where you Just Don’t Care, leading to code like mute( () -> { doStuff(); } ) — which is actually pretty neat. Very handy to have in your coding toolbox, much like Binkley‘s “Java 8 AutoCloseable trick“.

By the way, feel free to send in stuff you think belongs here!

Programmatic Reload of Logback Configurations

Logback has the capability to programmatically and explicitly load various configurations. This can be useful when you need to adjust logging levels at runtime, and it’s actually pretty easy to do, as well.
You’d want to use something like this for a long-running application, or one that has an extensive load process: imagine a production environment, where you want to see details that would be hidden by convention.
For example, imagine you track a given method invocation, but your production logs don’t include the tracking, because it’s too verbose. But if a problem occurs, you want to be able to see the invocation. Changing the logging configuration and redeploying (or restarting) is an option, but it’s expensive and embarrassing, when all you really need to do is see more information.
The core operative code looks like this:

LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory();
context.reset();
JoranConfigurator configurator = new JoranConfigurator();
configurator.setContext(context);
configurator.doConfigure(this.getClass().getResourceAsStream("/logback.xml"));

Note that doConfigure can throw a JoranException if the configuration is invalid somehow.
I built a project (called logback-reloader) to demonstrate this. The project has a LogThing interface, which provides a simple doSomething() method along with an accessor for a Logger; the doSomething() method simply issues a series of calls to generate log entries at different levels.

public interface LogThing {
    Logger getLog();
    default void doSomething() {
        getLog().trace("trace message");
        getLog().debug("debug message");
        getLog().warn("warn message");
        getLog().info("info message");
        getLog().error("error message");
    }
}

I then created two different implementations – ‘FineLogThing’ and ‘CoarseLogThing’ which are identical except that they’re named differently (so that I can easily tune the logging levels).
It would have been easy to use a single implementation and declare two components with Spring, but then I’d be deriving the logger from the Spring name and not the package of the classes. This was just a short path to completion, not necessarily a great design.

Why Spring? Because I’m using Spring at work, and I wanted my test code to be reusable.

Then I created a custom Appender (InMemoryAppender) to provide easy access to logged information. I wanted to do this because I wanted to programmatically check that the logging levels were being changed; the idea is that my custom appender actually maintains a list of logged entries internally so I can query it later. The reason the logged entries is a static List is because Spring doesn’t maintain the Appenders – logback does – so again, this was a short path to completion, not necessarily a “great design.”
So to put it together, I created a TestNG test that had two tests in it. The only difference in the tests is that one uses “logback.xml” – the default configuration, loaded by default but explicitly included here to remove dependency on order of execution in the tests – and the other uses “logback-other.xml“. (I could have parameterized the tests as well – again, shortest path, not “great design.”)
Our default logback configuration is pretty simple, albeit slightly longer than I’d like:

<configuration>
    <appender name="MEMORY" class="com.autumncode.logger.InMemoryAppender"></appender>
    <logger name="com.autumncode.components.fine" level="TRACE"></logger>
    <logger name="com.autumncode.components.coarse" level="INFO"></logger>
    <root level="WARN">
        <appender -ref ref="MEMORY"></appender>
    </root>
</configuration>

Note that it’s appender-ref, no spaces. The Markdown implementation from this site’s software is inserting the space before the dash.

The “other” logback configuration is almost identical. The only difference is in the level for the coarse package:

<configuration>
    <appender name="MEMORY" class="com.autumncode.logger.InMemoryAppender"></appender>
    <logger name="com.autumncode.components.fine" level="TRACE"></logger>
    <logger name="com.autumncode.components.coarse" level="TRACE"></logger>
    <root level="WARN">
        <appender -ref ref="MEMORY"></appender>
    </root>
</configuration>

Here’s the first test:

@Test
public void testBaseConfiguration() throws JoranException {
    LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory();
    context.reset();
    JoranConfigurator configurator = new JoranConfigurator();
    configurator.setContext(context);
    configurator.doConfigure(this.getClass().getResourceAsStream("/logback.xml"));
    appender.reset();
    fineLogThing.doSomething();
    assertEquals(appender.getLogMessages().size(), 5);
    appender.reset();
    coarseLogThing.doSomething();
    assertEquals(appender.getLogMessages().size(), 3);
}

This verifies that the coarse logger doesn’t include as many elements as the fine logger, because the default logback configuration has a more coarse logging granularity set for its package.
The other test is almost identical, as stated: the only differences are in the logback configuration file and the number of messages the coarse logger is expected to have created.
So there you have it: a simple example of reloading logback configuration at runtime.

It’s worth noting that this isn’t “new information.” It’s actually shown pretty well at sites like “Obscured by Clarity,” for example. The only contribution here is the building of a project with running code, as well as loading the configuration from the classpath as opposed to from a filesystem.

Interesting Links, 15 Feb 2016

  • A great quote from ##java: < surial> maven/gradle are to ant, as svn is to cvs.
  • JavaCPP is a new project that attempts to bridge a gap between C++ and Java, entering the muddy waters along with JNI and JNA (as well as a few other such projects). It actually looks pretty well done – and targets Android as well as the JVM, which seems like a neat trick.
  • First in a couple from DZone: “Reactive Programming by Example: Hands-On with RxJava and Reactor” is a presentation (thus a video) of a use of RxJava. Reactive programming is one way to introduce a scalable processing model to your code, although it’s hardly the only one (and it’s not flawless, either, so if you’re one of the anti-reactive people, cool your jets, it’s okay). If you’ve been wondering what this whole reactive thing is, here’s another chance to learn.
  • Speaking of learning: “Monads: It’s OK to Feel Stupid” punts on the idea of describing what a monad is, saying that it’s okay if you don’t understand them – you can use them anyway. (Java’s streams provide a lot of access to functionality through monads, which present “computations represented as sequences of steps.”)
  • The 5 Golden Rules of Giving Awesome Customer Support” goes through some basic things to think about for, of all things, customer support. (Surprise!) The things are topics, not good headings, but one thing they didn’t point out was that people who use your open source software library are customers, too. You’ll want to read the article to get more relevance out of the headings. The points are:
    • All users are customers
    • Your customer took the time
    • Your customer is abrasive and demanding
    • Your customer doesn’t understand your product
    • Your customer doesn’t care about your workflows

Interesting Links, 9 Feb 2016

  • From Parks Computing, a short word of advice in “On Recruiting” for the movers and shakers (and those who want to be movers and shakers): “The quality of your company’s software will never exceed the quality of your company’s software developers.”
  • DZone is back with a few interesting posts: “OpenJDK – Is Now the Time?” starts by wondering is OpenJDK is reaching critical mass to the point where it should be considered instead of the standard Oracle JDK. It’s an odd post.
    • It points out that if Google had used OpenJDK instead of Oracle’s libraries, the lawsuit might not have happened (Editor’s note: it might have!). This is a good point.
    • It says that the deployment options might open up, with standard package management instead of a custom update process specific to Java. This is also a good point.
    • It points out that OpenJDK’s performance and scalability is the same as the Oracle JDK. This is… not a good point. The codebases are the same (they’re routinely synchronized: code in one will be in the other eventually.) Oracle’s JDK is effectively OpenJDK with some closed-source libraries, so Oracle’s JVM can write JPEGs natively (and some other features like that.)
    • It also points out community improvements to OpenJDK – “As open source developer’s continue to provide insight into the source code, it is likely that OpenJDK could begin to outperform the version released by Oracle.” Um… since the codebases are the same, that’s not likely to happen much at all.
  • From ##java, cheeser had a beautiful expression of reference equivalence. Someone was asking about how two references (A and B) pointing to the same object work – cheeser said, “If B is your *name*, A would be a nickname. Both of them mean you so anything said to either name or nickname both go to you.
  • Fix PATH environment variable for IntelliJ IDEA on Mac OS X” describes a way for OSX users to provide the OS’s PATH to the popular IDE. It turns out that programs installed via brew aren’t necessarily available to IDEA unless you start IDEA from the shell – which few do. It’s easy to fix; this post shows you how.
  • Another from DZone – they’re on fire! – Per-Ã…ke Minborg posted “Overview of Java’s Escape Analysis“, which discusses what escape analysis is (it’s a way of determining the visibility of an object) and what it means for performance. (If an object isn’t used outside of a method or a block, it can be allocated on the stack rather than on the JVM heap – and as fast as the heap can be in Java, the stack is much faster.)
  • Pippo is a new, very small microframework based on services. The example looks … easy enough; take a look, see what you think.
  • Yet one more from DZone: Exceptions in Java: You’re (Probably) Doing It Wrong advocates the use of RuntimeException to get rid of those pesky throws clauses and forced try/catch blocks in your Java code. It’s an argument Spring advocates, and checked exceptions aren’t part of languages like Scala… but I personally find the over-reliance on unchecked exceptions to be terrible. The core argument against check exceptions from the article: “The old argument is that (the use of checked exceptions) “forces” developers to handle exceptions properly. Anyone on a real code base knows that this does not happen, and Exceptions are routinely ignored, or printed out and then ignored. This isn’t some sign of a terrible developer; it is such a common occurrence that it is a sign that checked Exceptions are broken.” Except no, it’s such a common occurrence that it’s a sign that developers are terrible. This article was so terrible that I’ll probably write up a better response as soon as I get some time.