ByteCode.News
Submit RSS Atom Sign in

Back to the channels

#java

  1. * Munnu joined #java
  2. * fwumo joined #java
  3. * OmniRadix69891 joined #java
  4. * uidzero joined #java
  5. * LtHummus joined #java
  6. * OmniRadix69891 joined #java
  7. * cmiles74 joined #java
  8. NeXeN jreicher: yeah i like it, but i would prefer a solution that doesn't come with instructions one must follow
  9. * DynamiteDan joined #java
  10. * _10KBps joined #java
  11. * erbium joined #java
  12. * amosbird joined #java
  13. * mz` joined #java
  14. * sparr joined #java
  15. * priime joined #java
  16. * mixfix41 joined #java
  17. * canton7 joined #java
  18. * bullshark joined #java
  19. jreicher NeXeN: what do you mean? I'm not arguing, just trying to understand.
  20. NeXeN well 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
  21. * jjakob joined #java
  22. NeXeN it is a good solution, none the less
  23. jreicher You 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.
  24. NeXeN yes, a dev would want to use it. it switches contexts and so it's tidy way to keep from remembering to close a context
  25. jreicher Is 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?
  26. jreicher ^private^provide
  27. NeXeN the spring implementation is quite different as spring already understands contexts really well and it's well suited for it
  28. NeXeN and 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
  29. * michele2 joined #java
  30. NeXeN essentially 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
  31. NeXeN but 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
  32. NeXeN hehe, jep 401 (not found)
  33. jreicher You mean the value object jep? I'm aware of that stuff
  34. jreicher ~jep401 you say?
  35. javabot '401 you say?' is not a valid JEP reference.
  36. jreicher Oh wow. I thought it would strip the suffix
  37. jreicher ~jep401
  38. javabot 'JEP 401: Value Objects (Preview)' can be found at http://openjdk.java.net/jeps/401
  39. NeXeN yeah, 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
  40. nevet JEP 401: Value Objects (Preview)
  41. NeXeN i 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
  42. jreicher Why didn't you rewrite the whole thing in C like a normal person?
  43. NeXeN so 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
  44. jreicher (I'm joking, BTW)
  45. NeXeN i have some in C, but just where i needed performance
  46. NeXeN anyways, 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)
  47. NeXeN and i see that all my work has been deprecated. i think value objects will be how i'll do things moving forward
  48. jreicher I haven't used them yet but I've been really looking forward to doing so.
  49. NeXeN i 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
  50. NeXeN that'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
  51. NeXeN which 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)
  52. NeXeN one 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
  53. * sunyour joined #java
  54. * sbalmos joined #java
  55. * summerisle joined #java
  56. * deebo joined #java
  57. * ramontjunior joined #java
  58. * deepy joined #java
  59. * acidjnk joined #java
  60. * hugdru joined #java
  61. * pebble joined #java
  62. * hugdru joined #java
  63. * hugdru joined #java
  64. * hugdru joined #java
  65. * hugdru joined #java
  66. * hugdru joined #java
  67. * hugdru joined #java
  68. * hugdru joined #java
  69. * hugdru joined #java
  70. * Muspah joined #java
  71. * qbone joined #java
  72. * dumptruckman joined #java
  73. * antonix joined #java
  74. * digicyc joined #java
  75. * gh0stbuster joined #java
  76. * MikeBux joined #java
  77. * dmlloyd joined #java
  78. * Disconsented joined #java
  79. * OmniRadix698919 joined #java
  80. * Geolykt joined #java
  81. * jreicher joined #java
  82. * jbosmans joined #java
  83. * leppard joined #java
  84. * leppard joined #java
  85. * leppard joined #java
  86. * akaWolf joined #java
  87. * leppard joined #java
  88. * leppard joined #java
  89. * leppard joined #java
  90. * leppard joined #java
  91. * leppard joined #java
  92. * jreicher joined #java
  93. * leppard joined #java
  94. * Inline joined #java
  95. * leppard joined #java
  96. hassoon 'morning
  97. * jreicher joined #java
  98. Inline morning
  99. * odinsbane joined #java
  100. odinsbane Intellij is giving me a strange warning. `'ForkJoinPool' used without 'try'-with-resources statement`
  101. odinsbane The forkjoinpool isn't autoclosable and if I put it inside of a try/catch it doesn't get rid of the warning.
  102. * ramontjunior joined #java
  103. deebo it is autocloseable though? via AbstractExecutorService
  104. odinsbane Ah, I see. ForkJoinPool now implements closable, but I'm still targeting java 8.
  105. odinsbane Looks like that change happened in java 19.
  106. deebo language level for project maybe off then?
  107. odinsbane That would explain it. It is set to 25 somewhere, but maven has a rule to target 8.
  108. Bombe Yeah, you need to configure some more shit to make IDEA adhere to that.
  109. * ramontjunior joined #java
  110. dreamreal targeting java 8, ouch :/
  111. Para With a gun, I hope.
  112. dreamreal hey, java 8 was really good
  113. * canton7 joined #java
  114. * Fiji joined #java
  115. * jamezp joined #java
  116. sbalmos 8 was good, 11 was good
  117. * kinabalu joined #java
  118. * hwpplayer1 joined #java
  119. * RetroPunk joined #java
  120. dreamreal 25 is better, and the next LTS is likely to be yet another game changer
  121. * Soulcatcher joined #java
  122. * hwpplayer1 joined #java
  123. odinsbane 25 seems to have better performance for me than 21.
  124. dreamreal tehre's a reason for that!
  125. * cmiles74 joined #java
  126. * hwpplayer1 joined #java
  127. * odinsbane joined #java
  128. * sa02irc joined #java
  129. * ernimril joined #java
  130. * Cae2 joined #java
  131. * hwpplayer1 joined #java
  132. * GreenResponse joined #java
  133. * vincere joined #java
  134. * [twisti] joined #java
  135. * ramontjunior1 joined #java
  136. * ramontjunior joined #java
  137. * rorx joined #java
  138. * cmiles74 joined #java
  139. * MikeBux joined #java
  140. * hwpplayer1 joined #java
  141. * bionade24 joined #java
  142. * Ekho joined #java
  143. * Joel joined #java
  144. * magla joined #java
  145. * hwpplayer1 joined #java
  146. * HamAdams joined #java
  147. * ta71 joined #java
  148. * metalmaniac joined #java
  149. * sa02irc joined #java
  150. * dob1 joined #java
  151. * kathadris joined #java
  152. * internecine joined #java
  153. * lava joined #java
  154. * henbruas joined #java
  155. * hwpplayer1 joined #java
  156. Bombe I’m happy we recently switched our main product from Java 11 to 21.
  157. * cmiles74 joined #java
  158. dreamreal We went 8->17, with a plan to go to 25 real soon now
  159. ernimril jikes, what is taking you soo long to get to modern java?
  160. dreamreal maintainers and/or love
  161. dreamreal ernimril: I thought you had your own compiler
  162. ernimril I do, I am actually working on it right now :-)
  163. dreamreal So why you carin about dum ol jikes huh
  164. ernimril It can actually compile itself in a loop now (java 25).... But I know it still has a few problems with real world codebases
  165. ernimril jikes was a fine compiler, sadly it never got updated for java 5
  166. dreamreal i remember being quite impressed when it first came out
  167. ernimril it was on hold for a long time, but I have gotten back to it now
  168. * cmiles74 joined #java
  169. * hwpplayer1 joined #java
  170. * Maldivia joined #java
  171. * bullshark joined #java
  172. * leppard joined #java
  173. * Inline joined #java
  174. * m joined #java
  175. jbosmans way back when, it used to be expensive supported middleware keeping solutions back from upgrading
  176. * Pixi` joined #java
  177. * hwpplayer1 joined #java
  178. * leppard joined #java
  179. * Inline joined #java
  180. * Candle joined #java
  181. * dstein64 joined #java
  182. * Ragnor joined #java
  183. * Candle joined #java
  184. * raj joined #java
  185. * Gaz7051122720067 joined #java
  186. * Soulcatcher joined #java
  187. * graves joined #java
  188. * hwpplayer1 joined #java
  189. * jetchisel joined #java
  190. * Optic joined #java
  191. * hwpplayer1 joined #java
  192. * yano joined #java
  193. * whaley joined #java
  194. Optic java 21 is the last 32 bit java i think
  195. * kento2 joined #java