clair077

Google I/O 2017 had several major announcements , but one of the most interesting to me is " first-class support for Kotlin " on Android. The Kotlin blog post on this announcement discusses the benefits this brings to Kotlin users: In case you are concerned about other platforms that Kotlin supports (Kotlin/JVM for server and desktop, Kotlin/JS and Kotlin/Native), please be sure that they are as important for us as ever. Our vision here is to make Kotlin a uniform tool for end-to-end development of various applications bridging multiple platforms with the same language. ... First-class support on Android will likely bring more users to Kotlin, and we expect the community to grow significantly. This means more libraries and tools developed in/for Kotlin, more experience shared, more Kotlin job offerings, more learning materials published, and so on. We are excited to see the Kotlin ecosystem flourish! An interesting point related to and included in this announcement is me...

I have written about several command-line tools provided with the Oracle and/or OpenJDK Java Development Kits (JDKs) in the past, but I've never written exclusively about the jstat tool . The Oracle JDK 9 Documentation Early Access states that jstat is used "to monitor Java Virtual Machine (JVM) statistics." There is also a warning, "This command is experimental and unsupported." Although I quoted the JDK 9 documentation, jstat has been a part of the Sun/Oracle JDK in some form ( known at one time as jvmstat ) in Java SE 8 , Java SE 7 , Java SE 6 , and J2SE 5 . Instrumentation for the HotSpot JVM was introduced with Java 1.4.1 (only enabled when -XX:+UsePerfData was set) and has provided "always-on instrumentation" since Java 1.4.2. Much of the information that jstat provides can be gleaned from visual tools such as VisualVM , JMX and platform MBeans, garbage collection logs or via JVM options. However, jstat provides advantages when compared ...

There has been an unusual level of drama, intrigue, and politics in the world of Java over the past few weeks that culminated in this week's JSR 376 Java Platform Module System Public Review Ballot . Java modularity [including the Java Platform Module System (JPMS)] has been arguably the most significant piece of JDK 9 and so it's not surprising that it has received so much attention. In addition to the typical publicly available mailing list traffic , there have been blog posts and open letters to further advertise the contention and debate surrounding JPMS ( JSR 376 ), described as "a central component of Project Jigsaw ." The final vote was, according to the JSR #376 Java Platform Module System Public Review Ballot page , 10 votes for and 13 votes against, so "the EC has not approved this ballot." The comments that go along with the votes in the text area at the bottom of the ballot page are telling. In particular, I thought it interesting how many re...

In the blog post Applying JDK 9 @Deprecated Enhancements , I discussed additions of the optional elements (methods) forRemoval() and since() to the @Deprecated annotation in JDK 9 . I stated in that post, "The application of new JDK 9 @Deprecated methods on the Java SE API can also be instructive in how they are intended to be used." In this post, I look at the application of the enhanced @Deprecated annotation to the JDK class java.util.Observable . The class java.util.Observable has been with us almost since the beginning (since Java 1.0). As of JDK 9, however, it will be marked as deprecated. The following screen snapshot shows a portion of this class's Javadoc representation in a web browser. This is an example of a class that in the category "Deprecated With No Plans for Removal" described in my previous post . The presence of since() provides information on when it was deprecated (JDK 9) and the absence of forRemoval() indicates lack of concrete...