12 ms·
Java 26 is here
- wiseowise 7mo agoAndroid as always in shambles. Shame that neither Google, nor ecosystem cares about Java because they’ve bought JetBrains kopium.
- pjmlp 7mo agoGoogle basically played a J++ with Android Java, with Kotlin as their .NET/C#. At least they are forced to partially update Android Java, now Java 17 subset, so that Kotlin can keep up with was is mostly deployed at Maven Central.
- xxs 7mo agoThat's a proper late 90s reference, props!
- cogman10 7mo agoPretty sure they did a J# ;). But I agree that Kotlin is their C#. The JDK and JVM has advanced so fast while android has been lagging. It's pretty frustrating, especially because google has been so slow to pull in changes from later java versions. A part of me wishes that android would just dump their hokey dalvik, ART, and other BS and just use the OpenJDK or a fork of the OpenJDK with whatever special sauce they need. A lot of the project Leyden stuff lends itself nicely to maybe someday being able to run real java on android. Edit: Apparently android is forking OpenJDK, since Android 7. https://en.wikipedia.org/wiki/Android_Nougat https://en.wikipedia.org/wiki/Android_Nougat
- freedomben 7mo agoDo you think it's legal reasons, technical reasons, NIH syndrome, or some other reason why Android doesn't use OpenJDK?
- cogman10 7mo agoA little bit of all of the above. Android's usage of Java started right as Sun was being acquired by oracle and right before the jdk was GPLed. ... And I'll be. Apparently Android is using the OpenJDK since Android 7. [1] [1] https://en.wikipedia.org/wiki/Android_Nougat https://en.wikipedia.org/wiki/Android_Nougat
- pjmlp 7mo agoIt isn't, check Gerrit commit history, they only take bits and pieces, plus ART doesn't do all bytecode equivalents. Some JVM bytecode don't have counterparts in Dex, rather get desugared into multiple instructions.
- freedomben 7mo agoWas ART better at the time they wrote it? Do you know if there were any reasons other than perhaps legal, that caused them to go that route?
- pjmlp 7mo agoMostly not wanting to pay Sun for Java Embedded licenses. https://venturebeat.com/ai/google-sun-wanted-money-for-android https://venturebeat.com/ai/google-sun-wanted-money-for-andro... The problem isn't ART per se, embedded Java vendors also have their own internal implementations, but the big difference is that they pay for their licensing and support standard Java.
- hencq 7mo agoJ++ predates C#. It was Microsoft's version of Java that wasn't quite compatible.
- cogman10 7mo agoCorrect, and J# was a brief transition language to help migrate Visual J++ applications onto the .Net SDK. J++ -> J# -> C# was the evolution. I say J# is a more apt comparison because like Microsoft's Java, android has a substantial set of APIs that aren't part of the JDK standard. Working on Java vs Anrdoid is practically like working with the JDK vs .Net.
- pjmlp 7mo agoJ++ already had those extensions, hence the lawsuit.
- pjmlp 7mo agoJ# was the transition product to port J++ into .NET, I am quite sure. Not only I was there on those years, my employer was a MSFT partner that got to test .NET before it was announced to the world, so that we could have our products as part of the announcement event in Portugal. OpenJDK is cherry picked, Google only picks pieces of it, rather than full compatibility.
- rossjudson 7mo agoNo idea what you are talking about. Google internally has a massive amount of code based on JDK 21, and the (amazing and completely transparent move) to JDK 25 is nearly complete. That's the full OpenJDK @ Google, and it has been for a very long time.
- pjmlp 7mo agoI am talking about fu..... Android!
- cyberax 7mo ago> Google basically played a J++ with Android Java No, they didn't. Google happily used regular Java until Oracle played Oracle. Then Google stopped updating the supported Java language version and started diversifying away from Java.
- pjmlp 7mo agoThey definitely did not, it was Android Java from day one, and Oracle should have crushed them like Sun did to Microsoft, unfortunately Google was the geek darling of do not evil, thus they got a pass from fanboys.
- cyberax 7mo agoAndroid was not 100% compatible with Java, but mostly because it had a specialized environment. It did not support things like dynamic bytecode generation, but it faithfully reproduced pretty much everything else that made sense. And yeah, it would have been so much better with Oracle(tm)(r)(c)(fuckyou) running Android with Pure Java(tm)(r)(c)(screwyou) instead. Now with EJB5 and more XML! You might be too young to remember, but SunOracle essentially abandoned the Java language development for more than a decade, until Kotlin provided a very much needed magic kick. Oh, and if you think _Google_ is bad for splitting the Java ecosystem, let me introduce you to J2ME and JavaCard.
- pjmlp 7mo agoMy dear I am programming since 1986, and a Nokia alumni.
- krkelldlgl 7mo agoWhat a clusterfuck this still is. I’m glad I haven’t written a LOC in this brittle eco system.
- geodel 7mo agoOracle's Java Mobile Edition could've crushed Android. No one stopped them. > Google was the geek darling of do not evil, thus they got a pass from fanboys. Oracle's case against Google went all the way up to Supreme Court of US. Oracle did not win anything substantial in courts against Google is not fanboys' doing.
- sulam 7mo agoI wouldn’t blame Google for Oracle being a lawnmower.
- haolez 7mo agoI was pretty surprised when I learned recently that the Java alternative for green threads doesn't use colored functions. It put Java in a higher place in my perception.
- dmos62 7mo agoWhat are colored functions?
- jauco 7mo agohttps://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... In this context: functions anotated with async
- ihumanable 7mo agohttps://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... The terminology is used to talk about languages that have async and sync functions where you declare (or color) the function as either async or sync. In these languages it's pretty common for the language to enforce a constraint that async functions can only call other async functions. Javascript / Typescript, Python are popular examples of languages with colored functions.
- cogman10 7mo agoAny time you have a barrier between one function being able to call another. The original article on this called them red functions and green functions. A green function can call a red function but a red function can't call a green function. In terms of async, it's when you have to have a function with "async" attached to it and making it so that only other async functions can call async functions. It ends up creating a weird circumstance where you can end up with a lot of duplicated APIs, particularly in libraries, because you are providing both async and non-async versions of functions.
- dwaite 7mo ago
- vyskocilm 7mo agoJEP 504: Remove the Applet API Glad to see this being removed. Java plugins especially on Linux were awful and required by tons of corporate stuff. Anyone remeber IcedTea Web? A functional and opensource Java plugin and Java Webstart implementation?
- hju22_-3 7mo agoRemember IcedTea Web? Oh boy, I still have environments that use it.
- cyberax 7mo agoI made several Webstart corporate apps back in the day! The infrastructure was pretty neat, when it worked. And it was a whole lot better than JS back then, still in the IE6 times.
- vyskocilm 7mo agoYeah XMLHttpRequest and activex thing IE6 had. That was Javascript style that days.
- anthony88 7mo agoNote that the the Java plugin and webstart was removed a long time ago. I personally regret that the API was removed as it's a few classes and they are still used. Just search JApplet on Github. It's also possible to run applets in the modern browsers with WASM or in Java IDE's as plugin.
- freedomben 7mo agoAs someone who has been out of the Java world for many years, but recently forced back into it due to Android dev requirements, Post lawsuit, what is the relationship between Android (Google) and Java now? When can we expect 26 on Android? On that note, why is Android always so far behind? Is it because Kotlin is primary or is it deeper? Did the lawsuit play a role?
- deleted 7mo ago[deleted]
- gf000 7mo agoJava's primary development happens on OpenJDK. Android has their own runtime (creatively named as Android runtime), which does not run java byte code, but their own binary format. JVM class files can be compiled to that format, but the support for that always lags behind OpenJDK java versions. Part of the reason kotlin became the de facto language on the platform was that they supported only terribly old Java at the time, that didn't even have lambdas even though it was already out. The problem is that most of the Java libraries want to follow the desktop/server, aka the OpenJDK scene, but that would make them incompatible with Android so there was/is some incentives to bump up the version they support.
- whynotmaybe 7mo agoI've used Java decades ago (anyone remember servlet?) and I'm glad that I can use flutter for Android development.
- freedomben 7mo agoI do really need to give flutter a try. My only reason I haven't yet is that I have no desire to learn Dart. How do you (or anyone) like Dart compared to Java or Kotlin?
- whynotmaybe 7mo agoWent from c# to flutter and it was easy. The new concepts for me were using immutable classes with the keyword "final", and the whole concept of state management in mobile apps because I've mainly done backend. I've only used kotlin in the android files for flutter but nothing else. I'm also not totally objective on that because my Java experience is from a long long time ago, my general feeling is that flutter is less bloated than java. And I don't want to start a culture war on this, because we all know turbo Pascal is the best.
- badgersnake 7mo agoVector API (Eleventh Incubator) - maybe 11th time’s the charm.
- mjuarez 7mo agoWhen it was about the 7th incubator iteration, I got curious so I read the actual JEP history, and it had this informative tidbit, also included in the latest release: "The Vector API will incubate until necessary features of Project Valhalla become available as preview features. At that time, we will adapt the Vector API and its implementation to use them and then promote the Vector API from incubation to preview." Project Valhalla has been "in progress" for at least a decade now (Wikipedia say 2014). So who knows when we'll actually see a Vector API in preview.
- gf000 7mo agoOn the other hand, there is a bunch of movement on Valhalla side nowadays. You can download a build and try out value types yourself!
- lenkite 7mo agoThey made the problem complexity of Valhalla ~10,000x harder by very strict backward compatibility needs. Project Valhalla can take many human generations and multi-billion man years to finish as a consequence.
- xeubie 7mo agoI think astronomers could measure the age of the universe in nano-Valhallas. Every year, it feels 50% closer to completion... In all seriousness I'm happy with what Mr. Goetz and the team have done. Sealed interfaces (java 17) + exhaustive switch statements (java 21) means we now have union types in java! And instead of jumping on the async/await bandwagon we now have a more general solution that doesn't lead to API duplication (virtual threads). But Valhalla has been a veeery long time coming.
- noelwelsh 7mo ago'Tis true. At the same time, Project Valhalla will be the most significant change to the JVM in a very long time, and probably its best chance to stay relevant in the future.
- dzonga 7mo agothe people that work on Java & the JVM are very smart. it has become a best of breed language - hell its better than Go for industry purposes. the drawback with Java will always be the CULTURE - (maybe someone can insert a quote of how in physics progress is only made, when old physicist die - I don't wanna be morbid ) but with Java same that's when the culture will change. All those people using typescript (could be using Java - but the culture doesn't want them and consider them heretics for not embracing religion of OOP and FactoryFactory)
- karel-3d 7mo agoI didn't use Java since 7, but from people that do - nowadays you basically don't code Java, you code Spring Boot. And that has all the bad things you think when people say "Java". I don't know if it's true though.
- ezfe 7mo agoThere's a lot of programming that has nothing to do with SpringBoot - and I say this as someone who works in a backend team that uses SpringBoot for all our apps.
- deleted 7mo ago[deleted]
- shermantanktop 7mo agoYou're talking to specific people. A completely different culture of Java usage can and does exist a lot of places. It is absolutely true that success creates a certain ossification of practice. But SpringBoot is not necessary, any more than Guice or any other framework-y thing.
- gf000 7mo agoThere are more Java devs than people in my home country. Like how could you even give a single description for all of them? They all work on vastly different stuff, from low-latency trading to robotics, to regular old CRUD. Not even the CRUD part is as monotonic though as you make it out to be.
- rusakov-field 7mo agoAh , Java, a language I pray I never have to ever touch again.
- dxxvi 7mo ago[flagged]
- albusdumbledor3 7mo agoDont you have parents to tell them that? Open a pr in the codebase
- jesse_dot_id 7mo agoCool. I feel as though I'll never be able to escape 8, or ignore Ellison's legacy, unfortunately.
- MeetingsBrowser 7mo ago> or ignore Ellison's legacy, unfortunately. Can you elaborate?
- olivia-banks 7mo agoReally glad to see we're getting a native PEM API.
- lucketone 7mo agoPleasantly surprised. But it is a preview though.
- ludovicianul 7mo agoI program in Java for more than 15 years now. I can resonate with people hating the language from it's early days due to the experience with all the enterprisy features and over abstractions. Or confunding Java with the Spring ecosystem. But Java came a long way over the years. It's now what many would call a "modern" language. It's less verbose, has many of the features people find appealing in Scala and Kotlin and it can even compile to native binaries using GraalVM. This made building CLIs in Java feasible. Or lambdas.
- zadikian 7mo agoLack of virtual threads was its biggest remaining problem because this made the common ways of doing cooperative multitasking very ugly. Go's big thing was having that from the start. Maybe now that Java has it too, it's set? Though JS will still have the least boilerplate because of the way it handles types.
- deepsun 7mo agoIMO, Kotlin coroutines are better of Go's goroutines, although they are a little different beasts to compare honestly (apples and oranges). Go inits goroutines on stack, but min size is 4KiB, so it's not trivial to grow them. Also you need to watch over and destruct goroutines manually to prevent memory leaks (using var wg = sync.WaitGroup defer wg.wait() wg.Add(1) go func() { defer wg.Done() } ) And create a separate channel to return errors from a goroutine. Definitely more work.
- zadikian 7mo agoIt is, but your typical backend code isn't dealing with that most of the time. You can just use blocking I/O in handlers.
- Ternari 7mo ago>you need to watch over and destruct goroutines manually to prevent memory leaks No, you don’t. Any stack-allocated resources are freed when the function returns. WaitGroup is just there for synchronization.
- oystersareyum 7mo agoDo changes to Java itself impact e.g. Clojure? I think it uses many java primitives instead of emitting jvm byte code but I can be wrong.
- lucketone 7mo agoIn general, some java language changes do involve JVM changes. So yes, it impacts other jvm languages like Closure. Here most obvious would be GC improvements.
- jillesvangurp 7mo agoSome of the standard library stuff could be usable from Clojure and other languages. The jvm level optimizations (garbage collection) should benefit all jvm languages. The language changes are mostly not that relevant unless you program directly in Java. I use Kotlin myself (after doing Java since 1995). Most of the overview here reads like they are adding a lot of stuff that Kotlin has had for many years. Structured concurrency, lazy stuff, etc. You can argue about which language does it better/nicer/etc. but that debate is a bit boring to me. But good for Java developers that they are getting some obviously useful things that so far they never had. Progress is nice. Better late than never.
- gf000 7mo agoJava improvements usually have a runtime component, so no, kotlin simply couldn't have had Lazy no matter what. It was just syntactic sugar for a getter.
- jillesvangurp 7mo ago"Just syntactic sugar" That's what most modern programming languages provide. Syntax matters. Kotlin offers a lot of syntactic sugar for things that are a bit verbose in Java. The new structured concurrency stuff in Java is actually a great example of that. More or less does the same thing, Kotlin manages to do it with a nice Kotlin DSL. Java does it with a lot of builders and function chaining. Which is a lot less readable. In the end, Java caught up and you can now use this for more complex concurrent/parallel code (both should be possible with this, like it is with co-routines in Kotlin). Which is a good thing.
- Bnjoroge 7mo agoMan I still have scars learning Java in college. Took the entire fun out of coding until I ended up learning C.
- AgentMarket 7mo ago[flagged]
- GTP 7mo agoI haven't read a Java manual since the time of Java 8. Do you have any books or other resources you could recommend to catch up with all that has changed in these years?
- severino 7mo agoYou might find those useful: https://www.marcobehler.com/guides/a-guide-to-java-versions-and-features https://www.marcobehler.com/guides/a-guide-to-java-versions-... https://advancedweb.hu/a-categorized-list-of-all-java-and-jvm-features-since-jdk-8-to-21/ https://advancedweb.hu/a-categorized-list-of-all-java-and-jv... And this more like a reference: https://javaalmanac.io/ https://javaalmanac.io/
- rileymichael 7mo agohttps://javaevolved.github.io/ https://javaevolved.github.io/
- esfandia 7mo agoA couple of books were helpful to me, both by Venkat Subramaniam and published by Pragmatic Programmers: - Functional Programming in Java - Cruising Along With Java (this covers everything else that is "new" other than functional programming)
- einrealist 7mo agoI have been using Java since version 1.4. Both the language and its ecosystem have come a long way since then. I endured the height of the EJB phase. I adopted Spring when version 1.2 was released. I spent hours fighting with IDEs to run OSGi bundles. I hated building UIs with Swing/AWT, many of which are still in use today and are gradually being replaced by lovely JavaFX. When I look at code I wrote around 12 years ago, I'm amazed at how much I've matured too.
- tannhaeuser 7mo ago> I hated building UIs with Swing/AWT, many of which are still in use today and are gradually being replaced by lovely JavaFX. Dude JFX yielded what was called RIAs to JavaScript like almost 15 years ago. Of the three major GUI toolkits Swing, JavaFX, and SWT it was Swing that gained HighDPI support first (10 years ago), and continues to be the base for kick-as IntelliJ IDEA and other Jetbrains IDEs.
- zelphirkalt 7mo agoSwing was simpler in some ways than JavaFX. I still remember JavaFX treeview taking 3 Generics and I was unable to figure out what one of them is for from the docs. Had to go on Stackoverflow, where someone said it basically didn't matter. But JavaFX looked great at the time.
- zelphirkalt 7mo agoOne of the best tools I built was years ago with Swing and Miglayout. Still remember it fondly.
- OSaMaBiNLoGiN 7mo agoAll the changes look great. But I don't know how I feel about the syntax. A lot of things that very well could be first-class just aren't. Instead of a `lazy` keyword, we get `LazyConstant<T>`. I'm sure there's reasons as to why. I just don't know them.
- ivan_gammel 7mo agoIt‘s easier to evolve library code. If Java would ever infer type of constants from initializer (makes more sense than a new keyword), it could look nice and powerful: private final LOG = lazy(logger(MyThing.class));
- vips7L 7mo agoBecause library code is easier to maintain and for people to understand. And plus if you add a new keyword someone else will complain about complexity of keywords.
- samus 7mo agoOnce introduced, keywords and Java syntax is nearly impossible to change or to remove. If it's possible to get the job done using a class, perhaps with some JVM magic, it's not wise to whip out new syntax.
- gib444 7mo agoI wonder what percentage of java code in the world is still java 8, and always will be?
- gf000 7mo agoStill a lot, but in absolute terms the majority of Java applications are 8+ for 4-5 years now, according to Oracle's statistics - so they are a minority. It's just that there are so many java projects that it is still a huge number.
- devnotes77 7mo ago[dead]
- elgllhlhmh 7mo agoToo little, too late. Followers.
- larrylawnmower 7mo ago[flagged]
- nameconflicts 7mo agoI think Java became popular because of Sun. My experience with Java-based apps is bad. Laggy, resource-heavy, IDE bound, and it causes premature hardware performance degradation.
- Tostino 7mo agoHeh, you have no idea how many websites you interact with daily are powered by Java backends in that case.
- microflash 7mo agoModern Java is pretty succinct and expressive and I enjoy working with it. Like any long-lived project, Java has its quirks and baggage but you can let go of that baggage if you want. The ecosystem is evolving nicely with new features and it is quite pleasant to work with these days. I’m looking forward to migrate apps at work to 26.
- EdwardDiego 7mo agoSeeing as we're having a $LANG war, after 15 years in JVM land, I moved to a Python / Go shop, and fuck I miss Java. Not so much the language (although modern Java is pretty slick), but the stuff surrounding it. * No typosquatting issues because every package has a group id verified by real humans and DNS TXT records. * JMX as a standardized mechanism of exposing ways to interact with running code / expose metrics. (Even if you have to deal with the stupid ass protocol where you have to connect using a DNS identity the JMX server recognizes) * Logging libraries that give people running the code control over what gets logged and how, not the developers (looking at you Golang, wtf is with your logging approach where devs have to explicitly consider the fact that you might want to run logging at DEBUG and code it into your start up args?) * The ability (via JMX) to set, at runtime, one particular logger in one class or file to a desired logging level without restarting the application. * The performance of the JVM. * The vast FOSS ecosystem. * Not having to fight C build chains for that one dependency that's using CGo or a Python wrapper around a C lib that no wheel supports for your given tuple of Python version, OS, and architecture. Honestly, as someone who is a self-taught developer who taught himself in Python, I thought I was coming home to my first love. Turns out, I really hate the horrible things you can do in Python - looking at you Django, don't be so dynamic your brains fall out - and really dislike the experience of trying to run a Go service compared to a JVM service. Java and its ecosystem is just good at getting shit done in a predictable manner at both the dev level and ops level.
- HendrikHensen 7mo ago> * No typosquatting issues because every package has a group id verified by real humans and DNS TXT records. While I think this is a huge boon, have you ever published a package on the Maven Central repository? I must confess I haven't in a few years now, but when I did until ~3 years ago it was a major pain in the ass. And every release again. I think there's something to say about Go's model where the package is just in some Git hosting and a release is just creating a tag. As a package maintainer, this is just pure bliss compared to the Maven thing. > and really dislike the experience of trying to run a Go service compared to a JVM service. What are you running into specifically? I have the complete opposite experience. With Go, 1 small binary comes out that I can run anywhere (and put into a distroless container), whereas with Java I have to find a way to somehow run a full JVM (most often with (large parts of) an OS too). Perhaps you're alluding to the things you can do with JMX, but I have never really seen much benefit in that. I found it trivial to add similar functionalities with internal HTTP endpoints easily. But since I don't have much experience in this particular area, probably I'm missing something.
- pregnenolone 7mo agoIf we ignore the fact that value types likely won’t ship before we have flying cars, Java has evolved greatly. I really like how they’ve solved concurrency, but I dislike how they’ve handled modules but this a minor issue. The main problem with Java has always been its build tools. They’ve consistently been bad and continue to be. Even today, creating a bundled application with a stripped down JDK with jlink and jpackage is incredibly painful. You’ll need extensive knowledge of the Java CLI, modules, build tool plugins, or tools like Mill which simplify using jlink and jpackage, but even then it remains complex and frequently fails. In reality it should be as simple as something like "java package". Even these days, I frequently see Java developers presenting their desktop apps on Reddit and if you look at how they deploy them, it's often a fat JAR because they struggle to use jlink and jpackage effectively. Ironically, even generateing a fat JAR can be challenging. As someone who has spent over two decades developing desktop applications including witnessing the shift to horrendous Electron firsthand I can tell you that this was a primary reason Java basically vanished from being so prevalent on desktops. Inexperienced developers often struggled to deploy even simple Java applications, grappling with either runtime incompatibilities (Ironically, developers are somewhat reintroducing the same problem with WebView-based applications) or having to tell their users how to launch a Java app. While some claim desktop apps are dead – which is nonsense – the same applies to CLI applications. CLI apps remain prevalent, primarily written in native languages or Golang, sometimes even Node or one of its derivatives. Rarely Java for the reasons I just mentioned and don't get me started with Graal Native. If someone decides to write a simple trivial CLI app in Golang, they'll simply build it with a single command and be done with it. With Graal Native, you'll have to go through using the tracing agent, and if you're lucky you'll have a fat native executable after minutes of compile time. Forget Graal for a minute though. Java would already go a long way if bundling your application with a stripped down JDK (jlink) was as easy as typing in a single command without having to deal with complicated Maven or Gradle plugins.
- spopejoy 7mo agoTIL Mill, I've been in build hell trying to package a javafx GUI gradle project that depends on a non-module-ified lib (usb4java, long story, no I can't use anything else). Beryx/badass failed entirely, was able to get something working with Gradle doing jlink and manual CLI jpackage ... But tbh the whole experience makes me distrust the Java ecosystem if you're supporting anything that is slightly out of the community's view or priorities. Even JavaFX shows very patchy support for certain very standard UI concepts, and the situation with packaging is bad as you say. Anyway, is mill worth switching away from Gradle? (Does mill integrate at all with idea?)
- zvqcMMV6Zcr 7mo ago> My hope is that the first JEPs out of Project Valhalla will be announced later this year I have heard about Valhalla at least around release of Java 8. That said that site is a solid description of other current and upcoming JEPs.
- winrid 7mo agoLazy Constants looked interesting. The impl uses unsafe: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/lang/LazyConstantImpl.java https://github.com/openjdk/jdk/blob/master/src/java.base/sha...