NeXeNjreicher: yeah i like it, but i would prefer a solution that doesn't come with instructions one must follow
jreicherNeXeN: what do you mean? I'm not arguing, just trying to understand.
NeXeNwell it's an idiom devs have to adopt if they use the lib. i wanted to be dx focused as it's really not a permenant solution just a way to help people ease into the domain
NeXeNit is a good solution, none the less
jreicherYou mean it's the devs using the lib that would be writing this try-with-resource block? I thought it was in the library itself.
NeXeNyes, a dev would want to use it. it switches contexts and so it's tidy way to keep from remembering to close a context
jreicherIs there a way to private an in-library helper of some kind so that this solution (which seems to be the right one) can be used without consuming devs having to write it?
jreicher^private^provide
NeXeNthe spring implementation is quite different as spring already understands contexts really well and it's well suited for it
NeXeNand i really expect that to be 90% of the use case, but i also wanted a way for "vanilla" client code to interface with the lib without having to instantiate contexts and manually manage the lifecycle
NeXeNessentially the lib lets you take a pojo and either a) use a provided object or b) wrap their object so that they can created the objects using factories i've hidden behind this context, so it's seamless you can begin to use and test value objects (identityless). there's some guards for mutation issues and other things
NeXeNbut you know let you benchmark if you could take a stream of objects and what they would perform as a value object....uh lemme find the jep number
NeXeNhehe, jep 401 (not found)
jreicherYou mean the value object jep? I'm aware of that stuff
jreicher~jep401 you say?
javabot'401 you say?' is not a valid JEP reference.
jreicherOh wow. I thought it would strip the suffix
NeXeNyeah, so the lib wraps a block of code in this context with the try-with-resources, so that the code within that block will utilize these value objects instead of regular identity based objects
nevetJEP 401: Value Objects (Preview)
NeXeNi originally had been building a lib to do a similar thing as value objects, which essentially packs objects into primitives for performance, but now that we have jep 401, i refactored the lib to essentially let you choose your strategy, identity safe, value objects, or primitive packed
jreicherWhy didn't you rewrite the whole thing in C like a normal person?
NeXeNso i didn't abandon my old effort but i see that also it will be defeated by value objects. also i did some panama stuff and since it's essentially a benchmarking lib, i have made also a strategy for it, to store off heap
jreicher(I'm joking, BTW)
NeXeNi have some in C, but just where i needed performance
NeXeNanyways, at the end of the day, now i have a neat little javafx dashboard that runs simulations to max out and count garbage collection and other stutters so i can watch how each strategy performs (identity safe, value objects, primitive packed, and panama offheap)
NeXeNand i see that all my work has been deprecated. i think value objects will be how i'll do things moving forward
jreicherI haven't used them yet but I've been really looking forward to doing so.
NeXeNi need to start writing some docs, i'm so lazy. i want to upload it so i can get advice, but i'm embarrased because i can't maintain a project like that.....i'm too lazy
NeXeNthat's the purpose. i had the idea to merge it with what i had already been doing because i wanted to test it on an app i have that has lots of gc churn in the eden space
NeXeNwhich i find i can get from like 3x to 30x in simulations (like vectors and pixel visual simulations, real data streaming in from the firehose is a different story)
NeXeNone of the difficulties i have found is with threading. man with virtual threads being so cheap they really move the pressure around. it used to be you want to get latency down as small as possible, but now you gotta worry about backpressure because everything's insanely good now
hassoon'morning
Inlinemorning
odinsbaneIntellij is giving me a strange warning. `'ForkJoinPool' used without 'try'-with-resources statement`
odinsbaneThe forkjoinpool isn't autoclosable and if I put it inside of a try/catch it doesn't get rid of the warning.
deeboit is autocloseable though? via AbstractExecutorService
odinsbaneAh, I see. ForkJoinPool now implements closable, but I'm still targeting java 8.
odinsbaneLooks like that change happened in java 19.
deebolanguage level for project maybe off then?
odinsbaneThat would explain it. It is set to 25 somewhere, but maven has a rule to target 8.
BombeYeah, you need to configure some more shit to make IDEA adhere to that.
dreamrealtargeting java 8, ouch :/
ParaWith a gun, I hope.
dreamrealhey, java 8 was really good
sbalmos8 was good, 11 was good
dreamreal25 is better, and the next LTS is likely to be yet another game changer
odinsbane25 seems to have better performance for me than 21.
dreamrealtehre's a reason for that!
BombeI’m happy we recently switched our main product from Java 11 to 21.
dreamrealWe went 8->17, with a plan to go to 25 real soon now
ernimriljikes, what is taking you soo long to get to modern java?
dreamrealmaintainers and/or love
dreamrealernimril: I thought you had your own compiler
ernimrilI do, I am actually working on it right now :-)
dreamrealSo why you carin about dum ol jikes huh
ernimrilIt can actually compile itself in a loop now (java 25).... But I know it still has a few problems with real world codebases
ernimriljikes was a fine compiler, sadly it never got updated for java 5
dreamreali remember being quite impressed when it first came out
ernimrilit was on hold for a long time, but I have gotten back to it now
jbosmansway back when, it used to be expensive supported middleware keeping solutions back from upgrading