Java is really conservative language-wise while C# is pretty much add everything you see, reminiscent of C++.
Also, a significant part of Java development happens at the runtime level, where I would wager the catch-up is in the opposite direction, in some areas by quite large margins.
Not considering async/await (because I'm not really a fan), they're neck-and-neck in my opinion. I don't think C# has been as careful with its abstractions and the general aesthetic of the language to the degree that Java has; but in many cases you can almost compile a block of Java as C# and vice versa. I think the primary differentiator is what toolchain/ecosystem you prefer, and I'm solidly on the Java side of that line.
That being said, I'm currently getting paid to write C#, so if you've got any resources for converts, I'd love them! :)
What do you think is more elegant in Java than C#? I like both but I think things like LINQ, delegates, reflection, nullabity and even properties are much cleaner in C# vs streams (exceptions?), consumer<T> (weird names. accept? not invoke?), erasure and then just in general its not as nice, Optional<T> (its nullable?!), and getters/setters (I don't want to code gen this away).
> What do you think is more elegant in Java than C#?
Broad availability of third-party libraries? Java Flight Recorder? IntelliJ? Multiple build system options including first-class support for Bazel, Gradle, and so on. (Msbuild gets old quick...)
That said, personally I prefer TypeScript over all of the above if performance isn't an issue. ;-)
We're talking about language design choices not ecosystem.
Even still, libraries are not a problem. Nothing you can't do in C#. You should check out Rider. Bazel and Gradle are cross platform as well.
Flight Recorder is good. I'll give you that. The .NET debugging tools are top notch...on windows. JFR wins out handily until the Linux tools reach parity. Though, again, this is all ecosystem and not language design.
>I don't think C# has been as careful with its abstractions and the general aesthetic of the language to the degree that Java has
You say "careful", others would say "stubborn". The refusal to add things like operator overloading lead to a much less aesthetically pleasing language to read and write.
I can understand the resistance to traditional operator overloading, but something like implementing a Monoid interface which specifies operator methods might work. I think the sort of value types that people are likely to implement with Valhalla will make the case for this much stronger.
Nice to see that Records are finally out of preview. But note that Sealed Classes are still in Preview mode and are subject to change (or removal) in newer versions.
Very cool to see that Scala continues to have a huge impact on Java’s roadmap.
Records and Sealed Classes are borrowed from Scala.
Could be not the best news for new Scala adoption, but good news for developers having better abstractions in Java
Edit: Kotlin, and other languages should also mentioned since they also include similar features. I still think Scala has had the most influence over the years.
We see similar developments with C# borrowing features from F#, with records in v9, pattern matching, etc.
While it's good for C#/Java, it does make it harder to push for adoption for a language such as Scala and F#. Why bother investing in the languages with a much smaller market share when the big boys adopt good bits and pieces from them constantly?
> Why bother investing in the languages with a much smaller market share when the big boys adopt good bits and pieces from them constantly?
This won't always apply, but sometimes (many times?) there's a software endeavor that permanently feels on the margins of a programming language's capabilities, whatever that means. You may forego market share in order to be 5 or 10 years ahead of current practice. In other words, the mainstream isn't converging to a stable F# / Scala / whatever. It's lagging behind. It's not the last time that a mainstream language adopts a feature that has been available for years in a more fringe ecosystem.
In practice, I'm sure the most important thing is humans and their skill, so mainstreamness matters. But if you can somehow be less sensitive to that, you may reap a lot of benefit from using Foo before it was cool.
Another thing to note that cutting edge languages do not always deliver great features , they also deliver with great frequency half baked features to be discarded or deprecated in few years. Also since most effort spent on language , tooling remain primitive and slow for long time.
So I do not see them a sure win for projects I work on.
The only big F# feature I know of that's fallen out of favor is type providers, and, IMO, that's not because the feature was half-baked so much as because it was one of the many casualties of .NET's transition to being a truly cross-platform toolkit.
Because Scala is a truly innovative and experimental language that came out of a programming language research group. That's why there's a lot of features that didn't play out well in real-world. F# started out as .NET rendition of OCaml. Most languages initiated by large crops don't try to be innovative, rather they take approaches introduced by different niche languages (many of them are only for research purpose) and incorporate to their language. Languages that try cater to a large audience should be adopting features from experimental languages.
F#'s relationship has been vastly overblown. The truth is that they're about as closely related as C# and Objective-C. In the same way that the overlap between C# and ObjC is basically just the C bit, the overlap between F# and and OCaml is basically just the ML bit. (Actually, even less than that.) You could say that it was inspired by OCaml, but it includes almost none of what makes OCaml OCaml, and adds a lot of its own new ideas.
I haven't touched OCaml in a while, but the things it has and F# doesn't that I can remember include: Functors (in the ML sense), camlp4, polymorphic variant types, multiple inheritance, class interfaces.
Things F# has that OCaml lacks: Extension methods, units of measure, type providers, quotations, computation expressions, active patterns, overloading.
Probably most of the F# things could be (and perhaps have been) added to OCaml with camlp4, which is more powerful than F#'s quotations. Versus, F# may never be able to have all of OCaml's ad-hoc polymorphism features. So there's that. But I'm mainly meaning to compare what's actually built into the language.
Great point about half-baked features. The investment boils down to risk-reward. Can we say that the features that are introduced into Java at this point are features that have stood the test of time in other languages?
I have already used `records` in some project I work on. To me it does not look too clever / funky. It still looks like very obvious Java code but little more concise.
>Why bother investing in the languages with a much smaller market share when the big boys adopt good bits and pieces from them constantly?
because if you know exactly what you want to do there's no reason to settle for the second best thing. If you want F#, no harm with going exactly with F#.
I talked to a bunch of Jane Street engineers once and the consensus seemed to be that Ocaml, despite its very small footprint, actually helped them attract the kind of people who were super enthusiastic about building really good stuff with a good technology, so it actually made recruiting for them easier.
> actually helped them attract the kind of people who were super enthusiastic about building really good stuff with a good technology, so it actually made recruiting for them easier.
Sounds like a strong case of selection bias.
There is no shortage of people who are super enthusiastic about building really good stuff with good technology, and it's hard to believe that it's easier to hire Ocaml engineers than other languages.
I really don't want to sound elitist, but there is the issue that probably 90% of people who have ever written code for money know enough Java to get by and credibly claim they can do it on a resume. Just the ubiquity in university intro courses and enterprise use means everyone gets exposed to it.
On the other hand, if you see someone took the time to learn OCaml, I think you can be reasonably well assured they legitimately love programming. Signal value jumps from "this person has ever programmed" to "maybe this person has a real passion for it."
Agreed. I worked with a team who was heavily into scala and one of their beliefs was that all the smartest people want to work on scala, thus having the company use scala will filter only the smartest people to want to work for us.
The C# versions of F# features tend to be pretty clunky compared to the F# versions. This is because F# was designed for them from the beginning, rather than having them tacked on. Functional programming is getting easier in C#, no question about that, but honestly, it still kind of sucks. And the OOP-minded C# devs on your team still won't be able to make sense of your code that leverages all these fancy new features anyway.
But it's fine, we don't really care about language adoption if the best most supported most tested most hiring languages swallow their features, right ?
What matters is what we do with the language, more than the name of it no?
The problem (as I see it, anyways) is that the 'big boys' that I referred to in my initial comment have been around a long time (2000 for C#, 1995 for Java) and over that long history, have had a slew of language changes. They are starting to suffer from the same problem that C++ suffers from, where every shop defines their own subset of the language with which they use. Meanwhile, the languages that they graft features from (e.g., F#) tend to be smaller and more coherent with respect to the feature set.
And even C#, which has grown a lot, tends to have pretty orthogonal features, so that you don't end up too often in C++'s problem that every feature interacts with every other feature and complicates it.
Really sorry to ask the dumb question here, but what is V9? A cursory Google search didn't show me anything about e.g. a major update to the V8 JavaScript engine?
"We see similar developments with C# borrowing features from F#, with records in v9, pattern matching, etc."
Parsing that sentence the subject is C# and F# is referenced, but the subject of the sentence didn't change, it remained C# thus logically v9 applies to it.
This is why it's so important to have different programming languages! Sometimes it's hard to do things differently when you are just looking at your own programming language, and the tools it has available to it. Not everyone programming language needs to be a behemoth to be useful to other people. I say keep making new an interesting programming languages! It will only lead to better programming languages over all
Yes you are right, records have been around for a long time.
COBOL was a popular, very early language supporting hierarchical data of different types. This dates back to approximately 1960.
FORTRAN didn’t have records other than I/O “records” (at least for the first 20 years). ALGOL-60 didn’t have records. Algol-68 did have records, however Algol-68 wasn’t in very widespread use. I never had an opportunity to use it; compiler technology at that time wasn’t really ready for such a challenging language. Algol-68 may not have had widespread use, but a number of it’s features made their way into influential languages like C, Pascal, and Simula. These languages did have records.
As I recall, IBM’s PL/1 did have records, I seem to recall using them in the 70’s in a PL/1 program. PL/1 was kind of an amalgamation of FORTRAN and COBOL’s features.
In the end... Pascal was/is hugely influential, and, yeah, it called these kinds of things "Records." But the funny thing is it's been so long since I wrote Pascal or Modula-2 that when I first heard the term "Record" in the context of Java I never made the connection.
I think it's fair, though, to say that it's likely that the implementation and/or semantics may be more based on other JVM languages, who have to work on Java's terms.
In particular, I'm talking about the fact that Java doesn't really have "copy types" or "pass by copy" or whatever. So, sure, C has struct, Swift has struct, etc, but Java can't really model its version off of the way those work.
No, I was talking about the now usual in the English-speaking practice amplification of its meaning as "can be supported or shown by persuasive argument", e.g., That is arguably the best book on the subject.
"Data" is such an overloaded and vague term, anyway. Almost all classes have "data", so what the heck is a "data class"? Is it one that only has data (not behavior)? Nope- these can have arbitrary methods.
So, I'm kind of glad they didn't use it. (But, to clarify, I really don't care what color the bike shed is)
I'm more wondering why they didn't go with "struct" or "value class", especially because the latter is exactly what we've been calling "class whose equals() is defined by content rather than identity" for many years.
Because while in the end project valhalla will not call them value classes, it is a sort of an overloaded term.
Structs/value types can be mutable, records are not. They are basically tuples with names. And as far as I know, while records have a sane default equals defined, they are still identity objects in that they are passed by reference.
But in any case, I'm thinking that the real timeline is more that Java is prioritizing features that are most attractive from Kotlin, which borrowed the ideas from Scala. But Scala never got super popular, so there was not much pressure or "proof" that these were good ideas until everyone fell in love with Kotlin.
I think Kotlin is more at risk than Scala on the server at least. Scala still has a lot of advanced features that sets itself apart. Kotlin is a better Java but Java is catching up fast.
Agreed. But Kotlin 1.5 will have enough interesting stuff with the new inline class and const methods that I think it'll keep its appeal for quite some time.
Developing now 80% in Kotlin and 20% in Java (on backend), I really think the main advantage of Kotlin over Java is nullability. You can use @Nullable/@NotNull annotations in Java, but nullability being a part of the type system in Kotlin is better. I also love being able to create simple functions and add extension methods to existing classes. But still, nullability is the strongest advantage of Kotlin and I don’t see how Java will address it.
Agreed about nullability. And Java will never fix it fully or I'll eat my hat.
... but, you have to be pretty damn good to win out over the native language of a platform. And if it were just Kotlin today vs. Java 16, I think Kotlin is a much nicer language, but it doesn't really differentiate itself that much. Sure, it's syntax is much nicer, but you still basically have the same semantics as Java. You have classes; everything is a reference; no const/immutable data; no (good) general way to clone things; you have the same-ish type system with inheritance and interfaces, but no type classes; still have weird shit like sized numeric types with over/underflow; exceptions for error handling; etc.
At least Scala has monads and type classes, so you can say it actually has some expressability that Java truly doesn't. I'm not sure that Kotlin has that. Clojure is a totally different beast that really doesn't directly compete over Java devs, IMO. It just happens to use the JVM as a platform.
But I fear kotlin will fall in-between all the platforms they try to support, and will end up comparatively bad on all. Like, you can’t really target both your coroutines on each platform as well as project loom properly, same with project Valhalla and the like.
Why can't coroutines take full advantage of Loom's green threads on JVM and do other stuff on Native/JS/whatever?
I generally agree that being multiplatform is a lofty goal. And as much as I like Kotlin, it clearly inherits some of Java's (IMO) deficiencies. I'm not sure why I'd want those deficiencies exported to my native code when I could use lots of other nice languages.
I think Loom can be abstracted away by Kotlin quite easily. Valhalla on the other hand won't work at all. You won't be able to have inline classes in android/older Java versions. Even more - specialized generics.
I hope they're subsidizing the Scala project, and Kotlin too. Nothing better for a dominant player than having other people scout the territory for you.
Can't read whether this is sarcastic or tongue in cheek ;-)
Java 11 is the newest LTS release.
The next LTS release will be Java 17.
Many companies won't touch anything that isn't LTS. There are still a large number of companies staying on Java 8 :shrug:
yeah I'm confused too, so its because Java 9 officially came out September 2017 and they've been releasing very fast but have completely ditched semantic versioning
Java 8 → Java 11 → Java 17. Those are the LTS releases. If you want to follow a release cadence similar to Java 5 → Java 6 → Java 7 → Java 8, that's what you'll track.
The intermediate releases can be used to test against, but adopting them too soon often means tackling lots of issues in your dependencies. And updating your application servers to a new major Java version every six months is not something you can do easily coming from older Java versions. It's not impossible, but it may require a different deployment strategy and may not benefit you much over going from LTS to LTS.
I think that there is also an unspoken feeling that the LTS releases are more stable, which again may be due to the libraries you depend on not always being as well tested on the intermediate releases. I think a lot of Java developers burned their fingers on Java 9 and 10 and are now sticking to the LTS releases, but that is just my gut-feeling.
I struggle to imagine any meaningful definition for LTS that includes "tracking latest" except by coincidence (during the window of time when the most recent release is an LTS release).
If you're doing green field JVM developer and NOT using big frameworks like Spring or an app server it is pretty safe to use the intermediate releases.
... if you're willing and able to update your entire app to a new JDK the month it comes out.
This is where I hope Java adopts the .NET support lifecycle. .NET also has (relatively) fast-paced releases now, once per year with LTS every other year, but the prior non-LTS is supported for 3 months after the next one comes out. That's still pretty aggressive, but it's very doable with a modern app to upgrade within 3 months.
With Java, JDK 15 support ends this month, the same month that JDK 16 comes out. Not just that, but we're halfway through the month already. So if you're on JDK 15, you now have only two weeks to upgrade and still be supported, according to their official schedule.
Edit: I may have been too generous in my reading of their support roadmap. It seems like the previous non-LTS version is immediately out of support as soon as the new one "supersedes" it.
Uh, probably just my narrow corporate world view but... is there any serious development in java NOT using Spring?
Time for me to learn so let me rephrase this question!
Those who use java without EE or Spring framework, what are your go-to libraries? What are you using for DI / REST / ORM / Auth etc?
> is there any serious development in java NOT using Spring?
Yes. And I don't just mean people doing Android development.
1) DI: Don't always need DI. For things like injecting values from config, it's really unnecessary given that we have very good control over production, down to building our boxes from a playbook. For things like mocks, plain old Java suffices -- you can roll your own (actually, someone in your team just needs to do it once and it keeps getting improved/forked). Guice exists as a fallback.
2) REST: Jersey + own libraries on top, Retrofit. Using Spring for REST is probably the poorest use for Spring, for me.
3) ORM: you can use "just" JPA. Don't always need an ORM either -- the strategy varies depending on the requirement. Although for some projects I have used Spring Data JPA because it seemed like the easiest path. At least Spring was localized to that artifact.
4) Lots of good OAuth2 libraries as well as things like pac4j. If you're wondering about Spring Security, it's definitely one to consider if you're doing lots of webapps in Java. But in a polyglot environment, a lot of Java code just handles APIs while node handles the UI.
Anyhow, this isn't to hate on Spring or anything -- I use it if it adds value. This is more about not taking the the complexity hit if you can help it. It also makes the code a bit more straightforward and readable.
Different needs for different domains. For example, there's an old pack of machine learning code that I maintain, and it (and a bunch of other Java code that I see from other institutions) does not use or need DI, ORM, Auth nor proper REST, they typically handle processing of non-database data with no or minimal web interaction, and plain old objects are fine for that - if we started from scratch and chose Java instead of some other language, we would still not use Spring for that.
Google used Guice for DI (Or Dagger2 sometimes), rest is it's own thing, orm is "there is no ORM go write your spanner queries", and Auth is it's own thing.
Note that blindly following LTS is not a great idea for many teams that deploy applications (as opposed to libraries), including teams working in large companies, if you have access to modern CI/CD tooling. Personally, I'd let production stay a little behind the latest release but always run a task on my build server to build and test my code on the latest JRE.
If you read Ron Pressler's comment on Reddit[1], the recommendation is
> In any event, the default position should be to keep up with the current JDK as much as possible (it's OK to skip a version or two), and consider LTS only if there is some specific difficulty preventing you from doing so. As I said before, the "current JDK" upgrade path is designed to be the one that is overall the cheapest and easiest for the vast majority of users -- easier and cheaper than the old model.
For users who are happy with the current JDK language level, newer releases also have JRE improvements:
> ...those users should [also] prefer the current JDK, too, as that is the easiest, cheapest update path. Also, new feature releases contain performance and monitoring improvements (e.g. JFR, ZGC, AppCDS in the last few releases) that may be of interest even when users are not interested in new language/library features.
> The problem with LTS is that it's costly (costlier than the old model): on the one hand, the risk of a breaking change in an LTS patch is no lower than in a feature release, and on the other hand, the patches no longer contain many gradual implementation features (that you use without knowing). In addition, the OpenJDK development process revolves around feature releases without regard for LTS, so features can be removed without notice in an LTS release. This makes an LTS->LTS upgrade more costly than in the old model.
> LTS is designed and is advisable for companies that prefer a costly, but well-planned, three-yearly upgrade process.
> Even if you've carefully considered the options and decided that LTS is the right approach for you, you are strongly advised to test your app against the current JDK release to reduce the cost of an LTS->LTS upgrade.
> It's true that upgrading from 8 to post-9 can be non-trivial (9 was the last ever major release), but once you do that, you have an update path that ensures you'll not have a major upgrade ever again.
Java upgrades inside enterprises cost time and money, no sense in taking that cost if you can help it, and many engineering teams with good DevOps can easily dodge this cost.
And what do you do if you "try it out" and some months later you identify a problem? Then you have to rewrite all the code without the new features to go back to the LTS version, and likely you'll have to downgrade or even swap out some of your dependencies. That's painful and expensive, there needs to be a very good reason to justify that risk.
You don't need to downgrade dependencies, libs are at 8 and 11 right now and support up to 16 (e.g. jackson is I think at Java 7, and supports records from Java 16).
What kind of problem could you identify? Same might happen with LTS release (e.g. I had it in JDK 8, suddenly I wasn't able to use some crypto libs).
Fixes always go first to JDK latest, and then are backported to 11 and 8.
If you're using JBoss/Wildfly the recommendation is to stick to the LTS. The last JDK supported is 13 since 14 removed some API's and the team is still working to fix it.
Basically there's six month feature releases but every five or six releases there's going to be an LTS release. Most companies use the LTS releases. Next big LTS release is later this year.
As a student most of the way through a Java course, I'm wondering what Java is still used for. Java applets are dead, Android is moving on to Kotlin (apparently Google got in legal trouble with Oracle even though Java is "open source?"), and I can't think of any desktop applications that use Java anymore. Java is supposed to be able to "run anywhere," yet C++ is more portable because it doesn't require the JVM to run.
Yet clearly I'm mistaken, since Java is still one of the most popular languages.
Edit: also please help me understand - do I have to pay for a license even though Java is open source? Is this normal for other languages too?
>As a student most of the way through a Java course, I'm wondering what Java is still used for.
A huge majority of all code behind services, websites, and businesses you interact with every day. From Google, Facebook, Apple, and Twitter to your bank, and from Android to you favorite new unicorn. Of the top 25 unicorns "20 use Python; 19 use Java; eight use Kotlin. Coinbase was the only top-ten unicorn found to use Swift." [1]
And that's just startups and FAANG. On top of that, every enterprise, government organization, and financial organization also uses tons of Java with the exception of Microsoft shops, which use C# in its place (or also use C# on top of Java).
Think of it this way: you know how C# is a big industry? It's #5 in the TIOBE index. Java is #2, and has been between bouncing between #1, #2, and #3 spots for decades.
And on top of Java there's the JVM, which also powers Kotlin, Clojure, Scala, Groovy, and other languages...
>Java applets are dead
Java applets have been dead on arrival. It was just a fan around 1997-1999 and not that succesful even then (I was there). They were never a big part of Java's allure.
>Java is supposed to be able to "run anywhere," yet C++ is more portable because it doesn't require the JVM to run.
The only successful Java applet I know was Runescape (if that was an applet? it ran in browser), an RPG game that ran in Java in the browser, for 15 years or so roughly afaik, today they switched to a non browser based client instead.
Other Java applets almost never worked for some reason. Like, sometimes I'd visit a website about some mathematical topic, and the whole browser would hang while some java applet demonstrating the math was supposedly loading, and then most of the time it didn't actually work.
Don't know about "successful" or "useful", but the Java Applets on Complexification were some of the most beautiful software I've ever seen: http://www.complexification.net/gallery/
The first "real" Java program I wrote back in 1997 was a huge applet. It was the replacement for an existing X Windows application, with 42 screens. The applet itself worked great, but the networking technology at the time was such that when all the users on a network segment started their browser and launched the applet, it bogged things down to a crawl. Still, when it was loaded it was amazing (for 1997). It looked almost exactly like the original application, and updates were as easy as putting a new jar file onto the web server.
Roughly 20 years ago we embedded Java applets inside a HTML-based online help. This turned the help from a reading resource (which tells you where to find certain preferences) into an actually interactive resource, composed from the same applets that also formed the Application itself.
Worked like a charm. I have yet to see anything similar to that.
The only applet I know of outside the early few years of hype that still works and does something useful is Falstad's circuit simulator. https://www.falstad.com/circuit/
It's a very popular backend language. Ironically, "run anywhere" isn't much of a requirement for backend development.
> C++ is more portable because it doesn't require the JVM to run.
For backend development, this isn't much of an issue either way. These days, the main advantages C++ has to Java is startup time and no GC pauses.
It's also not as portable as you'd think. Take a look at cross-platform C/C++ projects and you'll see a lot of special cases for particular platforms.
Java's popularity mostly boils down to it's mature, has a large ecosystem, and is adequate for a lot of things. Unless you're writing an iPhone app or system-level code, it's unlikely to be a bad choice.
> Ironically, "run anywhere" isn't much of a requirement for backend development.
If you’re using Java, you can develop on macOS, deploy on Windows Server, then switch to Linux on AWS Graviton and M1 Macbook. Without a singe recompilation.
I'd say they're at a point where they're not a problem for most use cases, but if you're trying to get p9999 latency down, you might have to start looking at them.
The default GC has ridiculously good throughput with modest latency (10ms for quite large heap sizes), but there are also alternatives like ZGC and Shenandoah that optimize for latency instead, and they promise <10 ms latency, but in practice they are around 3-4 ms. At which point, not running a real time OS, you will get bigger hiccups from the OS scheduler.
Also, for very different use cases like soft real time, there are specific JVMs with real time guarantees.
Vast majority ( if not All ) of Fortune Global 2000 use Java as their Main Programming Language for their BackEnd.
And this isn't changing anytime soon. Their initial investment, continue investment and Java Ecosystem itself are still marching forward. I dont see any language ecosystem that could match or challenge Java any time soon. Remember you only see Java Haters on HN and Reddit. In the Real World it is all about Business Values Delivered and Get Shit Done.
JVM in itself is a monster with State of the Art GC and JIT.
All of the above means there is a positive feedback loop into making Java better. And there are things that were in the work for 10 years ( Like GraalVM ) before hitting mainstream. And many more to come.
> C++ is more portable because it doesn't require the JVM to run
Java is portable BECAUSE of the JVM. If a new computer architecture hits the scene, once someone writes a JVM for it your .class files will run on it (probably).
Your C++ program, however, will definitely not run and you'll need to recompile it with a compiler that targets that new architecture.
The same compiled Java code will(should) run on a Mac or a PC or any Linux box, but you need a different executable for each target with a C++ program.
The JVM isn't portable. That needs to be recompiled for each new target, but your Java .class files are portable.
For a couple decades, x86 was absolutely dominant and there were no new architectures of any importance outside specific niches. Once you dealt with the OS specific oddities (which java also helped with), C++ was highly portable.
I work in embedded. Embedded Java has always been a huge set of tradeoffs, which is why it never took off outside of application platforms like mobile phones and set-top boxes.
If you wanted the full fat SE Sun/Oracle JVM you were pretty much stuck with power or ARM, and even then you had to be careful. Remember the portability disaster that was symbian and Java ME? These ISAs weren't exactly the low end of the embedded market at the time either. The farther away from x86 you got the less portability you could actually take advantage of.
> Remember the portability disaster that was symbian and Java ME?
Don't forget Java Card in that list. Which Oracle still tries to claim as a Java portability win, even though it doesn't support basically anything. And I don't mean missing standard libraries, I mean like it doesn't support char, double, float, and long, or multidimensional arrays. Support for int is even optional. Doesn't support exceptions and you can't even assume it has a garbage collector. Among many other limitations.
No, they aren't, they regularly have non-portable dependencies or assumptions about the environment.
For example, it's more or less impossible to write a Java program that runs on Windows, Android, and iOS - the 3 most popular OS's. You have completely different UI support between Windows & Android, and there's not really any JVM for iOS (there's AOT, but now you're not even pretending to run a .class file)
So to make a "portable Java" program you're already stuck compiling it 3 times for the 3 major OS platforms, but without anything helping you to actually specialize for a platform like exists with C++. Making Java less portable in practice than C++.
Toss in that other popular platform, web, and the "portability" of Java gets even worse compared to others like C++.
Maven runs on 1 out of the 4 mentioned platforms. There are no Android, iOS, or web builds of Maven.
Maven is used to ship dependences for the other platforms, but it is not run itself on those other platforms. Shipping an Android-specific library on Maven isn't magically portable (which is what's common here - OS-specific libraries on Maven). It's still Android-specific.
All Android builds use Gradle and download their dependencies from Maven Central.
I have no idea what you're talking about.
Let me repeat this: all Windows, macOS, Linux, and Android apps that use Maven or Gradle to build ALL download their dependencies from Maven Central. These are the very same libraries, same bytecode.
For example, do you use Mockito? You will download that exact same library from Maven Central regardless of the platform you are building on.
When you build Android you're not building it on Android, you're building it on Windows, MacOS, or Linux. Maven itself is not being run on Android or iOS.
The Java code that powers Maven isn't portable. The AndroidX code hosted on Maven that everyone is pulling down for Android isn't portable, either.
Your claim would be like saying that PHP is portable because every platform has a web browser that can talk to the server running modphp. That's not what portability means.
> For example, do you use Mockito? You will download that exact same library from Maven Central regardless of the platform you are building on.
Mockito only runs on 2 of the 4 platforms (doesn't run on iOS or web).
Who cares about Maven-the-app, we are talking about the portability of the JVM bytecode.
There are gigs of JVM bytecodes stored on Maven Central and these bytecodes are being downloaded and run on macOS, Windows, Linux, and Android on a daily basis without a single change. The very same libraries. Unchanged.
That's the very definition of portability.
I don't understand why you keep shifting topics by bringing up irrelevant observations.
Any libraries in the Maven repos that rely on JNI have to include platform-specific native libraries for each platform. For example, anything that uses Unix-domain sockets, which weren't supported in Java until this very release.
There's no portability requirement to being on Maven Central. Maven Central regularly hosts non-portable bytecode - like every AndroidX library.
And, again, none of those libraries run on Windows, Android, iOS, and web - the 4 major platforms by market share. At best you get half of those, but typically you don't even get that, and that's still only libraries. None of them are portable applications.
It's trivial to write semi-portable C++ snippets, too, that's not a major achievement.
Now you're being intentionally obtuse and moving the goal posts from your original claims just to score points.
You're not arguing in good faith.
Feel free to stick with your invalid views on portability, the rest of us JVM developers will keep enjoying the portability that this wonderful technology provides us.
Java is used all over the place for various backend applications, e.g. data processing, web backends. It's fast, well documented and has a great standard library and ecosystem. In many of these applications you control the deployment environment, so making sure that your container has the JVM isn't an issue.
Except for "Java applets are dead", everything else you wrote is wrong :-)
Android is not moving to Kotlin: Kotlin is simply supported as a first class language in Android. Most of Android itself is written in Java and while it's clear that an increasing number of Android developers are switching to Kotlin, Java will never stop being supported on Android.
The legal battle between Google and Oracle has nothing to with Google using Java.
You can use Java for free and without any licensing concerns (use Open JDK).
C++ is less portable than Java precisely because Java runs on a JVM.
Yes, golang is shiny new thing, but there is TONS of boring back-end done in Java.
Whole Alibaba runs on Java, for example. I know of some companies (won't share names but fill in the blanks) that used to be Go shops, that were eaten by Alibaba and they migrated from Go to Java.
Wouldn't agree on the GO statement, yes GO is great in terms of performance but it still lacks some important language features AFAIK no generics, no proper exception handling. I honestly don't know how the GO ecosystem is, but I can't imagine it's as mature as java. Perhaps I'm wrong tho
That's just like saying Go does not have application servers, DI, IOC, ORM frameworks, runtime reflection and so on. Different languages have different ways of achieving user requirements. It is not one-to-one matching.
> ... I can't imagine it's as mature as java.
Yes, depending on perspective, not as mature or not as fossilized as Java.
Here at Quobyte, we're developing a distributed file system that is partially written in Java. The JVM is rock-stable, fast, and developers are very productive in Java.
I discovered Quobyte today thanks to this comment. I am extremely excited to start exploring your technology.
I am also working on a networked file system solution. My approach is likely fundamentally different. Instead of a single file system to represent file system artifacts across various devices I am using a single simplified data model as an abstraction for all file systems and pairing that with a new security/identity scheme. The idea is to solving for file asset distribution using point-to-point solutions that don't compromise security or privacy.
I suspect your approach is likely far more stable as I am still working out the kinks in my models, but I supply a complete GUI in the browser that works the same in all browsers on all modern OSs.
> and I can't think of any desktop applications that use Java anymore.
The desktop application everyone has to use to report the income tax in my country is written in Java. Which is nice since it runs anywhere that has a recent enough JRE; in a distant past, before it was rewritten in Java, it was first a DOS-only and then a Windows-only desktop application.
I have worked with Java EE (Enterprise Edition) for a few years. Java in the backend is probably the most common one when doing enterprise software.
Lets define it differently: Everything what is not an SAP System and is backend and is not Cobolt, is Java at least for automotive and banking. Automotive -> managing cars, service contracts, financing offers, accessories and for banking -> money management, insurance, contract management etc. You go to a shop and you wanna finance something? Might be a Java backend or Cobolt :D)
Spring/Spring Boot as a Framework got a lot of traction because Java specification process was just way slower and more boilerplate
And yes Oracle got fed up of doing Java for free for too long and if you wanna use an older version of java and still need patches, you will need to pay.
Luckily there is were java actually shows it strength which i have not seen in other languages: You define a specification, you get a reference implementation from someone and then everyone around it starts to build on those specifications.
This allows for different jpa (database access with java) implementations, different application server etc. It also allows for different companies to do their own JVM implementation/maintenance track/version.
From an ecosystem pserpective, the JVM itself (without java) also did a great job and shows how versatile it is. Close to what .net is doing but in a more free version. And you could throw .net/c# into the same similiar category as Java. Language feels similiar and if you are a MS company, you just use C# perhaps. But switching between c# and java is much easier than to other languages.
From all languages i know and worked with, i do like JVM based languages the most. golang is interesting but nothing i would wanna use for a big code base at all. C/C++ i would use if i need to because of tooling features, how you write it and how hard it is to write it good;
Java is fast, java has great tools for a long long time: Great Debugging features, great memory and performance analysis and tools, lots and lots of frameworks and architecture catalog.
PHP is written and used in business context like java but without the benefits of running on the JVM. I don't recommend it. Its not bad, its less boiler plate but its just not a nice well defined well designed language. Most shocking to me was the performance optimizations which were done a few years ago which shows how little interest in that language exists that you can just optimize it that much. What facebook did with PHP was just shitty and weird.
To give you some more details of how Java can be used in the backend, while there's obviously unknown "generic business logic" there's also big name infrastructure pieces you can look up:
Java is not commonly used for consumer desktop applications, where it often is necessary/desirable to invest in fully native apps for Windows and MacOS. But desktop Java is quite common in business desktop applications, for example, medical devices (like radiology image viewers).
I'll give you a bit of advice I give to engineers I mentor. Go to a tech jobs site like dice.com, and put in a technology you're curious about. So, put in java for your zip code. See what jobs are available. Are they back end? desktop? Then you'll find out where java (and any other tech) is used, and how popular it is. For example, how many jobs are there for PHP compared to Java?
I'm not saying you should adapt a technology based solely on the number of jobs...but we all gotta eat. And on the flip side if you see Java jobs decline over the years...time to learn the one that's increasing :)
Java is _very_ prevalent in Financial IT - almost everywhere. C++ is probably the only language in the same league in terms of usage. I have also seen C# lately in bunch of places but mostly middle-office/back-office.
Most OpenJDK implementations do not require a license.
There are multiple implementations of the Java VM. Java is designed by a collaboration of companies and OpenJDK is the reference implementation. Based on the license of the company, its implementation is free or not.
Now, Oracle was the biggest and most well known contributor of OpenJDK for a long time (and probably still is). And Oracle did something unusual, which is that they made their own version no longer free. Which is why you are confused. You can still get Java from Oracle, with Long Term Support, but now it is paid support.
The OpenJDK reference implementation is still free, and many companies have made their own tweaks and provide Long Term Support for these versions, mostly because they use tons of Java and/or want others to keep using Java because of its massive ecosystem, for which they can provide consulting/paid support. Note, you can still run these versions commercially, but if you want support you likely have to pay.
The Google issue was that before all this OpenJDK stuff, all designing of Java was done by a single company, Sun, which was bought by Oracle. So a single company designed, developed, implemented, maintained, and built up the ecosystem of Java. This includes years of R&D in what keywords to use, and how classes work, basically the rules of the language. Tons of developers got into Java. And they attracted big customers like banks and governments to pay them for this R&D with support and development.
Then came Google and they said, we like this language design and ecosystem and developer skills, but we don't want to pay for that support, so thanks for all the hard designing of your language, but we will create our own implementation and pay you nothing. Basically Google didn't want to pay it's share of the Java R&D.
Now things get a bit blurry because of Oracle, which bought Sun, and tried to make a lot more money off Java while reducing R&D spending. So Oracle isn't too popular either.
Things have improved since Oracle decided that Java isn't something to make a lot of money off, and the whole Google debacle. Now Oracle is mostly stewarding the language and other companies are now also contributing features.
The past few years there have been some good and strong updates to Java, making it feel more like a leading language than a trailing language.
Basically, get AdoptOpenJDK, latest version if possible, and don't use preview features.
> do I have to pay for a license even though Java is open source?
Most people use free OpenJDK builds (Adopt OpenJDK, Zulu OpenJDK, Oracle OpenJDK to name a few). There are some builds which require license, like Oracle Java. If you need some kind of advanced support, you have that option.
A good part of AWS is written in Java. The Hadoop, Storm, Spark, Kafka etc major backend projects are written in Java.
In fact if you are writing anything even half serious. Java is what you chose to write it in.
>>Java is supposed to be able to "run anywhere," yet C++ is more portable because it doesn't require the JVM to run.
Manual garbage collection is long dead, and it won't be revived any time soon. Machines have gotten too fast and resourceful for most of the developer community to give it a serious selection choice for their projects.
Not saying C++ or Rust is dead. They have their place. But they are not going to be used for bulk of everyday projects. That ship sailed long back.
Java is rarely used for sexy stuff like front-ends or (increasingly) apps.
Java is, however, used for services. Bank logins, search engines (Google originally used it), insurance systems.
C#, C++ and Rust are in the same area. But Java, for the most case, has been around longer.
A LOT of companies used it and can't easily switch their codebase to something newer and shinier. And now Java improves with every release they have fewer reasons to move.
Other languages have started to eat into Java's market share, but coincidentally a lot of them run on the same host VM as Java. For instance, Kotlin, Scala and Clojure are more and more frequently seen in backend, web and mobile development.
These languages are definitely much more "portable" depending on what your definition of portability is; the JRE runs on A LOT of systems and abstracts much of the underlying system away for you, meaning that IME you have to write a lot less platform-specific code if you're targeting e.g. Windows, macOS and Linux.
As for your edit, the licensing is a bit complex for Java but TL;DR if you install OpenJDK releases you do not need to worry yourself about licensing.
> better be in a Java shitshow with slow idiots than in a C++ shitshow with autist geniuses :D
Please don't use Autism as an insult. It's exceptionally degrading to conversation here and presents no value; it does nothing other than cast you in a negative light.
I'll ~delete~ edit my comment if you edit the remark out, provided you do so before my ~delete~ edit threshold expires.
Edit: delete threshold expired. Can only edit, and won't be able to edit once the edit threshold expires.
A lot of Universities teaches Ancient C++ and developers start to hate it. The rant of Linus also caused huge disaster newcomers coming into C++ and that shifted people into Rust.
Happy with the number of comments on this release.
HN is a funny place.One day you are convinced no smart person on HN is still writing Java and the next day you see droves discussing about a java release.
The idea that the tools you use is a reflection of how smart you are is just plain old silly. Most of the work you do in software is language/tools independent. A smart software developer can do great work with almost any tool.
Apache feels like a forgotten gem in the ops world. Everyone moved onto Nginx and at some point will run into some use-case that needs a feature that's only in Nginx+. And since Nginx+ is so expensive people end up just patching the OSS Nginx with the modules they need. But that whole time Apache was there with every conceivable battery and feature already included.
Except its configuration language is awful. Nginx is pretty bad too, and then there's Caddy which seems the most tolerable so far. Usability matters quite a lot!
It is probably fairly easy to create a fork of Apache with a better configuration language. The fact that no such fork exist (or more precisely, the fact that you don't mention it, which is strong evidence that you know of no such fork) is evidence that most Apache users are OK with or roughly indifferent toward its conf language. (I know nothing of it.)
I, too, believe that usability matters a lot, and I'm curious what you think of bash.
Or it could be evidence of Apache's configuration language being closely tied into its internal implementation in a spaghetti-code way! If there's one fundamental truth in open source, it's that maintaining things is hard, doubly so when it's a fork of a complex system that few people fully understand. The absence of a fork does not mean users are satisfied, simply that the people who might be motivated to fork have better alternatives for their time (for instance, learning Nginx).
I'm not very fond of it, to put it lightly. You can get some things done quickly in it, I'll admit, but anything past a few hundred lines quickly becomes unmaintainable.
Yes. It feels out-of-place. All other keywords are like one word: enum, class, public, protected, native, sealed, ...
But looks entirely different: Two words, connected by a hyphen.
But I think, it was done because of backwards compatibility. If they would have called it "closed", it would maybe break hundreds of programs that have methods/variables called "closed"
There was a lengthy discussion some time ago[0]. Quote:
#### Why not "just" make contextual keywords?
At first glance, contextual keywords (and their friends, such as
reserved type identifiers) may appear to be a magic wand; they let us
create the illusion of adding new keywords without breaking existing
programs. But the positive track record of contextual keywords hides
a great deal of complexity and distortion.
Each grammar position is its own story; contextual keywords that might
be used as modifiers (e.g., `readonly`) have different ambiguity
considerations than those that might be use in code (e.g., a `matches`
expression). The process of selecting a contextual keyword is not a
simple matter of adding it to the grammar; each one requires an
analysis of potential current and future interactions. Similarly,
each token we try to repurpose may have its own special
considerations; for example, we could justify the use of `var` as a
reserved type name because because the naming conventions are so
broadly adhered to. Finally, the use of contextual keywords in
certain syntactic positions can create additional considerations for
extending the syntax later.
Contextual keywords create complexity for specifications, compilers,
and IDEs. With one or two special cases, we can often deal well
enough, but if special cases were to become more pervasive, this would
likely result in more significant maintenance costs or bug tail. While
it is easy to dismiss this as “not my problem”, in reality, this is
everybody’s problem. IDEs often have to guess whether a use of a
contextual keyword is a keyword or identifier, and it may not have
enough information to make a good guess until it’s seen more input.
This results in worse user highlighting, auto-completion, and
refactoring abilities — or worse. These problems quickly become
everyone's problems.
So, while contextual keywords are one of the tools in our toolbox,
they should also be used sparingly.
There was a lot of discussion about this and they eventually settled on the hyphen. Consider this our introduction to hyphenated keywords and expect to see a lot more of them in the future.
I made this argument before, but was informed that they have support for contextually distinguishing between names and keywords some time between Java 8 and 10. So while e.g. the introduction of enum did cause all these issues for variables named enum, "var" did not and a hypothetical "closed" would not.
There are plenty of languages which have contextually sensitive keywords for that exact reason. C# (a closer peer to Java syntactically) has contextual keywords including "var" and "notnull": https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
Following the various openjdk mailing lists is an awesome way of learning about all the considerations that go into making language choices for java. And indeed this was not random, but the result of a lot thinking (as shown in a another sibling post).
C++ has had two-word keywords since the beginning, static_cast, dynamic_cast, etc.
What I truly don't like is C's propensity to add new keywords that begin with an underscore and an uppercase letter. Like _Bool, or _Atomic. (I know the rationale, these can't be used as identifiers due to UB, but it still looks weird to me.)
Oracle had no qualms about breaking a metric boatload of code by shutting down the old sun.* APIs. Their justification was "You were not supposed to use these internal tools", but the reality of the matter is that migrating to a new Java version took lots of code rework.
I'm surprised they were so shy to break code by introducing new keywords, after they wreaked havoc on people's codebases with removing sun.misc.BASE64Decoder etc
Super interested in https://openjdk.java.net/jeps/386 as alpine linux is at the heart of a lot of docker images. We use ubuntu currently as our base image, but tried to use alpine recently and ran into some issues with musl.
I am curious where does it leave libraries like Lombok that basically ports a non-record type Java class to make it more record type-e by adding things like @Value, @Data annotations. Are those libraries/frameworks going to become obsolete now?
I'd say that now with 15 adding records and instanceof pattern, Java 8 is finally looking pretty dated!
You're also missing out on var and switch expressions, which are very visible features (as are records and instanceof patterns), so the difference should be obvious between a Java 8 codebase and a Java 15 one.
I think it's interesting to discuss how many are stuck on java8. It was a long time many of us were stuck on java6 or 7, and finally got up to java8. But then when 9, 10 and 11 came no one made an effort to upgrade. Why? And now we're at 15 and people are starting to feel the heat.
We only migrated our main service from 8 to 15 a month ago (AWS deprecation), but still have lots of 8 code laying around (luckily some of the container-features were backported)
> I think it's interesting to discuss how many are stuck on java8. [...] But then when 9, 10 and 11 came no one made an effort to upgrade. Why?
A lot of things broke in Java 9, which was short-lived (both it and Java 10 lasted only six months each), and then Java 11 broke many other things (for instance, it removed all of J2EE). As late as last year, I was still seeing changes in libraries to fix issues with Java 9 or later. It's not that no one made an effort to upgrade, it's that it was a lot of effort, and often required upgrading to later versions of libraries, which have their own breaking changes.
In my experience mst of these changes are simple to add to your projects pom or build.gradle. For instance the removal of the jaxb xml runtime is a simple 1 liner to your project:
Speaking from personal experience, the creators of most of the recent JDK versions have made very poor efforts to explain the changes, it's mostly just a list of RFC type documents, and who has time?
An example of something that compares favourably would be Go, where they always blog about the changes, and there's easy to find official language documentation (and not just autogenerated API docs).
Have you tried for example the linked article with all the JEPs listed with lengthy descriptions? And with links to relevant mailing lists if it didn’t satisfy your curiosity?
I just yesterday took the time to go and read through them. And I still consider it awful UI.
- A list of links is not a summary. The list is too short, reading every individual linked document is too long. The format of JEPs tends to bury the lede. As such it feels like wading through mud.
- Changes that affect the programmer experience are mixed at random with changes that affect internal details of the implementation.
- Changes that introduce experimental features are mixed at random with changes that are final.
Hopefully, there will be a day/release in the Java world when we will be able to write 10x - 20x shorter programs (in terms of LOC) with most mundane stuffs disappearing under the hood. Sighs!!
It will be interesting to see the reaction of project managers some of whom still measure productivity in terms of lines of code/# of commits! (yeah, they do and still exist).
I did, the main issue is that jaotc doesn't do any pruning of the unused methods, so it generates too much assembly code.
If i remember correctly, compiling just guava was to close to 1 gig.
GraalVM native image is far better, it "compiles" more slowly but the resulting executable is not too big.
Graal is a separate project and jaotc did use that. I believe the reason for the “separation” is that the two projects have different priorities and didn’t develop at the same pace. I believe graal is still only at version 11.
But since Java, the language is highly backward compatible, one can trivially use Graal as is (without the preview features though)
In the 1990s it looked very much as if desktop and server heterogeneity would be the norm. That you'd pick between alternatives like Solaris on SPARC, HP-UX on PA-RISC, Irix on MIPS, Windows on Alpha / MIPS / x86 / PowerPC, MacOS on PowerPC, OS/2 on PowerPC / x86 etc etc.
The designers of Java, as well as software community at large, had dealt with the pain of moving large codebases across platforms and so the WORA promise was very appealing.
It would have been cool if Limbo/Dis would had gotten more attention at the time. To me it looks like a more promising base, and was released the same year as Java. I can't at the moment find under what terms it was released back then, but it's free software now.
Java apps are pure Java for the most part, they basically contain no native code, unless for some very specific OS API call (in which case portability is a non-goal) — and the JVM will run any class file thrown at it.
Android is special because it has many many special APIs, so I don’t see your point. Just look at the (unfortunately not too numerous) desktop java apps. The exact same jar from n years ago will just run on all three main OSs.
> Java programs normally sit on a server, or many servers of the same arch.
That's true right now, but it wasn't true in the recent past (SPARC) and it might not be true in the near future (ARM).
Early in my career I was on a team that migrated our Java application from elderly Sun boxes to newer x86 hardware, and it was relatively painless. There's a good chance we'll eventually to the same from x86 to ARM. Most developers will also continue develop on x86 for the foreseeable future.
Looks like they added sensible no-boilerplate immutable data objects, and are trying to unbox their boxed primitives, yay for common sense at long last.
While they're about it, they should also add immutable/copying data structures.
This is definitely good, but I'm also meaning Clojure style lists, maps, etc where you can treat any given copy of the entire data structure as one big immutable value.
By being slightly behind, you get to learn from those languages that live on the bleeding edge. The laggards get to benefit from all the corner cases found and mistakes committed.
Looks like no type aliases still? Does anyone know if type aliases are anywhere on the road map for Java? Is there some philosophical objection to them?
Considering how heavily they have borrowed from Scala lately, I would have expected them to pick this up. I found them quite useful in Scala (and in Golang as well).
Java is not borrowing from just Scala, it's borrowing from all languages and adding its all twists to things, just like Scala itself has always done (it's cleary inspired by Java itself, ML and Haskell, probably more).
The language is getting fragmented: value-based classes, records. I wish the features were introduced still keeping one kind of objects, instead of splitting the universe into 3 kinds of objects (usual objects, value-based objects, records).
The feature I am awaiting most is the Project Loom.
The new object type being promoted from preview feature is just the record type. Records are still Objects, they just provide a low ceremony way to create an immutable object holding some data.
I see these record classes in the same category as enum objects, an evolution of the language to improve developer ergonomics.
Upcoming is inline-classes (previous called value types.) When this happens we'll have a true "special" kind of Object, one that does not have any identity. The motivation here is mostly performance. The details are available in Brian Goetz "State of Valhalla" update https://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-back...
Even if `record` is a syntactic sugar, I'd better see a canonical constructor added to all usual classes. The constructor parameters are of types of all the fields, in the declaration order. In this case we could say
class Point { public final int x, y; }
instead of
record Point(int x, int y) { }
Usual non-record classes would benefit greatly from such a feature too.
Actually, if class fields have different visibility, several canonical constructors are needed. If public fields exist, a constructor that sets all public fields. If protected fields exist, a constructor that sets all public and protected fields. If package-private fields exist - setting all public, protected, and package-private fields. If private fields exist - setting all public, protected, package-private, and private fields.
What remains, is value-oriented versions of equals(), hashCode() and toString() to be defined. Probably better to express as a base class than the new keyword `record`;
class Point extends Record { public final int x, y; }
A polyfill for such a base class for older Java:
import org.apache.commons.lang3.builder.EqualsBuilder;
import org.apache.commons.lang3.builder.HashCodeBuilder;
import org.apache.commons.lang3.builder.ToStringBuilder;
class Record {
@Override
public int hashCode() {
return HashCodeBuilder.reflectionHashCode(this, true);
}
@Override
public boolean equals(Object obj) {
return EqualsBuilder.reflectionEquals(this, obj, true);
}
@Override
public String toString() {
return ToStringBuilder.reflectionToString(this);
}
}
I practice such classes in my code, for constructors, I just don't bother for final (Java does not support it well anyways), and have factory methods in a separate class, so they are out of the readers view.
Adding a new canonical constructor to all classes would very likely have backwards compatibility issues, so we'd likely need some sort of opt-in mechanism. In the end the language designers decided that they wanted to give developers a way to create a very focused kind of object.
Additionally, one less talked about benefit of records is they have a simplified serialization scheme that is safer by default. Records when being deserialized have each of their members read and then the canonical constructor is called, if the values are not valid then the constructor can reject the fields instead of allowing an "impossible" object from being created.
Compiletime checked state machines with Sealed Classes [preview feature] https://benjiweber.co.uk/blog/2020/10/03/sealed-java-state-m...
Autobuilders, Mixins, Conversions & more with Records https://benjiweber.co.uk/blog/2020/09/19/fun-with-java-recor...
Pattern Matching fun https://benjiweber.co.uk/blog/2021/03/14/java-16-pattern-mat...