Live data from Hacker News

New language features since Java 8 to 17

advancedweb.hu

341–350 of 358 posts

Re: New language features since Java 8 to 17

#341
post #164

Earlier quoted context omitted.

Counterpoint: it's become a fairly multi-paradigm language at this point, and a multi-paradigm language is exactly what should be the defacto language in curriculums Whether or not Java is the best one for this purpose is up for debate, but I think it's no longer a bad one

> Counterpoint: it's become a fairly multi-paradigm language at this point, and a multi-paradigm language is exactly what should be the defacto language in curriculums I'm surprised you would say this, as it is the exact opposite of my experience as university teacher. I think we should teach concepts , and concepts appear much more crisply in small and focused languages. I think students gain more from being exposed…

> … concepts appear much more crisply in small and focused languages.

How about a multi-paradigm language that isn't muddled?

http://mozart2.org/mozart-v1/doc-1.4.0/tutorial/index.html

Re: New language features since Java 8 to 17

#342
post #182

Earlier quoted context omitted.

I suppose it depends on how long that CS 101 course would be. At our department, we used to have an initial half-semester course that taught computational problem solving and programming using Standard ML. It was necessarily based on functional programming, although Standard ML is impure enough that we could also do simple IO. In the next course, they were taught object-oriented design and programming in Java. This h…

Interesting. I guess my thinking was that "paradigms" are mostly artifacts of a) history, and b) ways of describing ideas which at production scale may lend themselves better or worse to a given problem space (in terms of maintainability, etc), both of which are good to learn eventually, but neither of which matter that much when you're just trying to figure out what code is. But I guess when you're just trying to fi…

> … a language that was designed holistically to be cross-paradigm from the outset?

http://mozart2.org/mozart-v1/doc-1.4.0/tutorial/index.html

https://www.info.ucl.ac.be/~pvr/book.html

Re: New language features since Java 8 to 17

#343

I’m stuck on 8 and 11 in my current projects, so I haven’t seen much of these in the field other than the new record feature. What I am really surprised about is the var construct. Honestly, this leaves me a little conflicted since it seems to be antithetical to the principles of a strongly-typed language. So does this now reclassify Java as a weakly- or dynamically-typed language? I would perhaps argue against it be…

> seems to be antithetical to the principles of a strongly-typed language. So does this now reclassify Java as a weakly- or dynamically-typed language? Var and type inference are neither antithetical to static typing nor do they make a language dynamically typed. They're antithetical to the verboseness of Java.

Java is not usually considered to be a statically-typed language and I was not implying that it was. And the definition of dynamic typing is somewhat vague to me, although allowing unspecified type inference is somewhat dynamic, even though one cannot reassign the variable to a different type at a later point.

And my point about was that Java was designed to be verbose, except that now “var” breaks this verboseness. I am sure there was plenty debate on this topic already, but I thought it would be interesting to reason about how this changes the character and perception of Java.

Re: New language features since Java 8 to 17

#344

Earlier quoted context omitted.

> seems to be antithetical to the principles of a strongly-typed language. So does this now reclassify Java as a weakly- or dynamically-typed language? Var and type inference are neither antithetical to static typing nor do they make a language dynamically typed. They're antithetical to the verboseness of Java.

Java is not usually considered to be a statically-typed language and I was not implying that it was. And the definition of dynamic typing is somewhat vague to me, although allowing unspecified type inference is somewhat dynamic, even though one cannot reassign the variable to a different type at a later point. And my point about was that Java was designed to be verbose, except that now “var” breaks this verboseness.…

> Java is not usually considered to be a statically-typed language

Java is absolutely considered a statically typed language. Compare it to Python and CL, then you know what the difference is.

Re: New language features since Java 8 to 17

#345
post #315
post #253

Earlier quoted context omitted.

Meanwhile there's a article literally on the front page about zero-click exploits being used against iMessage

Java doesn't help against exploits, there are plenty in Android phones as well.

It certainly adds a layer of protection that makes issues like the classic C errors with buffer overruns and derefing invalid pointers a LOT less likely.

Re: New language features since Java 8 to 17

#346
post #290

Earlier quoted context omitted.

