In this article, we will discuss a few memory management concepts in Java with a heavy focus on the interaction between the Garbage Collector and the different reference objects available.
This is no introduction, so let us mutually agree that you have Java Heap and GC basics down. Many articles cover this topic quite well, and you might actually wonder why am covering something that is already well discussed over the www.
Since its stable release in 2016, Akka Streams is quickly becoming the de facto standard integration layer between various Streaming systems and products. Enterprises like PayPal, Intel, Samsung and Norwegian Cruise Lines see this is a game changer in terms of designing Reactive streaming applications by connecting pipelines of back-pressured asynchronous processing stages.
This comes from the Reactive Streams initiative in part, which has been long led by Lightbend and others, allowing multiple streaming libraries to interoperate with each other in a performant and resilient fashion, providing back-pressure all the way. But perhaps even more so thanks to the various integration drivers that have sprung up in the community and the Akka team—including drivers for Apache Kafka, Apache Cassandra, Streaming HTTP, Websockets, and much more.
Streams are another feature that were added with Java 8. It provides a different way of performing operations on a Collection. Rather than implementing how to perform an operation on a Collection you instead define what you want to come out of it, which follows the Functional Programming paradigm that was made available with Java 8. This is similar to how SQL queries work, you define what you want it to select, pass it some criteria to meet, press run and out pops the result of the query. You didn’t need to tell it how to go through all the records in the table, it just does it. That’s basically what using a Stream does in Java 8.
Cyclic dependencies have long been seen as a major code smell. We like to point to John Lakos as a reference [Lako1996], and a Google search about this topic will bring up valuable resources if you are unfamiliar with the negative effects. In this blog post, I take it as a given that you are interested in detecting cycles and that you agree that they should be avoided. If you see things differently, that’s fine by me – but then this blog post won’t be really interesting for you.
A number of static analysis tools exist that can detect those cycles in your code base automatically. SonarQube was one of them, until the Dependency Structure Matrix (DSM) and cycle detection was dropped with version 5.2. The DZone article by Patroklos Papapetrou (“Working with Dependencies to Eliminate Unwanted Cycles”) and the SonarQube documentation (“Cycles – Dependency Structure Matrix”) illustrate the previous functionality.
One of the most important things to do at this stage of the lifecycle of Java EE is highlight successful adoption stories at a regular cadence. The community has been doing just that for a long time, including at JavaOne. A number of these stories are curated at Zeef.
Sayo Oladeji recently agreed to share a very cool such adoption story on a mission-critical system for Eko Electricity — one of Lagos' largest utilities providers. Sayo had a number of insightful things to say about Java EE worth paying attention to. I have highlighted specific passages that really stand out.
Oracle Code 2017, a new global event series for and about open source developers, is open now for papers from technologists ready to share their coding expertise.
Oracle Code is an opportunity for developers around the world to learn to build applications using the most popular open source technologies and latest development techniques, with topic areas covering an array of technologies and practices including containers, microservices and APIs, DevOps, and open source technologies. “We’re looking for technical content about your approach to solving specific problems in the app development process,” says Bruno Borges, principal product manager for Oracle Cloud platform as a service (PaaS) and an open source evangelist.
Almost a year ago, my colleague Florian Benz wrote an article about our journey to better API documentation. Since then, we worked continuously on updates and improvements, but it was mostly inside our internal projects. But today, after open-sourcing the project and adding many cleanups and enhancements, we are proud to present the first official release of Spring Auto REST Docs — the fully automatic API documentation for Spring MVC.
Spring REST Docs project is fairly popular among spring developers. By plugging into MockMvc-based tests for API, it enables us to capture various artefacts (called snippets) about the test itself. The snippets can be as simple as showing the API call as a curl request, capturing the request and response as raw HTTP data or creating an entire table of request and response JSON fields. Then the actual documentation is just putting it all together using AsciiDoc or Markdown — essentially providing a huge amount of work for free. However, there is still some overhead which our project tries to tackle.
As promised in part one, this is the second in series on REST using Apache Wink. My earlier article was on JAX-RS (REST Web Services) using Apache Wink. You can understand how to use complex return types, such as XML using JAXB and JSON using Jackson as the stream reader or stream writer.
Firstly, set up the REST project as described in REST Using Apache Wink.
Method references are a feature of Java 8. They are effectively a subset of lambda expressions, because if a lambda expression can be used, then it might be possible to use a method reference, but not always. They can only be used to call a singular method, which obviously reduces the possible places they can be used, unless your code is written to cater for them.
It would be a good idea if you knew the notation for a method reference. In fact, you have probably already seen it assuming you read the title. If not then just look below.
Parboiled2 is a macro-based PEG parser generator written in Scala. It has become our preferred tool for creating parsers for simple grammars. It offers a fairly simple syntax for creating parsers and boasts significantly better performance over Scala combinators.
To illustrate its use, we will use this post to build a parser for a simplified version of the Slack Assisted Search.
Although PayPal has been using Spring in production for many years, as part of a goal to move towards microservices, PayPal recently introduced Spring Boot to its Java framework (known as “Raptor”), which includes RESTful services, Batch, and Message Daemon applications. Besides Spring Boot, other Spring projects are used, such as Spring framework, Spring Batch, and Spring Integration.
PayPal's Java RESTful framework provides a microservices architecture and deployment model, relying on a PaaS infrastructure on the cloud, CI, Docker, embedded containers, and Spring Boot. Additionally, many Spring Boot starters, and Spring-based features, were developed to achieve PayPal needs.
Welcome to another installment of This Week in Spring! As usual, we’ve got a lot to cover so let’s get to it: We’ve got a fresh batch of both new Spring Cloud software from the team and microservice themed S1P 2016 replays from Pieter Humphrey this week, so fasten your seat belt!
spring-rabbit-junitmodule, the ability to dynamically register queues at runtime, and numerous other niceties that — among other things — will be integrated into the imminent Spring Boot 1.5!
DiscoryClientabstraction with Marathon for Apache Mesos.
When I started programming in Java, I considered the null value my enemy and I dreaded NullPointerExceptions, which happened fairly often to me. Over time, I learned to work with it, and nowadays, I can consider my personal battle with nulls a victory. Most NPEs that I see nowadays are caused by incorrectly set up mocks during development. I can’t even remember the last time I caused an NPE in a production environment. But enough bragging, here’s my list of practices when dealing with null values.
Handling nulls can be a complicated problem on its own and therefore we should make it as clean and as obvious as possible. One very bad practice that I’ve seen in some codebases is using Objects methods, Optional classes, or even a separate method using Optional in places where a simple null check would be enough. This caused me to check where the method comes from, what it contains, and wonder what the difference is between this and direct comparison. Of course, your mileage may vary, but for me, this is significant overhead that we should avoid.
After you’ve read Part 0 about why functional programming is cool, we will take our first big steps into this topic today. In Java 8, functions became first class. Therefore, you can take functions as arguments of other functions, return functions, and store functions as objects.
As you know, code quality is important. That’s the reason we use private functions to reduce the methods one object of a class has. We don’t want to show the underlying code to others, they just have to work with some public methods on the object. But what if we want to create functions in our class that are visible to just one method and invisible to the rest of the class? With functions as first class objects, we can store the function in a single object, which can be seen just in this very one method.
Every few years, when a new version of Java is released, the speakers at JavaOne tout the new language constructs and APIs, and laud the benefits. Meanwhile, excited developers line up, eager to use the new features. It’s a rosy picture—except for the fact that most developers are charged with maintaining and enhancing existing applications, not creating new ones from scratch.
Most applications, particularly commercially sold ones, need to be backward-compatible with earlier versions of Java, which won’t support those new, whiz-bang features. And, finally, most customers and end users, particularly those in enterprises, are cautious about adopting the newly announced Java platform, preferring to wait until they’re confident that the new platform is solid.
It was announced a few days ago that JDK 9 is feature complete! Many of the "features" that made the cut are additions, but some are removals. This post looks at some of the items being removed from OpenJDK and/or Oracle's JDK with Java 9.
Part of JEP 220 ("Modular Run-Time Images") is the removal of the Java Endorsed Standards Override Mechanism ("means whereby later versions of classes and interfaces that implement Endorsed Standards or Standalone Technologies may be incorporated into the Java Platform") and the removal of the Extension Mechanism for Support of Optional Packages ("allows the Java virtual machine (VM) to use the classes of the optional extension in much the same way as the VM uses classes in the Java Platform"). Upgradeable Modules are intended to replace the endorsed-standard override mechanism in JDK 9. Regardung the extension mechanism, JEP 220 states, "The extension mechanism was introduced in JDK 1.2, which was released in 1998, but in modern times we have seen little evidence of its use." Erik Costlow's post Planning safe removal of under-used 'endorsed extension' directories provides more background on these removals and how to detect if they will affect a particular Java application.
Carrying on our series of Git Questions, this week Gary Hockin (PhpStorm Advocate) and I look at the question, "How do I make sure my GitHub fork is up to date when the open source project it forked has moved on?"
GitHub’s help does, of course, cover this question. But not everyone is comfortable working from the command line, and even those who are comfortable sometimes prefer to use the IDE if they’re already working in it.
One of the most common features for a login form is the remember me feature that allows users to be automatically signed in from a certain machine even after the HTTP session expires:
Web applications usually implement this feature by using cookies. When the user selects the remember me option and signs in, the application stores a cookie to identify the user. The next time the user requests the web application, the standard authentication process is skipped and the user is automatically logged in.
As some of you are aware, the Java EE Guardians and DZone jointly conducted a community survey to help determine Java EE 8 features prior to JavaOne 2016. You may also be aware that we shared the results of that survey with Oracle before the details of the renewed Java EE 8 scope was announced. Now is a great time to start analyzing those results a bit more.
Shortly before JavaOne 2016, after months of silent inactivity, Oracle announced that it was committed to delivering Java EE 8. While this was undoubtedly good news, the problem was that Oracle appeared to also wish to significantly shift the focus of Java EE 8 — basically unilaterally. Oracle's rationale was that so much time had passed since initial launch that the focus of Java EE 8 needed to be shifted. We thought the best way to ensure that was a wise thing to do is by asking the community directly through an open survey — the very same way the initial scope of Java EE 8 was formulated.
Netty's package structure is fantastic.
Every programmer should study it; every system should mimic it; every project manager should print it out, slap on a wall, and say to developers, "That."