Posts

Showing posts from April, 2017

Java and Docker: Now and the Future

Sharat Chander 's blog post Official Docker Image for Oracle Java and the OpenJDK Roadmap for Containers provides a high-level overview of the "Official Docker Image for Oracle Java," an introduction to Docker and why containers like Docker are desirable, and a peek at things to come for Java on Docker . The post also provides a link to the " Docker image for Oracle Server JRE " that "is now available on Docker Store ." Chander briefly discusses attempts to set "up a consistent, reproducible environment that scales to thousands/millions of instances" for the cloud and how operating system tools and hardware virtualization have been used in this way. He then introduces Docker as another approach and provides a brief description of the benefits of Docker. Chander's post introduces Alpine Linux and quotes their web page , "Small. Simple. Secure. Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc...

Oracle JDK 9 Early Access Documentation Updated

Raymond Gallardo 's 4 April 2017 post Early Access documentation for Oracle JDK 9 has been updated today announces updates to the Oracle JDK9 Documentation Early Access page . Gallardo highlights a few of the updated sections including What's New in Oracle JDK 9 , Oracle JDK 9 Migration Guide , HotSpot Virtual Machine Garbage Collection Tuning Guide (including Garbage-First Garbage Collector Tuning ), javapackager tool for "packaging Java and JavaFX applications," and XML Catalog API . The Main Tools to Create and Build Applications section features information on jlink ( JEP 282 ), jmod (create and show contents of Project Jigsaw JMOD files), and jdeprscan (static analysis tool that scans ... for uses of deprecated API elements ). There is also information on jhsdb for obtaining "specific information from a hanging or crashed JVM." I summarized some of the tools and features being removed from the JDK with Java 9 in the post JDK 9 is the End of t...

Implications of the Presence of StringBuffer

Image
When I am working on legacy code and run across instances of StringBuffer , I typically replace them with instances of StringBuilder . Although a performance advantage can be gained from this change, I often change it in places I know will have little noticeable effect in terms of performance. I feel it's worth making the change for a variety of reasons in addition to the potential for performance benefit. There's rarely a reason to not choose StringBuilder over StringBuffer (API expectations are the most common exception) and the existence of StringBuffer in code misleads and provides a bad example to those new to Java. In the book The Pragmatic Programmer: From Journeyman to Master , Andy Hunt and David Thomas discuss "the importance of fixing the small problems in your code, the 'broken windows'." Jeff Atwood touched on this subject in the post The Broken Window Theory and it has been more recently addressed in the posts Software Rot, Entropy and the...

Use Cases for Java Enhanced Enums

In the message Enhanced Enums -- use cases , Brian Goetz writes, "We're hoping to get user feedback on the feature [ Enhanced Enums ] as it is now implemented." He states the first purpose of his message, "To get things started, here are some typical use cases where generic enums might be useful." The first of the two presented examples is refactoring com.sun.tools.javac.code.Dynamic class and its eight factory methods returning different instances of BootstrapArgument with different instances of its nested Kind enum into a single method using the dynamic enum. The second use case example of a possible application of enhanced enums that Goetz provides is command line parsing in which an enum is used to represent the data types of parameters. Vicente Romero replied to Goetz's message with two more examples of where enhanced enums might be applied: "code sharing between enum constants" and "the power of sharper typing". Goetz encou...

Java Finalizer and Java File Input/Output Streams

I often find myself noticing topics online more after I've worked directly with them or spent time learning about them. The recent Stephen Connolly ( CloudBees ) post FileInputStream / FileOutputStream Considered Harmful caught my attention because of my recent issues with Java's finalizer . In that post , the author talks about potential consequences of java.io.FileInputStream and java.io.FileOutputStream implementing overridden finalize() methods FileInputStream.finalize() and FileOutputStream.finalize() . With talk of deprecating the finalizer in JDK 9 , my perspective is that a subject I had not thought about in years is all of a sudden all around me. Connolly's post references the Hadoop JIRA HDFS-8562 ("HDFS Performance is impacted by FileInputStream Finalizer"). That JIRA was opened in June 2015 and its description includes interesting background on why the finalizer of FileInputStream causes issues for those using HDFS . This JIRA is also interes...

Java Garbage Collectors: When Will G1GC Force CMS Out?

In JEPs proposed to target JDK 9 (2017/4/4) , Mark Reinhold has written that JEP 291 ("Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector") is one of two JEPs that "have been placed into the 'Proposed to Target' state by their owners after discussion and review". If things go well for JEP 291, it will be targeted for JDK 9. Reinhold explains in this message why JEP 291 can still be targeted to JDK 9 at this relatively late date: "JEP 291 requires only a minuscule code change, to enable the proposed warning message to be issued. It's a JEP in the first place not because it's a risky change but to bring visibility to the plan to remove the CMS collector in the long term." As these sentences state, the JDK 9 targeted action is simply to mark the Concurrent Mark Sweep (CMS) collector as deprecated with the idea that it will be removed at some point "in the long term." Although G1GC is the default garbage collector for ...