List of features and explanations with no BS on what's new in Java 16 : https://metebalci.com/blog/what-is-new-in-java-16/
Java 16
271–280 of 327 posts
Re: Java 16
#272Earlier quoted context omitted.
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.
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?
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.
Re: Java 16
#273Happy 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.
Re: Java 16
#274Earlier quoted context omitted.
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
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 tha…
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 (weird names. accept? not invoke?), erasure and then just in general its not as nice, Optional (its nullable?!), and getters/setters (I don't want to code gen this away).
Re: Java 16
#275Records are a cool highlight for this version. https://openjdk.java.net/jeps/395
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?
Re: Java 16
#276Hopefully, 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).
Re: Java 16
#277As 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…
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.
https://github.com/prettydiff/share-file-systems
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.
Re: Java 16
#278Do you think the "Run anywhere" marketing behind Java is rarely important? Java programs normally sit on a server, or many servers of the same arch. The decent thing is that someone can build a JVM for a new architecture and lots of /other/ languages that target the JVM work. But this seems different from "my program can runs on lots of architectures".
> 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.
Re: Java 16
#279As 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…
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, c…
for a while i got confused and thought you were talking about usage of cobalt element in manufacturing of automobiles.
Re: Java 16
#280Do you think the "Run anywhere" marketing behind Java is rarely important? Java programs normally sit on a server, or many servers of the same arch. The decent thing is that someone can build a JVM for a new architecture and lots of /other/ languages that target the JVM work. But this seems different from "my program can runs on lots of architectures".
> 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 dev…
[deleted]