Hacker News Reader

Comment by chrismonsanto | Hacker News Reader

> Packages and modules should never be reliant under an assumption about the underlying file system, as it tend to lock languages to certain platforms.

And it gives you an escape hatch from Java-style module nonsense: of COURSE I want to traverse 7 singleton directories to get to the source code!

View on HN

Java allows you to put all your source files in one directory and javac *.java will happily compile them. Package-directory structure applies only for compiled classes and internal content of a jar file. For Java sources, that is just a convention.

But of COURSE, it is so modern to blame Java for everything these days.

I had no idea. Why do so many projects setup these crazy directory trees for source then?

Because it allows you to have your User.java class in both com.comp.ldap and com.comp.db packages.

Blaming java is nothing new.

That would be a simple fix to be honest - and one that Java 8 could make without backward compatibility issues. Simply allow the hierarchy to be short cutted if a directory contains the a dot separated name

e.g instead of com/foobar/bar/module/a/b allow com.foobar.bar.module/a/b

I believe Java will behave sanely with regard to source directories. If you have a file Foo.java declaring itself as "package x.y.z", then it can happily live as "src/Foo.java".

It's only when you try to run the thing that the JVM will complain (with the rather unhelpful error message "wrong name: x/y/z/Foo"). So if your build process builds the correct folders and stores the .class files there, it's going to work. (Not that it's very useful; after all, your build system would have to know where to put everything.)

The fact that we are comparing all of this with java makes me so sad.

Which happens to be shared by other languages as well.

Reply on news.ycombinator.com