Interesting Links, 2017-Feb-23

Interesting Links – 14-Feb-2017

  • From DZone: Distributed Systems Done Right: Embracing the Actor Model is a reference to a webinar (ugh, “webinar”) from Lightbend on, well, the Actor Model, a way of representing distributed services. Powerful model, even if you don’t use Actors as described.
  • TwelveMonkeys is a set of additional plug-ins and extensions for Java’s ImageIO. It includes BMP, TIFF, JPEG, PNM, and a few others.
  • From user u1dzer0: Awesome Asciidoctor: Include Partial Parts from Code Samples describes how AsciiDoctor can extract, well, partial code samples from a block of code. Given Java’s verbosity (not a bad thing, but a still thing that many people don’t like), having a way to ignore code can help focus on relevance. (Also see: Dexy.)
  • JSON is the new Data Transfer Object is a short reference to JSON – Javascript Object Notation – in Java EE. JSON is becoming one of the more popular serialization formats (and I use “becoming” sarcastically – it’s very popular already). For better or for worse, it’s time. This isn’t a long article, nor is it very deep – but it touches on something that’s become more and more important over time.
  • The Deadly Diamond Of Death In Java 9’s Module System discusses a problem Java 9 has with automatic modules, when a dependency has two names but one resolution path. (Confused? Read the article – it describes it better than I do, but at much more length.)

An Aside About Scala

A mailing list that was pretty popular back in the day recently had some activity asking about Java 8. The discussion itself was a little bit interesting, including a reference here and there to other languages… like Scala. Kirk Pepperdine wrote a post that absolutely riveted Your Humble Author, and may have actually convinced him to stop bothering with Scala except where absolutely necessary. I’d like to quote it here, since Yahoo!’s web page formats things poorly sometimes:

I personally don’t feel that Scala offers any advantages over Java. If you take away the opinions on style, I’d argue that moving to Scala actually leaves you at a slight disadvantage. First, point, the JVM support for languages other than Java was quite poor until Nashorn. Nashorn was actually 2 separate projects. One to get JS running in the JVM and the second was to refactor the JVM to isolate the APIs needed to support alternate languages. Scala hasn’t been able to take advantage of those changes as of yet and I’m not sure they are interested in doing so. Next is tool support. The Java tooling chain is and remains quite broken in 8. I fear that this situation will get slightly better in 9 but then changes there will batter the tooling china quite badly. Unless the Scala people step up to the plate (and there is no evidence of them doing so to date), the dismal state of the tooling chain in Scala will continue to get worse. I currently see very little motivation for companies to invest in the work needed to improve the tooling in Scala. Though I see that this might change, every time I’ve previously thought it might get better, something in the market changes and Scala takes a hit and things don’t get better so my track record on predicting this is admittedly very poor. But then I’m predicting improvements in this area and they’ve simply not happened.
What makes me more hopeful is that I know of a couple of very big projects running in stealth that are based on Scala. These projects are big enough that they’ve really been hurt by the weak tooling story in Scala and I imagine or can only hope that they will start to look at fixing the problems they are facing. Many of these problems are baked into the JVM so to fix them, we need to further fix the JVM’s support for alternate languages. The feeling I get coming from some JVM developers is that it’s the JVM that is past EOL. Maybe Graal will be the thing that replaced HotSpot… not sure… all I know is that the JVM is past due for a huge refactoring and simply don’t see anyone.. certainly not Oracle funding that effort.

I’ve “played”with the new features and to be honest find the Scala implementations cleaner and easier to write and understand.

To say that Scala is less verbose than Java maybe true in the small but I’ve found it not to be so true in the large. Reachability in a language is very important and deserved or not, Scala as the reputation of not being so reachable and hence not so readable. IME, almost everyone one I know struggles with the readability of Scala even those that have been using it for quite some time. This is not to say that Scala code can’t be read, it’s simply that Scala code not naturally easily readable and hence people struggle with it.
I think we had the same types of problems with Smalltalk. People resisted Smalltalk for some of the same reasons and in cases where C/C++ wasn’t so desirable we saw teams jumping to Java. In this era I think the current alternative to Java is Go. The buzz around Go is more marketing and hubris than reality but it has a buzz and level of activity that feels familiar to the buzz that we say with Java in it’s early days. Just like people kicked the tires and sniff around Smalltalk and then moved on, I get the same sense here with Scala.

Java is starting to give under its own weight of patched-on features, IMHO.

On the contrary, I think that Brian has done a wonderful job integrating Streams and Lambda’s into Java. The only thing I can complain about that makes things a wee bit difficult is this aversion to mutable state. Fine if you don’t like mutable state but that streams make the mutable/immutable decision is an overreach on Brian’s part. It disallows a valid model that we need to work in. It’s different than how everything else works in the language. Streams are inherently single threaded and thus concurrent modification of state is a concern that lies outside the internals of a Lambda expression. IOW, Java != Scala in that Scala had immutability baked into (just about) everything right from the beginning. Brian did consider these points when he designed Lambdas and he opted for his bias towards immutability.. so be it.. All I know if that Lambda’s do not feel like they are patched on to me. They feel like a natural part of the language… much better than the earlier proposals that were tabled. The work on ValueTypes and type inference is also focusing on making sure that the added features do not feel like bolted on bits and that they fit naturally into the current language. Brian’s idea was to create small changes in the language that have a huge impact on your code. While I don’t agree with all of his choices I do think he’s done a brilliant job.
Regards, Kirk

