Being a developer today is perhaps more exhilarating than at any other time in history. We have incredible choice when it comes to languages and frameworks, and tools like GitHub and StackOverflow have connected millions to make sharing code and expertise simple and fast. These conveniences have allowed us all to spend more of our time being creative and honing our craft, rather than fighting with source code repos and ancient languages. But in this age of global sharing and constant collaboration, one of our most important development tools, the IDE, has remained stubbornly individual and private. Why?
IDEs are very personal — perhaps to a fault. Before developers can start work on a project, we have to set up our IDE’s workspace, from configuring the project to marrying that workspace to a runtime that we download and configure separately. If the runtime is using a desktop or laptop, we may have to contend with resource limitations and can’t easily share their runtime with others (in fact the steps we took to make it work might not even work for someone else). If the runtime is shared on a Virtual Machine (VM), then it’s likely a large one that’s hard to keep synchronized with the ever-evolving codebase and dependencies. Today, when most developers contribute to many projects (often simultaneously), this setup tax becomes prohibitive — and seems to go against the sharing and collaboration that’s swept the rest of the development tooling world.
The ForkJoinPool was introduced in Java 7. Is is similar to the Executor framework but with one difference. ForkjoinPools act in a recursive way, unlike Executor threads, which splits the task and submits smaller chunks to worker Threads. ForkJoinPool takes a big task, splits it into smaller tasks, and those smaller tasks split themselves again into subtasks until each subtask is atomic or not divisible. So it works recursively.
Please see the following picture , know the ForkJoin pool concept.
I’ve been using JDK 8 for over two years now and have found the new functional style of programming it provides really powerful. The thing that really impresses me about lambda expressions and streams is how I keep finding places where I am just blown away by how simple they make things.
Let’s have a look at a recent example I found which nicely demonstrates the power of collectors, but also shows one of the limitations of streams.
In this article, I’d like to introduce about JUnit 5 Dynamic Tests feature which allows us to declare and run test cases generated at runtime.1. Static Tests vs. Dynamic Tests1.1. Static Tests
To get to know about the Dynamic Tests vs. Static Tests, let take a look at an example below. We have a very simple TranslatorEngine class which is responsible for translating text from English to French. Note that the class is implemented basically, without optimization, to make it easy to understand.
In 1974 Brian Kernighan (yes, the Unix and The C Programming Language guy) and Bill Plauger (pair programming ground-breaker and another huge C and C++ wizard) wrote The Elements of Programming Style. The 56 maxims they proposed have influenced many programming books over the past four decades, but some of the issues treated are basically procedural -- many of which are still relevant, but some of which have been abstracted away by modern (predominantly object-oriented) paradigms.
Others have since written similar manuals (for C, 24 years old; for Java, 16 years old; for C#, 10 years old). But we'd like to build on the collective experience of the software development community to update K&P's classic structured programming principles for our multi-paradigm world.
In the last post I showed how the Java 7 try-with-resources feature reduces boilerplate code, but probably more importantly how it removes errors related to unclosed resources, thereby eliminating an entire class of errors. In this post, the first in an ad-hoc series on Java 8 features, I'll show how the stream API can reduce the lines of code, but also how it can make the code more readable, maintainable, and less error-prone.
The following code is from a simple back-end service that lets us query metadata about messages flowing through various systems. It takes a map of key-value pairs and creates a Lucene query that can be submitted to SOLR to obtain results. It is primarily used by developers to verify behavior in a distributed system, and it does not support very sophisticated queries, since it only ANDs the key-value pairs together to form the query. For example, given a parameter map containing the (key, value) pairs (lastName, Smith) and (firstName, Bob), the method would generate the query "lastName:Smith AND firstName:Bob". As I said, not very sophisticated.
The new JDK™ 9 early access release contains a JDK enhancement proposal JEP 143, Improve Contended Locking, to improve the performance of contended monitors. Monitors are used by the Java synchronized statement to lock access to a code block. If the synchronized block is called by several threads, the monitor becomes contended. This can degrade performance dramatically. So let us look at the performance improvements of contended monitors.
The graphic shows the time of one method call. The lower numbers mean better performance. The test consists of 8 threads accessing a synchronized block, and all threads are accessing the same monitor. You can download the test here. The test was run on an Intel i5 4 core CPU. As we can see, JDK 9 improves the performance of contended monitors. Let us now look at a direct comparison between JDK 8 and 9.
Welcome to another installation of This Week in Spring! This week I’m in NYC (for the NYC Java SIG), Austin and San Francisco (for the Silicon Valley Spring User Group) talking to customers and doing meetups! We’ve got a lot to cover, as usual, so let’s get to it!
Recently I needed to create a regular expression to validate the format of a comma-separated list of email addresses. Just thought I’d share the result in case it is of use to anyone:\w+@\w+\.\w+(,\s*\w+@\w+\.\w+)*
Here’s an example of applying the pattern in Java:
There is clearly some differences on opinions out there and not all of them are positive for the JVM community. What does it mean to be a “leading edge” developer on the JVM. On the JVM, there are many languages like Scala, Kotlin and Clojure to name languages with real forward momentum.Are All Languages Welcome on the JVM?
So can you program in two (or more) languages at the same time? Comments like this one give me pause.
We started working on design smells many years earlier than when we started writing our book "Refactoring for Software Design Smells" (see http://www.designsmells.com). I was digging through some of the old documents and remembered that we did not cover many smells, considering them to be "uncommon smells". By "uncommon smells", I mean the ones that we (co-authors of the book) hadn't seen commonly occurring in software projects, and so did not think that they were worth discussing in detail in the book. We toyed with the idea of listing them in an appendix in the book, but dropped that idea because some readers could object the selection of the smells that formed the core of the book; for example, readers may question the choice of smells covered in the book, and may consider some of the smells mentioned as "uncommon smells" as common in their projects!.
Given the fact that it's been a couple of years since the book was published, I thought it would be interesting to see what you think about these smells. So with that, here are some of the smells that did not make it to our book. If this article generates much interest, I can post more smells in future articles!
Java web applications have come a long way since the days of servlets and Java Server Pages (JSPs). There are now many Java web frameworks for a developer to choose from, including Spring MVC, Java Server Faces, Struts, GWT, Play, and Grails. As with many other emerging technologies, an abundance of choices of web frameworks will lead to developer fatigue, the feeling of being overwhelmed by the need to keep up with the modern development world’s rapidly multiplying set of options. Interoperability tools like JNBridgePro are an ideal way to deal with many kinds of developer fatigue, particularly when the new technologies are based on Java or .NET. With JNBridgePro, you can learn a small piece of a new technology, while bridging back to other parts of your project, which use the old, familiar technology.
For example, let’s say that you’re a .NET developer maintaining an all-.NET web application using ASP.NET as the web framework. If you’re tasked with updating the application to use a modern Java web framework, you can simplify your task and avoid developer fatigue by reimplementing only the front end, while preserving the familiar .NET code in the back end.
In part one, we started to look at a new approach to defining default arguments for methods. Here we continue with a few detailed examples.Default Arguments and Functional Programming
Let me introduce you to the MaleProgrammer class, which I'll use as an example for the rest of this newsletter:
Earlier this month I attended Pivotal’s SpringOne platform conference in Las Vegas. In case you’re not familiar with it, Spring is a Java Framework “that helps development teams everywhere build simple, portable, fast and flexible JVM-based systems and applications.”
For some of you out there you may be thinking Java is old school and not relevant in in today’s modern world of digital business. Au contraire mon frere. James Governor, the D’artagnan of the analyst world, countered this belief of irrelevance in his SpringOne talk entitled, “When Web Companies grow up, the become Java Shops.”
Every day we try to find new ways to improve developer experience with IntelliJ IDEA. It may be a bugfix, a performance improvement, or a new feature (usually in this order). Today we’d like to introduce a new plugin called JVM Debugger Memory View.
The plugin extends the built-in debugger with capabilities to explore objects in the JVM heap during a debug session. The Memory View shows you the total number of objects in the heap grouped by their class name.
Java lacks a built-in way to define default arguments for methods and constructors. Over the years, several approaches have been proposed, each with its pros and cons. The most widely-known one uses method overloading, though varargs, null values, the builder pattern, and even maps have been used as well. Here we propose a new approach based on functional constructs.Functional Default ArgumentsBackground
Many languages support default arguments for methods and constructors out of the box, i.e. Scala:
In 2002, Joel Spolsky coined something he called “The Law of Leaky Abstractions.” In software, an “abstraction” hides complexity of an underlying system from those using the abstraction. Examples abound, but for a quick understanding, think of an ORM hiding from you the details of database interaction.
The Law of Leaky Abstractions states that “all non-trivial abstractions, to some degree, are leaky.” “Leaky” indicates that the abstraction fails to adequately hide its internal details. Imagine, for instance, that while modifying the objects generated by your ORM, you suddenly needed to manage the particulars of some SQL query. The abstraction leaked, forcing you to understand the details that it was supposed to hide.
Last weekend I spent an afternoon at a coffee shop with no wifi in order to solve a problem that I thought should have been simple (automatic de-duping) but which had stumped me for weeks. (I was getting false positives in a pattern I couldn't figure out.)
It took me less than an hour to solve the problem. Turns out I had been counting on one number (but really a string) being very unlikely to collide with other numbers for more than a few digits, when in fact that number -- for domain-specific reasons -- was supposed to share lots of n-grams with other numbers. Dead-simple fix, once I figured this out..and felt stupid for not noticing it before.