141–150 of 251 posts
Earlier quoted context omitted.
You say only, but I find that to be much more fussy.
Exactly, I hate dealing with Lombok projects for that reason. I'd rather the cruft than the compiler add-on.
Lately I have insight similar to 'what hardware improvements give, software bloat take it away', 'what JDK platforms give third party Java frameworks take it away. I have this misfortune of dealing daily with a nasty Java framework which converts compile time errors into runtime errors, single error trace with multiple stack traces , most of them being from framework itself. One thing that might improve situation is…
as a node dev, I see people using typescript with node. I wonder why don't those people just use java ? and let us clay potters shape plain js to our will. rather than pollute the node ecosystem with typescript
I would like to ask a question, in order to elicit the detailed and considerate comment that HN is known for. It's not intended to inflammatory in any way shape or form! I am not a Java developer. I am one of those users who has a bad memory of using Java desktop apps in ~2001 where they ate a ton of ram, seemed horrendously slow, and had example "Hello Worlds" that are reminiscent of Enterprise FizzBuzz [1]. At some…
Earlier quoted context omitted.
Part of the vision of pattern matching is aggregation and destructuring [1]. This is just exploratory but may be what you're thinking about? [1] https://github.com/openjdk/amber-docs/blob/master/site/desig...
Interesting but the "Isn't this just multiple return?" section seems to completely miss the point. I don't see any examples of what multiple-return would look like. And multiple-return is what I want. At first glance, it looks like this (sure, more powerful) pattern matching system is not going to satisfy my desire for a compact syntax that lets me do the equivalent of this typescript: const [foo, bar] = getMeTwoThin…
With the pattern matching the best you are going to get is nasty boiler plate like
var returnedTuple = getMeTwoThings();
if (returnedTuple instanceof MyTupleType(Foo foo, Bar bar)) {
// Do something with foo and bar
} else {
// Not reachable unless refactoring, etc. So panic here.
}
I would like to ask a question, in order to elicit the detailed and considerate comment that HN is known for. It's not intended to inflammatory in any way shape or form! I am not a Java developer. I am one of those users who has a bad memory of using Java desktop apps in ~2001 where they ate a ton of ram, seemed horrendously slow, and had example "Hello Worlds" that are reminiscent of Enterprise FizzBuzz [1]. At some…
The builds may ship with different optional features enabled, such as various garbage collectors or I think support for the GraalVM stuff. Support terms differ.
> Why there are different JDKs -- I get that that it's good to have different language implementations, but there are really quite a lot!
Most of what you will get these days are just different builds of the OpenJDK class library + tools + Hotspot (JVM). Well, except for the android runtime, but we don't talk about that one. Historically there have been been more JVMs and class libraries but that has been consolidated a lot since oracle opensourced it. There still is OpenJ9 and some smaller, more specialized ones.
Earlier quoted context omitted.
> the important thing is that Java 17 is an LTS That's not _strictly_ true. Java 17 is a release of the reference implementation, but there are a number of distributions from a variety of vendors. Oracle are going to provide long term support for their distribution, and it sounds like many will follow their lead. (If you are going to provide LTS it would be a little perverse to be out of sync with other providers of…
Do you know of any vendor for which 17 isn't considered an LTS? Genuinely curious
Yes, these are "distributions" (binaries) of OpenJDK that do not provide any sort of support, and clearly no LTS flag to them.
I understand wanting to remove the overcomplicated Security Manager, but we have one use case which, as far as I can see, has not been mentioned at https://openjdk.java.net/jeps/411 : we install a custom security manager to prevent the software, when run on a developer machine, from accidentally connecting to non-localhost network addresses (we actually use a whitelist). I wonder how we'll do that after Java 17.
I'm curious if it would be possible to remove null from Java. There's already support for Optional. I mean I guess a lot of code would stop compiling, or could it be deprecated somehow.
Earlier quoted context omitted.
> Language > Pattern Matching for instanceof (16) > Records (16) > Restore Always-Strict Floating-Point Semantics (17) > Sealed Classes (17) > Switch Expressions (14) > Text Blocks (15) This is what excites me. Records, switch expressions and sealed classes are all excellent and even better together. Along with pattern matching switch statements, Java is finally losing a lot of cruft people complain about.
I'm trying to find a good use case for records, but the best I can come up with is using it for composite hashmap keys. I suppose when combined with sealed classes and pattern matching features at some point it might be more useful, but what is the main use for records right now? Given that they're immutable and have no convenient way to be copied when modified, I find them quite tedious to use.