Interesting Links, 2017-Feb-2

Interesting Links – 2017-jan-23

  • Is it me, or is it actually ironic that the website for Rome (a utility library for RSS) doesn’t have an associated RSS feed?
  • The Log: What every software engineer should know about real-time data’s unifying abstraction, submitted by user whaley, is an excellently written article that discusses logs in the context of distributed systems – where the log is king, whether you use it or not. It’s a fantastic summary of distributed data processing from the standpoint of the technologies that the technique rely upon.
  • What Happens When You Mix Java with a 1960 IBM Mainframe which discusses a presentation by US Government employee Marianne Berlotti. In it, she describes Java having been used to serve as an integration layer between thoroughly modern technology and mainframes from the distant past (including providing a layer between JDBC and an IMS database – and for some reason, your author has a true fondness for heirarchical databases.) Neat stuff, even though the Java applications serve as performance problems in the architecture.

EJB Injection in JSP with Java EE 7

User suexec asked ##java about accessing an EJB from a JSP template.
User dreamreal (i.e., your author) put together a simple application (rather imaginatively called “suexec-war” ) to explore the possibilities. The application was built from Adam Bien‘s minimalistic Java EE 7 Maven archetype, deployed into Wildfly 10.0.
It turns out that to the best of my understanding, injection of an EJB into a JSP is simply unsupported. The JSP can use JNDI to acquire an EJB via JNDI (see source) but the CDI injection never worked.

Next, I wrote a simple servlet (called, of all things, TestServlet.java). Here, the @EJB MyEJB ejb worked like a charm.

To render, I used the Handlebars template library just for kicks; Freemarker (or even JSP itself) would have worked just as well, but I wanted to play with something different.
The process would have been the same no matter what templating library was chosen: you’d take the values you wanted to render and store them somewhere such that the rendering engine could access them. In my case, I could have built a composite object (or even asked Handlebars to call the greet() method itself, using the ejb value) but I was aiming for simplicity rather than optimal behavior, following whaley’s “Make it work, make it pretty, make it fast” principle (from “Suffering-oriented programming” )- this is rough code, meant to serve more as a smoke test than an actual example of a great application, so I left off at “make it work,” leaving even “make it pretty” to others.
Comments and improvements welcomed.

Interesting Links – 18 Nov 2016

Today’s apparently a Microsoft edition of the interesting links! Almost everything relates back to them this time…

  • From wyvern: “The Error Model” is an article discussing… exceptions. Exception handling and the “checked or unchecked” question is (still) controversial in Java; article provides some interesting context on error handling approaches, and explains how error handling evolved in Midori (Microsoft’s experimental research OS). A fundamental decision when choosing to make your API throw a checked or unchecked exception is whether or not a particular error is considered fatal or not. This is frequently a murky question: if you’re writing a one-off script, IOException may be fatal, but for a long-lived daemon, it should be handled safely and not rethrown to the top level. While we obviously can’t use Midori’s exact approach in Java, the thought process exhibited is helpful when deciding how to structure your APIs to allow tidy error handling. The whole Midori blog series is worth reading, if you’re looking for more.
  • Microsoft has announced that it is a Linux Foundation platinum member. My, how things have changed…
  • Speaking even more of Microsoft, it looks like they’ve finally open-sourced their SQL Server JDBC driver, and it’s hosted in a Maven repository. Typically, people use jTDS instead, but this is potentially great news; it’s not clear offhand what the advantages are compared to jTDS, but the more options you have, the better, right? Plus, this is another example of Microsoft actually contributing to the larger ecosystem, something many are still not used to. Now, if they could only make SQL Server less of a pain to work with…
  • Finally, stepping off the Microsoft train, user asgs pointed out Simon Ritter‘s “20 Years Of Java Deprecation,” which details the list of accumulated deprecated classes and methods in the Java runtime library. It’s actually a really low number given Java’s maturity (maybe that’s a sign of maturity?) — and it also points out that hardly anything is actually removed, although that will change with Java 9, with a whopping six methods being removed.

