ByteCode.News
Submit RSS Atom Sign in

Back to the channels

#java

  1. * youfoundwaldo joined #java
  2. * marcel joined #java
  3. * Betal joined #java
  4. * ErikT joined #java
  5. * youfoundwaldo joined #java
  6. * youfoundwaldo left #java
  7. * youfoundwaldo joined #java
  8. * metalmaniac joined #java
  9. * kcomhnall joined #java
  10. * pengu1nx3 joined #java
  11. dreamreal https://bytecode.news/posts/2026/03/json-toon-yaml-and-more-considering-data-serialization-formats
  12. Tenchi dreamreal: so did you upgrade to v3 or not ?
  13. * cptaffe joined #java
  14. * x1bncwn joined #java
  15. dreamreal yes
  16. dreamreal I did not migrate away from JSON anywhere
  17. dreamreal but jackson 3 was implemented, everywhere except in one place
  18. dreamreal but that's a separate article
  19. cheeser yaml is the best data transport format.
  20. DoofusCanadensis look, you
  21. cheeser if you're looking to fight me, i'll add you to the list. i think i have this right. it's a yaml doc so ...
  22. cheeser hey, copilot, i'm getting an NPE because in the code you generated, you're not passing a parameter so the default value of null gets used. fix it, please. "oh, i see what's wrong. I need to pass 'context = null' as an argument so the default value of null doesn't get applied to that parameter."
  23. DoofusCanadensis geez
  24. * MonsterAbyss joined #java
  25. * agnivn joined #java
  26. * jjj333_p joined #java
  27. * stewi joined #java
  28. * deavmi joined #java
  29. * deavmi joined #java
  30. * kcomhnall joined #java
  31. * waz joined #java
  32. * LtHummus joined #java
  33. * pengu1nx1 joined #java
  34. pengu1nx1 Memory pooling is used for storing many Objects of the same type with short lifespans, right? I don't quite understand the reasoning, does the garbage collector immediately remove free space? Or why is memory allocation so bad?
  35. * zorone joined #java
  36. deebo note sure what you mean with "memory pooling", generic object pooling can be used for situations where the objects are reusable/borrowable and take a "long" time to initialize, like http or database connections
  37. * dinomug joined #java
  38. pengu1nx1 I meant that, my bad
  39. deebo outside of the well known uses, probably not worth it, atleast not without validating a bottleneck that could be helped with a pool
  40. * jreicher joined #java
  41. * Aedil joined #java
  42. dmlloyd https://openjdk.org/jeps/8357464 looks nice
  43. javabot dmlloyd's title: "JEP draft: Enhanced Local Variable Declarations (Preview)"
  44. nevet JEP draft: Enhanced Local Variable Declarations (Preview)
  45. Para Oh I'm loving that.
  46. * MonsterAbyss joined #java
  47. deebo hmm, is there something blocking typescript type destructuring like {location: {int x, int y}, double radius} = myCircle;, that Circle(Point(...), ...) looks wordy
  48. Para That's more of a TypeScript's quirk though, as its emulating types on top of duck-typed objects.
  49. * MonsterAbyss joined #java
  50. Para If that lands proper, IDEA's going to have some kind of smart refactoring thing available for picking values anyway so I'm not that worried :)
  51. deebo yeah then you try to indent it and it swaps half your file with ai slop
  52. Para There probably is one step more in squeezing that, but it would look a bit noisy IMHO. Like, either use vars instead of object names. Java already kinda has parsed meaning for ((()()) so it wouldn't be that easy to handle in backwards compatible manner, but as it's a draft, maybe they'll come up with something extra.
  53. Para Like for example if it's a sealed class, the matching is exhaustiva -> allow some shorthand.
  54. deebo great feature though, i'll just end up hating the verboseness and lisp level of () in deep nesting
  55. Para Use proper lisps and it'll be ridinculously simpler :)
  56. Para Destructuring in Clojure is very dense and feature rich.
  57. Para (that family also includes Fennel and jank)
  58. * henbruas joined #java
  59. kcomhnall heh, so that jep preview is something that's clearly already existed in other languages? Rust.. Python.. Typscript as you guys already mentioned and others.
  60. kcomhnall yeah..."nice"
  61. kcomhnall or am I missing something?
  62. * ForeverDreaming joined #java
  63. * kcomhnall suddenly feels like writing in C#
  64. dmlloyd yeah the language team is very careful about adding stuff
  65. dmlloyd other languages are a bit more aggressive about it
  66. kcomhnall by the language team I assume you're talking about project amber?
  67. Para Java the language, JVM the runtime/platform. They're two very distinct things, but obviously interlinked.
  68. * MikeBux joined #java
  69. Para JVM is bleeding edge, Java is conservative. It has always been like this on purpose.
  70. dmlloyd amber is only one of several projects related to enhancing the language
  71. kcomhnall bleeding edge? huh.. interesting take on a mature runtime env
  72. kcomhnall the maturity is the whole reason I enjoy using Java... hardened and w.o.r.a are important for my projects.
  73. kcomhnall "JVM"
  74. MikeBux i still wan to learn a compiled language like go, rust or c/c++ though,
  75. * TomyWork joined #java
  76. dmlloyd that's also a poor distinction, as java is compiled at run time, and can optionally be pre compiled to a native executable by projects such as graalvm
  77. Para Maturity and bleeding edge are not exclusive either; that's why e.g. that draft is available through feature flag as preview.
  78. MikeBux yes but the usual way is to compile the bytecode at runtime, which means, every time you want to run a program, it needs to be compiled
  79. kcomhnall ~karma Para
  80. javabot para has a karma level of 24, kcomhnall
  81. kcomhnall hmm
  82. dreamreal jep 8357464
  83. nevet jep 8357464: draft: Enhanced Local Variable Declarations (Preview) (https://openjdk.org/jeps/8357464)
  84. * ne555 joined #java
  85. * stfstfm joined #java
  86. dreamreal pengu1nx1: that's a very complex subject; java's memory model is largely pluggable and therefore there's not a great answer to it that is actually correct for all cases
  87. dmlloyd the upside of jit compilation is that you get compiled cods tailored for your cpu's features every time, which isn't always possible or practical with precompilation
  88. Para look also: linux kernels
  89. dreamreal yeah, sometimes there's a question of whether you need it or not: tradeoffs everywhere
  90. dmlloyd code, not cods 🐟
  91. dreamreal I don't mind go but I've failed to be impressed with it
  92. Para vibe cod
  93. dreamreal I do mind rust but OTOH it HAS impressed me
  94. dreamreal https://bytecode.news/posts/2026/03/enhanced-local-variable-declarations-in-java
  95. * MonsterAbyss joined #java
  96. * agnivn joined #java
  97. * odinsbane joined #java
  98. * simon816 joined #java
  99. * x1bncwn joined #java
  100. * odinsbane joined #java
  101. nimaje dmlloyd: well for that you could also change the system to compile to some IR, distribute that and on install optimise it for the target cpu (afaik android does that)
  102. dreamreal nimaje: it's doable, yes
  103. * yano joined #java
  104. dmlloyd well, java bytecode _is_ an IR
  105. dreamreal I have a project that runs on an embedded device that's, well, Intel, sort of... we COULD theoretically AOT it externally but that's a lot
  106. dreamreal (It is intel but we don't know the exact cpu profile)
  107. Para IA-32
  108. nimaje a jit can additionally optimise on concrete runtime values, especially if it knows that it will be loaded once and then stay the same
  109. dreamreal yes, we're aware :D
  110. Para That sounds like AI to me!
  111. dreamreal you know, as time goes by I hate the "AI" label more and more
  112. dreamreal I mean, AI is... a whole series of algorithms, an LLM is just one variant and an expensive one
  113. nimaje about everything is AI, be more specific
  114. * acidjnk joined #java
  115. cheeser dmlloyd: so that JEP is destructuring, basically
  116. dmlloyd yeah basically, at least for the local variable case
  117. dmlloyd it will be very helpful for cases where you have to interrupt/split an otherwise trivial conditional to introduce a local variable
  118. * 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.
  119. * nevet joined #java
  120. dreamreal How expensive is that, though
  121. dreamreal (interrupting/splitting an otherwise trivial conditional...)
  122. dmlloyd the only cost would be at compile time; the bytecode is the same
  123. dmlloyd oh, the cost there is reduced readability
  124. dmlloyd in other words, the language enhancement will enable better readability
  125. dreamreal ... will it? I mean, it might - and destructuring CAN be useful in some languages, but the places where it'd really matter would be really limited. Simple expressions might benefit but I really do wonder how many people are desperate for deconstructed declarations like that.
  126. dreamreal I've been using Java since 1998, and I've yet go to "dang, I sure wish java let me do deconstructed declarations," not that it might be the best thing java's seen since sliced bread or whatever
  127. * sa02irc joined #java
  128. * agnivn joined #java
  129. Chronos What's an example of a deconstructed declaration?
  130. dreamreal Predicate(subject, predicate, value) = p.rdf; // do something with subject
  131. Chronos dreamreal: Thanks.
  132. * Chronos is mildly skeptical of the value of that particular syntactic sugar.
  133. Chronos It looks like Java 21 has something called "Record Patterns" which has some kind of deconstruction.
  134. Chronos If I'm understanding this correctly...
  135. Chronos For example: Object obj = new Person("Alice", 30); if (obj instanceof Person(String name, int age)) { ... }
  136. dreamreal yes
  137. dreamreal but that's a different level of deconstruction
  138. Chronos Oh, it looks like JavaScript has had this feature since ES6
  139. Chronos dreamreal: Ah.
  140. Bombe dreamreal, eh, I feel the same about pattern matching.
  141. Bombe It always feels like I’ve failed to properly utilize OOP when I suddenly need to know the type of an object.
  142. Chronos OK, I can see how this syntactic sugar could be nice :)
  143. cheeser i've wanted destructuring plenty of times in java but kotlin kinda ruined me in that regard.
  144. cheeser pattern based destructuring will be fine, i guess, but not as convenient as kotlin's syntax.
  145. * dragonmaster left #java (WeeChat 3.6)
  146. * jamezp joined #java
  147. * kcomhnall joined #java
  148. dreamreal that's kind of the problem: kotlin has it, other languages have it, does java NEED it?
  149. dreamreal I mean, it's possible; it might be a simple extension of the switch/case stuff
  150. sbalmos depends on whether you see continued viability of the ecosystem as Java-centric, or JVM-centric
  151. dreamreal That's a good point - I guess I see it as jvm-centric so it's kinda meh for me to worry about destructured stuff
  152. * agnivn joined #java
  153. * waz joined #java
  154. * sa02irc joined #java
  155. * Exagone313 joined #java
  156. * waz joined #java
  157. * meyou joined #java
  158. * Aedil joined #java
  159. * dinomug joined #java
  160. * 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.
  161. * nevet joined #java
  162. * mindCrime joined #java
  163. * kcomhnall joined #java
  164. * stfstfm_ joined #java
  165. * kcomhnall joined #java
  166. * magla joined #java
  167. * waz joined #java
  168. * schan99 joined #java
  169. * Candle joined #java
  170. * ne555 joined #java
  171. * ForeverDreaming joined #java
  172. * graves joined #java
  173. * stewi joined #java
  174. * dinomug joined #java
  175. * jaskarth joined #java
  176. * MikeBux joined #java
  177. * mindCrime joined #java
  178. * polarian joined #java
  179. * kathadris joined #java
  180. * kathadris joined #java
  181. * stfstfm joined #java
  182. * Ragnor joined #java
  183. * waz joined #java
  184. * ferdna joined #java
  185. * zorone joined #java