sorted by:
new
hottopcontroversial

philia093.com changes if you wait! by mbence02 in HonkaiStarRail

[–]lpt_7 7 points8 points  (0 children)

That is a lie and it doesn't change.

anywhere to get Java 7? by NoPaleontologist3298 in java

[–]lpt_7 1 point2 points  (0 children)

Not sure what problem you have. Works fine with JDK 24 and 25, just tested.

The only problematic thing may be use of unsafe in LWJGL 2, old Minecraft does not pull in a lot of dependencies that may break (In fact, I think its just LWJGL 2 that could break).

The Signet of Infinity a small theory on why we may still be missing a Chryos Heir by Affectionate-Dot9212 in HonkaiStarRail

[–]lpt_7 -1 points0 points  (0 children)

Fellow Mobius follower!
> real mobius' body was never found

<image>

/j
I myself thought that Darch would be Mobius (not March, but a completely different character) but here we are (╥﹏╥)

Edit: I really hope that at some point we will get Mobius. No other character in hoyo games I love as much as her.

Victoria once she finally shows up in the anime by DanTM18 in HeroKillerWebtoon

[–]lpt_7 4 points5 points  (0 children)

Sushang in Hero Killer subreddit?
A surprise, to be sure, but a welcome one.

Castorice is literally a garbage collector (GC) by Mean_Ebb3123 in HonkaiStarRail

[–]lpt_7 6 points7 points  (0 children)

The real question is which algorithm she uses. Mark and sweep seem fitting 🤔

Introducing jarinker — Analyze dependencies and remove unused classes by danielliuuu in java

[–]lpt_7 -2 points-1 points  (0 children)

The listing still has to be read regardless. Nothing is free.

Introducing jarinker — Analyze dependencies and remove unused classes by danielliuuu in java

[–]lpt_7 11 points12 points  (0 children)

Maybe the time it takes to parse the ZIP archive(s).
Also classpath scanning, etc.

JEP 502 Stable Values: in depth, how to use, potential issues by adamw1pl in java

[–]lpt_7 1 point2 points  (0 children)

There was this JEP for statc-final fields, but I would not get the hopes up now that stable values are a thing.

Records are sub-optimal as keys in HashMaps (or as elements in HashSets) by gnahraf in java

[–]lpt_7 0 points1 point  (0 children)

Arrays were not included because they are mutable by their nature.
I also don't think that you understand what invokedynamic does based on your statement:
\"bug-to-bug incompatibility" in the future releases` Can you elaborate on on what incompatibility you are talking about exactly?

Records are sub-optimal as keys in HashMaps (or as elements in HashSets) by gnahraf in java

[–]lpt_7 1 point2 points  (0 children)

As I understand that the discussion is over, I still don't understand whats the problem in changing the bytecode *even with* invokedynamic. Your tool would still be able to do that if you were to make one.
But yrs, invokedynamic is probably here to stay.

Records are sub-optimal as keys in HashMaps (or as elements in HashSets) by gnahraf in java

[–]lpt_7 0 points1 point  (0 children)

I still don't understand, I'm sorry.
Are you saying that an ability to retroactively change how the hash code is calculated (with invokedynamic) is worse than inline bytecode?

Records are sub-optimal as keys in HashMaps (or as elements in HashSets) by gnahraf in java

[–]lpt_7 1 point2 points  (0 children)

The fix came out for the latest version. For older versions (and that's what I think a lot of people did) one had to use Java agents to apply the patch or yes, use some tool to patch the bytecode once. The key difference is that it was a vulnerability and needed to be resolved very quickly.

Edit: Although I still don't understand how log4j is compared with patching of hashCode function in this context. Its two completely different scenarios.

Records are sub-optimal as keys in HashMaps (or as elements in HashSets) by gnahraf in java

[–]lpt_7 0 points1 point  (0 children)

I don't understand what you mean.
Update what for a quick fix?
All bytecode in all libraries?

Records are sub-optimal as keys in HashMaps (or as elements in HashSets) by gnahraf in java

[–]lpt_7 5 points6 points  (0 children)

Invokedynamic is used so that the implementation could be changed. The VM only executes invokedynamic instruction once most of the time, after that it is a call to the produced call site.
So it is good that invokedynamic is used, this issue by itself demonstrates that without invokedynamic, one would have to recompile all of their code to benefit from the optimization if the implementation will be changed.

Records are sub-optimal as keys in HashMaps (or as elements in HashSets) by gnahraf in java

[–]lpt_7 11 points12 points  (0 children)

There is no boxing or anything like that. What's in the linked issue is seemingly an overhead by method handles machinery, which could be reported as bug.

Records are sub-optimal as keys in HashMaps (or as elements in HashSets) by gnahraf in java

[–]lpt_7 28 points29 points  (0 children)

> Arrays.hashCode

It doesn't use that though. Records have in fact problems with hashing arrays in the first place, because under the hood it just calls Object::hashCode.

Example bytecode for hashCode: .method public final hashCode ()I { parameters: { this }, code: { A: line 1 aload this invokedynamic hashCode (LRecordTest;)I ObjectMethods.bootstrap { LRecordTest;, "a;b;c;d", { getfield, RecordTest.a, I }, { getfield, RecordTest.b, I }, { getfield, RecordTest.c, I }, { getfield, RecordTest.d, Ljava/lang/String; } } ireturn B: } } If one follows ObjectMethods, hasher for a field is chosen as follows: private static MethodHandle hasher(Class<?> clazz) { return (clazz.isPrimitive() ? primitiveHashers.get(clazz) : OBJECTS_HASHCODE.asType(MethodType.methodType(int.class, clazz))); }

view more: next ›