4 ms·

Java 8 made it an "okay" language for me to use. It's a lot better nowadays, but historically the biggest problem with Java has been the 3rd party libraries.

by sbov 7y ago

Java 8 made it an "okay" language for me to use. It's a lot better nowadays, but historically the biggest problem with Java has been the 3rd party libraries. They tended to be written with extensibility in mind at the expense of usability. Extensibility is great, but it's not the only important thing in a design. I'm not a huge fan of annotations. It makes the language feel a bit magical and hard to debug in some places. It can be difficult to track down how a given library actually treats an annotation - or even a set of annotations since you can put more than one on a given thing. It puts the language in a strange place: sometimes both boilerplate-heavy and magical. > The introduction of annotations in JDK 5 has made enterprise Java development a whole lot simpler by allowing things like dependency injection. This is a bit weird - you don't need annotations to do dependency injection. And you don't need a DI framework either. One thing I don't quite understand is the infatuation with DI frameworks in Javaland. I prefer to just do it by hand where both necessary and plausible.

rurounijones 7y ago
99% of the time I see DI used in Java it is solely to enable mocked dependencies in unit testing rather than injecting different production implementations depending on environmental differences or something like that. I have had Code Reviews where "This is all good, but you should use Guice to mock X" where X is the one time I might have a package-private test only constructor with a NullObject for the one dependency I need to mock out in a commit and Guice is not currently used in the package at all. Personally I think DI has reached cargo cult status in Javaland.
- miohtama 7y ago
  Dynamic languages like Python do not have this issue as you can mock any method runtime for the duration of test. This can done via "monkey patching". It is unclean, but the development cost of having a framework to do just this is a tad high. The only downside is that if you parallel test you need to run them in separate processes (which you usually want to do.any case).
jesseschalken 7y ago
You're right. Java is a decent language with a decent type system (bar the lack of null safety and some other quirks). It's all the annotations and reflection and XML and magic that creates most of the pain, and that's the fault of the library and framework developers, not Java itself.
- sgift 7y ago
  > Java is a decent language with a decent type system (bar the lack of null safety and some other quirks). Optional is your (and my) friend. It has a small performance penalty and for historic reasons it will never be used everywhere, but for new externally visible code (code not in the class) I try to use it and it makes for face nicer APIs. I never understood why XML config everywhere and "we should configure it all instead of programming it" took off. You shouldn't change things on production anyway, so the main aspect "you can change it without recompile" is moot and instead you have all the downsides of not having part of your code checked by the compiler.

by sbov 7y ago

rurounijones 7y ago

99% of the time I see DI used in Java it is solely to enable mocked dependencies in unit testing rather than injecting different production implementations depending on environmental differences or something like that. I have had Code Reviews where "This is all good, but you should use Guice to mock X" where X is the one time I might have a package-private test only constructor with a NullObject for the one dependency I need to mock out in a commit and Guice is not currently used in the package at all. Personally I think DI has reached cargo cult status in Javaland.

miohtama 7y ago
Dynamic languages like Python do not have this issue as you can mock any method runtime for the duration of test. This can done via "monkey patching". It is unclean, but the development cost of having a framework to do just this is a tad high. The only downside is that if you parallel test you need to run them in separate processes (which you usually want to do.any case).

jesseschalken 7y ago

You're right. Java is a decent language with a decent type system (bar the lack of null safety and some other quirks). It's all the annotations and reflection and XML and magic that creates most of the pain, and that's the fault of the library and framework developers, not Java itself.

sgift 7y ago
> Java is a decent language with a decent type system (bar the lack of null safety and some other quirks). Optional is your (and my) friend. It has a small performance penalty and for historic reasons it will never be used everywhere, but for new externally visible code (code not in the class) I try to use it and it makes for face nicer APIs. I never understood why XML config everywhere and "we should configure it all instead of programming it" took off. You shouldn't change things on production anyway, so the main aspect "you can change it without recompile" is moot and instead you have all the downsides of not having part of your code checked by the compiler.