Interesting Links – 15 Nov 2016

  • Big news: JRebel 7 has been released, with a new agent enabling you to change class hierarchy and interface implementations on the fly. For Spring it now also supports reconfiguring dependency injection in non-singleton scoped beans.
  • From Light Java, “JEE is dead.” Misses a lot of history – blames Java EE for WebLogic’s speed and deployment model (what about containers like Orion, which could deploy the same apps in a few seconds, and didn’t need ejbc? What about JBoss, which was free? This post ignores both, saying Java EE containers were slow and expensive), and misrepresents a question about Oracle as a statement of Oracle policy, also misunderstands some other core facets – and tries to market Light Java itself as a framework, making this a bit of a “your framework is dead! Use mine!” post, but it’s still interesting. Of course, it’s not the only microcontainer framework out there in Java…
  • From /r/java, Jadler looks like a good HTTP mocking library.
  • Also from r/java, Nudge4j is a small jar to create a web-enabled access point for a running JVM – you can effectively type code to run inside a running VM. I haven’t tried it, but what an idea.
  • jsoup 1.10.1 has been released. Lots of little changes; the biggest seems to be the ability to preserve case of tags (as an optional feature) but memory usage has also been optimized.
  • John McClean posted an interesting article: “Trampolining: a practical guide for awesome Java Developers“.

Interesting Links – 8 Nov 2017

  • From ernimril: a video! CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17” is an hour and twenty minutes of Jason Turner talking about writing a game for the Commodore 64 using, surprise, C++17 and translating to 6502 assembly. (Play at 1.25x speed to save some time – or 2x speed if you want that Brian Goetz effect.) It’s actually really fascinating to watch, and has nothing to do with Java whatsoever.
  • For Mac users, particularly on Sierra: “MacOS Sierra problems with java.net.InetAddress: getLocalHost()” documents some lookup problems on the recent MacOS update. Short form: make sure your /etc/hosts actually has your local domain name resolving to 127.0.0.1.
  • FindBugs is apparently having some problems.
  • Non-java, but useful for programmers anyway: Bulletproof Mind: 6 Techniques for Mental Resilience from the Navy SEALs. Some adult language, but it’s an excellent article and we’re all adults anyway.
  • “Docker in Production: A History of Failure” is a litany of issues with the popular virtualization technology. It’s worth reading, even if you’ve deployed Docker successfully – if only to keep track of how far there is to go.
  • From the Python world: EAFP and LBYL. In Python, apparently using the “Easier to Ask For Permission” approach yields massive performance gains; Java, like C and C++, tends to prefer LBYL, which stands for “Look Before You Leap.” Worth keeping in mind, especially as Java adds more functional programming concepts. It’d be interesting to see EAFP and LBYL contrasted well in Java – and note that EAFP tends to prefer try/catch to manual boundary checking, so maybe Java’s already there to a large degree.

Interesting Links – 4 Nov 2016

Oh, boy, a bunch of releases:

  • Guava 20, the ultra-useful third-party library for Java that virtually everyone can and should be willing to use, has been released…
  • MongoDB 3.4, the NoSQL document database used by jabavot and many others, has been released…
  • LWJGL 3.1.0, the lightweight java graphics library, has been released…

Finally, DZone publishes something I wanted to read:

  • “Everything You Want to Know About ThreadLocal Random Implementation,” a really interesting walk through a random number generator.
  • From cheeser: Whiley, “A Programming Language with Extended Static Checking.” It’s another language for the JVM with significant whitespace (blocks are determined by indentation); it also provides a way for methods and functions to guarantee at the compilation stage that return values comply with a specification. It looks neat. It’s been around since 2009, and there’s no way to tell if it has any sort of path to critical mass yet. Take a look!

Interesting Links, 31 Oct 2016 (and 25 Dec 1038)

  • kumuluzEE is “A lightweight framework for developing microservices using standard Java EE technologies and migrating existing Java EE applications to microservices.” It’s not immediately clear from the web page what makes it ideal for migrating to microservices, but there it is.
  • “Don’t Even use COUNT(*) For Primary Key Existence Checks” has some valuable performance advice, and considers multiple DB implementations while offering it.

Now for some Scala stuff:

  • “Quo Vadis, Scala?” has some considerations of the value of Scala on the larger JVM ecosystem. Turns out that Scala has more impact than some think it does, and less impact than others think. Go figure. 🙂
  • “Sbt makes me want to give up Scala” has some well-considered criticisms of the Simple Build Tool, SBT, Scala’s primary delivery mechanism. Well-written and justified; if a build tool is the primary contact point someone has with a language, and that build tool is slow and uncomfortable to use, well… that impression is going to stick with people. SBT is really powerful… and it sucks. This post walks through a lot of why.
  • From user tetero, apparently inspired by the SBT link, “Scala Collections: Why Not?” is a video presentation by Paul Phillips that feels like it’s a rant about why he’s leaving Scala: it doesn’t do things the way he wants. Sure, what he wants would be good (simplicity, accuracy, honesty, clarity) and it highlights what people see as the worst in Scala: the community’s hardheadedness about how good Scala really is. It turns out to be an anti-Scala rant, in the end, but the truth is that Scala is better than he makes it sound and just as bad as he makes it sound. Use Scala if it works for you, and don’t, if it doesn’t. (The user in question said that this video was part of what led him to Clojure. There’s nothing wrong with Clojure, but like most things, it’s not perfect and Scala’s type system oddities seem like a poor sole motivator.)