It still seems bizarre to me that the Java ecosystem relies upon code-sharing through precompiled binary packages. Compared to for example Rust or Elixir where you only download source and build it locally so that everything is built with the same compiler and environment. This makes it absolutely trivial to debug your dependencies and even fork them when necessary. Most Java programmers wouldn't ever dream of doing that.
Give it another look, it's actually quite nice. The issue you find with it doesn't come up that often in practice. Most of the time (99.9+%) you can find the source code to a specific JAR easily. Want to fork or modify? No problem, just edit he code, compile a new JAR, drop it somewhere. Done. It's like if the intermediate code to your favorite language's JIT were shippable (I'm actually surprised more languages don't do this).
That's actually a major drawback on Rust to be adopted in enterprise settings. Any GPL library statically compiled would force the entire codebase to be licensed under GPL as well.
Whether it's source or a binary doesn't matter. You aren't allowed to use a compiled GPL library in non free code. LGPL was specifically made for that case.
GPL can contaminate you when shared as a dynamic library under certain circumstances. But that doesn't matter, since there are few mainstream libraries in these communities licensed as GPL. Nearly all of it is MIT or Apache.
Why? It makes a ton of sense. Its been a while but I'm pretty sure decompilation leads to much higher level/understandable code in java/c#. Good enough to step into and debug libraries.
And given how fragile/unreproducible it is you almost never want to modify lines in a dependency. In python I'd make a wrapper or monkey patch it instead of modifying the dependency(Or if you need to actually for the library and add it to the dependenies).
Unless it was blocking a one of task that I needed done right away.
Java IDEs can debug third-party code just fine with decompilation. C# IDEs can get the original source code (https://www.jetbrains.com/help/rider/Debugging_External_Code...). Having to build all dependencies would be slower with no significant benefit, especially since the code compiles to bytecode, not native code. Forking is also doable, e.g. with an internal package feed (and you don’t need to integrate your build stuff with theirs).
Isn't this due to inherent limitations of native binaries? Java has very few native dependencies, so its trivial to do binary dependencies. Besides, most packages in maven central have their sources in there as well. You can easily download the source package and let the debugger use that.
No, had nothing to do with native dependencies, they are even more rare in Elixir than Java. It’s simply a different choice in the design.
I know that I can step into a source package with the debugger, but editing that source and rebuilding doesn’t compile the change into my build does it? The last step of debugging is fixing the code, its much more convenient to first try this in the same project where you encountered it.
