ByteCode.News
Submit RSS Atom Sign in

Back to the channels

#java

  1. * domicron joined #java
  2. * domicron9 joined #java
  3. NeXeN cheeser: yes, when someone would say "this means war" meant something else
  4. * zorone joined #java
  5. * Nitrousoxide joined #java
  6. * Nitrousoxide joined #java
  7. * rvalue- joined #java
  8. * metalmaniac joined #java
  9. * pr3d4t0r joined #java
  10. * Aedil joined #java
  11. * Aedil joined #java
  12. * stewi joined #java
  13. * domicron joined #java
  14. * stewi joined #java
  15. * stewi joined #java
  16. * stfstfm joined #java
  17. * Ragnor joined #java
  18. * sponkz joined #java
  19. * domicron joined #java
  20. * domicron joined #java
  21. * Deknos joined #java
  22. deebo hmm any annotation processors / some syntactic sugar i don't know about that would turn @FunctionalInterface lambdas into concrete classes at compile time
  23. * Inline joined #java
  24. deebo basically to write a bazillion spring RowMapper/ResultsetExtractors and then referring to them by the class from an annotation
  25. * Wbooze joined #java
  26. * Afroboy joined #java
  27. * Square2 joined #java
  28. * metalmaniac joined #java
  29. * kathadris joined #java
  30. Bombe Argh, why does the maven-assembly-plugin’s jar-with-dependencies descriptor include dependencies scoped "test" in the final JAR file?
  31. * Deknos joined #java
  32. * MikeBux joined #java
  33. * onu joined #java
  34. Bombe Hmm, interesting, mvn -X package shows all dependencies as compile-scoped, but mvn dependency:tree shows the scopes as I expected them to be.
  35. Bombe Now why do they differ, and how do I convince the maven-assembly-plugin to not do that?
  36. * B_fd joined #java
  37. Swayze its a long story ...
  38. Swayze dependency:tree shows your logical POM declarations, while mvn -X shows the flattened, active classpath used by plugins during execution...
  39. * Aedil joined #java
  40. * waznot joined #java
  41. dreamreal ~jini
  42. javabot JINI was an architecture for networked devices. It included a lot of features for remote method invocation, storage, discovery, and other things. Its most successful aspect was *probably* ~javaspaces, but that's anecdotal; JINI is dead and gone, with Apache River (https://river.apache.org) being made read-only in the early 2020s.
  43. dreamreal ~javaspaces
  44. javabot JavaSpaces was a distributed storage/invocation mechanism for JINI. It typically was implemented as an ~imdg, and survives today as the underlying technology for some implementations of IMDGs, such as ~gigaspaces; implementations tended to take the base specs and amplify them to incredible levels, because the specification itself was rather sparse.
  45. dreamreal ~imdg
  46. javabot IMDG stands for "In-Memory Data Grid," usually a memory-based map, often distributable. Implementations center around the JCache API (JSR 107) or JavaSpaces, typically. Tend to be memory-hungry and incredibly fast. See ~infinispan, ~terracotta, ~gridgain, ~coherence, or ~gigaspaces.
  47. dreamreal blitz
  48. dreamreal ~blitz
  49. javabot dreamreal, what does that even *mean*?
  50. Bombe Swayze, hmm. Okay, that answers the “why.” :D
  51. * mixfix41 joined #java
  52. Bombe Motherfucker. maven-assembly-plugin 3.6.0 does it the way I expect it to, 3.7.1/3.8.0 do not.
  53. * raj joined #java
  54. Bombe Ah. https://github.com/apache/maven-assembly-plugin/issues/1236
  55. nevet [MASSEMBLY-1031] Regression: assembly plugin 3.7.0 now includes scope=provided dependencies if they also occur transitively · Issue #1236 · apache/maven-assembly-plugin
  56. javabot Bombe's title: "[MASSEMBLY-1031] Regression: assembly plugin 3.7.0 now includes scope=provided dependencies if they also occur transitively · Issue #1236 · apache/maven-assembly-plugin · GitHub"
  57. Bombe Alright, 3.6.0 it is. :D
  58. * mixfix41 joined #java
  59. dreamreal https://bytecode.news/posts/2026/04/layoffs-at-oracle
  60. javabot dreamreal's title: "Layoffs at Oracle | bytecode.news"
  61. * waznot joined #java
  62. * geenvoud joined #java
  63. * jamezp joined #java
  64. * GreenResponse joined #java
  65. cheeser a confusing article. i'm not sure what it's trying to say.
  66. Tenchi the layoffs article? it says a lot
  67. * ChaiTRex joined #java
  68. cheeser but what's it all about, alfie?
  69. Tenchi i only skimmed, but there's a handful of takeaways for me... layoffs aren't fun, layoffs happen for a reason, they affect more than just the employee being laid off BUT the separation of employees from the company doesn't necessary mean a net loss for the community/ecosystem
  70. Tenchi also touches on the whole free lunch paradigm
  71. cheeser right. it says things but doesn't really *say* anything. is it "we can't complain if we don't pay?" "layoffs suck." not exactly groundbreaking. it just felt like it was building to a point that never landed. at least for me.
  72. * Chronos comments on the Oracle Layoffs article
  73. Chronos I just love making myself look dumb for the world to see!
  74. cheeser Chronos: i had a similar thought. :)
  75. Chronos I just had to sneak in a little Oracle bashing too, heh.
  76. Chronos Because, hey, _Oracle_.
  77. * MonsterAbyss joined #java
  78. cheeser yeah. oracle really sucks. but they are (mostly) our overlord for better and worse.
  79. Chronos They have been, in my opinion, pretty decent stewards of Java.
  80. Chronos Now that work is finally beyond Java 8, it's been fun using some of the new Java features.
  81. cheeser it could've been worse for sure. as far as the tech goes, they've been great honestly. it's mostly the business and community bits they suck at.
  82. cheeser e.g., the Java EE -> Jakarta EE thing could've been way less heartburn. but trademark law is dicey and i can appreciate why they wouldn't want to take on unnecessary burdens. it just made life harder for the rest of us.
  83. * agnivn joined #java
  84. * deepSleep joined #java
  85. * kcomhnall joined #java
  86. * kcomhnal1 joined #java
  87. * agnivn joined #java
  88. * agnivn joined #java
  89. * tonitch joined #java
  90. * Aedil joined #java
  91. * jayyyy50 joined #java
  92. jayyyy50 hello
  93. jayyyy50 is anyone avalible to play
  94. DoofusCanadensis can billy come out to play?
  95. ernimril all work and no play makes Jack a dull boy
  96. jayyyy50 hello
  97. * jayyyy50 left #java
  98. * pengu1nx joined #java
  99. pengu1nx Hi, I need some advice on how I can/should plan a game I'm trying to create with my friend. I really don't have an idea on how this is usually done. We started, but it's getting a bit chaotic in my eyes
  100. Para What kind of game?
  101. Para Mainly, realtime, networked, turn based, 2D/3D graphics...?
  102. pengu1nx 2D, realtime, singleplayer
  103. pengu1nx Nothing too complicated, but we use libGDX for it as it gives us some handy tools
  104. Para ~libgdx
  105. javabot Para, libgdx is a cross-platform Java game development framework based on OpenGL (ES) that works on Windows, Linux, Mac OS X, Android, your WebGL enabled browser and iOS. It comes with extensions for physics engines (Box2d, Bullet), AI, pathfinding and more. See http://libgdx.badlogicgames.com/ and #libgdx
  106. Para So yeah, that.
  107. Para Dunno if their channel is any active.
  108. pengu1nx yes but that doesn't help with planning?
  109. Para Well, planning is a wide subject.
  110. pengu1nx Hmm, I'll try to specify what I mean
  111. Para For example https://en.wikipedia.org/wiki/Entity_component_system might be useful for designing the architecture.
  112. nevet Entity component system - Wikipedia
  113. pengu1nx Yes, we use that, we installed ashley
  114. Para There's plenty of actual gamedev resources available online if you're struggling with the actual design of the game.
  115. pengu1nx I think what I'm looking for is a way to create class diagrams and how they interact, or some way to visualize the code flow of the game
  116. pengu1nx Since that seems beneficial before writing the code that's meant to implement it
  117. Para Well, you have an 2D drawing environment. Start drawing boxes and lines... :)
  118. Para Other than that, pen and paper. Most diagramming methodologies are kinda stupid, use what works for you.
  119. Para [thing] ---(verb/action)--> [thang], e.g. [cat] --(eats)--> [fish]
  120. * sponkz joined #java
  121. Para That's pretty much all you need to get started.
  122. pengu1nx I'll think about it a bit, tahnks
  123. Para https://gamedev.net/ :)
  124. javabot Para's title: "Game Development Community - GameDev.net"
  125. * stfstfm_ joined #java
  126. [twisti] Para: i discovered ECS on my way out of game dev, always regretted never being able to play around with that
  127. * kento2 joined #java
  128. * gareppa joined #java
  129. * tronexte joined #java
  130. * sponkz joined #java
  131. * B_fd joined #java
  132. * julemand101 joined #java
  133. * metalmaniac joined #java
  134. * johnjay joined #java
  135. * mindCrime joined #java
  136. * pengu1nx joined #java
  137. * waznot joined #java
  138. * waz_ joined #java
  139. * metalmaniac joined #java