Community
Chat Logs
Wednesday, August 19, 2026
- * jreicher joined #primate
- * skillnews joined #primate
- * skillbot joined #primate
- bluedreamreal: https://dpaste.com/967MYB5BR
- jreicherblue: what is that?
- bluejreicher: a demonstration of why I dislike java
- jreicherBecause you used Integer rather than int and you think it should mean the same thing?
- bluejreicher: no, because == behaves unexpectedly, even for java. the first comparison is true, the second is false
- blueit's bad enough that == checks for identity, but it's even worse that it does not at least behave consistently
- jreicher== is behaving there exactly as it's defined for Integer. The definition is different for int. It has nothing to do with the language.
- blueobviously I'm not alone in thinking that, otherwise JEP 401 weren't a thing
- blueand java doing some kind of object caching for -128 to 127 is the very definition of dumb
- jreicherWhat object caching are you talking about?
- bluein the example I provided, the compiler outputs true, then false
- blueie, n1 == n2 (with the values of 127) is true, whilst n3 == n4 is false
- bluehttps://docs.oracle.com/javase/specs/jls/se21/html/jls-5.html
- nevetChapter 5. Conversions and Contexts
- blue"If the value p being boxed is the result of evaluating a constant expression (§15.29) of type boolean, byte, char, short, int, or long, and the result is true, false, a character in the range '\u0000' to '\u007f' inclusive, or an integer in the range -128 to 127 inclusive, then let a and b be the results of any two boxing conversions of p. It is always the case that a == b."
- jreicherblue: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Integer.html#valueOf(int)
- nevetInteger (Java SE 21 & JDK 21)
- jreicher"This method will always cache values in the range -128 to 127, inclusive, and may cache other values outside of this range."
- jreicherSo again, it's the definition of that specific method, and nothing to do with the language
- bluehow does the distinction matter? Integer.valueOf is very much an inherent part of the language, it's not like it's a third-party library
- blueI mean, Integer is java.lang.Integer
- jreicherFair, I'm not going to argue the distinction. I'm just trying to point out that it's in the definition of one very specific part of the language/jdk. it's not like this is a design principle that extends throughout the entire language. And that one tiny corner is behaving exactly as it's defined.
- blueI'm not arguing that something isn't working as designed, jreicher. My point is the design is faulty, not just of this, but generally of the == operator comparing by identity. And the java language design process itself seems to have reached the same conclusion (only needing 30 years?), otherwise we wouldn't have JEP 401
- blueof course I find it deeply regrettable that JEP 401 won't extend to strings, but that's life, can't have it all
- jreicherI'm not arguing with you about the faultiness of the design, but the extent of it. You're making a claim about valueOf(). Is it faulty? Perhaps? Does that mean "the language is faulty"? That's nonsense.
- jreicherPut another way, if you want to make a claim about ==, then pick an example that doesn't depend on a quirk of just one method.
- bluethe claim is easily abstractable: if something is inherently immutable, such as strings, then it is faulty to compare it by identity
- bluestrings are my biggest pet pieve
- jreicherI agree, that's an easy to understand claim. I see no reason to believe it's true though IN GENERAL. I could have a very complex object that, although being immutable, is quite impractical to have an equality test in any way other than identity.
- jreicherhttps://en.wikipedia.org/wiki/Graph_isomorphism_problem
- nevetGraph isomorphism problem - Wikipedia
- jreicherFor example
- bluethat may be the case, but is it the *common* case? i.e., is this more important than the usefulness of string comparison by == ?
- blueother languages have mechanism for explicit identity comparison, like === in javascript
- bluemechanisms*
- jreicherI'm fairly sure I will be sympathetic to all the cases you want to call "common" for the purposes of being cases that i will be sympathetic to.
- jreicherThe point is that your claim is much harder in general.
- jreicherAnd so I reject that it's a claim about the entire language. That still makes very little sense.
- blueI do not mean to reject the entire language on account of those faults. But they are massive faults in my eyes, and very annoying pet pieves. The best way to express it from my position is that java is not low-level enough to justify a c-like/rust/zig strcmp, but String#equals is in fact exactly that. Expressed differently: at the abstraction level that java is -- no manual memory management -- my
- blueexpectation is for the == operator to work as expected (by which I mean a general programming, c-inherited expectation)
- bluethe combination of a higher-level language and low-level gotchas is terrible
- blueand this *is* a gotcha. it cannot be argued away by "learn the language better". A language is primarily judged on ergonomics, expectation management, and ease of understanding. I do not need to under the java object model to use == on two strings, that's an expectation mismatch
- blues/under/understand/
- jreicherOf you expect == to be what you expect, because you came to Java prejudiced with your expectation. I'm asking you to justify that expectation rather than keep putting forward this circular argument.
- jreicherWhy SHOULD == work that way? What's wrong with object identity for complex objects?
- blueand I just did: java is not low-level enough to justify a strcmp instead of ==
- jreicherThe burden of proof is the other way. You need to justify your expectation.
- bluethere's nothing wrong; but working with strings is by far and wide the more common case than working with complex (immutable, so rarer still) objects you need to compare
- jreicherI already said I would be sympathetic to the common cases, but you keep trying to make a claim about == in general.
- jreicherIf you restrict what you are saying to just the definition of == for String, we won't have an argument.
- bluebut that *is* my point. I want == to generally work for strings, integers, and anything else that, for lack of a better umbrella term, I put under "immutable", as in representing a concrete value that's unchangeable without reassignment. You seem to take issue with some (as far as I'm concerned) corner case of complex immutable objects?
- jreicherYou don't get to say "I want to change the behaviour for String, and I want to achieve that by changing the behaviour for EVERYTHING". That's maddeningly silly. Why can't you see that? You're either talking about String, or your'e talking about everything. If the former, restrain yourself. If the latter, justify it properly.
- blueI already did; == should compare by value for immutables, by identity otherwise (mostly custom objects) -- this is the javascript behaviour. Additionally, there should be an explicit === operator or just the java #equalsTo method, if you explicitly want to enforce "by identity"
- jreicherI'll offer you a better category: immutable scalars. That's probably what you really mean.
- jreicherSo complex immutable objects don't owe you anything.
- bluehm, unsure. What about two sets that both contain [2, 3] ?
- jreicherExactly.
- blueyou really want to compare them by identity? is that meaningful? I don't think so
- jreicherYou really want to compare them with value equality? You sure that's reasonable?
- blueI think so. That's my mathematical understanding of sets, and tuples, and I find it good
- bluewe could argue if it should be limited to immutable or mutable sets, but I find it good
- jreicherIt's not a mathematical question. It's a computational one.
- bluebut still I'd like to harp on th ecomplex immutable objects. Could you explain *why* it makes sense to compare them by identity? they're unchangeable post-construction, so what benefit does the identity comparison hold?
- jreicherI just did. Consider the computation of doing value equality. A set with a million elements should do the trick as an example.
- blueisn't that an implementation detail though?
- jreicherThe implementation has to satisfy the contract, and conversely the contract can't be something that's impossible to implement. So consider the contract carefully. You're the one who is preoccupied with programmer expectation, and I think you are right.
- blueI'd be remiss to not remind here that the tuples & records proposal for javascript (tuples would be immutable arrays, records immutable objects) wasn't rejected on account of computational complexity, but on account of browser makers not wanting to have additional primitives in the language, due to bad past experience in the introduction of bigint
- jreichertuples and records are different to sets.
- blueI'm pretty sure that an array comparison of millions of elements presents a similar, if not higher challenge (sets are generally unordered), than sets?
- jreicherProbably, yes, but I don't think that's the same as a tuple or record either.
- bluejust to be clear here, since the terms are terribly overloaded in CS. a 'tuple' in the proposal would have been the exact same thing as a JS array, with the exception that it would be immutable, and its comparisons would be by value(s). And 'record', the same, for JS objects
- blueby which term I don't mean any JS object, but a classic dictionary object, {}
- bluehash map/associative array/whatever other name CS has for it
- jreicherI don't take tuples to be the same as a JS array
- bluein the proposal, they were. I'm strictly speaking of how the proposal defined them
- jreicherAre you sure?
- jreicherWhy have a new type identical to something that already exists?
- bluebecause immutability is great
- bluearray: [], tuple: #[] (as per the proposal)
- jreicherAnd what do you think immutability would do to the use of the array?
- bluewell, as per the proposal, nothing, arrays would stay the same
- blue[1, 2] == [1, 2], false
- jreicherIf the "array" (tuple) is immutable, it means you can only set the elements at initialisation, right?
- blue#[1, 2] == #[1, 2], true
- blueyes
- jreicherSo what do you think that does to the "array" (tuple)?
- blueintern it
- jreicherAnd?
- blueyou're gonna argue it becomes a comparison by identity. but that supports exactly my point for Java!
- jreicherNot at all. Not even close.
- jreicherWhat's the initialisation syntax?
- blue#[1, 2]
- jreicherWhat would that look like for a tuple with a million elements?
- blue#[1, 2, ..., 1000**2]
- jreicherDo you think that would happen?
- bluesurely. I can see you reading into stuff from fasta files into memory
- bluethere are many use cases; conf files (as per the record syntax, immutable objects: #{}); read the conf once, then reread when it is saved, and now you have a reliable way to check if it actually changed
- jreicherWell I don't. I think the only reason "most people" consider tuples and records feasible candidates for value equality is that the literal addressing in source code of them has a natural limiting effect on their dimensionality. They are effectively scalars.
- jreicherThey're tiny.
- bluewhat about vector equality in a coordination system (higher dimension)?
- bluecoordinate system*
- jreicherSame. From a computational point of view it's effectively a scalar. But I don't really care about the terminology. What I care about is the scale. If you want to limit your complaint to small immutable objects, we don't have an argument. But if you want to make a general point you have to explain why it's reasonable for large complex objects.
- blueI'm not gonna die on the large complex objects hill. My point is ergonomics: if 90% of the use cases are covered, that's fine by me
- bluethat being said, I would stand unopposed to an Object.same static method or so
- dreamrealblue: that paste is not why you dislike java
- dreamrealthat behavior is documented and well-known and predictable *and* justifiable
- dreamrealdislike java if you like, justifying it is dumb
- dreamrealInteger equality is based on object equality, and new integers are allocated sparsely: the range from -127 to 127 is always going to get you the same integer object
- dreamrealapart from that, no
- dreamrealand as always you don't use == to compare *object equality* but only object *identity*
- dreamrealthis is not a "oh use == for these objects but not these over here" situation
- dreamrealif you want object identity, use ==. If not, use equals(). That's it.
- dreamrealand there *are* instance methods for helping be more explicit.
- dreamrealbut for SOME reason most java coders don't need them, being able to reason
- dreamrealwas hoping there was soemthing worthwhile here
- jreicherActually it might be worth considering the idea that == is object equality for primitive types too. It's just that they are very special objects.
- jreicherSorry, I mean object identity!
- dreamrealHmm, I wonder if java exposes the reference information for primitives like that
- dreamrealvalhalla's going to mangle all of that, including the rules about integer allocation, I think
- dreamrealI haven't tried valhalla out yet: work's on java 17, with an intended migration to 25 later this quarter: when that happens we'll break the chains to old java versions (we're lucky we got 17 when we did) and THEN when valhalla gets to LTS we'll be able to try it out
- dreamrealbut until it's LTS there's no point
- dreamrealwe'll have to see if I last a work for that to happen :D
- dreamrealbut shhhh that's not common knowledge
- jreicherYour work migrates to something when it's LTS? We normally do it when it's EOL.
- dreamrealWe're apparently forward-thinking! haha
- dreamrealactually, the developers on the team said "screw this, we're not staying on 8"
- dreamrealand by the time the people who would have said "oh yes we are" had a choice we'd already migrated
- dreamrealthere's a lot of political momentum involved, part of why I might move on
- jreicherAh, the good old mutinous developers strategy
- dreamrealI was shouting for 21, but 17 won (installation rules won) and now we have release to move to 25, it's just a drag to move the toolchain
- dreamrealand we have bigger problems
- bluedreamreal: -128 to 127, you mean!
- bluedreamreal: btw, we're on 21 (I think I told you). I got us there from... *drums* java 8.
- dreamrealblue: the actual range doesn't matter
- dreamrealand good
- dreamreal21 is good
- blueI feel like my boss though will comfortable sit on 21 until it's literally cut away from under his feet, which is like, 2031
- dreamreal17 is okay but 21 is far better
- blueof course, I personally want to go up to 25, because you know, wasm shenanigans
- bluenot that we're gonna use that, but I just *like* 25 because it's wasmable
- * dreamreal refuses to point out cheerpj which can wasmify java 7
- dreamrealsorry, java 9
- dreamreal8
- dreamrealdamn it
- dreamreal8
- bluebtw; if anyone wants to have with a primate java backend, you're all cordially invited!
- dreamrealdamn cat
- bluehaha
- bluewants to help*
- dreamrealshe's a lovely creature but wants my right hand
- bluethere's a poc just awaiting for you (yes, looking at YOU) to make it a reality!
- bluehttps://github.com/primate-run/wasm/tree/master/java
- blueof course, that poc is just me running java in wasm, but hey, that's something!
- bluemostly I haven't explored that further because I'm lacking the mindset of what would be a good API for the routes
- blueeverything I came up with seemed overengineered to me
- dreamrealThat's unlikely to be avoided with java
- blueIOW, forcing users to write a class for every route file, seems like a nightmare
- blueiirc java 25 though has toplevel methods
- dreamrealit's pretty much the standard for Java
- dreamrealdon't use them
- bluewhy not?
- dreamrealkotlin has them, but I would avoid them here
- dreamrealidiom
- blueWHY
- dreamrealeveryone would look at primate and say "okay it has java" and use spring or quarkus instead
- dreamrealthey use annotations for methods to establish routes
- blueimport static primate.Route.*; void main() { get(request -> "Hello from Java"); }
- bluethat's good, no?
- dreamrealit's very easy, very convenient, and is a standard now
- dreamrealit's also insufficient for anything but a toy
- dreamrealbut do as you wish, see what happens, if I wa sthe one to build the better mousetrap I'd have done it already
- blueI don't need to reinvent spring though
- dreamrealnobody does
- blueI need a good wasm backend for primate
- dreamrealand vert.x and quarkus and others don't
- bluewhat's wrong with the snippet I just examplified?
- dreamrealit's very short, and gives no hint to context or routes or parameters or any other routes
- blueroutes are filesystem based, you know that
- dreamrealand the thing about classes being in files is that it makes them very easy to *find*
- dreamrealyes, and you'd be swimming against 30 years of java convention
- dreamrealIBM tried that
- blueyou have to flip the mindset. I'm not trying to convince JAVA users. I'm convincing primate users who might need to use a Java lib! that's a different value proposition
- dreamrealsure, and I'm not the one who can speak to them
- blueI don't need to go up against spring or vert.x or quarkus or whoever's the new kid on the block, because I don't care about them; I can about making most of the java ecosystem integratable to a primate application
- bluethat's a whole different ball game!
- dreamrealSure
- bluealso, unrelated, there's a dude who wants to work with me on flog
- bluehe proposed the original version: make the *engine* interchangable
- bluethis was my original idea before I decided it was too much work for one person
- * skillnews joined #primate
- * skillbot joined #primate
- * skillnews joined #primate
- * skillbot joined #primate
- * skillbot joined #primate
- * skillnews joined #primate
- * skillnews joined #primate
- * skillbot joined #primate
- * skillbot joined #primate
- * skillnews joined #primate
- * skillnews joined #primate
- * skillbot joined #primate
- * skillbot joined #primate
- * skillbot joined #primate
- * skillnews joined #primate
- * skillnews joined #primate
- * skillbot joined #primate
- * skillnews joined #primate