3 ms·

Did you know that Java lets you any number of module scoped classes in a single file, just that the public class has to have the same name as the file? There ar

Did you know that Java lets you any number of module scoped classes in a single file, just that the public class has to have the same name as the file? There are a lot of things like that you can do in Java which people just don't do that makes many things a lot cleaner. Its just that the eco system standards were set by people who thought that having unique class names were super important even though Java already have namespacing. Also that you need to have 100% super guaranteed unique global namespaces making your folder structure that horrible net.xxx.abc.adsasd.dfer.cthulu.NetXxxAbcAdsasdUtilityHelperBuilderFactory things, which for some reason wasn't needed in any other programming language and it worked just fine for them so you don't need that either. With that instead of importing stuff you could just write something like, assuming each library have a sensible top level name: gzip.File g = gzip.File.FromDirectory(dir); When I write Java personally it looks closer to that. And when I follow a corporate style I write it more like that, as close as possible while still following the style guide. I 100% believe Java could have been a nice experience if it didn't have its horrible over engineered style guides.

dirkt 6y ago
> There are a lot of things like that you can do in Java which people just don't do that makes many things a lot cleaner. The problem is not "people could use that particular Java feature to make code cleaner, but they don't". The problem is on a higher-level: If you have ever tried to read your way through some library, e.g. Spring, you'll see code spread over hundreds of files, and it takes ages to just find out where that particular bit of code you need is, because it's automatically injected in some builder class which is an inner object extending some other object that implements an interface somewhere. And then you have several competing abstractions, and sometimes one gets used, and sometimes the other. IDEs and type hierarchies help, but only to some degree. And then you are still stuck with an overengineered abstraction that nevertheless does not allow you to do the obvious thing that needs to be done in your particular case. So you need to implement a fragile workaround, for example copying one of the library classes, modifying it a bit, and then injecting it instead of the one from the framework. All of which will horribly break if someone changes something in the library. "Style" is never the problem.
- username90 6y ago
  > The problem is on a higher-level: If you have ever tried to read your way through some library, e.g. Spring, you'll see code spread over hundreds of files, and it takes ages to just find out where that particular bit of code you need is, because it's automatically injected in some builder class which is an inner object extending some other object that implements an interface somewhere. There is nothing about Java the language which forces code to be written this way though.

dirkt 6y ago

> There are a lot of things like that you can do in Java which people just don't do that makes many things a lot cleaner. The problem is not "people could use that particular Java feature to make code cleaner, but they don't". The problem is on a higher-level: If you have ever tried to read your way through some library, e.g. Spring, you'll see code spread over hundreds of files, and it takes ages to just find out where that particular bit of code you need is, because it's automatically injected in some builder class which is an inner object extending some other object that implements an interface somewhere. And then you have several competing abstractions, and sometimes one gets used, and sometimes the other. IDEs and type hierarchies help, but only to some degree. And then you are still stuck with an overengineered abstraction that nevertheless does not allow you to do the obvious thing that needs to be done in your particular case. So you need to implement a fragile workaround, for example copying one of the library classes, modifying it a bit, and then injecting it instead of the one from the framework. All of which will horribly break if someone changes something in the library. "Style" is never the problem.

username90 6y ago
> The problem is on a higher-level: If you have ever tried to read your way through some library, e.g. Spring, you'll see code spread over hundreds of files, and it takes ages to just find out where that particular bit of code you need is, because it's automatically injected in some builder class which is an inner object extending some other object that implements an interface somewhere. There is nothing about Java the language which forces code to be written this way though.