# Stephen Colebourne Thoughts and Musings on the world of Java and beyond This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Embedded records - extracting data from classes DevFeed: [Embedded records - extracting data from classes]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2025-11-05T06:30:00Z Content type: article Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [data]() Tags: [classes](), [data](), [java](), [javaideas](), [serialization]() ### AI overview The article discusses embedded records, a proposal to extend the benefits of Java records to classes that represent data. It addresses the gap between records and classes and mentions possible relevance to Serialization 2.0. ### Source excerpt At Devoxx Belgium 2025 I discussed the idea of embedded records with a few people. The idea is to take what is great about records, and extend that to classes that represent data. This responds to a pain point in Java, where there is a bit of a cliff-edge between records and classes. While millions of classes could and should be converted to records, millions more cannot. Yet they still represent data, and it would be a Good Thing to be able to capture that. Especially with Serialization 2.0 on the horizon. Please see the proposal document for more details. ## Type conversion in Java - an alternative proposal for primitive type patterns DevFeed: [Type conversion in Java - an alternative proposal for primitive type patterns]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2025-10-15T06:09:00Z Content type: opinion Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [Code](), [Exception]() Tags: [exception](), [java](), [javaideas](), [pattern-matching](), [patterns](), [safety]() ### AI overview The article proposes an alternative to Java's primitive type patterns in JEP 507. It distinguishes type checks from primitive type conversions and introduces type conversion casts and patterns, including a cast that throws an exception when a conversion would lose information. ### Source excerpt A lot of good work has been done by the core Java team on patterns, providing new ways to explore data. The latest extension, in JEP 507, is the idea that primitive type patterns should be supported. Today I'm publishing an alternative approach. Primitive Types in Patterns, instanceof, and switch The current proposal is as follows: long val = createLong(); int i = (int) val; // cast long to int, potentially silently losing information switch (val) { case int j -> IO.println("Long fits in an int"); case long v -> IO.println("Long does not fit in an int"); }; I like the idea of being able to tell if a long value fits into an int without loss. But I hate the syntax. The key problem is that type patterns check the supertype/subtype relationship, and int is not a subtype of long. The result is code that doesn't seem to make sense. The official explanation is based on the notion that develoeprs use instanceof String before a cast to String all the time. Thus a parallel can be drawn to have an instanceof int before a cast to int. Effectively the aim is to extend the meaning of type patterns to cover primitive type casts, which are type conversions, not type checks. I know I am not alone in finding this argument weak, and in finding the proposed syntax highly confusing. But it took a while, and an 8 page document, to figure out exactly why. Type conversion in Java In response to the JEP and subsequent discussions, I have written up a detailed proposal for type conversion casts and type conversion patterns. These allow developers to more clearly express the difference between type checks (that check the supertype/subtype relationship) and type conversions (where primitive types are changed to a different type). The big idea is to introduce a new kind of cast, the type conversion cast that operates like a standard primitive type cast, but throws an exception when the conversion would be lossy. long val = createLong(); int i = (int) val; // cast long to int, potentially losing ## Pattern match Optional in Java 21 DevFeed: [Pattern match Optional in Java 21]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2024-02-20T09:19:00Z Content type: article Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [Code]() Tags: [code](), [java](), [java21](), [null](), [optional](), [pattern-matching]() ### AI overview This article presents a rarely useful technique for pattern matching an Optional in Java 21 by converting its value with orElse(null) and testing it with instanceof. It discusses functional Optional methods, an iterable helper, limitations in Java 17, and a possible use in long if-else chains. ### Source excerpt I'm going to describe a trick to get pattern patching on Optional in Java 21, but one you'll probably never actually use. Using Optional As of Java 21, Pattern matching in Java allows us to check a value against a type like an instanceof with a new variable being declared of the correct type. Pattern matching can handle simple types and the deconstruction of records. But pattern matching of arbitrary classes like Optional is not yet supported. (Work to support pattern match methods is ongoing). In normal code, the best way to use Optional is with one of the functional methods: var addressOpt = findAddress(personId); var addressStr = addressOpt .map(address -> address.format()) .orElse("No address available"); This works well in most cases. But sometimes you want to use the Optional with a return statement. This results in code using get() like this: var addressOpt = findAddress(personId); if (addressOpt.isPresent()) { // early return if address found return addressOpt.get().format(); } // lots of other code to handle case when address not found One way to improve this is to write a simple method: /** * Converts an optional to an iterable for use in the for-each statement. * * @param <lT> the type of optional element * @param optional the optional * @return an iterable representation of the optional */ public static <lT> Iterable<lT> inOptional(Optional<lT> optional) { return optional.isPresent() ? List.of(optional.get()): List.of(); } Which allows the following neat form: for (var address : inOptional(findAddress(personId))) { // early return if address found return address.format(); } // lots of other code to handle case when address not found This is a great approach providing that you don't need an else branch. Using Optional with Pattern matching With Java 21 and pattern matching we have a new way to do this! if (findAddress(personId).orElse(null) instanceof Address address) { // early return if address found return address.format(); } else { // lots of ## Java on-ramp - Fully defined Entrypoints DevFeed: [Java on-ramp - Fully defined Entrypoints]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2022-10-06T11:18:00Z Content type: opinion Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [Code](), [openjdk]() Tags: [classes](), [code](), [getting-started](), [java](), [javaideas](), [launch]() ### AI overview The article argues that Java should introduce a dedicated entrypoint class declaration to make starting programs easier for newcomers and more useful for developers generally. The proposal would provide simpler syntax that compiles to a class file with distinct rules, including inferred class names and top-level code. ### Source excerpt How do you start a Java program? With a main method of course. But the ceremony around writing such a method is perhaps not the nicest for newcomers to Java. There has been a bit of dicussion recently about how the "on-ramp" for Java could be made easier. This is the original proposal. Here are follow ups - OpenJDK, Reddit, Hacker news. Starting point This is the classic Java Hello Word: public class HelloWorld { public static void main(String[] args) { System.out.println("Hello World"); } } Lots of stuff going on - public, class, a class name, void, arrays, a method, method call. And one of the weirdest things in Java - System.out - a public static field in lower case. Something that is pretty much never seen in normal Java code. (I still remember System.out.println being the most confusing part about getting started in Java 1.0 - why are there two dots and why isn't it out()?) The official proposal continues to discuss: A more tolerant launch protocol Unnamed classes Predefined static imports for the most critical methods and fields The ensuing discussion resulted in various suggestions. Having taken some time to reflect on the proposal and discussion, here is my contribution, which is that what is really needed is something more comprehensive. Entrypoints When a Java program starts some kind of class file needs to be run. It could be a normal class, but that isn't ideal as we don't really want static/instance variables, subclasses, parent interfaces, access control etc. One suggestion was for it to be a normal interface, but that isn't ideal as we don't want to mark the methods as default or allow abstract methods. I'd like to propose that what Java needs is a new kind of class declaration for entrypoints. I don't think this is overly radical. We already have two alternate class declarations - record and enum. They have alternate syntax that compiles to a class file without being explictly a class in source code. What we need here is a new kind - entrypoint - tha ## Proposed Europe/Oslo timezone alias change could discard pre-1970 data and break Joda-Time behavior DevFeed: [Proposed Europe/Oslo timezone alias change could discard pre-1970 data and break Joda-Time behavior]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2021-09-25T00:55:00Z Content type: opinion Language: en Sources: [Stephen Colebourne]() Topics: [DateTime](), [Programming](), [systems](), [Operating system]() Tags: [blog](), [jdk](), [joda](), [operating-systems](), [smartphones](), [systems](), [timezone]() ### AI overview The article criticizes a proposed change to the IANA timezone database that would make Europe/Oslo an alias of Europe/Berlin because their post-1970 data matches. It argues that this could replace researched pre-1970 Oslo data with Berlin data and cause Joda-Time tests and timezone identifier handling to fail. ### Source excerpt The last time I wrote about the timezone database on this blog, the database was under threat from a lawsuit. Fortunately that lawsuit went away relatively quickly as the company involved got the message that their action was a big mistake. Unfortunately this time the mess is internal. Paul Eggert is the project lead of the timezone database hosted at IANA, a position referred to as the TZ Coordinator. He is an expert in the field, having been involved in documenting timezone data for decades. Unfortunately, he is currently ignoring all objections to an action only he seems intent on making to solve an invented problem that only he sees as important. The database is the world's principle source of timezone information. The data is included in everything from operating systems to smartphones to programming language development kits such as the JDK. While you may never have heard of it, the sheer pervasiveness of the data makes the potential impact of change or damage pretty huge. The timezone database contains information about how clocks have varies in each region around the world. The mandate of the project is to record this information from 1970 onwards. Of course, computers being what they are, a function that returns the timezone for a given date can be passed in a pre-1970 date as well as a post-1970 one. For this, and reasons of completeness, the timezone database contains pre-1970 data as well as post-1970 data. If you go to your JDK or operating system and ask for the timezone offset for 1920-01-01 for the ID "Europe/Oslo" or "Europe/Berlin" you will get an answer: DateTimeZone oslo = DateTimeZone.forID("Europe/Oslo"); System.out.println(oslo.getOffset(new DateTime(1948, 6, 1, 12, 0))); //prints 3600000 DateTimeZone berlin = DateTimeZone.forID("Europe/Berlin"); System.out.println(berlin.getOffset(new DateTime(1948, 6, 1, 12, 0))); //prints 7200000 The proposed change is to downgrade "Europe/Oslo" to be merely an alias for "Europe/Berlin". The rationale is th ## Java switch statement redesign: benefits and complexity DevFeed: [Java switch statement redesign: benefits and complexity]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2019-11-04T20:32:00Z Content type: opinion Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [upgrade](), [Code]() Tags: [code](), [coding](), [java](), [upgrade]() ### AI overview This opinion article examines planned changes to Java's switch statement, including expression forms and new arrow syntax. It argues that the redesign addresses some classic switch problems but introduces substantial complexity and awkward syntax. ### Source excerpt The switch statement in Java is being changed. But is it an upgrade or a mess? Classic switch The classic switch statement in Java isn't great. Unlike many other parts of Java, it wasn't properly rethought when pulling features across from C all those years ago. The key flaw is "fall-through-by-default". This means that if you forget to put a break clause in each case, processing will continue on to the next case clause. Another flaw is that variables are scoped to the entire switch, thus you cannot reuse a variable name in two different case clauses. In addition, default clause is not required, which leaves readers of the code unclear as to whether a clause was forgotten or not. And of course there is also the key limitation - that the type to be switched on can only be an integer, enum or string. String instruction; switch (trafficLight) { case RED: instruction = "Stop"; case YELLOW: instruction = "Prepare"; break; case GREEN: instruction = "Go"; break; } System.out.println(instruction); The code above does not compile because there is no default clause, leaving instruction undefined. But even if it did compile, it would never print "Stop" due to the missing break. In my own coding, I prefer to always put a switch at the end of a method, with each clause containing a return to reduce the risks of switch. Upgraded switch As part of Project Amber, switch is being upgraded. But sadly, I'm unconvinced as to the merits of the new design. To be clear, there are some good aspects, but overall I think the solution is overly complex and with some unpleasant syntax choices. The key aim is to add an expression form, where you can assign the result of the switch to a variable. This is rather like the ternary operator (eg. x != null ? x : ""), which is the expression equivalent of an if statement. An expression form would reduce problems like the undefined variable above, because it makes it more obvious that each branch must result in a variable. The current plan is to add no ## User-defined literals in Java? DevFeed: [User-defined literals in Java?]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2019-03-22T11:39:00Z Content type: opinion Language: en Sources: [Stephen Colebourne]() Topics: [Java]() Tags: [java]() ### AI overview The article proposes adding user-defined literals to Java so classes could convert literal character sequences into instances such as Currency, LocalDate, Pattern, and URI. It discusses type inference, raw-string processing, and compile-time validation as required semantics. ### Source excerpt Java has a number of literals for creating values, but wouldn't it be nice if we had more? Current literals These are some of the literals we can write in Java today: integer - 123, 12s, 1234L, 0xB8E817, 077, 0b1011_1010 floating point - 45.6f, 56.7d, 7.656e6 string - "Hello world" char - 'a' boolean - true, false null - null Project Amber is also considering adding multi-line and/or raw string literals. But there are many other data types that would benefit from literals, such as dates, regex and URIs. User-defined literals In my ideal future, I'd like to see Java extended to support some form of user-defined literals. This would allow the author of a class to provide a mechanism to convert a sequence of characters into an instance of that class. It may be clearer to see some examples using one possible syntax (using backticks): Currency currency = `GBP`; LocalDate date = `2019-03-29`; Pattern pattern = `strata\.\w+`; URI uri = `https://blog.joda.org/`; A number of semantic features would be required: Type inference Raw processing Validated at compile-time Type inference Type inference is of course a key aspect of literals. It would have to work in a similar way to the existing literals, but with a tweak to handle the new var keyword. ie. these two would be equivalent: LocalDate date = `2019-03-29`; var date = LocalDate`2019-03-29`; The type inference would also work with methods (compile error if ambiguous): boolean inferior = isShortMonth(`2019-04-12`); public boolean isShortMonth(LocalDate date) { return date.lengthOfMonth() < 31; } Raw processing Processing of the literal should not be limited by Java's escape mechanisms. User-defined literals need access to the raw string. Note that this is especially useful for regex, but would also be useful for files on Windows: // user-defined literals var pattern = Pattern`strata\.\w+`; // today var pattern = Pattern.compile("strata\\.\\w+"); Today, the `\` needs to be escaped, making the regex difficult to read. Clearly, ## Commercial support for Joda and ThreeTen projects DevFeed: [Commercial support for Joda and ThreeTen projects]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2019-01-09T12:23:00Z Content type: opinion Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [Maintainers](), [Open Source](), [Security]() Tags: [java](), [joda](), [maintainers](), [open-source](), [security](), [threeten]() ### AI overview The article announces commercial support through Tidelift subscriptions for Joda-Time, Joda-Money, Joda-Beans, Joda-Convert, Joda-Collect, ThreeTen-Extra, and ThreeTen-backport. It explains that Tidelift directs part of subscription income to maintainers while leaving projects free and permissively licensed. ### Source excerpt The Java ecosystem is made up of many individuals, organisations and companies producing many different libraries. Some of the largest projects have long had support options where users of the project, typically corporates, can pay for an enhanced warranty, guaranteed approach to bug fixes and more. Small projects, run by a single individual or a team, have been unable to offer this service, even if they wanted to. In addition, there is a more subtle problem. The amount a small project could charge is too low for a corporate to pay. This sounds odd, but was brought home to me by this thread on twitter: As the thread indicates, it is basically impossible for a corporate to gift money to a small project, and it is not viable for small projects to meaningfully offer a support contract. The problem is that not paying the maintainers has negative consequences. Take the recent case where a developer handed his open source project on to another person, who then used it to steal bitcoins. Pay the maintainers I believe there is now a solution to the problem. Tidelift. Tidelift offers companies a monthly subscription to support their open source usage. And they pay some of that income directly to the maintainers of the projects that the company uses. Maintainers are expected to continue maintaining the project, follow a responsible disclosure process for security issues and check their licensing. Tidelift does not get to control the project roadmap, and maintainers do not have to provide an active helpdesk or consulting. See here for more details. As such, I'm now offering commercial support for Joda-Time, Joda-Money, Joda-Beans, Joda-Convert, Joda-Collect, ThreeTen-Extra, ThreeTen-backport via the Tidelift subscription. This is an extra option for those that want to support the maintainers of open source but haven't been able to find a way to do so until now. The Joda and ThreeTen projects will always be free and available under a permissive licence, so there is no need to w ## Should you adopt Java 12 or stick on Java 11? DevFeed: [Should you adopt Java 12 or stick on Java 11?]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2018-10-31T07:02:00Z Content type: opinion Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [releases](), [upgrade](), [Security]() Tags: [java](), [lts](), [openjdk](), [patches](), [releases](), [upgrade]() ### AI overview This article examines whether JVM users should adopt Java 12 or remain on Java 11. It explains Java's six-month release cycle, the role of long-term-support releases, and the compatibility and security-patch risks involved in adopting non-LTS versions. ### Source excerpt Should you adopt Java 12 or stick on Java 11 for the next 3 years? Seems like an innocuous question, but it is one of the most important decisions out there for those running on the JVM. I'll try to cover the key aspects of the decision, with the assumption that you care about running with the latest set of security patches in production. TL;DR, It is vital to fully understand and accept the risks before adopting Java 12. The Java release train There is now a new release of Java every six months, so Java 12 is less than five months away despite Java 11 having just been released. As part of the process of moving to more frequent releases, certain releases are designated to be LTS (long term support) and as such will have security patches available for four years or more. This makes them "major" releases, not because they have a bigger feature set but because they have multi year support. It is expected that Java 11 patches (11.0.1, 11.0.2, 11.0.3, etc.) will be smaller and simpler than Java 8 updates (8u20, 8u40, 8u60, etc.) - Java 11 updates will be more focused on security patches, without the internal enhancements of Java 8 updates. Instead, Oracle want us to think of Java 12, 13, 14 etc. as small upgrades, similar to an imaginary Java 11u20, 11u40 etc. To be blunt, I find this nonsensical. Senior Oracle employees have repeatedly argued that updates such as 8u20 and 8u40 often broke code. This was not my experience. In fact my experience was that update releases primarily contained bug fixes. The only break I can remember was the addition of --allow-script-in-comments to Javadoc, which isn't a core part of Java. As a result, I have never feared picking up the latest update release - and this has been a core benefit of the Java platform. Drilling down into why update releases tend to cause no problems, lets examine the differences between release types: Model Old model New model Upgrade Java major releases Java update releases Java release train Java patches Freque ## Oracle JDK licensing changes in Java 11 and OpenJDK alternatives DevFeed: [Oracle JDK licensing changes in Java 11 and OpenJDK alternatives]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2018-09-26T10:57:00Z Content type: opinion Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [openjdk](), [.NET 11](), [Adoptium](), [GNU General Public License]() Tags: [adoptium](), [java](), [jdk](), [lts](), [openjdk](), [oracle]() ### AI overview The author argues that Oracle JDK for Java 11 has commercial-use restrictions and recommends choosing a free OpenJDK build for commercial use. The article cites Adoptium as a GPL-licensed option intended to provide more than four years of security patches. ### Source excerpt TL:DR; Java is still available at zero-cost, you just need to stop using Oracle JDK and start using an OpenJDK build, such as this one or this one. The trap Java 11 has been released. It is a major release because it has long-term support (LTS). But Oracle have also set it up to be a trap (either deliberately or accidentally). For 23 years, developers have downloaded the JDK from Oracle and used it for $free. Type "JDK" into your favourite search engine, and the top link will be to an Oracle Java SE download page (I'm deliberately not providing a link). But that search and that link is now a trap. Oracle JDK, the one all web searches take you to, is now commercial not $free. The key part of the terms is as follows: You may not: use the Programs for any data processing or any commercial, production, or internal business purposes other than developing, testing, prototyping, and demonstrating your Application; The trap is as follows: Download Oracle JDK (because that is what you've always done, and it is what the web-search tells you) Use it in production (because you didn't realise the license changed) Get a nasty phone call from Oracle's license enforcement teams demanding lots of money In other words, Oracle can rely on inertia from Java developers to cause them to download the wrong (commercial) release of Java. Unless you read the text/warnings/legalese very carefully you might not even realise Oracle JDK is now commercial, and that you are therefore liable to pay Oracle for using this particular JDK in production. (Update, 2018-10-03: Searches for Java 11 and JDK 11 now seem to be resolving to OpenJDK builds, not commercial ones!) Is this trap malicious behaviour on the part of Oracle? Readers will have their own opinions. I do suggest bearing in mind that Oracle invests huge amounts in developing Java, so it is reasonable to have a commercial plan available for those that want it. And they do provide a $free alternative completely valid for commercial use... The ## 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 ## Time to look beyond Oracle's JDK DevFeed: [Time to look beyond Oracle's JDK]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2018-09-03T08:38:00Z Content type: article Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [openjdk](), [Development](), [GNU General Public License]() Tags: [java](), [jck](), [openjdk](), [oracle](), [tck]() ### AI overview This article explains why Java users should consider OpenJDK builds beyond Oracle's JDK starting with Java 11. It describes how vendors produce builds from the OpenJDK source code, how TCK certification establishes Java SE compatibility, and how Oracle's JDK licensing and support differ from other builds. ### Source excerpt From Java 11 its time to think beyond Oracle's JDK. Time to appreciate the depth of the ecosystem built on OpenJDK. Here is a list of some key OpenJDK builds. This is a quick follow up to my recent zero-cost Java post OpenJDK builds In practical terms, there is only one set of source code for the JDK. The source code is hosted in Mercurial at OpenJDK. Anyone can take that source code, produce a build and publish it on a URL. But there is a distinct certification process that should be used to ensure the build is valid. Certification is run by the Java Community Process, which provides a Technology Compatibility Kit (TCK, sometimes referred to as the JCK). If an organization produces an OpenJDK build that passes the TCK then that build can be described as "Java SE compatible". Note that the build cannot be referred to as "Java SE" without the vendor getting a commercial license from Oracle. For example, builds from AdoptOpenJDK that pass the TCK are not "Java SE", but "Java SE compatible" or "compatible with the Java SE specification". Note also that certification is currently on a trust-basis - the results are not submitted to the JCP/Oracle for checking and cannot be made public. See Volker's excellent comment for more details. To summarise, the OpenJDK + Vendor process turns one sourcebase into many different builds. In the process of turning the OpenJDK sourcebase into a build, the vendor may, or may not, add some additional branding or utilities, provided these do not prevent certification. For example, a vendor cannot add a new public method to an API, or a new language feature. Oracle JDK http://www.oracle.com/technetwork/java/javase/downloads/ From Java 11 this is a branded commercial build with paid-for support. It can be downloaded and used without cost only for development use. It cannot be used in production without paying Oracle (so it is a bit of a trap for the unwary). Oracle intends to provide full paid support until 2026 or later (details). Note that ## 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. ## 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 ## 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 ## Java SE 9 - JPMS automatic modules DevFeed: [Java SE 9 - JPMS automatic modules]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2017-05-09T07:14:00Z Content type: article Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [modules](), [migration]() Tags: [java](), [java9](), [migration](), [modules](), [opinion]() ### AI overview This article explains automatic modules in Java SE 9's Java Platform Module System (JPMS), including how they support migration from classpath-based applications when dependencies have not yet been converted to modules. It describes modulepath behavior, automatic-module defaults, and the author's view that this design is problematic. ### Source excerpt This article in my series on the Java Platform Module System (JPMS) is focussed on automatic modules. JPMS was previously known as Project Jigsaw and is the module system in Java SE 9. See also Module basics, Module naming and Modules & Artifacts. Automatic modules Lets say you are in charge of Java, and after 20 years you want to add a module system to the platform. As well as the problems of designing the module system itself, you have to consider migration of all the existing code written in Java (and to a degree, other JVM languages). The solution to this that JPMS has chosen is automatic modules. Unfortunately, my opinion is that it is the wrong solution. To understand automatic modules, we have to start by looking at how jar files will be specified in future. In addition to the classpath, Java SE 9 will also have a modulepath. The basic idea is that modules (jar files containing module-info.class) will be placed on the modulepath, not the classpath. In fact, placing a module on the classpath will cause the module declaration (module-info.class) to be completely ignored, which is usually not what you want. As a basic rule, the modulepath cannot see the classpath. If you create a module and put it on the modulepath, all its dependencies must also be on the modulepath. Thus, in order to write a module at all, all the dependencies must also have been converted to be modules. And many of those dependencies are likely to be open source projects, with varying release schedules. Clearly, this is a bit of a problem. Essentially, it would mean that an application would need to wait until every dependency had become a module before it could add module-info.java. The "solution" to this is automatic modules. An automatic module is a normal jar file - one without a module-info.class file - that is placed on the modulepath. Thus the modulepath will contain two types of module - "real" and "automatic". Since there is no module-info.class, an automatic module is missing the me ## Java SE 9 - JPMS modules are not artifacts DevFeed: [Java SE 9 - JPMS modules are not artifacts]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2017-04-24T08:12:00Z Content type: article Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [modules](), [Maven](), [Maven Central]() Tags: [bug](), [build-tool](), [java](), [java9](), [maven-central](), [modules]() ### AI overview This article explains that Java Platform Module System modules in Java SE 9 are distinct from build artifacts such as JAR files. Each project version can produce a different artifact while retaining the same module name. Build tools such as Maven select the artifact version, while JPMS assembles the runtime module graph and rejects duplicate packages on the module path. ### Source excerpt This is the next article in a series I'm writing to help make sense of the Java Platform Module System (JPMS) in Java SE 9. JPMS was developed as Project Jigsaw. Other articles in the series are Module basics and Module naming. Module != Artifact If you want to grasp what JPMS modules are all about, it turns out that it is critical to understand what they are not. In particular, they are not artifacts. Firstly, lets define an artifact. An artifact is a file produced when developing software. For a project on Maven Central, this includes jar files of bytecode, jar files of sources and jar files of Javadoc. We are interested primarily in the bytecode for this discussion. Secondly, lets assume that a project is going to have the same module name over time. This is just like package names - projects don't change package name with every release. Given this, what is the mapping between an artifact and a module? Versions Each version of a project will consist of a different artifact (jar file), perhaps released on Maven Central. Each version will have the same module name. But, we also know that the Java platform (JPMS) does not know about versions or version-selection. Therefore, when assembling a modulepath for Java SE 9, something else is going to have to choose the correct version of the module. This will typically be the build tool, eg. Maven. But while the classpath will tolerate having two versions of the artifact (typically with bad consequences at runtime), the JPMS modulepath will refuse to start if there two modules contain the same package, as would happen if two versions of the same module are found. Maven already manages versions of course, picking one version from a set of versions, where all with the same groupId:artifactId. With Java SE 9 we can say that Maven is picking one artifact from a set of artifacts to use in the runtime JPMS module graph. Artifacts JPMS runtime module org.joda : joda-convert : 1.2 Build tool must pick one of these artifacts for th ## Java SE 9 - JPMS module naming DevFeed: [Java SE 9 - JPMS module naming]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2017-04-20T14:01:00Z Content type: opinion Language: en Sources: [Stephen Colebourne]() Topics: [modules](), [Java](), [Software]() Tags: [best-practices](), [bestpractice](), [java](), [java9](), [jvm](), [module](), [modules](), [opinion](), [recommendations]() ### AI overview This opinion article recommends naming Java Platform Module System modules with reverse-DNS names related to their packages, preferably matching the super-package name. It explains namespace ownership and grouping packages into sub-modules without overlap. ### Source excerpt The Java Platform Module System (JPMS) is soon to arrive, developed as Project Jigsaw. This article follows the introduction and looks at how modules should be named. As with all "best practices", they are ultimately the opinion of the person writing them. I hope however to convince you that my opinion is right ;-). And as a community, we will certainly benefit if everyone follows the same rules, just like we benefited from everyone using reverse-DNS for package names. TL;DR - My best practices These are my recommendations for module naming: Module names must be reverse-DNS, just like package names, e.g. org.joda.time. Modules are a group of packages. As such, the module name must be related to the package names. Module names are strongly recommended to be the same as the name of the super-package. Creating a module with a particular name takes ownership of that package name and everything beneath it. As the owner of that namespace, any sub-packages may be grouped into sub-modules as desired so long as no package is in two modules. Thus the following is a well-named module: module org.joda.time { requires org.joda.convert; exports org.joda.time; exports org.joda.time.chrono; exports org.joda.time.format; // not exported: org.joda.time.base; // not exported: org.joda.time.tz; } As can be seen, the module contains a set of packages (exported and hidden), all under one super-package. The module name is the same as the super-package name. The author of the module is asserting control over all names below org.joda.time, and could create a module org.joda.time.18n in the future if desired. To understand why this approach makes sense, and the finer details, read on. JPMS naming Naming anything in software is hard. Unsurprisingly then, agreeing an approach to naming modules has also turned out to be hard. The naming rules allow dots, but prohibit dashes, thus lots of name options are closed off. As a side note, module names in the JVM are more flexible, but we are only cons ## Java 9 modules - JPMS basics DevFeed: [Java 9 modules - JPMS basics]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2017-04-17T05:17:00Z Content type: article Language: en Sources: [Stephen Colebourne]() Topics: [modules](), [Java 9](), [Java](), [Access Control]() Tags: [access-control](), [java](), [java-9](), [java9](), [jvm](), [maintainability](), [modules]() ### AI overview This article introduces the Java Platform Module System (JPMS), the major new feature of Java SE 9. It explains modules as a new JVM structural element that contains packages and enables stronger access control, while noting compatibility with most existing code. ### Source excerpt The Java Platform Module System (JPMS) is the major new feature of Java SE 9. In this article, I will introduce it, leaving most of my opinions to a follow up article. This is based on these slides. Java Platform Module System (JPMS) The new module system, developed as Project Jigsaw, is intended to raise the abstraction level of coding in Java as follows: The primary goals of this Project are to: * Make the Java SE Platform, and the JDK, more easily scalable down to small computing devices; * Improve the security and maintainability of Java SE Platform Implementations in general, and the JDK in particular; * Enable improved application performance; and * Make it easier for developers to construct and maintain libraries and large applications, for both the Java SE and EE Platforms. To achieve these goals we propose to design and implement a standard module system for the Java SE Platform and to apply that system to the Platform itself, and to the JDK. The module system should be powerful enough to modularize the JDK and other large legacy code bases, yet still be approachable by all developers. However as we shall see, project goals are not always met. What is a JPMS Module? JPMS is a change to the Java libraries, language and runtime. This means that it affects the whole stack that developers code with day-to-day, and as such JPMS could have a big impact. For compatibility reasons, most existing code can ignore JPMS in Java SE 9, something that may prove to be very useful. The key conceptual point to grasp is that JPMS adds new a concept to the JVM - modules. Where previously, code was organized into fields, methods, classes, interfaces and packages, with Java SE 9 there is a new structural element - modules. a class is a container of fields and methods a package is a container of classes and interfaces a module is a container of packages Because this is a new JVM element, it means the runtime can apply strong access control. With Java 8, a developer can express th ## Java Time (JSR-310) enhancements in Java SE 9 DevFeed: [Java Time (JSR-310) enhancements in Java SE 9]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2017-02-07T14:47:00Z Content type: article Language: en Sources: [Stephen Colebourne]() Topics: [DateTime](), [Java](), [LocalDate](), [API]() Tags: [format](), [formatting](), [java](), [java9](), [jdk](), [jsr310](), [localdate](), [stream](), [time]() ### AI overview This article reviews selected enhancements to the java.time API planned for Java SE 9 after its introduction in Java SE 8. It covers new LocalDate date-stream methods, higher clock precision and millisecond-compatible ticking, more efficient epoch-second conversion, expanded Duration operations, new Instant conversion factories, and additional date-time formatting and parsing support. ### Source excerpt The java.time.* API (JSR-310) was added to Java SE 8, but what has been going on since then? Java Time in Java SE 9 There are currently 117 java time issues targetted into Java SE 9. Most of these are not especially interesting, with a lot of mistakes in the Javadoc that needed fixing. What follows are some of the interesting ones: Main enhancements: JDK-8146218 - Add LocalDate.datesUntil method producing Stream. Adds two new methods - LocalDate.datesUntil(LocalDate) and LocalDate.datesUntil(LocalDate,Period) - returning a stream of dates. JDK-8068730 - Increase precision of Clock.systemUTC(). The clock in Java - System.currentTimeMillis() - has ticked in milliseconds since Java was first released. With Java SE 9, users of Clock will see higher precision, depending on the available clock of the operating system. JDK-8071919 - Clock.tickMillis(ZoneId zone) method. With the system clock now returning higher precision, a new method was added - Clock.tickMillis(ZoneId) - that chops off the extra precision to restrore the millisecond ticking behaviour of Java SE 8. JDK-8030864 - Add efficient getDateTimeMillis method to java.time. This adds two methods named epochSecond to Chronology that have no object creation to convert date-time fields to an epoch-second. JDK-8142936 - Duration methods for days, hours, minutes, seconds, etc. The Java SE 8 API of Duration turned out to be incomplete for certain use cases. This change adds a slew of new methods that allow parts of the duration to be reliably returned. JDK-8148849 - Truncating Duration. Adds a method Duration.truncatedTo(TemporalUnit) to allow truncation, similar to the existing method on Instant. JDK-8032510 - Add Duration.dividedBy(Duration). A new method to allow a duration to be divided by another duration. JDK-8133079 - LocalDate and LocalTime ofInstant() factory methods. Add new factory methods in LocalDate and LocalTime to simplify conversion from Instant. JDK-8143413 - Add toEpochSecond methods for efficient acc ## Code generating beans - mutable and immutable DevFeed: [Code generating beans - mutable and immutable]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2016-09-26T01:36:00Z Content type: opinion Language: en Sources: [Stephen Colebourne]() Topics: [Code generation](), [Java](), [Data structures](), [Code](), [ide](), [Open Source]() Tags: [abstract-class](), [code](), [code-generation](), [compilation](), [constructor](), [data-structure](), [hashcode](), [interface](), [java](), [javaone](), [jodabeans](), [properties](), [tostring]() ### AI overview This article discusses Java bean code generation, arguing that immutable beans and data structures are preferable to mutable beans. It compares IDE generation with annotation processors such as AutoValue, Immutables, and VALJOGen, which generate implementations during compilation. ### Source excerpt Java has long suffered from the pain of beans. To declare a simple data class takes far too much code. At JavaOne 2016, I talked about code generation options - see the slides. Code generation of mutable and immutable beans The Java ecosystem is massive. So many libraries releasd as open source and beyond, which naturally leads to the question as to how those libraries communicate. And it is the basic concept of beans that is the essential glue, despite the ancient specification. How do ORMs (Hibernate etc.), Serialization (Jackson etc.) and Bean Mappers (Dozer etc.) communicate? Via getters and setters. The essential features of beans have moved beyond the JavaBeans spec, and are sometimes referred to as POJOs. The features are: Mutable No-args constructor Getters and Setters equals() / hashCode() / toString() But writing these manually is slow, tedious and error-prone. Code generation should be able to help us here. But should we be using mutable beans in 2016? No, no, no! It is time to be writing immutable data structure (immutable beans). But the only practical way to do so is code generation, especially if you want to have builders. In my talk at JavaOne 2016, I considered various code generation approaches: IDE code generation This is fine as far as it goes, but while the code is likely to be correct immediately after generation, there is still no guarantee that the generated code will stay correct as the class is maintained over time. AutoValue, Immutables and VALJOGen These three projects - AutoValue, Immutables, VALJOGen - use annotation processors to generate code during compilation. The idea is simple - the developer writes an abstract class or interface, and the tool code generates the implementation at compile time. However, these tool all focus on immutable beans, not mutable (Immutables can generate a modifiable bean, but it doesn't match the JavaBeans spec, so many tools will reject it). On the up side, there is no chance to mess up the equals / hash ## Private methods in interfaces in Java 9 DevFeed: [Private methods in interfaces in Java 9]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2016-09-20T06:26:00Z Content type: tutorial Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [Java 9](), [interfaces](), [Code]() Tags: [code](), [feature](), [interfaces](), [java](), [java-9](), [java9](), [new-feature]() ### AI overview This article explains private methods on interfaces in Java 9. It contrasts them with the public abstract, static, and default methods supported in earlier Java versions and describes supported and invalid modifier combinations. Private interface methods may be static or instance methods and are not inherited by sub-interfaces or implementations. ### Source excerpt Java SE 9 is slowly moving towards the finishing line. One new feature is private methods on interfaces. Private methods on interfaces in Java 9 In Java 7 and all earlier versions, interfaces were simple. They could only contain public abstract methods. Java 8 changed this. From Java 8, you can have public static methods and public default methods. public interface HolidayCalendar { // static method, to get the calendar by identifier public static HolidayCalendar of(String id) { return Util.holidayCalendar(id); } // abstract method, to find if the date is a holiday public abstract boolean isHoliday(LocalDate date); // default method, using isHoliday() public default boolean isBusinessDay(LocalDate date) { return !isHoliday(date); } } Note that I have chosen to use the full declaration, with "public" on all three methods even though it is not required. I have argued that this is best practice for Java SE 8, because it makes the code clearer (now there are three types of method) and prepares for a time when there will be non-public methods. And that time is very soon, as Java 9 is adding private methods on interfaces. public interface HolidayCalendar { // example of a private interface method private void validateDate(LocalDate date) { if (date.isBefore(LocalDate.of(1970, 1, 1))) { throw new IllegalArgumentException(); } } } Thus, methods can be public or private (with the default being public if not specified). Private methods can be static or instance. In both cases, the private method is not inherited by sub-interfaces or implementations. The valid combinations of modifiers in Java 9 will be as follow: public static - supported public abstract - supported public default - supported private static - supported private abstract - compile error private default - compile error private - supported Private methods on interfaces will be very useful in rounding out the functionality added in Java 8. [Next page]()