As 2013 starts drawing to a close, I have recently spotted several posts related to what I consider “core Java” knowledge appearing. This post is a listing of three posts and a forum with brief descriptions of these. I have two purposes in doing this: (1) to help others be aware of the existence of these fine posts and (2) to serve as a sort of glorified “bookmark” for myself when I want to find these again. These posts and forum were good enough to justify me taking the time to “print” (save) them to my hard drive as PDFs.
HotSpot JVM Flags
Kirk Pepperdine‘s “A Case Study of JVM HotSpot Flags” is an excellent resource on practical analysis and application of HotSpot’s JVM flags. Pepperdine demonstrates use of the -XX:+PrintFlagsFinal flag (I have blogged on this as well) to “identify the redundant flags by figuring out what the default settings are” so that he could remove deprecated flags and flags that simply explicitly set to the default values they would have had anyway. Pepperdine then analyzes some of the flags remaining after removal of deprecated flags and removal of flags that simply restated the defaults. He analyzes how they interact and sometimes supersede one another. Pepperdine’s concluding paragraph is well articulated advice:
I think it’s fantastic that we have a technology that is so configurable, so flexible. But this flexibility is a double edged sword and one shouldn’t just jump blindly into using all of that configurability. One thing I do know is that your applications performance does depend on how it’s configured. Messing up on even one flag can have a detrimental effect on the performance of your application and getting it wrong is far easier than getting it right. And quite often, the JVM does get it right, right out of the box.
Remote Java Debugging
Adam Bien‘s post “What are the Options of Remote Debugging…” provides a short review of key options available for debugging a remote Java process such as an application server. In this post, he references Connection and Invocation Details for greater details but provides concise summaries of available transports (dt_socket and dt_shmem for socket and Windows shared memory access respectively), suspend=y versus suspend=n, and server=y versus server=n.
Java Standard Library/Language Wish List
The question “What is a feature that the Java Standard Library desperately needs?” was recently asked on Reddit. I found the replies (72 so far) to be interesting for a variety of reasons. There were a few examples of comment authors demonstrating their superior knowledge at the expense of others as has become increasingly common in online forums, but most of the comments were insightful and provided an interesting perspective on what Java developers would like to see added to the language (in a few cases) or to the SDK (more common in replies, probably because more closely aligned with the question). Answers included all of subset of Guava, all or subset of Apache Commons, deprecation and removal of largely unused features and libraries, and properties annotations or other mechanism to replace get/set methods (or Project Lombok).
I thought that Tillerino made an insightful comment that some Java developers might not realize regarding the “commons” libraries like Apache Commons (Lang specifically) and Guava. Tillerino stated:
commons-lang per definition provides those classes which are not in the Java API. Is is not uncommon that features which commons-lang provides appear in the Java API and are then removed from commons-lang. I have used a couple of other packages and while commons-lang is probably part of 90% of all projects, the others are just way to specialized to be a part of the Java API. It’s important for Java developers to know which features are easily accessible through the commons, but I think the line has been drawn pretty well.
Recent examples of where Java SE has adopted and standardized popular libraries’ features include Java 7’s addition of the Objects class and Java 8’s addition of the Optional class, both of which have obvious similarities with classes such as Guava’s Objects class and Optional class. We see this in the Java EE world as well with one of the prime examples being the many new features of Java EE in recent years inspired by the Spring Framework.
This is a general principle that I have written about in my post Standardization: The Dangerous Relationship for Open Source. We developers should be “happy consumers” about this principle as open source seems to help refine best of breed ideas that the slower-moving standards organizations can adopt into the standards once those features’ popularity and usefulness is proven. These open source produces’ implementations allow us to use the feature before it is available in a standard implementation.
The RMI/Distributed Garbage Collection Connection
I appreciated Nikita Salnikov-Tarnovski‘s recent post RMI enforcing Full GC to run hourly for three reasons:
- The ultimate issue he addresses in this post is one I’ve run into before myself.
- I agree with his opening statement about the the bugs we are chasing down “are evolving and becoming meaner and uglier over time.”
- Salnikov-Tarnovski not only states the solution to this mean bug, but he describes his process for isolating the bug and determining its cause.
The issue that Salnikov-Tarnovski ran into had to do with the “hourly Full GC taking place” due to the setting of the HotSpot RMI property called sun.rmi.dgc.server.gcInterval. The fix for bug JDK-6200091 (“RMI gcInterval is too short by default”) lengthened the settings of sun.rmi.dgc.server.gcInterval and sun.rmi.dgc.server.gcInterval to one hour in Java SE 6. For reference, other posts of interest related to regular periodic distributed garbage collection include How we solved – GC every 1 minute on Tomcat, Analyze GC logs for Sun Hotspots, JVM 6, Unexplained System.gc() calls due to Remote Method Invocation (RMI) or explict garbage collections, and If you don’t do this JBoss will run really slowly.
I like that Salnikov-Tarnovski documented his steps in resolving the issue rather than simply stating the resolution. Although the resolution in this case was searching with Google search engine for someone else’s account of how to resolve the issue, the several steps tried before that can be illustrative to others of how to narrow down a problem and hone in on a defect. One of the greatest questions I’ve been asked on this blog was when a person left a comment asking how I found the fix that I had documented in that post. By the time I posted and read this comment, I had forgotten the steps I had used to resolve that particularly tricky issue and so could not really help.
In Salnikov-Tarnovski’s case in this post, about all that was provided was “sometimes the system is slow” (I’m sure many of us have been on the receiving end of that more than once). The steps used to diagnose the issue included monitoring response times to see a regular pattern, ruling out the usual suspects in cases like these, increasing logging output, and finally resorting to Google.
Conclusion
There are thousands of new posts each week detailing a wide variety of new technologies and tools for the software developer. These are valuable posts and help all of us to learn new things, but I also appreciate posts and forums that provide focus on “core concepts.” While core concepts may not be as exciting or flashy as new things, core concepts help us to better deliver and manage software for our customers’ benefit.
