Death To Sub-Sub-Sub-Directories!

[Lawrence D'Oliveiro]

Google’s tool for creating an Android project insists on creating a
subdirectory hierarchy corresponding to the package naming hierarchy. Thus,
if you name your class “com.example.test_project.Mainâ€, it will put
Main.java inside the subdirectory src/com/example/test_project/.

But it turns out no part of the build process depends on this: you can put
all source files at the top level of your “src†subdirectory, and the
project still builds just fine.

 

[markspace]

But it turns out no part of the build process depends on this: you can put
all source files at the top level of your “src†subdirectory, and the
project still builds just fine.

Builds? Or runs? The directory structure you excoriated is standard in
the Java world. Why not use it? (Seriously, why not? If the tool
builds things there automatically, what is the advantage of not being
compatible with the rest of the planet and doing things differently?)

 

[Lew]

Google’s tool for creating an Android project insists on creating a
subdirectory hierarchy corresponding to the package naming hierarchy. Thus,
if you name your class “com.example.test_project.Mainâ€, it will put
Main.java inside the subdirectory src/com/example/test_project/.

But it turns out no part of the build process depends on this: you can put
all source files at the top level of your “src†subdirectory, and the
project still builds just fine.

This is simply the normal behavior for file-system-based Java installations,
such as those on Windows, Linux, Solaris, and Mac. No surprise, since Android
is built on a Linux core (well, GNU OS, I suppose I should say).

While it is not true that anything or anyone "insists" on using a reasonable
package structure, or to utterly eschew the default package, it's awfully
foolish to build anything other than toy examples in the default package.
That's why the very strong bias is to the best practice of non-default
packages for all types. You should follow that practice.

 

[Lawrence D'Oliveiro]

Builds? Or runs?

Builds and runs. I have at least 4 Android projects structured this way now.

The directory structure you excoriated is standard in the Java world. Why
not use it?

Because it’s a pain in the bum,

(Seriously, why not? If the tool builds things there automatically

No tool “builds things there automaticallyâ€.

 

[Roedy Green]

But it turns out no part of the build process depends on this: you can put
all source files at the top level of your “srcâ€瑩 subdirectory, and the
project still builds just fine.

It will matter if you run without jarring. That structure lets
java.exe find the class files without searching.

See http://mindprod.com/jgloss/classpath.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
Politicians complain that Kindles and iBooks are killing jobs by
destroying the paper book industry. I see it that they have create a way
to produce books for less than a third the cost without destroying forests
and emitting greenhouse gases in the process. They have created wealth.
They are encouraging literacy and cutting the costs of education.

 

[Lawrence D'Oliveiro]

It will matter if you run without jarring.

It builds classes.dex just fine.

That structure lets java.exe find the class files without searching.

java.exe? What’s that?

 

[Esmond Pitt]

Because it’s a pain in the bum

Is that supposed to be a reason? Because it isn't.

If you do as you suggest you lose automatic recompilation of dependent
classes.

 

[Lawrence D'Oliveiro]

Is that supposed to be a reason? Because it isn't.

Want some examples?

If you do as you suggest you lose automatic recompilation of dependent
classes.

No I don’t.

 

[Lew]

No, it isn't, not for disciplined non-ignoramuses, or for people who can give
engineering reasons for their pronouncements.

Want some examples?

If you have to ask ...

You /DO/ realize that "it's a pain in the bum" is neither logic nor evidence,
don't you?

Don't you?

No I don’t.

Care to apply some reason, evidence and/or logic there, sport?

 

[Lew]

java.exe? What’s that?

If you don't know, then you are definitely participating in the wrong group.
This is a newsgroup for Java programmers, buddy.

Regardless, here's your answer:
http://lmgtfy.com/?q=what+is+java.exe

 

[Arved Sandstrom]

It builds classes.dex just fine.


java.exe? What’s that?

Hey, Lawrence, no need to be so gratuitously silly. You've been around
the programming block for a number of decades, and know damned well what
an *exe is. You also have been using Java just long enough that you
should know what the Java interpreter and compiler (and possibly) other
binary executables are called, even on Linux/UNIX.

Deliberate affected ignorance of Windows can be disregarded from Linux
neophytes - it's part of the discovery process - but it's tiresome from
experienced people who should know better.

AHS

 

[Dagon]

Google’s tool for creating an Android project insists on creating a
subdirectory hierarchy corresponding to the package naming hierarchy.

So does everyone else's java tools, including eclipse, netbeans, javac. And
by "insist", you mean "does this by default" - it's optional but highly
recommended.

Thus, if you name your class com.example.test_project.Main, it will put
Main.java inside the subdirectory src/com/example/test_project/.

Right. That's sensible for any non-tiny codebase.

But it turns out no part of the build process depends on this: you can put
all source files at the top level of your “src†subdirectory, and the
project still builds just fine.

Yup. You'll hate yourself when you try to manage a nontrivial project that's
set up wrong, but it's allowed by almost all java tools.

 

[Lawrence D'Oliveiro]

So does everyone else's java tools, including eclipse, netbeans, javac.
And by "insist", you mean "does this by default" - it's optional but
highly recommended.

It’s a pain in the bum.

Right. That's sensible for any non-tiny codebase.

I just looked at a “non-tiny codebaseâ€, not written in Java—the Linux
kernel. I counted up about 13 million lines of C code, and it goes no more
than 3 subdirectories deep. There is no hierarchical division along anything
resembling namespace lines. And this is widely regarded as one of the most
productive and high-quality software projects in the world.

I conclude from that that imposing a directory hierarchy along namespace
lines is not actually helpful for “non-tiny codebasesâ€. Furthermore, for
your typical, more modest-sized mobile-phone app, it’s going to be downright
counterproductive.

Yup. You'll hate yourself when you try to manage a nontrivial project
that's set up wrong, but it's allowed by almost all java tools.

I have no plans to use Java for anything other than Android development.

 

[Daniele Futtorovic]

I just looked at a “non-tiny codebase”, not written in Java—the Linux
kernel. I counted up about 13 million lines of C code, and it goes no more
than 3 subdirectories deep. There is no hierarchical division along anything
resembling namespace lines. And this is widely regarded as one of the most
productive and high-quality software projects in the world.

I conclude from that that imposing a directory hierarchy along namespace
lines is not actually helpful for “non-tiny codebases”. Furthermore, for
your typical, more modest-sized mobile-phone app, it’s going to be downright
counterproductive.

Gosh, you're such a twat.

 

[Esmond Pitt]

Want some examples?

Not particularly.But whether you want to try to back up your random
statements is up to you really, nothing to do with me. I'm not all that
interested in the discussion.

 

[Lawrence D'Oliveiro]

Not particularly.But whether you want to try to back up your random
statements is up to you really, nothing to do with me. I'm not all that
interested in the discussion.

Then you shouldn’t have opened your big mouth in the first place.

 

[Lawrence D'Oliveiro]

Gosh, you're such a twat.

For pointing out that your Emperor has no clothes?

 

[Esmond Pitt]

Then you shouldn’t have opened your big mouth in the first place.

You posted, I responded. If you don't want responses, don't post. If you
post waffle, expect to be picked up on it.

 

[Esmond Pitt]

No I don’t.

That's strange, I do:

A.java:

package p;

public class A
{

}

B.java:

package p;

public class B extends A
{

}

javac B.java:

B.java:10: cannot find symbol
symbol: class A
public class B extends A
^
1 error

 

[Zapotec]

Gosh, you're such a twat.

Whereas I recognize the technical and engineering reasons for requiring
the deeply nested long directory names, I also have to say I agree that
they can be a pain in the butt, on two counts:

1. Typing long directory names or click-click-clicking to deeply-nested
folders is a pain, and will be required if you aren't using an IDE
like NetBeans or Eclipse -- and if you are, you just have the
package/class hierarchy to click-click-click through to get to
particular source files, instead, though at least you'll usually be
working in one small area at a time, and when there are compiler
errors or stack traces you can usually click in an IDE to jump
directly from the message to a suspect line in a source file.

Of course, the one-public-class-per-file thing (which has the same
engineering reasons) then becomes annoying when it leads to a tab
explosion in your editor.

2. On Windows, at least, it's not implausible to reach the path name
length limit of the filesystem and run into even more headaches.