clair077

I previously blogged on how to effectively sweep problems under the rug in Java , but even with the tactics discussed in that post, it's not always possible to hide every problem encountered when developing software. In this post, I look at tactics software developers can use to avoid direct blame for problems and issues that cannot be hidden or easily fixed. Dealing with Version Control Tools Version control (AKA source control) offers several advantages , but can also be one of the easiest ways for others to know when you've introduced a particular bug or issue. One option that seems to not be used much anymore is to avoid version control systems altogether. Without version control, it isn't as easy for someone else to find out who delivered a particular line or lines of code. Even with some sort of version control in place, there are tactics to reduce the ability of others to see when you've introduced a bad piece of code or made a change with negative repercussi...

I have occasionally run into a situation in which I have needed to introduce a new API or construct for others to try out, but have known that it might change based on others' feedback after some use of it. In such cases, I've wanted to somehow annotate the construct to warn other developers of the tentativeness of this newly added construct. There are several alternatives that I have considered in these cases. Use a third-party annotation such as Guava 's @Beta annotation. Develop a custom annotation. Use comments/Javadoc only. Use @Deprecated annotation with Javadoc @deprecated tag. Third-party Annotation The Javadoc documentation for Guava's @Beta annotation states: Signifies that a public API (public class, method or field) is subject to incompatible changes, or even removal, in a future release. An API bearing this annotation is exempt from any compatibility guarantees made by its containing library. Note that the presence of this annotation implies nothing...

It appears likely that " raw string literals " are coming to Java. JEP 326 ("Raw String Literals") started as Issue JDK-8196004 and was announced as a "new JEP candidate" on March 2. The JEP and associated issue point out that "Java remains one of a small group of contemporary programming languages that do not provide language-level support for raw strings ." The JEP and associated issue specifically reference programming languages C, C++ , C# (" verbatim "), Dart , Go , Groovy , Haskell , JavaScript , Kotlin , Perl , PHP , Python , R , Ruby , Scala and Swift and the "Unix tools" bash , grep , and sed that were "surveyed for their delimiters and use of raw and multi-line strings." JEP 326 's "Summary" provides an overview of the proposed Java raw string literals: "A raw string literal can span multiple lines of source code and does not interpret escape sequences, such as \n, or Unicode es...

There have been some interesting posts this week and in recent weeks that provide more insight into the future of Java and the JDK. JavaFX Removed from JDK with JDK 11 In the blog post " The Future of JavaFX and Other Java Client Roadmap Updates ," Oracle's Donald Smith announced that "starting with JDK 11 , Oracle is making JavaFX easier to adopt by making the technology available as a separate download, decoupled from the JDK." Smith provides a brief history of JavaFX and discusses other motivations for the decision to decouple JavaFX from the JDK. The " The Future of JavaFX and Other Java Client Roadmap Updates blog post concludes with a reference to the March 2018 Oracle whitepaper " Java Client Roadmap Update ." That referenced whitepaper describes "the Java Client" as "consist[ing] of Java Deployment (Applets and Web Start) and Java UI (Swing, AWT and JavaFX) technologies" and then "provides an overview of the ...