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

Java 27

mail.openjdk.org

Post reply on HN
Print view View original

411–420 of 424 posts

Re: Java 27

#411

Post by dwaite »

unscaled wrote: post #239
dimaaan wrote: post #219

Earlier quoted context omitted.

Go has null pointer dereference problem. Rust is too low-level for typical enterprise app where requirements changes twice a day. You end up spending time and tokens fighting with borrow checker. C# is MS product, which is no-go for some folks. Kotlin probably would be the answer.

> Go has null pointer dereference problem. Which Java famously does not have. > Rust is too low-level for typical enterprise app where requirements changes twice a day. You end up spending time and tokens fighting with borrow checker. In my experience, you do not spend tokens fighting with the borrow checker anymore, newer models are smarter. But it might not be ideal for a lot of CRUD applications. > C# is MS produc…

> Which Java famously does not have.

Hmm? Java gets null dereferences all the time, that's what a NPE is. The VM takes on the extra plumbing to surface a dereference of a null pointer in a recoverable way to code. On Windows this is done using SEH, on Unix it is handling SIGFAULT - but each NPE corresponds to a null pointer dereference that java then tries to clean up.

That the language does not have a way to have compiler enforced "never null" is actually a huge productivity drain, specifically because you have to do your own defensive measures against null or attempt cleanup/recovery when it happens.

Even languages like Swift which use Optional (e.g. a maybe monad) to provide a concept of nilability still internally will hit null pointer dereferences on occasion with faulty bridged code/bindings. However, they treat this as a non-recoverable violation of invariants - a developer shouldn't be trying to recover from incorrect code at runtime.

Re: Java 27

#412

Post by dwaite »

gf000 wrote: post #318
unscaled wrote: post #310

Earlier quoted context omitted.

Have you worked on large (>500KLOC) codebases with an agent? Yes. But keep in mind KLOCs are not easily comparable across languages. Java is notoriously verbose. A 500KLOC codebase in Java would usually be half that size in Rust. If your argument is that large codebases makes life harder for agents, you should go with a less verbose language. I'm not sure what "manual optimization" means (isn't it a bit of an oxymoro…

