clair077

Because software bugs can make us appear bad as developers and lead to others thinking less of us, it is best to avoid writing bugs, to identify and fix bugs quickly, or to cover up our bugs. There are numerous blog posts and articles that discuss avoiding bugs and identifying and fixing bugs, so, in this blog post, I look at some of the most effective tactics for sweeping problems in Java code bases under the rug . Swallow Checked Exceptions Exceptions are one of the things that give us away when we've accidentally introduced bugs into the code. It's also a hassle to declare a throws clause on a method or catch a checked Exception . A solution to both problems is to simply catch the exception (even if it's a RuntimeException ) at the point it might be thrown and do nothing. That keeps the API concise and there is little one could do about the checked exception anyway. By not logging it or doing anything about it, no one even needs to know it ever happened. Comment Out...

One of the considerations when configuring Terracotta servers with tc-config.xml is the specification of health check properties between Terracotta servers (L2-L2), from clients to server (L1-L2), and from server to client (L2-L1). Terracotta checks the combination of these properties' configurations in high-availability scenarios to ensure that these combinations fall in certain ranges. This blog post demonstrates using Groovy to parse and analyze a given tc-config.xml file to determine whether Terracotta will provide a WARN-level message regarding these properties' configurations. The " About HealthChecker " section of the Terracotta 4.3.2 BigMemory Max High-Availability Guide ( PDF ) describes the purpose of the HealthChecker: "HealthChecker is a connection monitor similar to TCP keep-alive. HealthChecker functions between Terracotta server instances (in High Availability environments), and between Terracotta sever instances and clients. Using HealthChec...

Brian Goetz 's recent message Welcome to Amber! introduces Project Amber (part of OpenJDK and proposed originally in January ). Goetz opens the message with the introduction, "Welcome to Project Amber, our incubation ground for selected productivity-oriented Java language JEPs." Goetz reiterates that Project Amber is not for discussing ideas for arbitrary potential new language features, but rather is for collecting new language features for which a JDK Enhancement Proposal ( JEP ) already exists ("let's keep the focus on the specific features that have been adopted"). Three JEPs are already associated with Project Amber: JEP 286 ("Local-Variable Type Inference"), JEP 301 ("Enhanced Enums"), and JEP 302 ("Lambda Leftovers"). Goetz also writes that "the ' data classes ' and ' pattern matching ' features, already discussed publicly are intended to be adopted by Amber when we're ready to propose J...

JDK-8165641 ("Deprecate Object.finalize") has been opened to "deprecate Object.finalize() " because "finalizers are inherently problematic and their use can lead to performance issues, deadlocks, hangs, and other problematic behavior" and because "the timing of finalization is unpredictable with no guarantee that a finalizer will be called." I recently experienced and wrote about some of these nasty consequences of using Object.finalize() in the post Java's Finalizer is Still There . In the message RFR 9: 8165641 : Deprecate Object.finalize , Roger Riggs invites review and comment on the changes associated with this issue [150 new lines that include the addition of @Deprecated to java.lang.Object.finalize() and numerous additions of @SuppressWarnings("deprecation") annotations on current JDK classes' implementations of Object.finalize() methods]. The proposed addition of Javadoc @deprecated -associated text for the Obje...

When I was first learning Java and transitioning from C++ to Java, I remember being told repeatedly and frequently reading that one should not treat the Java finalizer like C++ destructors and should not count on it. The frequency and insistent nature of this advice had such effect on me that I cannot recall the last time I wrote a finalize() method and I cannot recall ever having written one in all the years I've written, read, reviewed, maintained, modified, and debugged Java code. Until recently, however, the effects of finalize() were not something I thought much about, probably because I have not used finalize() . A recent experience with finalize() has moved the effects of Java finalizers from an "academic exercise" to a real issue "in the wild." The method-level Javadoc document comment for Object.finalize() provides some interesting details on the Java finalizer. It begins by providing an overall description of the method, "Called by the garbag...