ByteCode.News
Submit RSS Atom Sign in

Back to the channels

#java

  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. kcomhnall my assumption would be a video about the addition of lambdas
  4. * noord joined #java
  5. cheeser nullability
  6. * Aedil joined #java
  7. * emaczen joined #java
  8. * agnivn joined #java
  9. Para video description mentions valhalla
  10. dreamreal Yeah, youtube title extraction is a PAIN
  11. dreamreal I don't even know WHY. I mean, I know WHY they make it a pain from their end, but dang
  12. Para Youtube's API and account management in general is superbly stupid.
  13. Para It's like 14 steps even when you know what you want to do.
  14. dreamreal Yeah, I don't think the bots want to use their API if that can be avoided: twitter's the same way
  15. dreamreal twitter'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. dreamreal I decided nevet'll get twitter support when it gets a sponsor who asks for it :D
  17. dreamreal I am still working on youtube, though
  18. dreamreal nitter still works but it does human verification; the other twitter things route to twitter itself now
  19. sbalmos the only thing more screwy than Youtube's API and account management is AWS IAM and its API authentication
  20. * sa02irc joined #java
  21. Para AWS IAM is good until policies.
  22. Para Like...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. NeXeN oh the nullability thing is huge but i mean it's survived thus far
  50. cheeser i'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. NeXeN there is always a way. use the force. if it doesn't work then make it work harder
  53. jreicher NeXeN: What's "the nullability thing"? The only JEPs I can find about this are still in draft.
  54. Para NeXeN: 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. dmlloyd the 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. dmlloyd there are some JDK trees that you can check out and mess around with if you're brave
  62. cheeser building openjdk is not exactly trivial or pleasant, though.
  63. jreicher Oh 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. NeXeN it'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. cheeser jreicher: it's a significant effort. it's been on brian's back burner for some time.
  68. cheeser but i think he considers it low hanging fruit compared to, say, value types.
  69. cheeser um. is that what I meant to say? i got distracted midsentence. it's low *priority* compared to ...
  70. NeXeN it can eliminate a performance concern
  71. NeXeN null 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. cheeser yep. 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. Para IIRC most null checks gets eliminated by JIT anyway.
  74. Para I've never found the attractiveness of this particular topic. Maybe im dum.
  75. cheeser i don't know that that's true... dmlloyd might know better. but that seems like a dangerous check to elide
  76. dmlloyd if the JIT can prove that a value coming in is always null, it'll drop the check
  77. dmlloyd that kind of thing can be invalidated by deoptimization
  78. cheeser i'd imagine that's vanishingly rare, though.
  79. NeXeN i do love value classes, and it's a good model for a personal project of mine
  80. dmlloyd not at all, every instance method call or field access has a null check on it
  81. dmlloyd so you definitely want to eliminate as many as possible
  82. cheeser the field would have to be final, no?
  83. NeXeN well 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. dmlloyd no, 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. NeXeN null just happens in the data a lot
  87. dmlloyd I mean if `foo` is itself a field then yeah it would be rechecked unless it was stable and final
  88. dmlloyd but 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. dmlloyd even `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. jreicher Yeah 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. NeXeN you get some extra decorators, like ! to be able to specify something, i forget i read the jep and docs
  110. NeXeN oh yeah it flattens the array as well, making it very performant
  111. NeXeN https://openjdk.org/jeps/8303099
  112. javabot NeXeN's title: "JEP draft: Null-Restricted and Nullable Types (Preview)"
  113. nevet NeXeN mentioned url: https://openjdk.org/jeps/8303099 ("JEP draft: Null-Restricted and Nullable Types (Preview)")
  114. NeXeN i am guilty of doing many sanity checks on incoming data
  115. * Square2 joined #java