Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A categorized list of all Java and JVM features since JDK 8 to 16

advancedweb.hu

Post reply on HN
Print view View original

231–240 of 243 posts

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#231

Post by pjmlp »

pcl wrote: post #62
The_rationalist wrote: post #59

Earlier quoted context omitted.

Kotlin supports reified generics (through extension methods) Java is getting reified generics and more importantly generic specialization which is critical for performance https://www.reddit.com/r/java/comments/m2dfb5/parametric_jvm...

Kotlin’s reified generics are pretty limited — they only work in inlinable situations, as there is no JVM support. I assume that Kotlin will quickly add proper reified generics support as soon as the JVM allows. (Your link above is about reified generics in the JVM, not just the Java language. Which is great news.)

It can't, because Android uses its own stack and ART will surely not be compatible with whatever comes out of Valhalla.

Then there are the JS and native backends as well.

So at best it will have to make use of KMM, and you will get classes with very different performance behaviours depending on the target runtime.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#232

Post by pjmlp »

jillesvangurp wrote: post #129

I've been using Java and the JVM since about 1995 when Sun released the early betas (pre 1.0). It's more or less a convenience marriage. Right place and right time I guess. I happened to specialize in it for a while. A long story short: I pivoted to Kotlin a while ago and stopped caring about what Oracle is doing to keep up. Too little, too late; and it seems to perpetually not matter at all unless you are still doin…

The day Fuchsia actually makes it, Kotlin will fizzle out, JetBrains has tied its future to whatever happens to Android.

Other than that, it is just yet another Beanshell, jTcl, Jython, JRuby, Scala, Clojure, XTend,....

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#233

Post by MaxBarraclough »

pjmlp wrote: post #229
MaxBarraclough wrote: post #137

Earlier quoted context omitted.

> No unsigned ints. I think that's a mixed blessing. I believe Java did this deliberately to avoid the trouble that C and C++ have with signed and unsigned integer types having to coexist. Personally I've never been inconvenienced by Java's lack of unsigned integer types, but I'm sure it can be annoying in some situations. I'm quite fond of Ada's approach to integer types, but I suspect I'm in a minority. > Silent in…

> I believe Java did this deliberately to avoid the trouble that C and C++ have with signed and unsigned integer types having to coexist. It did, from http://www.gotw.ca/publications/c_family_interview.htm > For me as a language designer, which I don't really count myself as these days, what "simple" really ended up meaning was could I expect J. Random Developer to hold the spec in his head. That definition says that…

Interesting, here's one of the methods:

https://docs.oracle.com/en/java/javase/15/docs/api/java.base...

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#234

Post by pgwhalen »

doctor_eval wrote: post #148
twh270 wrote: post #78

Earlier quoted context omitted.

Much of the verbosity came from the false presumption that every field in every class needs a public getter and setter. (I cannot express in words how terrible this is.) Some can come from the framework, mostly poorly-designed ones. I think Java 11 and higher are reasonably terse/expressive without being overly dense.

Couldn’t agree more, the madness of idiomatically adding setters and getters to every field was something I ended up putting an end to in my last gig, and my life improved immeasurably as a result.

I think I'm going to convince my team to get to 16 (with records) before I can convince them to stop adding getters and setters everywhere, but just out of curiosity... how did you manage to make this happen?

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#235

Post by garfieldnate »

Pretty cool! Java has indeed come a long way.

Not sure what most people think about the var keyword, but I have to say that I dislike it in a production codebase. The example from the article uses var instead of String, only saving two letters, and for classes with longer names var still has the disadvantage of making the code less readable; either you're looking at the code in an IDE and you'll have to click to the method to find out the return type, or you're looking at it on GitHub, etc. and you have to do a manual search to find out the return type. But I'm open to being persuaded otherwise :)

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#236

Post by jacques_chester »

thu2111 wrote: post #218
jacques_chester wrote: post #214

Earlier quoted context omitted.

No, not exactly. Thus ever the fate of tl;drs. The discussion further down about "scope variables" foreshadows making structured concurrency more strongly, directly supported by the language's runtime: > What about inheritance? Because SVs are immutable, and because structured concurrency also gives us a syntax-confined thread lifetime, SV inheritance fits structured concurrency like a glove

Scoped vars are nice but I never saw anyone claim they're a required part of structured concurrency. They're mostly an optimisation over ThreadLocal.

I never said required.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#237

Post by int_19h »

DaiPlusPlus wrote: post #182
int_19h wrote: post #151

Earlier quoted context omitted.

