# Java 9 Published articles for Java 9. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How to Generate Package Private Code with jOOQ's Code Generator DevFeed: [How to Generate Package Private Code with jOOQ's Code Generator]() Original publisher: [Read original article]() Author: lukaseder Published: 2023-06-28T15:54:18Z Content type: tutorial Language: en Sources: [jOOQ]() Topics: [Code](), [Java](), [Code generation](), [configuration](), [Java 9]() Tags: [code](), [code-generation](), [code-generator](), [compilation](), [configuration](), [how-to](), [java](), [java-9](), [jooq](), [jooq-code-generator](), [jooq-in-use](), [modularity](), [package-private](), [visibility](), [visibility-modifier]() ### AI overview This tutorial explains Java package-private visibility and shows how to configure jOOQ's code generator to generate package-private types. The approach can help keep generated jOOQ implementation details from leaking into client code. ### Source excerpt Java's package private visibility is an underrated feature. When you omit any visibility modifier in Java, then the default (for most objects) is package private, i.e. the object is visible only to types in the same package: In fact, a compilation unit (the .java file) can contain multiple such classes. You don't have to create ... Continue reading How to Generate Package Private Code with jOOQ's Code Generator -> ## Java Object Equivalence DevFeed: [Java Object Equivalence]() Original publisher: [Read original article]() Author: Bruce Eckel Published: 2021-02-04T00:00:00Z Content type: tutorial Language: en Sources: [Bruce Eckel - Computing Thoughts]() Topics: [Java](), [Testing](), [Java 9]() Tags: [code](), [floating-point](), [java](), [java-8](), [java-9](), [object](), [testing](), [time]() ### AI overview An update to the "Testing Object Equivalence" subsection in On Java 8 explains how Java's == and != operators compare object references, why boxed integer comparisons can vary by value range and object creation method, and why equals() should be used for object value comparisons. It also discusses related issues with floating-point comparisons and notes the deprecation of Integer(int) in Java 9 and later. ### Source excerpt This is an update to the subsection "Testing Object Equivalence" in the "Operators" chapter of On Java 8. This will appear in the book in its next update. The relational operators == and != work with all objects, but their results can be confusing: // operators/Equivalence.java public class Equivalence { static void show(String desc, Integer n1, Integer n2) { System.out.println(desc + ":"); System.out.printf( "%d==%d %b %b%n", n1, n2, n1 == n2, n1. ## ByteBuffer and the Dreaded NoSuchMethodError DevFeed: [ByteBuffer and the Dreaded NoSuchMethodError]() Original publisher: [Read original article]() Published: 2020-12-21T16:45:00Z Content type: article Language: en Sources: [Gunnar Morling]() Topics: [Java](), [Compiler](), [Apache Pulsar](), [Eclipse Vert.x]() Tags: [apache](), [compatibility](), [compiler](), [debezium](), [issue](), [java](), [java-9]() ### AI overview This article explains why Java code compiled with JDK 9 or newer can trigger NoSuchMethodError when run on Java 8. Covariant return types cause the compiler to record a method signature that is unavailable in Java 8, creating a compatibility problem for projects that target older Java runtimes. ### Source excerpt Table of Contents How to Prevent This Situation? The other day, a user in the Debezium community reported an interesting issue; They were using Debezium with Java 1.8 and got an odd NoSuchMethodError: ## -XX:MaxRAMPercentage is not what I wished for DevFeed: [-XX:MaxRAMPercentage is not what I wished for]() Original publisher: [Read original article]() Author: brice.dutheil@gmail.com (Brice Dutheil) Published: 2020-10-26T23:02:29Z Content type: opinion Language: en Sources: [The Coffee Workshop]() Topics: [Java](), [Java 9](), [openjdk](), [Docker](), [Kubernetes](), [Google]() Tags: [docker](), [gke](), [java](), [java-8](), [java-9](), [jdk](), [jvm](), [kubernetes](), [openjdk](), [production]() ### AI overview The author reflects on Java container memory support and argues that -XX:MaxRAMPercentage did not behave as expected for an application running in Docker containers on Kubernetes. The account links the issue to Java heap sizing, native memory, and production experiences that culminated in out-of-memory kills. ### Source excerpt This entry has been marinating for most of the year 2020. I should have published this opinion way earlier maybe end of 2019, but it took me time to realise I should split a bigger piece in smaller articles that hopefully made sense on their own. ## Moving Away from Java FX DevFeed: [Moving Away from Java FX]() Original publisher: [Read original article]() Author: Shai Almog Published: 2020-06-18T00:00:00Z Content type: article Language: en Sources: [CodeName One]() Topics: [JavaFX](), [Java](), [Chromium](), [Swing]() Tags: [browser](), [chromium](), [compatibility](), [desktop](), [install](), [java](), [java-8](), [java-9](), [jdk](), [jvm](), [openjdk]() ### AI overview Codename One is considering replacing its JavaFX-based simulator and desktop-port implementation with JCEF, because JavaFX installation and compatibility cause support problems and its browser widget has limited web standards support and stability. The existing JavaFX implementation will remain temporarily while JCEF is evaluated. ### Source excerpt Codename One itself never depended on JavaFX. This kept us small and performant. However, we need JavaFX to support HTML and media in the simulator and on the desktop ports. This was a choice we made easily back in the Java 8 days. JavaFX was integrated into the official JDK and this was an easy choice to make. Then Java 9 came out and everything broke. Most JVMs ship without JavaFX now and downloading it dynamically for the simulator is error prone to say the least. Even I had problems setting up our environment on some foreign machines. Every day we need to deal with multiple support queries and people who have issues with VM configuration. 99% are due to the pain of dealing with JavaFX installation on top of the VM. ## Using Java 13 Text Blocks (Only) for Your Tests DevFeed: [Using Java 13 Text Blocks (Only) for Your Tests]() Original publisher: [Read original article]() Published: 2020-01-13T16:30:00Z Content type: tutorial Language: en Sources: [Gunnar Morling]() Topics: [Java](), [Code](), [configuration]() Tags: [building](), [java](), [java-9](), [language](), [tests]() ### AI overview This tutorial explains how to use Java 13 text blocks in test code while keeping the main code compatible with older Java versions. It discusses preview language features, release cadence, and the importance of Java 8 compatibility for libraries. ### Source excerpt Table of Contents An Example Configuration Should You Do This? When Java 9 was introduced in 2017, it was the last major version published under the old release scheme. Since then, a six month release cadence has been adopted. This means developers don't have to wait years for new APIs and language features, but they can get their hands onto the latest additions twice a year. In this post I'd like to describe how you can try out new language features such as Java 13 text blocks in the test code of your project, while keeping your main code still compatible with older Java versions. ## Java release chains - Splitting features from security DevFeed: [Java release chains - Splitting features from security]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2018-09-20T10:10:00Z Content type: article Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [releases](), [Java 9]() Tags: [java](), [java-8](), [java-9](), [jdk](), [jvm](), [new-features](), [openjdk](), [release](), [releases](), [security]() ### AI overview This article explains how Java release cycles separate feature releases from security releases. It describes the six-month release cadence introduced with Java 9, contrasts it with Java 8 update numbering, and gives examples of feature and security changes in Java 8. ### Source excerpt There is now a Java release every 6 months - March and September. It started with Java 9 and we're about to get Java 11. But should you jump on the release train? To answer that, we need to look at how Java's release chains are being split. Looking back at Java 8 In the olden days life was simple. There was a "major" Java release every few years and it contained lots of new features, for example Java 5, 6, 7 and 8. Each major release included new JDK methods, new JDK classes, deprecations, new JVM features and new language features. However, life wasn't actually as simple as it seemed. Looking at Java 8, once it was released there was a regular frequency of "update" releases. The most well-known of these were 8u20, 8u40 and 8u60. But there were also many others - 8u5, 8u11, 8u25, 8u31, 8u45, 8u51, 8u65, 8u66, 8u71, 8u73, 8u74, 8u77, etc. So, what was going on? Well the plan was quite simple, just not that widely known. 8u20, 8u40, 8u60 and so on were "feature" releases, while all the rest were security patch releases. See the full table. 8u20, 8u40, 8u60 and so on were "feature" releases - every six months 8u5, 8u11, 8u25, 8u31 and so on were "security" releases - every three months, plus additional emergency releases If you look closely, you can see a pattern. The first security release after a feature release had a number 5 greater (8u25 is 5 greater than 8u20). The second security release after a feature release had a number 11 greater (8u31 is 11 greater than 8u20). This left space for emergency security releases like 8u66. So what was a Java 8 feature release? Well a feature release was allowed to contain anything that didn't impact the Java SE specification. So, JVM or tool enhancements might be allowed, particularly if covered by a flag that was disabled by default. For example, the "endorsed-standards override mechanism and the extension mechanism" was deprecated in 8u40, 8u60 added a new IBM character set, and 8u181 removed the Derby database from the JDK b ## From Java 8 to Java 11 DevFeed: [From Java 8 to Java 11]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2018-09-06T10:01:00Z Content type: tutorial Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [upgrade](), [Java 9](), [modules](), [Maven](), [Open Source]() Tags: [advice](), [java](), [java-8](), [java-9](), [jdk](), [library](), [module](), [modules](), [open-source](), [upgrade]() ### AI overview This article offers notes and advice for upgrading applications from Java 8 to Java 11. It explains that applications can usually continue running on the classpath without adopting modules, discusses removed Java EE, CORBA, and Java WebStart components, and describes warnings for restricted JDK APIs such as sun.misc.Unsafe. ### Source excerpt Moving from Java 8 to Java 11 is trickier than most upgrades. Here are a few of my notes on the process. (And here are a couple of other blogs - Benjamin Winterberg and Leonardo Zanivan.) Modules Java 9 introduced one of the largest changes in the history of Java - modules. Much has been said on the topic, by me and others. A key point is sometimes forgotten however: You do not have to modularise your code to upgrade to Java 11. In most cases, code running on the classpath will continue to run on Java 9 and later where modules are completely ignored. This is terrible for library authors, but great for application developers. So my advice is to ignore modules as much as you can when upgrading to Java 11. Turning your application into Java modules may be a useful thing to consider in a few years time when open source dependencies really start to adopt modules. Right now, attempting to modularise is just painful as few dependencies are modules. (The main reason I've found to modularise your application is to be able to use jlink to shrink the size of the JDK. But in my opinion, you don't need to fully modularise to do this - just create a single jar-with-dependencies with a simple no-requires no-exports module-info.) Deleted parts of the JDK Some parts of the JDK have been removed. These were parts of Java EE and Corba that no longer fitted well with the JDK, or could be maintained elsewhere. If you use Corba then there is little anyone can do to help you. However, if you use the Java EE modules then the fix for the deleted code should be simple in most cases. Just add the appropriate Maven jars. On the Java client side, things are more tricky with the removal of Java WebStart. Consider using Getdown or Update4J instead. Unsafe and friends Sun and Oracle have been telling developers for years not to use sun.misc.Unsafe and other sharp-edge JDK APIs. For a long time, Java 9 was to be the release where those classes disappeared. But this never actually happened. What you ## Java is still available at zero-cost DevFeed: [Java is still available at zero-cost]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2018-08-28T06:53:00Z Content type: opinion Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [openjdk](), [Java 9](), [releases]() Tags: [java](), [java-9](), [jdk](), [open-source](), [openjdk](), [release](), [releases]() ### AI overview The article explains how Java's six-month release cycle changed Oracle's free security-update and long-term-support policies, especially from Java 11 onward. It also describes OpenJDK-based alternatives and the factors developers should consider when choosing a JDK build. ### Source excerpt The Java ecosystem has always been built on a high quality $free (zero-cost) JDK available from Oracle, and previously Sun. This is as true today as it always has been - but the new six-monthly release cycle does mean some big changes are happening. Six-monthly releases Java now has a release every six months, something which greatly impacts how each version is supported. By support, I mean the provision of update releases with security patches and important bug fixes. Up to and including Java 8, $free security updates were provided for many years. Certainly up to and beyond the launch of the next version. With Java 9 and the six-monthly release cycle, this $free support is now much more tightly controlled. In fact, Oracle will not be providing $free long-term support (LTS) for any single Java version at all from Java 11 onwards. VersionRelease dateEnd of $free updates from Oracle Java 8March 2014January 2019 (for commercial use) Java 9Sept 2017March 2018 Java 10March 2018Sept 2018 Java 11Sept 2018March 2019 (might be extended, see below) Java 12March 2019Sept 2019 The idea here is simple. Oracle wants to focus its energy on moving Java forward with the cost of long-term support directly paid for by customers (instead of giving it away for $free). To do this, they need developers to continually upgrade their version of Java, moving version every six months (and picking up the patch releases in-between). Of course, for most development shops, such rapid upgrade is not feasible. But Java is now developed as OpenJDK, which means that Oracle's support dates are not the only ones to consider. OpenJDK A key point to grasp is that most JDK builds in the world are based on the open source OpenJDK project. The Oracle JDK is merely one of many builds that are based on the OpenJDK codebase. While it used to be the case that Oracle had additional extras in their JDK, as of Java 11 this is no longer the case. Many other vendors also provide builds based on the OpenJDK codebase. ## Upgrading to Eclipse Photon DevFeed: [Upgrading to Eclipse Photon]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2018-07-09T09:51:00Z Content type: tutorial Language: en Sources: [Stephen Colebourne]() Topics: [ide](), [Java](), [Java 9](), [modules](), [Maven](), [Code review](), [Test coverage](), [GitHub]() Tags: [code-coverage](), [code-quality](), [eclipse](), [github](), [how-to](), [ide](), [install](), [installations](), [java](), [java-9](), [maven-plugin](), [modules](), [plugins](), [update](), [zip]() ### AI overview A personal guide to upgrading to Eclipse Photon, covering its improved separation of test and main classpaths, support for Java 9 modules and Java 10 local variable type inference, JUnit 5, and code coverage assistance. It also describes installation options and a locally built GEBIT fork of the m2e-code-quality plugin. ### Source excerpt I use Eclipse as my Java IDE. And the new release, Photon is now out. Photon is a large release, with lots of new features. The most important is the separation of the test and main classpaths, which has always been a point of pain in the IDE. Now it just works as you would expect, and the Maven plugin M2E correctly sets it up: Note the darker colour of the src/test classpath elements. Support for Java 9 (modules) and Java 10 (local variable type inferenece) is also present, ready for Java 11 in September. You can also use JUnit 5. It even tries to help you reach 100% code coverage! All in all, I feel this is a release where upgrading will make a difference to everyday coding. I've upgraded my own Eclipse installations, and it all went pretty well. You can either start from a clean install (I prefer the basic IDE without plugins so I can choose which ones to add). Or you can add Photon as an update site, and let Eclipse update itself. One problem I had was the plugin that connects Maven (M2E) to Checkstyle (Eclipse-CS), known as m2e-code-quality. Fortunately, the team at GEBIT have been maintaining a fork of the original plugin. However, they don't release it in binary form. As such, I had to build the plugin locally (no big deal - its a simple build). To simplify the process however, I've created a repository on GitHub with my Eclipse setup files, and a binary zip of the GEBIT forked plugin. To use just the m2e-code-quality GEBIT fork, download the zip file and add it as an update site. Here are some instructions. Thank you Eclipse team for a great release! PS. I won't be answering "how to" questions about upgrading Eclipse or the eclipse-setup repository. There are plenty of other places to ask questions, such as Stack Overflow or the Eclipse Forums. ## Clean code with Java 9 at GeeCON DevFeed: [Clean code with Java 9 at GeeCON]() Original publisher: [Read original article]() Published: 2018-05-17T20:05:44Z Content type: opinion Language: en Sources: [Miro Cupak]() Topics: [Java](), [Code](), [HTTP]() Tags: [clean-code](), [conference](), [geecon](), [interfaces](), [java](), [java-9](), [jvm](), [new-features](), [optional](), [speaking](), [talk]() ### AI overview A personal report from GeeCON describes a live demo on writing cleaner code with Java 9. The talk covers JShell and several JDK 9 features, including collection factory methods, private interface methods, Stream API enhancements, Optional updates, StackWalker, and an HTTP/2 client. ### Source excerpt Last week, I was fortunate enough to attend GeeCON. GeeCON is a well-known conference in the JVM world and this year marked its 10th anniversary. More than 1200 people came to see over 80 sessions from more than 70 speakers distributed across 4 tracks over 3 days in Krakow, Poland. This was my first time attending GeeCON. In retrospect,... ## Java 9 at Java With The Best 2018 DevFeed: [Java 9 at Java With The Best 2018]() Original publisher: [Read original article]() Published: 2018-04-25T11:20:26Z Content type: article Language: en Sources: [Miro Cupak]() Topics: [Java](), [IntelliJ IDEA]() Tags: [conference](), [developer](), [java](), [java-9](), [java-with-the-best](), [speaking](), [talk]() ### AI overview The article recounts a talk about Java 9 at the online Java With The Best 2018 conference. The session explored JShell, updates to existing APIs, and new APIs including the HTTP/2 client. It also describes the platform's limitations for screen sharing, audience interaction, laptop use, and live coding. ### Source excerpt Java With The Best is a new Java conference in a series of developer conferences powered by BeMyApp. There are 2 main properties that differentiate this event from other conferences you may have attended - everything takes place online, without a physical venue, and attendees can book virtual 1-1 sessions with the speakers. The event featured 58... ## JPMS modules for library developers - negative benefits DevFeed: [JPMS modules for library developers - negative benefits]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2018-03-22T10:52:00Z Content type: article Language: en Sources: [Stephen Colebourne]() Topics: [Java 9](), [modules](), [Open Source](), [.env]() Tags: [developers](), [java](), [java-9](), [java9](), [lts](), [modular](), [modules](), [open-source]() ### AI overview The article examines Java 9's Java Platform Module System (JPMS) from the perspective of open source library developers. It argues that JPMS can provide negative benefits because libraries must balance modularization against compatibility with Java 8 and the adoption risks of moving to newer Java baselines. ### Source excerpt Java 9 introduced a major new feature - JPMS, the Java Platform Module System. After six months I've come to the conclusion that JPMS currently offers "negative benefits" to open source library developers. Read on to understand why. Modules for library developers Java 8 is probably the most successful Java release ever. It is widely used and widely liked. As such, almost all open source libraries run on Java 8 (as library authors want their code to be used!). Some libraries with a long history also still run on older versions. Joda-Convert has a Java 6 baseline, while Joda-Time has a Java 5 baseline. Others have a Java 8 baseline, such as ThreeTen-Extra. Java 9 was released in September 2017, but it is not a release that will be supported for a number of years. Instead, it had a lifetime of six months and is now obsolete because Java 10 is out. And in six months time Java 11 will be out making Java 10 obsolete, and so on. While most releases last six months, some are luckier. Java 11 will be a "long term support" (LTS) release with security and bug support for a few years (Java 8 is also an LTS release). Thus, even though Java 10 is out, Java 8 is still the sensible Java version for open source library developers to target right now because it is the current LTS release. But what happens when Java 11 comes out? Since Java 8 will be unsupported relatively soon after Java 11 is released, you'd think that the sensible baseline would be 11. Unfortunately I believe many companies will be sticking with Java 8 for a long time. An aggressive open source project might move quickly to a Java 11 baseline, but doing so would be a risky strategy for adoption. The module-path Before discussing the JPMS options for open source library developers, it is important to cover the distinction between the class-path and the module-path. The class-path that we all know and love is still present in Java 9+, and it mostly works in the same way. The module-path is new. When a jar file is on ## Exploring Java 9 at Index San Francisco 2018 DevFeed: [Exploring Java 9 at Index San Francisco 2018]() Original publisher: [Read original article]() Published: 2018-02-27T11:20:26Z Content type: article Language: en Sources: [Miro Cupak]() Topics: [Java 9](), [Java](), [Programming](), [Development]() Tags: [apis](), [coding](), [conference](), [developer](), [development](), [event](), [index](), [java](), [java-9](), [languages](), [programming](), [programming-languages](), [software-development](), [speaking](), [talk](), [talks](), [updates]() ### AI overview A post summarizes the author's "Exploring Java 9 with REPL" session at Index Developer Conference in San Francisco in 2018. The live-coding session introduced updates to existing Java APIs and new Java 9 APIs, including JShell, Stackwalker, ProcessHandle, and an HTTP/2 client. ### Source excerpt Index Developer Conference is a new conference organized by IBM to promote software development as a craft. The event took place at the Moscone Center, San Francisco, a popular software conference venue, on February 20-22, 2018. This was my first conference of the year and I was very excited about being invited to give 2 talks in 2... ## Java's six-month release cycle makes Java 9 obsolete after Java 10 is released DevFeed: [Java's six-month release cycle makes Java 9 obsolete after Java 10 is released]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2018-02-05T13:10:00Z Content type: opinion Language: en Sources: [Stephen Colebourne]() Topics: [Java 9](), [Java](), [upgrade](), [toolchain]() Tags: [dependencies](), [gradle](), [java](), [java-9](), [java9](), [lts](), [releases](), [toolchain](), [upgrade]() ### AI overview The article explains that Java's six-month release cycle makes Java 9 obsolete when Java 10 is released, ending Oracle security updates for the previous release. It outlines staying on Java 8 LTS, upgrading rapidly through releases, or accepting the security-update tradeoff, and emphasizes testing the full toolchain in advance. ### Source excerpt Java 9 is obsolete in just six weeks (20th March 2018). What? You haven't upgraded yet? Well, Java 10 is only going to last six months before it is obsolete too. Update 2018-03-20: Java 10 is released. Java 9 is obsolete. Release train impact 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. What do I mean by obsolete? In practical terms it means that there are no more security updates from Oracle. (Theoretically, the OpenJDK community could release security updates, but there is no sign of this yet). And since you don't want to run your software without the latest security updates, you are expected to upgrade to Java 10 as soon as it is released. As a user of Java, here are three possible ways to approach the release train: Stay on Java 8, the current LTS (long term support) release, until the next LTS release occurs (Java 11) Move from Java 9 to Java 10 to Java 11, making sure you update rapidly to get the security updates Stay on Java 9 (or Java 10) and don't worry about security updates If you have already moved to Java 9, you have effectively committed to option 2 or 3. If you care about security updates, you need to be prepared to switch to Java 10 shortly after it is release on 20th March. To do this, you probably should be testing with a Java 10 pre-release now. If you find that to be a challenge, you have to stop caring about security, or consider going back to Java 8 LTS. However you look at it, being on the release train is a big commitment. Will your dependencies work on the next version? Will your IDE be ready? Will your build tool (Maven, Gradle etc.) be ready? Will your other tools (spotbugs, checkstyle, PMD etc.) be ready? How fast are you going to be able to update when the release you are on is obsolete? Lots to consider. And given the number of external tools/dependencies to consider, I think its fair to say that its a bold choice to us ## My talk for the Singapore Java User Group DevFeed: [My talk for the Singapore Java User Group]() Original publisher: [Read original article]() Published: 2018-01-06T11:20:26Z Content type: article Language: en Sources: [Miro Cupak]() Topics: [Java](), [HTTP](), [Process]() Tags: [deep-dive](), [demo](), [event](), [examples](), [java](), [java-9](), [singajug](), [speaking](), [talk]() ### AI overview The author recounts presenting "Java 9, Episode 2" at the Singapore Java User Group's first 2018 event. The fast-paced live demo explored lesser-known Java 9 APIs, including Collections, Stream, CompletableFuture, StackWalker, Process, the HTTP/2 client, and JShell, with slides, a recording, and JShell history made available afterward. ### Source excerpt Huge thanks to the Singapore Java User Group for having me as a speaker at their first event of 2018, Pivotal for hosting the event and providing pizza and drinks, as well as all the attendees for finding the time, all the positive feedback and good questions! Despite taking place early in the new year, the event... ## Java 9 Flow API: Multicasting via a Processor DevFeed: [Java 9 Flow API: Multicasting via a Processor]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-12-14T13:20:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [Java](), [Java 9](), [reactive](), [Streams](), [implementation](), [API]() Tags: [backpressure](), [cancellation](), [concurrency](), [flow](), [flow-api](), [java](), [java-9](), [jdk](), [multicast](), [processor](), [reactive](), [reactive-streams](), [streams](), [subscriber](), [subscription](), [tck]() ### AI overview This tutorial explains how Java 9 Flow API processors can multicast elements from a single upstream source to multiple consumers. It focuses on coordinating subscriber demand, backpressure, dynamic subscription, and cancellation, and introduces MulticastProcessor as the intermediate solution. ### Source excerpt Introduction There are situations when the same elements of a source should be dispatched to multiple consumers. Certainly, if the source supports multiple subscribers and is deterministic (such as our previous async range), one can just instantiate the flow multiple times. However, if the source doesn't support multiple subscribers or each subscription ends up being unique and/or non-deterministic, that simple approach doesn't work anymore. We need a way to have a single realization of the (upstream) source yet allow multiple consumers. Since we are dealing with Flow.Publishers that require backpressure management, such intermediate solution has to coordinate requests from its Flow.Subscribers in addition to handling the dynamic subscription and unsubscription (cancellation) of said Flow.Subscribers while the flow is active. Enter, MulticastProcessor. Flow.Processor recap What is a Processor? By definition, it is a combination of a Flow.Publisher and a Flow.Subscriber, i.e., it can act as a source and can be subscribed to via subscribe() as well as the processor itself can be used with somebody else's Flow.Publisher.subscribe(). It has a mixed history as the idea comes from the original Observer pattern (i.e., java.util.Observable) and Rx.NET's Subject that allows dispatching signals to multiple Observers in an imperative (and synchronous) fashion. The Flow.Processor in Java 9 defines two type arguments, one for its input side (Flow.Subscriber) and one for its output side (Flow.Publisher). The idea behind it was that a Flow.Processor can act as a transformation step between an upstream and a downstream. However, such transformation often mandates the Flow.Processor implementation only accepts a single Flow.Subscriber during its entire lifetime. Since the implementation has to follow the Reactive Streams specification nonetheless, this adds a lot of overhead to the flow. As demonstrated in previous posts, when a flow is realized, there are only one subscriber per st ## Java 9: Updates to Optional DevFeed: [Java 9: Updates to Optional]() Original publisher: [Read original article]() Published: 2017-11-11T17:25:19Z Content type: tutorial Language: en Sources: [Miro Cupak]() Topics: [Java](), [Streams]() Tags: [java](), [java-9](), [jdk](), [streams](), [updates]() ### AI overview A tutorial on Java 9 updates to Optional. It explains the methods added in JDK 9 for handling absent values, including actions for empty values, supplying fallback Optionals, unwrapping values, and converting an Optional to a stream. ### Source excerpt In the previous post in this series, we examined features of the Stream API added in Java 9. A very useful API that plays well with streams, and was, in fact, used to make streams more robust, is Optional. Let's explore it with JShell! Optional provides a container that may or may not contain a... ## Java 9: Enhancements to the Stream API DevFeed: [Java 9: Enhancements to the Stream API]() Original publisher: [Read original article]() Published: 2017-11-10T03:28:40Z Content type: tutorial Language: en Sources: [Miro Cupak]() Topics: [Java](), [API]() Tags: [code](), [filter](), [infinite](), [java](), [java-9](), [new-features](), [streams]() ### AI overview This tutorial explains four Java 9 enhancements to the Stream API, including predicate-based take and drop operations and an overloaded iterate method. It uses JShell examples to compare the additions with Java 8 approaches, including handling conditions over infinite streams. ### Source excerpt In the last post in this series, we took a look at the new convenience factory methods for collections in Java 9. Collections play well with the Stream API, which learned a few new tricks since its introduction in Java 8 as well. There are 4 particularly exciting new features - let's explore them with JShell! ## State of Gradle Java 9 Support DevFeed: [State of Gradle Java 9 Support]() Original publisher: [Read original article]() Author: Eric Wendelin Published: 2017-10-17T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Java](), [Cross-Compilation](), [modules](), [Architecture & Design]() Tags: [cross-compilation](), [gradle](), [java](), [java-9](), [module](), [security](), [software-architecture]() ### AI overview This article explains Gradle's Java 9 support as of Gradle 4.2.1. It covers running and building applications with major JDK 9 distributions, cross-compilation from JDK 9 to JDK 8, limitations around Multi-Release JARs, and using Java 9 modules with Gradle. ### Source excerpt This post provides an overview of Gradle's Java 9 support, touching on runtime, cross-compilation, MRJARs, and Jigsaw modules support. We've fielded lots of questions since Java 9 was released last month, and decided it best to answer here. What Gradle supports as of version 4.2.1 As of Gradle 4.2.1, building and running Java applications using major distributions of JDK 9 such as Oracle JDK9, OpenJDK9 and Azul JDK9 is fully supported. Further, cross-compilation (built by JDK9 but runs on JDK8) is supported. Some builds will break when upgrading to Java 9, regardless of build tool used. The Java team have made good and necessary changes to the JDK to facilitate better software architecture and security, but this has meant removing access to some APIs. Even if your project is ready, some tools and Gradle plugins have not yet been updated to work with Java 9. There is no convenience methods for consuming and assembling Multi-Release JARs, but you can take a look at this MRJAR-gradle example if you desire to use them. Java Modules aka Jigsaw Support If you're not yet familiar with the Java 9 Platform Module System, also known as Project Jigsaw, you should read Project Jigsaw: Module System Quick-Start Guide. The motivation and terminology are well explained in The State of the Module System. A module is defined as "a named, self-describing collection of code and data" whereby packages are treated as code boundaries, and are explicitly exported and required. Non-exported packages are not visible to module consumers, and further 2 modules cannot export the same packages, nor can they have the same internal packages. This means that packages cannot be "split" or duplicated between multiple modules, or compilation will fail. Here is a guide that shows how to use Java modules with Gradle today. It walks you through the steps necessary to tell Gradle to use the modulepath and not classpath when compiling Java sources and patch modules for testing purposes. A bottom-up approa ## Java 9 Flow API: taking and skipping DevFeed: [Java 9 Flow API: taking and skipping]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-09-30T20:44:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [Java 9](), [API](), [reactive]() Tags: [api](), [flow](), [flow-api](), [implementation](), [java-9](), [jdk](), [publisher](), [reactive](), [reactive-streams](), [skip](), [skipwhile](), [streams](), [subscriber](), [subscription](), [take](), [takeuntil](), [takewhile]() ### AI overview A tutorial on implementing take and skip-style operators with Java 9's Flow API. It explains how to limit a flow, cancel the upstream subscription when the limit is reached, complete the downstream subscriber, handle terminal events, and account for backpressure behavior. ### Source excerpt Introduction Limiting or skipping over parts of a flow is a very common task: either we are only interested in the first N items or we don't care about the first N items. Sometimes, N is unknown but we can decide, based on the current item, when to stop relaying items or, in contrast, when to start relaying items. Take(N) In concept, limiting a flow to a certain size should be straightforward: count the number of items received via onNext and when the limit is reached, issue a cancel() towards the upstream and onComplete() towards the downstream. public static Flow.Publisher take(Flow.Publisher source, long n) { return new TakePublisher<>(source, n); } The operator's implementation requires little state: static final class TakeSubscriber implements Flow.Subscriber { final Flow.Subscriber downstream; Flow.Subscription upstream; long remaining; TakeSubscriber( Flow.Subscriber downstream, long n) { this.downstream = downstream; this.remaining = n; } @Override public void onSubscribe(Flow.Subscription s) { // TODO implement } @Override public void onNext(T item) { // TODO implement } @Override public void onError(Throwable throwable) { // TODO implement } @Override public void onComplete() { // TODO implement } } In its simplest form, there is no need for intercepting the request() and cancel() calls from the downstream: these can be passthrought, however, since the operator has to stop the sequence upon reaching the limit (remaining == 0), the upstream's Flow.Subscriber has to be stored. @Override public void onSubscribe(Flow.Subscription s) { this.upstream = s; downstream.onSubscribe(s); } In onSubscribe, we only have to store the Flow.Subscription and forward it to the downstream. @Override public void onNext(T item) { long r = remaining; if (r > 0L) { remaining = --r; downstream.onNext(item); if (r == 0) { upstream.cancel(); downstream.onComplete(); } } } While remaining is positive, we decrement it and save it into its field foll ## Java 9 Flow API: arbitration and concatenation DevFeed: [Java 9 Flow API: arbitration and concatenation]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-09-27T12:55:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [Java 9](), [Java](), [API]() Tags: [api](), [arbiter](), [arbitration](), [concat](), [concatenation](), [concurrent](), [event](), [flow](), [flow-api](), [java](), [java-9](), [jdk](), [onerrorresumenext](), [publisher](), [repeat](), [request](), [retry](), [submissionpublisher](), [subscriber](), [subscription](), [subscriptionarbiter]() ### AI overview This tutorial explains how to implement subscription arbitration for Java 9's Flow API when concatenating multiple publishers. It addresses stack growth, remaining-demand accounting, concurrent requests and cancellation, subscription switching, and produced-item tracking. ### Source excerpt Introduction A very common task is to combine multiple sources, or more generally, start consuming a source once the previous source has terminated. The naive approach would be to simply call otherSource.subscribe(nextSubscriber) from onError or onComplete. Unfortunately, this doesn't work for two reasons: 1) it may end up with deep stacks due to a "tail" subscription from onError/onComplete and 2) we should request the remaining, unfulfilled amount from the new source that hasn't be provided by the previous source to not overflow the downstream. The first issue can be solved by applying a heavyweight observeOn in general and implementing a basic trampolining loop only for certain concrete cases such as flow concatenation to be described in this post. The second issue requires a more involved source: not only do we have to switch between Flow.Subscriptions from different sources, we have to make sure concurrent request() invocations are not lost and are routed to the proper Flow.Subscription along with any concurrent cancel() calls. Perhaps the difficulty is lessened by the fact that switching sources happens on a terminal event boundary only, thus we don't have to worry about the old source calling onNext while the logic switches to the new source and complicating the accounting of requested/emitted item counts. Enter SubscriptionArbiter. Subscription arbitration We have to deal with 4 types of potentially concurrent signals when arbitrating Flow.Subscriptions: A request(long) call from downstream that has to be routed to the current Flow.Subscription A cancel() call from downstream that has to be routed to the current Flow.Subscription and cancel any future Flow.Subscription. A setSubscription(Flow.Subscription) that is called by the current Flow.Subscriber after subscribing to any Flow.Publisher which is not guaranteed to happen on the same thread subscribe() is called (i.e., as with the standard SubmissionPublisher or our range() operator). A setProduced(long n) ## Java 9 Flow API: timing out events DevFeed: [Java 9 Flow API: timing out events]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-09-25T11:46:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [reactive](), [Java 9](), [Concurrency](), [Programming](), [Streams]() Tags: [await](), [concurrency](), [flow](), [flow-api](), [java-9](), [jdk](), [programming](), [reactive](), [reactive-programming](), [streams](), [subscriber](), [subscription](), [timeout]() ### AI overview This tutorial explains how to design a timeout operator for Java 9 Flow API publishers. It models each event as a race between item arrival and a timer, signals a TimeoutException when the timer wins, and addresses serialized downstream signals when timeout and upstream events occur concurrently. ### Source excerpt Introduction One of the main properties of reactive programming is that the events may arrive over time instead of immediately available to a consumer. In traditional Future-based programming, one could wait for the result in a blocking manner via Future.get(long, TimeUnit). Other data sources, such as network InputStream have either their own built-in timeout facility or one has to use external means to close the stream after certain period of time to unblock the reader to it. Java 8 Streams have also no direct timeout support. In the reactive mindset, one can consider timing out events (items) as requesting an element and racing its arrival against the clock. If the item arrives in time, we should ignore the clock. If the clock fires first, we should stop the sender of the items and somehow notify the consumer of the situation. Perhaps the simplest way is to signal onError with a TimeoutException. Since there could be multiple items from a flow, we have to do this racing for each potential items over and over until the flow terminates. The timeout operator Since there is "time" in timeout, we'll need a source of time that can be started and stopped at will. The first tool that comes into mind is the java.util.Timer class, however, even its Javadoc suggest one uses a ScheduledExecutorService instead. If one has to deal with a lot of timed operations, besides of timing out flows, having the control over such signals via a (set of) ScheduledExecutorServices is desirable. Therefore, let's define our timeout API with it: public static Flow.Publisher timeout( Flow.Publisher source, long timeout, TimeUnit unit, ScheduledExecutorService timer) { return new TimeoutPublisher<>(source, timeout, unit, timer); } (Note that if one uses the Executors.newScheduledExecutorService(), it has to be shutdown at some point, otherwise it's non-daemon thread by default would prevent the JVM from quitting.) One primary responsibility of this type of operator is to make sure the ## Java 9 Flow API: switching threads DevFeed: [Java 9 Flow API: switching threads]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-09-21T10:49:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [Java](), [Java 9](), [API](), [reactive](), [Concurrency](), [Concurrent Programming]() Tags: [asynchronous](), [executor](), [executorservice](), [flow](), [flow-api](), [idea](), [intellij](), [java](), [java-9](), [jvm](), [main-thread](), [observeon](), [publisher](), [thread](), [threading](), [threads]() ### AI overview This tutorial explains how to switch execution between threads in reactive flows using Java 9's Flow API. It compares embedding thread switching in operators with a separate observeOn stage, then outlines an observeOn implementation based on Executor, asynchronous boundaries, bounded queues, and request management. ### Source excerpt Introduction Ensuring certain computations happen on the right thread, usually off the main thread, is a very common development task when dealing with reactive flows. When building up tools for Java 9's Flow API, one can decide to add this thread-switching support to each operator directly - see the range() operator from the start of the series -, or have a standalone stage for this purpose. This is a tradeoff. Inlining thread switching avoids bogging down the source thread like the thread-stealing behavior of most of the queue-drain approach presented so far. A separate operator allows better composition and may even allow working with exotic asynchrony-providing components. The observeOn operator In Java, threading support is provided via the Executor, ExecutorService and ScheduledExecutorService-based API. Executor is is the most basic one of them which only provides a single execute(Runnable) method. This allows creating an Executor from a lambda: Executor trampoline = Runnable::run; Executor swing = SwingUtilities::invokeLater; Executor pool = ForkJoinPool.commonPool(); As the least common denominator, we'll use Executor in defining our observeOn operator: public static Flow.Publisher observeOn( Flow.Publisher source, Executor exec, int prefetch) { return new ObserveOnPublisher<>(source, exec, prefetch); } Crossing an asynchronous boundary requires the temporary storage of an event until the other side can pick it up. The queue-drain approach can provide a nice bounded queue we can size with prefetch. In addition, the so-called stable-prefetch request management (shown in the mapFilter operator before) allows minimizing the overhead of requesting more items. First, let's see the skeleton of the operator's main Flow.Subscriber implementation: static final class ObserveOnSubscriber implements Flow.Subscriber, Flow.Subscription, Runnable { final Flow.Subscriber downstream; final Executor exec; final int prefetch; final Queue queue; F [Next page]()