Inside Java Newscast - Java 25, much like Java 21, will be described as a "long-term-support version" despite the fact that that's categorically wrong. Neither the JCP, which governs the Java standard, nor OpenJDK, which develops the reference implementation, know of the concept of "support".

Noob programmer here and I've recently taken an interest in Java. Been playing around with a bit and enjoying it overall. I started with C and kind of liked the procedural approach to problem solving but wanted something a bit more modern (you know, with strings and such) and Java is satisfying that.

One question I've been having however is whether or not Java is limited in any way by its heavy use of OOP compared to other languages that have a more multi-paradigm approach. Are other programming paradigms able to be used in Java, and if so is it common? Are different paradigms just different ways of organizing code and approaching problems from different angles? Or does Java's heavy use of OOP meaningfully limit in some ways compared to other languages/paradigms?

I'm not critiquing OOP so much as I am just curious whether or not its a limitation of the language in certain scenarios. Thanks.

EDIT: since my example stirred the pot a little bit to much (i even wrote that i dont want to discuss these explicit changes...)

Here is the actually question i want to answer:

How can i make changes to the JDK?

I've found some libraries like libp2p and not much else. This library feels... not very democratic, so to speak. As in, I think it's the opensource byproduct of a company doing a specific project and so it only concerns its own interests (and doesn't seem used at all outside their projects). Ideally I'd like DHT support, some nat traversal and not much else. What's people experience with this around here?

(To mods: not sure if this is a programming help question, I believe it's not since I've seen posts discussing libraries here but I'd understand if it must be removed)

Granted that it's highly subjective and opinionated, but what this author James Anderson states in this StackOverflow post very much resembles the voices of many like myself who are trying to switch from interpreted/dynamic languages to static and compiled ones like Java/C#. How do Java programmers tackle or respond to this stance?

Updates since the last time I shared this

• Minimum compatibility bumped to Java 21

• Generated code now uses switch expressions for (maybe too clever) type safe casts

• Options have their names shortened. generateToString -> toString_, generateEqualsAndHashCode -> equalsAndHashCode

• New "extends" option for dealing with more exotic cases.

System.out.println(Object.class.isAssignableFrom(String.class)); //true

System.out.println(String.class.isAssignableFrom(Object.class)); //false

This has always triggered me. I feel like that method is named backwards, IE the first example, I read it in english as "objects of type Object are assignable from variables of type String" However, that statement is false, because Since String extends Object, a variable of type String cannot reference an object of type Object.

But that statement evaluates to true. I feel like the method "isAssignableFrom" should be renamed "aVariableOfThisTypeCanReferenceObjectsOfThisClass" :

So then:

System.out.println(Object.class.aVariableOfThisTypeCanReferenceObjectsOfThisClass(String.class)); //true

System.out.println(String.class.aVariableOfThisTypeCanReferenceObjectsOfThisClass(Object.class)); //false

Anyone else agree?

BTW, it turns out this confusion is common. I googled:

java isAssignableFrom confusing

And there were several blogs and stackoverflow posts agreeing with me.

For example:

http://bryanpendleton.blogspot.com/2009/06/isassignablefrom-and-instanceof.html

I think that one of the reasons that I get a bit confused with isAssignableFrom is that it sort-of reads backwards from instanceof.

Assuming that you already have the Java SDK installed, these are the steps to get a hello world program running in TomEE.

1. Download / unpack Tomee.

   wget http://mirror.catn.com/pub/apache/tomee/tomee-1.7.2/apache-tomee-1.7.2-jaxrs.tar.gz tar -xvf apache-tomee-1.7.2-jaxrs.tar.gz

2. Create folders to store your app.

   mkdir -p apache-tomee-jaxrs-1.7.2/webapps/helloworld/WEB-INF/classes cd apache-tomee-jaxrs-1.7.2/webapps/helloworld/WEB-INF/classes

3. Create the HelloWorld.java

   vi HelloWorld.java

   import javax.ws.rs.*;

   @Path("/") public class HelloWorld {

    @GET
        public String home(){
        return "Hello World";
    }

   }

4. Compile it.

   javac -classpath "../../../../lib/*" *.java

5. Start the server.

   sh ../../../../bin/startup.sh

6. Navigate to page http://localhost:8080/helloworld

Lately, I’ve been wondering—maybe it’s time we imagine a real “Java 2.0.” A version of Java that breaks free from the decades-old design constraints and isn’t burdened by always having to preserve backward compatibility.

Yes, compatibility has been one of Java’s greatest strengths. But when it becomes a hard rule, it forces a lot of compromises. Just look at things like Date and Calendar—we all know they’re broken, yet they remain, because we can’t remove anything without breaking someone’s code.

Meanwhile, most modern languages today don’t even try to guarantee perpetual backward compatibility. Instead, they adopt semantic versioning or similar strategies to evolve the language over time. This gives them the freedom to redesign awkward parts of the language, deprecate outdated patterns, and experiment with new paradigms—without being held hostage by legacy decisions.

In contrast, Java often adopts features years after they’ve been proven in other languages—like var, record, and now pattern matching. The most extreme case? Project Valhalla. It’s been in the works for over 10 years, and may take 15 years to fully land. That’s half the entire lifespan of Java itself. It sounds insane when you step back—and honestly, it’s no surprise that other language communities poke fun at us for this kind of timeline.

Of course, breaking compatibility comes with pain. Python’s transition from 2 to 3 was rough, no doubt. But look at Python today—it’s cleaner, more consistent, and thriving. That pain was temporary. What’s worse is eternal stagnation in the name of safety.

Maybe what we need isn’t to blindly break stuff, but to invest in smoother migration paths. Imagine if Java provided official tools, clear upgrade guides, or even a “forward-looking” JDK mode—something that helps developers move ahead without feeling abandoned. That kind of vision might be what finally unlocks real progress.

Just some thoughts :)