Hacker News Reader

Comment by no_wizard | Hacker News Reader

You'd think after all the engineering that went into Java they would solve it to allow arbitrary directories and such.

I don't know why, but this bothers me for some reason. To the point that I (perhaps irrationally, I admit) couldn't get "into" learning the language.

Same deal with $GOPATH in Go, until vendoring became properly supported I just hated it.

View on HN

> allow arbitrary directories and such

OH PLEASE NO.

You generally don't write Java using bash/cd/vim; the IDE presents classes and package paths and puts files where they need to be. "Where is my code" is not something you need to explicitly think about.

In contrast, javascript/typescript files are often poorly organized and it's frequently necessary to look for code via grep-like tools. Yes sure, someone could organize js/ts files well, but it actually takes mental effort and coordination among the whole team.

Java was heavily inspired by smalltalk, which IIRC didn't give you a "filesystem" view of your project - it was an integrated environment with a proprietary storage format. Also IIRC early versions of IBM's VisualAge for Java maintained this paradigm. I think the "everything is individual files, but the IDE maintains them" was actually a pretty good compromise.

Java is not alone in this, turns out some conventions are great in large scale projects.

Simplifying conventions a bit here couldn’t hurt is another way of looking at it. Maybe instead of the long src directories it could be simplified to app and tests top level directories for example.

True, however since already the Visual Cafe, JBuilder and Visual Age days, Java IDEs have tried to provide a Smalltalk like experience, given where the community was coming from, so the concept of a virtual image mapped into the file system has always been present.

As such, code browsers always made this quite easy.

The fact that Eclipse provides a Smalltalk like code browser isn't an accident, rather its Visual Age roots.

It is only a problem when one makes the point to navigate through the source, outside Java tooling.

For a simple HelloWorld or a PoC development a flat list of .java files would work, but once you go past that (20+ files or so) a standardized directory structure is an important element of managing the complexity.

And using the JAVA ecosystem standard makes it easier for fellow/future developers to continue the support and expansion

you don't have to buck conventions, as much as allowing for alternate ones, is all.

There's room for a reasonable alternative that chops the directory structures into more reasonable nesting, for instance.

What is the proposed alternative exactly? I like main vs test. I like isolating java files from other languages or templates. I like the src directory bucketing sources from other root project build files and output artifacts. I have a ton of wishes for java improvements but this is functionally not an issue in day to day work.

C# is a very similar language with some of these restrictions loosened if you want to try that route.

Funnily enough, I did enjoy C# development once I worked around this sort of thing using package references

This is indeed supremely irritating. Besides this deep nested directory structure every 'public class/interface/enum/record' have to in their own file. This whole thing creates tons of files and directories with trivial amount of code.

Every top-level public(ish [1]) type declaration requires its own file. It may be irritating but it also brings some clear advantages for compilation speed. You can be irritated by many small files or by longer compilation times.

When you compile a file, the compiler quickly finds all other file dependencies and compiles (or just parses) only them, i.e. given a single file, the compiler knows exactly where to find all the declarations of all the types used in it. This property may not matter for languages that don't have good separate compilation anyway -- and few languages do, which is why people coming from other languages may find the restriction weird -- but Java's separate compilation is excellent. That turns out to also greatly help in-memory compilation for an upcoming feature where we can choose to compile files lazily, on demand: https://openjdk.org/jeps/8304400

To see that that is, indeed, the reason for the restriction, notice that it is only required for public(ish) top-level types. Non top-level public types can also be easily located, and non-public top-level types that are stored in files that don't match their names can only be referenced by code in that file (more precisely, the compiler is allowed to emit an error if they're referenced elsewhere). See the bottom of §7.6 of the JLS: https://docs.oracle.com/javase/specs/jls/se20/html/jls-7.htm....

Anyway, the point is that the restriction is there for a good reason. We sometimes entertain removing that restriction (and maybe someday we will), but the compilation benefits have so far turned up to be quite useful. We like our efficient separate compilation -- I don't think any other mainstream language does it as well as Java -- and may be able to get even more out of it.

[1]: Really, any top-level class that is referenced by name from other files.

those are features

not for the compiler, but for the poor souls than will not need to hunt where the hell that structure is defined

I like the Java conventions with all the files belonging to a package in individual nested directories of their own. It makes things systematised and easier to sort in my head when dealing with large projects with thousands of source files.

Reply on news.ycombinator.com