# javaideas Published articles for javaideas. 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 ## 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