ByteCode.News
RSS
SubmitLog in

Community

Chat Logs

Tuesday, February 17, 2026

  1. * CodeGeek!~codegeek@about/java/CodeGeek changed the topic to: Welcome! || Read Channel Rules at https://javachannel.org/ before participating. || Paste limit is two lines; ~pastebin lists options. || No applets, please. || Minecraft, Android, and Javascript all have their own channel. || You are being logged.
  2. * nevet joined #java
  3. kcomhnallmy assumption would be a video about the addition of lambdas
  4. * noord joined #java
  5. cheesernullability
  6. * Aedil joined #java
  7. * emaczen joined #java
  8. * agnivn joined #java
  9. Paravideo description mentions valhalla
  10. dreamrealYeah, youtube title extraction is a PAIN
  11. dreamrealI don't even know WHY. I mean, I know WHY they make it a pain from their end, but dang
  12. ParaYoutube's API and account management in general is superbly stupid.
  13. ParaIt's like 14 steps even when you know what you want to do.
  14. dreamrealYeah, I don't think the bots want to use their API if that can be avoided: twitter's the same way
  15. dreamrealtwitter's API is the only reliable way to get tweets programmatically, and it's $0.005/request, although they have aids for *repeated* requests
  16. dreamrealI decided nevet'll get twitter support when it gets a sponsor who asks for it :D
  17. dreamrealI am still working on youtube, though
  18. dreamrealnitter still works but it does human verification; the other twitter things route to twitter itself now
  19. sbalmosthe only thing more screwy than Youtube's API and account management is AWS IAM and its API authentication
  20. * sa02irc joined #java
  21. ParaAWS IAM is good until policies.
  22. ParaLike...I understand and agree why they're there, but its still bad.
  23. * jamezp joined #java
  24. * GreenResponse joined #java
  25. * ztevoz joined #java
  26. * kcomhnall joined #java
  27. * Ramazanenescik04 joined #java
  28. * Ramazanenescik04 joined #java
  29. * ztevoz joined #java
  30. * ztevoz joined #java
  31. * DoofusCanadensis joined #java
  32. * punk joined #java
  33. * stfstfm joined #java
  34. * punk joined #java
  35. * stfstfm joined #java
  36. * polarian joined #java
  37. * stfstfm joined #java
  38. * polyrob joined #java
  39. * skinkitten joined #java
  40. * RussEfarmer joined #java
  41. * javabot joined #java
  42. * BelleInPixieHoll joined #java
  43. * jamezp joined #java
  44. * Markow joined #java
  45. * stfstfm joined #java
  46. * BelleInPixieHoll joined #java
  47. * stfstfm joined #java
  48. * metalmaniac joined #java
  49. NeXeNoh the nullability thing is huge but i mean it's survived thus far
  50. cheeseri'm sad about nullable still being the default but i don't really see a way they can fix that without breaking almost every single line of code ever written.
  51. * mwnaylor joined #java
  52. NeXeNthere is always a way. use the force. if it doesn't work then make it work harder
  53. jreicherNeXeN: What's "the nullability thing"? The only JEPs I can find about this are still in draft.
  54. ParaNeXeN: If force doesn't work, you're not using enough.
  55. Chronos"Just don't make mistakes"
  56. * ra4king joined #java
  57. * stfstfm joined #java
  58. * lordnoid joined #java
  59. * qbone joined #java
  60. dmlloydthe draft JEPs are generally a reflection of whatever the current state of experimentation is... but they don't always update the JEPs quickly especially if lots of things are being experimented with
  61. dmlloydthere are some JDK trees that you can check out and mess around with if you're brave
  62. cheeserbuilding openjdk is not exactly trivial or pleasant, though.
  63. jreicherOh I'm just interested in knowing what the current thinking is. Is there a sincere effort to add nullability to the type system? Or do people just chat about it over cocktails?
  64. * monkeyPlus joined #java
  65. * svm_invictvs joined #java
  66. NeXeNit's about whether or not something can be set to null. some ways you can get a promise or other ways to keep from ever getting a null
  67. cheeserjreicher: it's a significant effort. it's been on brian's back burner for some time.
  68. cheeserbut i think he considers it low hanging fruit compared to, say, value types.
  69. cheeserum. is that what I meant to say? i got distracted midsentence. it's low *priority* compared to ...
  70. NeXeNit can eliminate a performance concern
  71. NeXeNnull checks are expensive, if one could eliminate null then it would be simpler to design things that don't null pointer error at runtime
  72. cheeseryep. and now that he's thinking "carrier classes" to remove the disconnect between regular classes and records, i'd imagine he's feeling similarly about the gap between value types and regular classes
  73. ParaIIRC most null checks gets eliminated by JIT anyway.
  74. ParaI've never found the attractiveness of this particular topic. Maybe im dum.
  75. cheeseri don't know that that's true... dmlloyd might know better. but that seems like a dangerous check to elide
  76. dmlloydif the JIT can prove that a value coming in is always null, it'll drop the check
  77. dmlloydthat kind of thing can be invalidated by deoptimization
  78. cheeseri'd imagine that's vanishingly rare, though.
  79. NeXeNi do love value classes, and it's a good model for a personal project of mine
  80. dmlloydnot at all, every instance method call or field access has a null check on it
  81. dmlloydso you definitely want to eliminate as many as possible
  82. cheeserthe field would have to be final, no?
  83. NeXeNwell it's like a promise can return a value or not you gotta wait or decide to do something else, and null is really that situation in a nutshell
  84. dmlloydno, the field value isn't null checked, the instance is
  85. dmlloyd`foo.bar(); foo.baz()` <- foo is provably null if `foo.baz()` is reached
  86. NeXeNnull just happens in the data a lot
  87. dmlloydI mean if `foo` is itself a field then yeah it would be rechecked unless it was stable and final
  88. dmlloydbut if it's like a local var then the second one doesn't get null checked
  89. dmlloyd(if `foo` is a stable final field then its value is cached in a register so there's only one load)
  90. dmlloydeven `this.foo()` has an implicit null check that has to get eliminated by *something* that knows `this` is never `null`
  91. * cptaffe joined #java
  92. jreicherYeah elimination of runtime checks is one of the reasons I like type systems. I think Alexis King's "parse, don't validate" essay makes the same point. And the runtime checks include both those done by the language and those the programmer had to write.
  93. * ForeverDreaming joined #java
  94. * magla joined #java
  95. * vincere joined #java
  96. * Ragnor joined #java
  97. * handicraftsman joined #java
  98. * geli joined #java
  99. * skinkitten joined #java
  100. * LtHummus joined #java
  101. * jwisbell35 joined #java
  102. * magla joined #java
  103. * jontxu joined #java
  104. * johni__ joined #java
  105. * kathadris joined #java
  106. * SJrX joined #java
  107. * LtHummus joined #java
  108. * kcomhnall joined #java
  109. NeXeNyou get some extra decorators, like ! to be able to specify something, i forget i read the jep and docs
  110. NeXeNoh yeah it flattens the array as well, making it very performant
  111. NeXeNhttps://openjdk.org/jeps/8303099
  112. javabotNeXeN's title: "JEP draft: Null-Restricted and Nullable Types (Preview)"
  113. nevetNeXeN mentioned url: https://openjdk.org/jeps/8303099 ("JEP draft: Null-Restricted and Nullable Types (Preview)")
  114. NeXeNi am guilty of doing many sanity checks on incoming data
  115. * Square2 joined #java