# Java 8 Published articles for Java 8. 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 Gradle Is Javamaxxing DevFeed: [How Gradle Is Javamaxxing]() Original publisher: [Read original article]() Author: Laura Kassovic Published: 2026-05-28T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Java](), [toolchains](), [toolchain]() Tags: [bytecode](), [compiler](), [garbage-collectors](), [gradle](), [java](), [java-8](), [jdk](), [jvm](), [openjdk](), [optimization](), [performance-optimization](), [release]() ### AI overview Gradle aggressively adopts new JDK releases because newer JVMs can improve build speed, memory use, startup behavior, and maintainability. JVM toolchains allow Gradle to run on JDK 26 while compiling and testing projects for older Java versions, including producing Java 8-compatible bytecode. ### Source excerpt Some people optimize one part of their lives to the absolute limit, then past it. They call it "-maxxing." Houseplantmaxxing. Sleepmaxxing. Tokenmaxxing. The Gradle Build Tool is Javamaxxing. TL;DR Breathe easy knowing you can run modern Gradle on JDK 26 while still shipping Java 8-compatible artifacts: Gradle aggressively adopts new JDKs because newer JVMs make builds faster, leaner, and easier to maintain. Upgrading the JDK that runs Gradle is often the easiest performance win. JVM toolchains fully separate the JVM running Gradle, the JVM compiling your code, and the JVM running your tests. NOT TL;DR We aggressively adopt new JDK releases as soon as we responsibly can. Not because it's trendy. Because newer JDKs make Gradle faster, leaner, and easier to maintain. Every OpenJDK release ships improvements to the JVM; garbage collectors, compiler infrastructure, startup behavior, memory layout, and runtime APIs. As a high-performance JVM build tool, Gradle benefits directly from all of it. The question people immediately ask is: Does this mean my project also has to run on the newest JDK? No. That coupling effectively disappeared once Gradle introduced JVM toolchains. With toolchains, the JVM that runs Gradle is completely separate from the JVM that compiles, tests, and executes your code. You can run Gradle on JDK 26 today and still produce Java 8 bytecode. What Is the Current State of Gradle and Java? We add daemon support for every new JDK as soon as the ecosystem permits: Java 24 in Gradle 8.14.0, Java 25 in 9.1.0 (released two days after JDK 25 GA), Java 26 in 9.4.0. The full mapping is in the Compatibility Matrix. We then bump the minimum JVM required to execute Gradle as users move. Gradle 9.0.0, released on July 31, 2025, raised the minimum JVM required to run the Gradle daemon to Java 17. That was the first daemon JVM floor increase since Gradle 5.0 made Java 8 the minimum back in 2018. The next major transition is already underway, Gradle 10.0.0 will likely ## Converting Future to CompletableFuture With Java Virtual Threads DevFeed: [Converting Future to CompletableFuture With Java Virtual Threads]() Original publisher: [Read original article]() Published: 2025-07-17T08:25:00Z Content type: tutorial Language: en Sources: [Gunnar Morling]() Topics: [Java](), [Concurrency](), [Concurrent Programming]() Tags: [api](), [asynchronous](), [blocking](), [java](), [java-8](), [threads]() ### AI overview This tutorial explains how Java 21+ virtual threads can help convert legacy Future objects into CompletableFuture instances. It contrasts blocking, polling, and asynchronous approaches, noting that virtual threads make blocking inexpensive by unmounting blocked threads from their underlying platform threads. ### Source excerpt This post explores how virtual threads in Java 21+ provide an elegant solution for converting legacy Future objects into CompletableFuture instances. Since Java 8, the CompletableFuture API provides a convenient way for performing asynchronous operations in a functional, composable way. This makes it very simple to call some long-running methods--for instance involving external I/O--asynchronously and process each result as soon as it is available, without blocking on any threads: ## jOOQ 3.19.0 Released with DuckDB, Trino, Oracle 23c support, join path improvements, an official gradle plugin, commercial maven repositories, policies, UDT paths, trigger meta data, hierarchies, and much more DevFeed: [jOOQ 3.19.0 Released with DuckDB, Trino, Oracle 23c support, join path improvements, an official gradle plugin, commercial maven repositories, policies, UDT paths, trigger meta data, hierarchies, and much more]() Original publisher: [Read original article]() Author: lukaseder Published: 2023-12-15T16:30:41Z Content type: release Language: en Sources: [jOOQ]() Topics: [releases](), [DuckDB](), [CockroachDB](), [Maven](), [Gradle](), [rdbms](), [Multi-tenancy]() Tags: [cockroachdb](), [cockroachdb-23](), [duckdb](), [gradle](), [gradle-plugin](), [implicit-joins](), [java-8](), [join-paths](), [jooq](), [jooq-3-19](), [jooq-development](), [maven](), [maven-repository](), [multi-tenancy](), [oracle-23c](), [policies](), [release-notes](), [releases](), [row-level-security](), [security](), [trigger-meta-data](), [triggers](), [trino](), [trinodb](), [udt-paths](), [udts]() ### AI overview The jOOQ 3.19.0 release adds experimental DuckDB support, Trino support, and support for CockroachDB 23 and Oracle 23c. It also improves join paths, introduces an official Gradle plugin and a commercial Maven repository, and adds policies for row-level security. ### Source excerpt New Dialects It's been a few releases since we've added support for new dialects, but finally some very interesting RDBMS of increasing popularity have joined the jOOQ family including: These dialects are available in all jOOQ editions. New dialect versions In addition to these entirely new dialects, big new CockroachDB and Oracle versions have shipped: ... Continue reading jOOQ 3.19.0 Released with DuckDB, Trino, Oracle 23c support, join path improvements, an official gradle plugin, commercial maven repositories, policies, UDT paths, trigger meta data, hierarchies, and much more -> ## How to fix the "Unable to locate a Java Runtime" error on Xcode with Kotlin Multiplatform DevFeed: [How to fix the "Unable to locate a Java Runtime" error on Xcode with Kotlin Multiplatform]() Original publisher: [Read original article]() Author: Marco Gomiero Published: 2021-12-27T00:00:00Z Content type: tutorial Language: en Sources: [Posts on Marco Gomiero]() Topics: [Kotlin Multiplatform](), [Xcode](), [iOS](), [Java](), [Kotlin](), [Android Studio](), [IntelliJ IDEA](), [simulator]() Tags: [android](), [android-studio](), [install](), [installation](), [intellij](), [ios](), [java](), [java-8](), [jdk](), [kotlin](), [kotlin-multiplatform](), [library](), [simulator](), [xcode]() ### AI overview A tutorial explains how to resolve Xcode's "Unable to locate a Java Runtime" build error when running a Kotlin Multiplatform project on the iOS simulator. The author found that the JDK installation method affected Xcode's Java runtime detection and restored builds with a manual installation; explicitly setting JAVA_HOME in plist files is also mentioned as an alternative. ### Source excerpt A couple of days ago I opened my Kotlin Multiplatform pet project MoneyFlow on a different machine than usual. When I tried to run the app on the iOS simulator on Xcode, the build failed with a very strange error: "The operation couldn't be completed. Unable to locate a Java Runtime". This was a very strange issue because the JDK is installed and everything is working on the command line and Android Studio/IntelliJ. ## 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. ## -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 M and L Patterns in Java SimpleDateFormat DevFeed: [Using M and L Patterns in Java SimpleDateFormat]() Original publisher: [Read original article]() Published: 2019-07-21T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [Java](), [Java 8](), [Android]() Tags: [android](), [format](), [formatting](), [java](), [java-8](), [locale]() ### AI overview This article explains the difference between the M and L pattern letters in Java SimpleDateFormat. It shows that they can produce the same results in English and German but differ in Russian, where M is used for dates with contextual month names and L for standalone month names. ### Source excerpt Introduction Using SimpleDateFormat to format dates and times is a common thing (as Java 8 Time API is not that available on Android yet). Usually it looks like: val formatter = SimpleDateFormat("dd MMMM yyyy", Locale.ENGLISH) formatter.format(date) We can use different formats and locales with not only providing correct translations, but also some additional locale-specific formatting rules. One tricky thing about SimpleDateFormat formats is why we have M and L when they look identical? ## Configuring JaCoCo coverage limits in Android Gradle projects DevFeed: [Configuring JaCoCo coverage limits in Android Gradle projects]() Original publisher: [Read original article]() Published: 2018-10-13T13:55:25Z Content type: tutorial Language: en Sources: [maiatoday]() Topics: [Android](), [Gradle](), [test-coverage](), [Kotlin](), [unit tests](), [Java]() Tags: [android](), [code](), [gradle](), [jacoco](), [java-8](), [kotlin](), [test-coverage](), [unit-tests]() ### AI overview A practical Android Gradle snippet that adds JaCoCo test coverage, Kotlin support, and coverage limits for selected important classes or packages. It explains how to add the configuration, run coverage verification, and find the generated HTML report. It also warns that a Robolectric-related configuration line can crash unit tests on Java versions newer than 8. ### Source excerpt I have found myself adding jacoco and coverage limits to more than one Android project. Enough times for me to extract the gradle bits in to a little nugget of grooviness to just drop into a project as needed. For a while now I have been reading about test coverage numbers and working with my intuition about what is the most valuable thing for me to spend my time on when building something. Also Kotlin. In the light of this my gradle build file snippet contains the following: Jacoco for test coverage Kotlin support A way to choose important classes and only set coverage limits on those Do this, Put the gist in a file jacoco.gradle Modify the jacoco.gradle file to add limits for your important packages. Add this line to your build.gradle apply from: 'jacoco.gradle' And then run the command ./gradlew tasks to see what new tasks are there to run. e.g. in the reporting section find something similar to ./gradlew/testDevDebugUnitTestCoverageVerification which will run the tests, make coverage reports and apply limits. Find the reports in a path similar to this ~/your\_project/your\_module/build/reports/jacoco/testDevDebugUnitTestCoverage/html/index.html Without further ado, the gist: The code in the gist was taken from so many blogposts. I can't even remember them all. Thanks to the original authors. Also note there is a small piece of cargo cult code that kept sneaking in from sundry blogposts that I don't need because I don't have Robolectric tests. As it turns out this code crashes unit tests on Java > 8. So remove this code if you have it and if it fits your usecase. tasks.withType(Test) { jacoco.includeNoLocationClasses = true } ## 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 ## Multi-release JARs in Java 9: Risks and Gradle Usage DevFeed: [Multi-release JARs in Java 9: Risks and Gradle Usage]() Original publisher: [Read original article]() Author: Cédric Champeau Published: 2017-12-19T05:00:00Z Content type: opinion Language: en Sources: [The Gradle Blog]() Topics: [Java](), [Gradle]() Tags: [gradle](), [java](), [java-8]() ### AI overview This article examines Java 9 multi-release JARs, which package different versions of the same class for different Java runtimes. It argues that the technology carries significant adoption risks while explaining how to produce and consume multi-release JARs with Gradle. ### Source excerpt With Java 9 came a new feature of the Java runtime called multi-release jars. For us at Gradle, it's probably one of the most controversial additions to the platform. TL/DR, we think it's a wrong answer to a real problem. This post will explain why we think so, but also explain how you can build such jars if you really want to. Multi-release JARs, aka MRJARs, are a new feature of the Java platform, included in the Java 9 JDK. In this post, we will elaborate on the significant risks of adopting this technology and provide how one can produce and consume multi-release JARs with Gradle, if desired. In a nutshell, multi-release jars allow you to package several versions of the same class, for consumption by different runtimes. For example, if you run on JDK 8, the Java runtime would use the Java 8 version of the class, but if you run on Java 9, it would use the Java 9 specific implementation. Similarly, if a version is built for the upcoming Java 10 release, then the runtime would use it instead of the Java 9 and default (Java 8) versions. Use Cases for multi-release JARs Optimized runtime. This answers a problem that lots of developers have faced in real world: when you develop an application, you don't know in what runtime it's going to be executed. However, you know that for some runtimes you can implement optimized versions of the same class. For example, imagine that you want to display the Java version number that your application is currently executed on. For Java 9, you can use the Runtime.getVersion method. However, this is a new method only available if you run on Java 9+. If you target more runtimes, say, Java 8, then you need to parse the java.version property. So you end up with 2 different implementations of the same feature. Conflicting APIs : Another common use case is to handle conflicting APIs. For example, you need to support 2 different runtimes, but one has deprecated APIs. There are currently 2 widely used solutions to this problem: The first one i ## Java Optionals and Kotlin Nulls DevFeed: [Java Optionals and Kotlin Nulls]() Original publisher: [Read original article]() Author: author@typealias.com (Dave Leeds) Published: 2017-09-01T00:00:00Z Content type: tutorial Language: en Sources: [Dave Leeds on Kotlin - typealias.com]() Topics: [Java](), [Kotlin]() Tags: [exception](), [extension-function](), [filter](), [java](), [java-8](), [kotlin](), [migration-guide](), [null](), [null-safety](), [optional](), [programming](), [safe-call-operator](), [standard-library](), [transformation]() ### AI overview A guide to translating Java Optional usage into idiomatic Kotlin null-safety patterns. It compares creation, transformation, filtering, and conditional operations, while noting trade-offs and cases where Kotlin nullable types replace Optional. ### Source excerpt When Java 8 introduced Streams for operating on collections of data, it also introduced a similar concept, Optional, which has many methods that are similar to Stream, but operates on a single value that might or might not be present. As you migrate your projects from Java to Kotlin, you might come across some Optional objects. What should you do? Should you leave them as Optional, or change them to more idiomatic Kotlin? ## Embracing Java 8 language features DevFeed: [Embracing Java 8 language features]() Original publisher: [Read original article]() Author: info@jeroenmols.com (Jeroen Mols) Published: 2017-07-21T00:00:00Z Content type: tutorial Language: en Sources: [Jeroen Mols]() Topics: [Java](), [Android](), [Android Studio](), [Gradle](), [toolchain]() Tags: [android](), [android-studio](), [blogs](), [functional](), [gradle](), [guide](), [java](), [java-8](), [lambda](), [toolchain](), [tools]() ### AI overview This tutorial explains how Android Studio 3.0 added backported support for most Java 8 language features across Android API levels. It covers enabling the features, configuring the Gradle plugin and toolchain, and using lambda expressions and method references to reduce boilerplate. ### Source excerpt For years Android developers have been limited to Java 6 features. While RetroLambda or the experimental Jack toolchain would help, proper support from Google was notably missing. ## TIP: Track Designer & GUIBuilder Issues DevFeed: [TIP: Track Designer & GUIBuilder Issues]() Original publisher: [Read original article]() Author: Shai Almog Published: 2017-04-09T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [ide](), [Tool](), [GUI](), [Java]() Tags: [command-line](), [debug](), [designer](), [eclipse](), [gui](), [ide](), [java](), [java-8]() ### AI overview A troubleshooting guide for tracking issues in the Designer resource editor and GUI Builder, focusing on their integration with IDEs, command-line diagnostics, Java 8 requirements, and Eclipse launch problems. ### Source excerpt We are on a mid-bootcamp break so the blog is back to life during this time (and there is so much to write!), more on that tomorrow but for now I'd like to write about fixing & tracking issues with the designer (resource editor) and the GUI builder. Both of these tools have issues most of which revolve around their connection to the IDE. The reason for this is that they are external tools that aren't a part of the IDE, this allows us to support all 3 IDE's without too much of an effort but also creates some issues that are often hard to debug. ## Dining Philosophers in Java 8 DevFeed: [Dining Philosophers in Java 8]() Original publisher: [Read original article]() Author: Bruce Eckel Published: 2016-12-29T00:00:00Z Content type: tutorial Language: en Sources: [Bruce Eckel - Computing Thoughts]() Topics: [Deadlock](), [Java](), [Concurrency](), [Concurrent Programming]() Tags: [concurrent](), [deadlock](), [java](), [java-8](), [thread]() ### AI overview This tutorial explains deadlock in concurrent programs through the Dining Philosophers problem and presents a Java 8 example using shared chopsticks and blocking queues. ### Source excerpt Because tasks can become blocked, it's possible for one task to get stuck waiting for another task, which in turn waits for another task, and so on, until the chain leads back to a task waiting on the first one. You get a continuous loop of tasks waiting on each other, and no one can move. This is called deadlock.1 If you try running a program and it deadlocks right away, you can immediately track down the bug. ## Java 8 Parallel Operations Are Not As Simple As They Seem DevFeed: [Java 8 Parallel Operations Are Not As Simple As They Seem]() Original publisher: [Read original article]() Author: Bruce Eckel Published: 2016-04-27T00:00:00Z Content type: article Language: en Sources: [Bruce Eckel - Computing Thoughts]() Topics: [Java](), [Streams](), [Code](), [Algorithms, Complexity]() Tags: [algorithms](), [java](), [java-8](), [jvm](), [parallel](), [streams]() ### AI overview This article explores Java 8 streams and parallel streams by comparing multiple ways to sum an incremental sequence of numbers. It reports that parallelization can be slower than sequential execution and may run out of memory in some generator-based cases, while noting that timing results are machine-dependent and imperfect. ### Source excerpt As an exploration of the uncertainties of streams and parallel streams, let's look at a problem that seems simple: summing an incremental sequence of numbers. There turns out to be a surprising number of ways to do this, and I'll take the risk of comparing them through timing--trying to be careful, but acknowledging that I might fall into one of the many fundamental pitfalls when timing code execution. The results may have some flaws (there's no "warming up" of the JVM, for example), but I think it nonetheless gives some useful indications. ## Mixins as an alternative to inheritance in Java 8 DevFeed: [Mixins as an alternative to inheritance in Java 8]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2016-04-26T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [Java](), [interfaces](), [Ruby](), [Scala](), [Polymorphism]() Tags: [inheritance](), [interfaces](), [java](), [java-8](), [programming](), [programming-language](), [ruby](), [scala]() ### AI overview This tutorial explains how Java 8 default methods in interfaces can be used to compose reusable behavior as mixins, providing an alternative to inheritance. It contrasts this approach with delegation and with mixins or traits in Ruby and Scala. ### Source excerpt Starting in Android N Google has added some java 8 language features. One of those features is the ability to add default methods to interfaces. Surprisingly (since java 8 has already been released 2 years ago) I haven't found good articles describing the advantage of default methods for interfaces: Mixins! ## Are Java 8 Lambdas Closures? DevFeed: [Are Java 8 Lambdas Closures?]() Original publisher: [Read original article]() Author: Bruce Eckel Published: 2015-10-17T00:00:00Z Content type: opinion Language: en Sources: [Bruce Eckel - Computing Thoughts]() Topics: [Java](), [Functional programming](), [Programming]() Tags: [functional-programming](), [java](), [java-8](), [lambda](), [programming-language]() ### AI overview The article explains that Java 8 lambdas support closures, with a caveat. It presents lambdas as a way to express what computation should be performed instead of how, and describes their relationship to functional programming within Java's object-oriented model. ### Source excerpt (Significantly rewritten 11/25/2015) Based on what I've heard, I was surprised to discover that the short answer is "yes, with a caveat that, after explanation, isn't terrible." So, a qualified yes. For the longer answer, we must first explore the question of "why, again, are we doing all this?" Abstraction over Behavior The simplest way to look at the need for lambdas is that they describe what computation should be performed, rather than how it should be performed. ## A private Maven repository for Android in 30 min DevFeed: [A private Maven repository for Android in 30 min]() Original publisher: [Read original article]() Author: info@jeroenmols.com (Jeroen Mols) Published: 2015-08-06T00:00:00Z Content type: tutorial Language: en Sources: [Jeroen Mols]() Topics: [Maven](), [Gradle](), [Android](), [Android Library]() Tags: [android](), [android-library](), [artifactory](), [blogs](), [gradle](), [installation](), [java-8](), [library](), [maven](), [maven-repository](), [tools]() ### AI overview A tutorial explains how to set up a private Maven repository with Artifactory and configure Gradle to upload Android library artifacts. It covers repository-manager setup, Java SDK 8 prerequisites, Artifactory installation, and Gradle configuration. ### Source excerpt Setting up your own Maven repository and uploading artifacts to it is quite a daunting task. As I went through this experience myself recently, I want to help others in setting up their own Maven repository via Artifactory and automate uploading artifacts using Gradle. ## HOW TO SET LOCAL AOSP GERRIT SERVER - PART 2 DevFeed: [HOW TO SET LOCAL AOSP GERRIT SERVER - PART 2]() Original publisher: [Read original article]() Author: Ramon Published: 2015-06-29T18:42:37Z Content type: tutorial Language: en Sources: [Ramon Fried]() Topics: [aosp](), [MySQL](), [Git](), [Java](), [ssh](), [bouncy castle](), [SSL](), [Authentication]() Tags: [android](), [aosp](), [bouncy-castle](), [gerrit](), [git](), [how-to](), [java](), [java-8](), [mysql](), [plugins](), [repo-mirror](), [ssh](), [ssl](), [tutorial]() ### AI overview Part 2 of a tutorial on setting up a local AOSP Gerrit server. It covers creating a Gerrit user and MySQL database, configuring Gerrit, installing required Java and cryptographic libraries, and setting up SSH, HTTP, authentication, email delivery, and plugins. ### Source excerpt Hi. This is part 2 of the "How to set local AOSP Gerrit server", you might want to start with part 1 here. In part 1 we've downloaded all the necessary stuff and in this post we're going to set it all up. First thing, let's bootstrap Gerrit. Let's create a Gerrit user: $ sudo [...] ## Exponential Backoff with Java 8 DevFeed: [Exponential Backoff with Java 8]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2014-10-26T00:00:00Z Content type: tutorial Language: en Sources: [Carlos Becker]() Topics: [Java 8](), [Algorithm](), [interface]() Tags: [algorithm](), [fibonacci](), [functional](), [java](), [java-8]() ### AI overview This tutorial explains exponential backoff and demonstrates an implementation in Java 8. It uses functional interfaces and a Fibonacci sequence to increase the waiting time between retries when a service connection fails with an expected error. ### Source excerpt Exponential backoff is an algorithm that uses feedback to multiplicatively decrease the rate of some process, in order to gradually find an acceptable rate. --- Wikipedia ## Java 8 DevFeed: [Java 8]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2014-08-04T00:00:00Z Content type: opinion Language: en Sources: [Carlos Becker]() Topics: [Java](), [Java 8](), [Programming]() Tags: [java](), [java-8](), [new-features](), [programming]() ### AI overview An opinionated overview of Java 8's notable features, including lambda expressions, Stream collection types, the Date and Time API, String.join, and Optional. The author also describes the labor involved in updating libraries and fixing compatibility issues in a real-world project. ### Source excerpt Earlier this year, the new version of the Java Programming Language was released. Finally, it enters the field of the "cool peeps" with some features it should have had since years ago, like Lambdas.