Java 16 for what? Does anybody really use > 8 in production?
Who still uses Java 8 in production? That is a serious risk. I thought everyone moved to 11 already. I use Java 15 in production in 3 projects.
We're still on 8 at
Java 16
181–190 of 327 posts
Re: Java 16
#182Earlier quoted context omitted.
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? 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.
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.
Re: Java 16
#183As 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…
> still 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++ pro…
> 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.
Re: Java 16
#184As 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…
> 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…
> but your Java .class files are portable.
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++.
Re: Java 16
#185As 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…
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.
Re: Java 16
#186As 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…
> 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.
Re: Java 16
#187Earlier quoted context omitted.
Yeah, same feeling here. The special-casing feels off. They must have had very good reasons to do that, I just haven't seen them outlined yet.
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 "spec…
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; }
record Point(int x, int y) { }
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; }
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);
}
}
Re: Java 16
#188Earlier quoted context omitted.
If you enjoy pattern matching in Java, I would recommend checking out the latest & greatest that C# has to offer as a comparison: https://docs.microsoft.com/en-us/dotnet/csharp/pattern-match... Being able to combine pattern matching with switch expressions has allowed us to construct extraordinarily concise state machines for our UIs.
I used Java a lot and like some aspects. But I think C# is way ahead in some important ways and Java is playing catch-up
They keep playing catch up with each other, in different ways across the eco-system and language features, since they exist.
Re: Java 16
#189Very 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?
No bother, beyond learning new concepts.
In the end platform languages always take the most relevant pieces from the guest languages, which eventually fade away.
Re: Java 16
#190Earlier quoted context omitted.
> 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…
> but your Java .class files are portable. 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…
> For example, it's more or less impossible to write a Java program that runs on Windows, Android, and iOS
Not only is it possible, it happens all the time.
The entire Maven Central repository, which contains tens of thousands of JVM libraries, is usable on all the platforms you just listed.
If that's not portability, I don't know what is.