clair077

Mark Reinhold posted " JDK 11 early-access builds " on the jdk-dev mailing list in which he wrote, "JDK 11 EA builds, under both the GPL and Oracle EA licenses, are now available at http://jdk.java.net/11 ." Reinhold adds, "These builds include JEP 320 (Remove the Java EE and CORBA Modules), so they're significantly smaller (nine fewer modules, 22 fewer megabytes on Linux/x64)." In the post " Rename 'incubating' language/VM features to 'preview' " on the same jdk-dev mailing list , Alex Buckley opens with, "Members of the Expert Group for JSR 384 (Java SE 11) have indicated to the Spec Lead that they support the goal of releasing non-final language/VM features in order to gain developer feedback, but also feel that the "incubating" terminology is too confusing." Buckley differentiates between " incubating APIs " ( JEP 11 ) and "incubating language/VM features" and proposes renaming ...

Because Java-based applications are often used in a wide variety of operating systems and environments, it is not uncommon for Java developers to run into issues related to character-based input and output. Blog posts covering these issues include The Policeman's Horror: Default Locales, Default Charsets, and Default Timezones ; Annotating JDK default data ; Encoding issues: Solutions for linux and within Java apps ; Silly Java Strings ; Java: a rough guide to character encoding ; and this post with too long of a title to list here . Several enhancements have been made to Java over the years to reduce these issues, but there are still sometimes issues when the default charset is implicitly used. The book Java Puzzlers features a puzzle (Puzzle #18) describing the quirkiness related to the "vagaries of the default charset" in Java. With all of these issues related to Java's default charset, the presence of the draft JEP " Use UTF-8 as default Charset " (...

JDK 7 introduced a new method on the java.lang.System class called lineSeparator() . This method does not expect any arguments and returns a String that represents "the system-dependent line separator string." The Javadoc documentation for this method also states that System.lineSeparator() "always returns the same value - the initial value of the system property line.separator ." It further explains, "On UNIX systems, it returns " \n "; on Microsoft Windows systems it returns " \r\n "." Given that a Java developer has long been able to use System.getProperty("line.separator") to get this system-dependent line separator value, why would that same Java developer now favor using System.lineSeparator instead? JDK-8198645 ["Use System.lineSeparator() instead of getProperty("line.separator")"] provides a couple reasons for favoring System.lineSeparator() over the System.getProperty(String) approach ...

I've felt for a long time that, for most Java classes that have distinguishing attributes, developers should take the time to override Object.toString() , even if it's just with an IDE-generated implementation or using a library class such as Apache Commons Lang 's ToStringBuilder . The overloaded Objects.toString() methods also make this easier than ever if one wants to implement toString by hand. The JDK class FutureTask , introduced with J2SE 5 , finally gets its own toString() implementation in JDK 10 . Richard Nichols 's 2012 post " How to get the running tasks for a Java Executor... " highlights the omission of a toString() method on the FutureTask class. He wrote: It seems odd that the API doesn't include any way to gather info about what's happening inside the Executor , and also, there's not even a toString() implementation for wrapping classes like FutureTask which would bubble your Runnable or Callable classes' toString...

A popular question on StackOverflow.com is, " How can a Java program get its own process ID? " There are several answers associated with that question that include parsing the String returned by ManagementFactory . getRuntimeMXBean() . getName() [but that can provide an "arbitrary string"], using ProcessHandle . getPid() [ JEP 102 ], using Java Native Access (JNA), using System Information Gatherer And Reporter (SIGAR), using JavaSysMon , using Java Native Runtime - POSIX , parsing the results of jps (or jcmd ) via invocation of Runtime . getRuntime() . exec(String) , and other approaches. JDK 10 introduces perhaps the easiest approach of all for obtaining a JVM process's PID via a new method on the RuntimeMXBean . JDK-8189091 ("MBean access to the PID") introduces the RuntimeMXBean method getPid() as a default interface method with JDK 10 . That issue states the "Problem" as: "The platform MBean does not provide any API to ...

JDK 10 introduces a Javadoc tag {@summary} via issue JDK-8173425 ("Javadoc needs a new tag to specify the summary."). This new tag allows the developer to explicitly specify what portion of the Javadoc comment appears in the "summary" rather than relying on Javadoc's default treatment looking for a period and space to demarcate the end of the summary portion of the comment. JDK-8173425 states, "Currently in javadoc the summary (firstsentence) of an element is deciphered by a dot-space rule, or if required using BreakIterator." It adds that it can be confusing to know what that implicitly selected summary sentence will be. The easiest way to see {@summary} in action may be through Javadoc examples. The next code listing shows four methods with similar Javadoc comments, two using explicit {@summary} tags and two relying on implicit Javadoc summary construction. Demonstrating {@summary} in Javadoc Method Comments package dustin.examples.javadoc...

JDK-8197594 ("String#repeat") includes the following it its "Description": "A String method for repeating sequences of characters has been long requested with no follow through." Evidence of this interest in a method on the String class for repeating sequences of characters can be found in JDK-8197594 's "Issue Links" that include JDK-8055862 ["Provide a String repeat method"] and JDK-6984084 ["(str) n times repetition of character constructor for java.lang.String"]. Both of these linked issues describe motivations for having such a method in the String class. Further evidence includes online questions such as Simple way to repeat a String in java , How to repeat string “n” times in java? , What is the simple way to repeat a string in Java? , and How do you repeat a string n number of times in Java programming? Guava provides this desired behavior via its Strings.repeat(String, int) method and Apache Commons Lang ...

Mark Reinhold 's post " JDK 10: First Release Candidate " announced "no unresolved P1 bugs in build 43" and named that Build 43 the initial JDK 10 Release Candidate . The Reinhold post also points to the " JDK 10 Early-Access Builds " page which contains links to the release notes ; to the Javadoc-based API documentation ; to the "early-access, open-source builds" (OpenJDK) for Windows , Linux , macOS , and Alpine Linux ; and to the Oracle JDK builds. The following screen snapshot shows the version information provided by the OpenJDK 10 Build 43 (the text in the screen snapshot is reproduced below the image): openjdk version "10" 2018-03-20 OpenJDK Runtime Environment 18.3 (build 10+43) OpenJDK 64-Bit Server VM 18.3 (build 10+43, mixed mode) The next screen snapshot shown the version information provided by the Oracle JDK 10 Build 43 (the text in the screen snapshot is reproduced below the image): java version "10...

In the blog post " JDK 10 Release Candidate Phase ", I looked at the twelve new features that are likely to be part of JDK 10 . In this post, I look at some of the APIs that appear likely to be removed in JDK 10 and I look at some APIs proposed to be deprecated in JDK 10. The information in this post is based on the current version (2018/1/31 19:49 -0800 [a337d4f5aa79]) of " Java SE 10 (18.3) (JSR 383) Proposed Final Draft Specification - DRAFT " and, because this source document is a draft, this information is subject to change. The JDK 9 enhanced deprecation feature ( JEP 277 ) allowed several JDK APIs to be annotated with @Deprecated 's new optional forRemoval() element to be set to true , which indicates that the annotated API "is earmarked for removal in a future release." The following APIs had this enhanced deprecation applied, were marked for "removal in a future release" in JDK 9, and now JDK 10 appears to be the version in whi...

A draft JDK Enhancement Proposal ( JEP ) was created in late 2017 called " Launch Single-File Source-Code Programs " (its associated JDK issue is JDK-8192920 ). As its name suggests, this draft JEP aims to "enhance the java launcher to support running a program supplied as a single file of Java source code." In other words, as the JEP describes, if one had a typical self-contained HelloWorld.java source code code file , one could simply run java HelloWorld.java from the command line rather than needing to use javac to compile HelloWorld.java into HelloWorld.class before running it with the java launcher . JEP owner Jonathan Gibbons summarized this when he introduced the JEP on the compiler-dev mailing list : This draft JEP contains a proposal to enhance the |java| launcher to support running a program supplied as a single file of Java source code. The program will be compiled and run, without the need to explicit invoke javac, or to package up a jar file. ...

Stephen Colebourne 's post " Java 9 has six weeks to live " starts, "Java 9 is obsolete in just six weeks ." Colebourne references the Mark Reinhold blog post " Moving Java Forward Faster " and writes, "The new Java release train means that there will be a new release of Java every six months. And when the next release comes out, the previous release is obsolete." Colebourne points out that those still on Java 8 can enjoy this "current LTS (long term support) release until the next LTS release occurs (Java 11)." However, for those who have already moved to Java 9, different choices must be made and Colebourne outlines these choices at a high level. Colebourne outlines several types of dependencies that must also move forward every six months and concludes, "I think it's fair to say that it's a bold choice to use Java 9 or 10." As a reminder, the aforementioned Reinhold blog post " Moving Java Forward Faster ...

JDK 9 added some new methods to the Objects class including two static methods highlighted in this post: requireNonNullElse(T,T) and requireNonNullElseGet​(T obj,Supplier<? extends T> supplier) . Both methods make it easier to verify that a given object is not null and to provide an alternative if the provided variable turns out to be null . As such, these methods and the similar methods introduced to Objects in earlier JDK versions [ requireNonNull​(T) , requireNonNull​(T,String) , and requireNonNull​(T,Supplier<String>) ] are most likely to be used to implement guard clauses in methods. The three methods mentioned in the last paragraph that were added to Objects prior to JDK 9 did not allow a "default" value to be used when the object being tested was determined to be null . Instead, each of these three methods throws a NullPointerException when the variable passed to them is null . The two methods added to Objects in JDK 9 do allow a default to be s...

With JDK 10 about to enter its release candidate phase , it's interesting to start looking at what will come after that via JDK 11 . As of this writing, four JEP s ( JDK Enhancement Proposals ) have been officially targeted for JDK 11 (with more likely to come). This post summarizes some details about each of the four JEPs currently targeted for JDK 11. JEP 309: Dynamic Class-File Constants JEP 309 ("Dynamic Class-File Constants") "seek[s] to reduce the cost and disruption of creating new forms of materializable class-file constants, which in turn offers language designers and compiler implementors broader options for expressivity and performance." JDK bug JDK-8189199 ("Minimal ConstantDynamic support") "implement[s] JEP 309 by properly parsing and resolving new CONSTANT_Dynamic constants in JVM class files used by Hotspot" and was resolved four days ago. JEP 309 was officially targeted for JDK 11 on 14 December 2017 . JEP 318: Epsilon:...

Roughly 18 months ago , I listed three blogs that regularly (daily or weekly) posted links to (and sometimes summaries of) new Java-related blog posts and articles. These blogs were listed under the "Other Resources" section at the bottom of my post " Recent Java News - Early June 2016 ". Two of those three featured blogs would stop posting those daily/weekly posts with links and summaries by the end of that same year (2016). In this post, I introduce a blog that has come to my attention since then and that I frequently reference when I wish to quickly determine what are the most interesting things going on in the Java online community. One of the blogs that I featured in my post " Recent Java News - Early June 2016 " was Robert Diana 's " Geek Reading " series. That series ended approximately one month after my post , but had posted 1150 messages with the " Geek Reading " tag by that time. The reasons for the discontinuation of th...

Mark Reinhold 's mailing list message " JDK 10 Release Candidate Phase: Process proposal " was posted today and opens with the sentence, "Per the JDK 10 schedule , we'll enter the Release Candidate Phase next week, on Thursday, 8 February." Reinhold proposes that the JDK 10 Release Candidate Phase be enacted in the same manner as the JDK 9 Release Candidate Phase and he provides a link to the (proposed) " JDK 10 Release-Candidate Phase " page. That page outlines the proposed processes associated with the JDK 10 Release Candidate Phase with specific focus on the level of bug fixes targeted for JDK 10 . The bugs are categorized as P1 through P5 and once the JDK 10 Release Candidate Phase is entered, "all P2-P5 bugs must be left to future releases" and the focus will be on fixing "all P1 bugs that are new in JDK 10 and critical to the success of the release." At the time of this writing, the following twelve features are targeted...