javabotjreicher's title: "jdk/src/java.base/share/classes/java/lang/RuntimeException.java at fb268a6f43fb7e7a0b962d10504a686acfd883ff · openjdk/jdk · GitHub"
jreicherArgh, sorry. Should have used a branch.
deebois that a link to the serilizationid? i mean more like public static RuntimeException INSTANCE = new RuntimeException();, i can of course do that myself, but i'd assume there's a publicly available one somewhere in the jdk
deeboor i could just subclass it and use the parent ctor to not create stack traces etc
odinsbaneClaude says it doesn't exist.
odinsbaneIt's really strange when it tries to shoehorn the question in to the project I'm working on.
odinsbaneIt says there are some private instances for OutOfMemory etc, because you might not be able to build a stack trace.
deebobut guess i'll create a local one myself, weirdly graphql-java uses failed completedfutures for flow control kindof, but they require a throwable
NeXeNdeebo: no doesn't look like it, i searched the source
NeXeNyou could create your own subclass and override fillInStackTrace() to make it light so you don't have lots of stacktrace
rosettahi
NeXeNmake it stateless, pass it to .. hrmm CompleteableFutre.failedFuture(YourExtendedClassRuntimeException.YOUR_PUBLIC_STATIC_FINAL_CONSTANT and make it like a singleton
* NeXeN shrugs
NeXeNyour fillInStacTrace() make it return this on your extended class
NeXeNerr sorry hard to explain what i mean. so you have a singleton. it's public static final. i would call it INSTANCE, ...like public static final YourExtendedClass INSTANCE = new YourExendedClass(); in the constructor Private YourExtendedClass() { super (null, null, false, false); (so you can suppress stack trace make it light) then @override like maybe public Throwable fillInStackTrace() { return this; ); so now pass the constant into
NeXeN CompleteableFuture.failedFuture() when you need it for flow control
NeXeNand when i meant you could, i mean yes i agree that'll work
NeXeNi just tried it and yeah it's pretty light
NeXeNbut i was reading the docs, can't you use DataFetcherResult from graphql?
javabotNeXeN's title: "Annotated Controllers :: Spring GraphQL"
deeboNeXeN: this is about org.dataloader dataloaders and their caching behaviour specifically
deebothe docs say the ValueCache#get() needs to return a failed CompletableFuture if the cache doesn't contain the value
deeboi just created a CheapoException that calls the super ctor that allows disabling stack traces
dreamrealis filling out the stack trace expensive for you? Are you getting them a LOT?
dreamrealNo doubt that they're "expensive" but spending 3000ns every 7s is... measurable but irrelevant
dreamreal(and yes, that 3000ns is pulled out of thin air: a deeper exception trace is going to cost more.)
NeXeNit could also have other issues
NeXeNso yeah, same thing i think you were trying before
NeXeNso you can return CompleteableFuture(YourExtendedClassException.INSTANCE) seems maybe name it CacheMissException to make it sensible
NeXeNi also think you could look at it differently. maybe use a container type like Optional to separate the missing state from failures. you can return a CompleteableFuture<Optional<V>> ...it wil distinguish between "we looked and wasn't there" and "something actually broke" (a true exception)
NeXeNi wouldn't do the static base exception class unless the interface you're dealing wit enforceses throwable
NeXeNyou could also handle it at the cache map level i think......getIfPresent/GetIfCompleted or a map lookup pattern type thing ...but do it before invoking operations that require a completable future by passing the miss handling path for standard checks
NeXeNi just don't like futures being used for routine cache misses. instead of treating it as exceptional which forces you into the failedFuture() and trying to optimize stack trace with this kludge, you could focus on clean state checking and validation. you could use like java-dataloader to provide inspection like methods for GIP/GIC (get if present, complete, respectively) and instead of blindly calling the lookup that forces error handling branch on a
NeXeNmiss, the code just checks if the value is already present/complete in the local cache map layer first
NeXeNusing like redis or memcached or something?
dmlloydI just heard a colleague utter the phase "JDK 33"
cheeserClair Obscur: Expedition 33 was incredible. you should go play it.
dmlloyddo I have to do the other 32 expeditions first?
odinsbaneThis is a crazy coincidence, I remember writing that a long time ago. Then today I want to javachannel.org and it was on the top of the blog.
odinsbaneI didn't realize it was mine, anyway. This whole chunk: double[] extrema = new double[]{-Double.MAX_VALUE, Double.MAX_VALUE};
odinsbane rectangles.stream().forEach((rect)->{
odinsbane double w = rect.getWidth();
odinsbane extrema[0] = w>extrema[0]?w:extrema[0];
odinsbane extrema[1] = w<extrema[1]?w:extrema[1];
odinsbane });
* cheeser eyes odinsbane
dreamrealbut... why are you telling ME this
odinsbaneThat should be replaced with rectangles.stream().mapToDouble().summaryStatistics()
dreamrealright, so replace it?
odinsbaneLike I said it is a crazy coincidence. I thought you wrote the blog post and didn't realize it was what I had sent you ... years ago?
dreamrealIt's dated 2026/09/26, I do not run javachannel.org and have not for years
cheeserfun fact: it's fully self-aware now and taking note of its haters.
dreamrealoof, the rendering on the site is... not great
dreamrealI dunno what we did to lose yawkat but...
cheeserhe's off at oracle doing the dark lord's work.
dreamrealoh, good for him!
odinsbaneAre the logs not working?
dreamrealwhat logs
dreamrealdang it,I am missing all the context for this discussion
odinsbaneAnyways, I just assumed you had written it because you had written the next four or five posts.
odinsbane- logs == channel logs
dreamrealodinsbane: fair, I guess. bytecode.news has channel logs for #java, through nevet; dunno about javabot.
dreamrealcheeser: I assume that's still okay, I can turn that off if you want
cheeseri don't mind.
cheeserthe bot is still logging. i'm mostly done with a migration off dropwizard. i just have to test that the web view still works and then i'll merge and deploy it.
dreamrealodinsbane: nevet's logs do not go back as far as javabot's, of course
odinsbaneOh, I was going to check the conversation from today.
jbosmanswhat's the added value of publicly sharing all logs?
dreamrealcontext, etc
jbosmanslike for AI ?
dreamrealLike, we have a lot of accumulated wisdom and the logs have a lot of it, if you know how to look
dreamrealno
cheeserfun fact: the early javabot had a primitive form of ... i guess it would be closer to ML than anything else. HAL it was called, iirc.
cheeserbut it tried to serialize a map of 65+M worth of data on every channel event. performance was not great.
dreamrealprevayler FTW!
jbosmansi understand the value of data, but the 100% "public" of it somehow doesn't sit 100% well with me, although it's been in the topic forever so sure no complaints :)
cheeserit's probably been the policy longer than you've used irc :)
dreamrealWell, for IRC the recommendation is this: if you don't want it known that you said it, don't say it
odinsbanejbosmans when you have a crappy web interface and you want to check if a topic was somehow resolved or not.
jbosmansinteresting, how long has it been the policy? :)
cheeserwell over 2 decades now
dreamrealjbosmans: stretches back through efnet and freenode #java for literal decades
dreamrealefnet #java had the same policy, freenode #java as well although the two channels aren't related
jbosmans:) in that case (alas) not longer
odinsbaneWe thought it would die with the y2k bug.
jbosmansanswers all make sense, just a difference of opinion, and also for me: times changed since then i think
jbosmanssame way eg http mostly went out of fashion vs https
dreamrealI don't think an AI scraper would have a great time pulling out coherent content from IRC logs like these
jbosmansaka you're a bytecode expert as you've shown just before :)
ernimrileh, bytecode is easy to read, I am not writing it myself though
ernimril(using the classfile api)
odinsbaneThis probably ~would be~ is a pretty good source for ai scraping. There's been a lot of trash talking, but a lot of questions have been answered to.
ernimrilodinsbane, ?
odinsbanes/to\./too\./
dreamrealernimril: he's talking about logs, I think.
odinsbanedreamreal said "I don't think an AI scraper would have a great time pulling out coherent content from IRC logs like these"
jbosmansah classfile api, that's brian goetz' latest hands on code iirc
ernimrilthe classfile api has been around for quite a few years now
jbosmanssounds great ^
dreamrealodinsbane: Well, I still disagree: the channel is borderline incoherent when it's busy, and most of the knowledge shared is shared more coherently elsewhere. After all, that's part of the reason javachannel.org existed in the first place: to take the incoherent stuff from the channel conversation and boil it into coherence.
jbosmanshmm i may be confusing it with something else :s i'm definitely a user of java rather than expert
jbosmans(classfile api was removed from preview with JDK 24 it seems so i'm not full out of date)
ernimrilyes, but it was in preview for several releases
ernimriland dmlloyd backported it to earlier versions
jbosmansright, i knew that
jbosmansi'm very much a user of java, maintaining things etc, so never preview features (for one)
jreicherjavabot logs are still missing from the website. Just sayin'.
javabotjreicher, what does that even *mean*?
jreicherOh I'm so sorry. That got mentioned just four hours ago. (Still catching up on scrollback)
jreicherdreamreal: I didn't realise you had the logs on bytecode. Ta.
jreicherAlso, where do you think Java knowledge is shared more coherently than here? (Other than "properly authored" articles/blogposts, etc.)