I'd definitely be curious about which signals you're drawing on. From what I've seen, the Valhalla OpenJDK wiki has gone without update for quite some time, and even that wiki refers to JEP 169 ("Value Objects") as old. I do get the feeling that there's activity, given that JEP 416 is targeted for Java 18 and specifically refers to Valhalla (and Loom) as benefactors of the proposal, and seeing as the mailing list is…

JEP 401 (candidate status) was updated this september: https://openjdk.java.net/jeps/401 Also in September, a brief status was posted: https://mail.openjdk.java.net/pipermail/valhalla-spec-observ...

Ah, very nice on both counts. It looks like instantiating generics over primitive types won't happen until a yet later JEP, and preview features tend to have a cycle time of at least two releases anyway, so I won't expect too much until Java 20. But it's still nice to see where things stand now :)

Re: New language features since Java 8 to 17

#347
post #301

Earlier quoted context omitted.

> Well for one, it has a repl Jshell > As per single core performance, javascript is faster and has had first-class-functions from the beginning Doubt. And no matter how I count, Java had first class functions for 8 years now, at the very least. Does it really matter when exactly did a language feature got implemented? > and you don't need 10 lines of code to print hello something to the screen. jshell: System.out.pr…

Javascript is faster than java... sorry... the JVM is slow. and ugly and verbose and all the things you mentions are bolted on after that fact or not even apart of the core programming language. which hurts your agreement of its being "elegant" or "designed well"

i think you're referring to startup time not actual runtime of long running tasks

Re: New language features since Java 8 to 17

#348

Earlier quoted context omitted.

There was an issue I ran into with regular Java, JDOM 2 Documents, One thing saves a reference, the other thing snips a piece out to use in the response... oops, the first reference points to a snipped Document. Worse, that behaviour changed without interface changes between JDOM 1 and 2, and it mattered to the code I was editing. Easy enough to fix with a ".clone()" but still... it's not just parallelisation. Immuta…

Huh. I don’t know enough about JDOM to ask more than stupid questions, especially when we’re talking about two different languages on the same VM. So please bear with me or ignore at your leisure. This all happened within Clojure? Their Java interop is reportedly good, but the docs also say you lose the immutability safeguards when you interact directly with Java classes. I dunno if “regular Java” means literally tha…

Sorry for being confusing, it was intended as an illustration of why Clojure's approach is good.

Non-immutable data being shared around is basically a recipe for weird action at a distance, is the point.

In what was intended to be a "compatible API, just change the imports" update, code broke because an unchecked invariant became a checked one, and then broke again because the workaround mutated data that was being referred to somewhere else.

Re: New language features since Java 8 to 17

#349

Earlier quoted context omitted.

You can mostly trust the JVM to not optimize this the way you'd want for primitives. ValueTypes are int he works though, and using a supplementary library for primitive specialization like Trove or fastutil have become the norm for now. Not ideal, but tolerable!

If your application needs that kind of control, use a more suitable, lower level language. If you just want that level of control for aesthetic reasons, get over yourself.

Java is that language though! It has primitives and primitive arrays and the language is built around many comfortable ways of using them compared to something "a bit more high level" like a python, javascript, or ruby; but you get to keep your compacting GC, chunky reflection, runtime introspection, compared to a C, C++ or rust.

Primitives don't play well with the generics though, for decent enough reasons, so the standard library leaves out many conveniences that you can pull in as needed. Of course we're excited about them playing well together, but the sweet spot in the design space is still being worked out. We call that effort ValueTypes, lol. (well sorta. there's more to value types than just primitive specialization but i digress)

I get that teasing jabs at java are always and fashion but consider that for many, it persists because it is a bit of a sweet-sport language. I think Go succeeds when it does for precisely the same reasons.

Re: New language features since Java 8 to 17

#350

Earlier quoted context omitted.

If your application needs that kind of control, use a more suitable, lower level language. If you just want that level of control for aesthetic reasons, get over yourself.

Java is that language though! It has primitives and primitive arrays and the language is built around many comfortable ways of using them compared to something "a bit more high level" like a python, javascript, or ruby; but you get to keep your compacting GC, chunky reflection, runtime introspection, compared to a C, C++ or rust. Primitives don't play well with the generics though, for decent enough reasons, so the s…

Don’t get me wrong, I like java and hate c++. I worry about the rapid pace of change post 8. Some of the changes seem great individually but trying to be everything to everyone is how you end up with c++.
Post reply on HN