The situation is changing in the CLR land, now that they can just say that legacy codebases can stay on .NET 4.x, and .NET Core is where all the fancy development is happening. There are already some C# language features that are Core-only because they require the corresponding runtime changes. The other thing is - people always forget that, unlike JVM, CLR has more than just the object layer. By design, it has enoug…

> By design, it has enough low-level constructs to compile a language like C++, complete with multiple inheritance, unions, varargs etc But the CLR doesn't support that. If you compile C++ code to IL then you'll get a compiler error if you use any types that use multiple-inheritance. The CLR's underlying type system is a huge limitation when it comes to using even simple modern ADTs. For example, in F# you can define…

You're confusing managed C++ with C++/CLI. The latter tries to introduce additional constructs to C++, so that it can partake in the CLR object model - and there you get all those limitations like no multiple inheritance. But you can, in fact, compile any random C++ code to IL - just run cl.exe with /clr:pure. The only thing that doesn't work in that case is setjmp/longjmp; everything else is available.

If you want to see it for yourself, take some .cpp file, and compile it with cl.exe /clr:pure /O2 /FAs. The latter switch will dump the IL assembly into the corresponding .asm file. Or you can inspect the output with ILSpy etc. You'll see that it compiles native C++ types down to CLR structs with no fields, but with explicitly set size (via StructLayout.Explicit); and then uses pointer arithmetic to access field values.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#238

Post by int_19h »

MaxBarraclough wrote: post #210
ragnese wrote: post #204

Earlier quoted context omitted.

Yeah, I've read little snippets like that from blog posts and stuff, but I've never written a single line of Ada, so I really don't know how that works out in practice. What happens if you overflow at runtime? A crash, I assume/hope? My point of view is that this is the opposite of what I'm talking about anyway. Java is a high level language where we are usually writing in Java because we're agreeing to give up a lot…

> What happens if you overflow at runtime? A crash, I assume/hope? In Ada, if range constraints are broken at runtime, a Constraint_Error is raised (or 'thrown', if you prefer). [0] (That's assuming of course that range checks haven't been disabled, which is an option that Ada compilers offer you.) > I don't see why the default for Java is to have these really nitty-gritty numeric types At the risk of retreading our…

It depends on the base type - you can get the traditional unsigned integer wraparound behavior, too. But Ada is very explicit about this, to the point of referring to them as "modulo types", and defining them using the mod keyword instead of range:

   type Unsigned_32 is mod 2**32;

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#239

Post by int_19h »

ragnese wrote: post #204
int_19h wrote: post #179

Earlier quoted context omitted.

OP mentioned "Ada's approach to types", as well. Ada lets you write stuff like "T is range 1 .. 20" or "T is range -1.0 .. 1.0 digits 18". This then gets mapped to the appropriate hardware integer or floating-point type.

Yeah, I've read little snippets like that from blog posts and stuff, but I've never written a single line of Ada, so I really don't know how that works out in practice. What happens if you overflow at runtime? A crash, I assume/hope? My point of view is that this is the opposite of what I'm talking about anyway. Java is a high level language where we are usually writing in Java because we're agreeing to give up a lot…

Think of range of permissible values as a contract. I agree that the default should be "no limit", but there are many cases where you do, in fact, want to limit it, that have nothing to do with performance per se - but if the language has direct support for this, then it can also use the contract to determine the most optimal representation.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#240

Post by doctor_eval »

pgwhalen wrote: post #234
doctor_eval wrote: post #148

Earlier quoted context omitted.

Couldn’t agree more, the madness of idiomatically adding setters and getters to every field was something I ended up putting an end to in my last gig, and my life improved immeasurably as a result.

I think I'm going to convince my team to get to 16 (with records) before I can convince them to stop adding getters and setters everywhere, but just out of curiosity... how did you manage to make this happen?

Well - I was the boss :) so that helped. But I’d also taken over a fairly unhappy and unproductive team that was ready to try new stuff. I’d been out of the game for a few years and had some fresh perspectives too.

So I did some small standalone projects and demonstrated how much easier life was with this and other (more significant) changes. For example, we had loads of operational problems with dependency injection - the usual cognitive and debugging issues - so I threw all of that out too, along with the frameworks that implemented them. Things started booting in a few seconds instead of minutes and I’d say the lack of setters/getters was mostly done because I built trust in my team that I was making their lives better so they just followed me.

Probably not the answer you were looking for but there was friction from the devs and in the end I just showed them how much nicer life could be...

Post reply on HN