> is notoriously verbose. A 500KLOC codebase in Java would usually be half that size in Rust Lol, no way. Especially that rust is pretty verbose all things together (which makes sense, given it's a low level language - ergo you have to literally express more things about the code)

> it's a low level language - ergo you have to literally express more things about the code

That isn't really a comparison of the languages as much as the standard runtimes and ecosystems. It is important to consider that each have comparable components.

So you aren't comparing a no_std rust project against a comparable JavaCard, but say Diesel vs Hybernate code examples around ORM.

Re: Java 27

#413

Post by mahboi »

gf000 wrote: post #319
what_hn wrote: post #111

Earlier quoted context omitted.

Same here with go, then Again go doesn't throw!

It just swallows errors, so you don't even know about it!

I don't get why they didn't just do !/? syntax like in Rust. Or at least make it a compiler error to ignore err returns.

Re: Java 27

#414

Post by gf000 »

dwaite wrote: post #412
gf000 wrote: post #318

Earlier quoted context omitted.

> is notoriously verbose. A 500KLOC codebase in Java would usually be half that size in Rust Lol, no way. Especially that rust is pretty verbose all things together (which makes sense, given it's a low level language - ergo you have to literally express more things about the code)

> it's a low level language - ergo you have to literally express more things about the code That isn't really a comparison of the languages as much as the standard runtimes and ecosystems. It is important to consider that each have comparable components. So you aren't comparing a no_std rust project against a comparable JavaCard, but say Diesel vs Hybernate code examples around ORM.

Comparable components, but almost every line of Rust code expresses information about the lifetime of objects - either implicitly (quite often), or explicitly.

Meanwhile in java it's a constant "Arc", and scopes don't mark "drop points"

Re: Java 27

#415

Post by troupo »

samus wrote: post #385
troupo wrote: post #360

Earlier quoted context omitted.

> They really aren't, and they are IMHO an antipattern since they break encapsulation. They don't. Java had to come up with the extremely verbose builder pattern for the exact same thing. And withers are basically the same tedious manual builder pattern, just with a different name. For withers C# just has the with keyword: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

With withers they will become less verbose. In the best case you'll only need to define a value type and a constructor taking an instance of that.

So, only one use case on only one part of the language.

Re: Java 27

#416

Post by troupo »

gf000 wrote: post #378
troupo wrote: post #369

Earlier quoted context omitted.

> but if ever in the future you would want to keep the same API surface but change the internal implementation detail, they let you. So do properties in C# which object initialization relies on. With significantly less manual code, or the need for tedious builder chains and withers. `{ prop = x }` is no more encapsulation breaking than ` .setProp(x) `, but actually makes developer experience better. > No, it's done u…

If the two calls are sequential then simply: var x = someFunction() someOtherFunction() If you would have written var xTask = SomeFunctionAsync(); await WaitForSomeOtherFunctionAsync(); string x = await xTask; then it would be: try (var scope = StructuredTaskScope.open()) { // JDK 24+ preview feature var x = scope.fork(() -> someFunction()); scope.fork(() -> waitForSomeOtherFunction()); scope.join(); String result =…

await implies async functions.

Looks like Java's "there is no simpler syntax than plain old synchronous code" is just a lot of extra manual wrangling of stuff

Re: Java 27

#417

Post by troupo »

samus wrote: post #388
troupo wrote: post #361

Earlier quoted context omitted.

> Probably not a good idea since they break encapsulation by exposing internals of the class. And thousands of manual get/set functions don't? Thousands of lines of builders don't? Object initializers are that plus much better handling of fields/properties that doesn't require hundreds of lines of tedious manual code: https://learn.microsoft.com/en-us/dotnet/csharp/programming-... > for the simple reason that there i…

> And thousands of manual get/set functions don't? My statement doesn't apply to mere data carrier classes. Anyway, getters and setters are an antipattern as well since one can just as well make all the fields public. > Thousands of lines of builders don't? With withers most of these will go away. And a class will be able to choose which things can be set, which is not the case for initializers. > But it's not synchr…

> Anyway, getters and setters are an antipattern as well since one can just as well make all the fields public.

I Java? Yes. Because of the language design, and not because of some inherent "encapsulation" or something.

Somehow `x with { a = b }` doesn't break encapsulation and offers nice DX. But object initializers? Lol

> And a class will be able to choose which things can be set, which is not the case for initializers.

The class in C# can easily chose what can and cannot be set. Because unlike Java it actually cares about things like this.

Quick example

    class Test {
        public int x { get; set; }
        public int y { get; }
    }

    var t = new Test{ x = 1, y = 2 };
I can give you a hint: this will not compile.

Another example:

  public class Matrix
  {
    private double[,] storage = new double[3, 3];

    public double this[int row, int column]
    {
        // The embedded array will throw out of range exceptions as appropriate.
        get { return storage[row, column]; }
        set { storage[row, column] = value; }
    }
  }

  var identity = new Matrix
  {
    [0, 0] = 1.0,
    [0, 1] = 0.0,
    [0, 2] = 0.0,

    [1, 0] = 0.0,
    [1, 1] = 1.0,
    [1, 2] = 0.0,

    [2, 0] = 0.0,
    [2, 1] = 0.0,
    [2, 2] = 1.0,
  };
Incomprehensible abilities for Java-land

> That code won't look that much different with async/await.

Lol. https://news.ycombinator.com/item?id=49726868

Re: Java 27

#418

Post by troupo »

za3faran wrote: post #404
troupo wrote: post #331

Earlier quoted context omitted.

> Are you referring to generators? Both I guess. Main thing is https://learn.microsoft.com/en-us/dotnet/api/system.collecti... which seems to be everywhere in the language and the library. > I believe the same justification applies here, it's mainly syntactic sugar, and can result in certain undesired behavior by bypassing constructors where validation can happen. This is mostly due language design. Java heavily reli…

> You mean it needs 15 lines whete C# needs one? ;) Can you elaborate? The async/await approach is much more than 1 line when you need to switch a call between them. Whereas the green thread approach does not need anything.

What's Java's equivalent of

   x = await someFunction()
   await waitForSomeOtherFunction()
(both are async)

Re: Java 27

#419

Post by spopejoy »

MisterMunchkin wrote: post #322
pineappletooth_ wrote: post #159

Still pretty fun that here banks are still using Java 8, where i work they use java 17 and you can still find work requirements asking for java 7 (mostly in goverment entities)

But why? Surely you can just run the original code on the new version?

A big issue with java at big companies is that the JVM deployment is managed by sysadmin and devs can't touch it. To bless a java upgrade therefore means getting a defensive bureaucracy to take on risk, however miniscule, and since most Java improvements only help devs (rarely do they enable critical user-demanded features), sysadmins won't budge.

Re: Java 27

#420

Post by gf000 »

troupo wrote: post #323
gf000 wrote: post #315

Earlier quoted context omitted.

At the same time, all this syntactic sugar makes the language's surface area gigantic . Like it's almost C++-level complex, and then you would have to properly understand all the interactions between this matrix of features. That's absolutely a valid language design and many people prefer that, but I personally prefer a bit smaller language with a bit more IDE auto complete, but where you never have to think about wh…

> a bit smaller language with a bit more IDE auto complete, but where you never have to think about what exactly does a line do. If you need IDE to autocomplete, then you definitely spend more time to understand what a line does ;)

While typing this comment I pressed/swiped on several words to finish them.

One reads much faster than they write, I don't really see a problem with easily guessable auto complete.

Post reply on HN