Novice linux java coder needs help getting progs to run

[RedGrittyBrick]

Why?

Because Sun says so and consequently many, perhaps most, of us have
become used to that particular convention. Other forms therefore are
harder to read and cause confusion. By all means do whatever suits you
on your own systems. When posting to comp.lang.java.* I expect you'll
encounter less friction, and garner more support, if you post code that
follows the Sun conventions and is easy to read for people used to those
conventions.

Just my ¤0.02 worth.

 

[boltar2003]

Because Sun says so and consequently many, perhaps most, of us have
become used to that particular convention. Other forms therefore are
harder to read and cause confusion. By all means do whatever suits you
on your own systems. When posting to comp.lang.java.* I expect you'll
encounter less friction, and garner more support, if you post code that
follows the Sun conventions and is easy to read for people used to those
conventions.

I suppose I should use the hideous K&R style dangly bracket convention as well?

Hmm, perhaps not. I think I'll stick with the way I code C++ thanks

B2003

 

[Andreas Leitgeb]

It isn't a question of "merit" but ...

The point has been made to the OP, and any further discussion
in this subthread is unlikely to help anyone, so I just apologize
for any unlucky wordings from my side. EOsT?

 

[Tom Anderson]

Why? It looks daft and is more hassle to type

Them's the rules. In practice, you don't run real apps that way, you run
then as executable JARs:

java -jar hello.jar

Which can happily be all lowercase if you like.

on systems which are case sensitive (ie almost all of them except
Windows).

It makes no difference if the system is case sensitive or not. If it is
case sensitive, it will say 'file not found' if the case is wrong, and if
it isn't, it will say 'class format error', because the file hello.class
contains a class called Hello, and java is case-sensitive internally.

Also, get back to utl!

tom

 

[Lew]

Why? It looks daft and is more hassle to type on systems which are case
sensitive (ie almost all of them except Windows).

What "looks daft" is the confusing violation of the convention. And how much
"hassle" is it to press a shift key, hm?

The coding conventions are well documented and universally followed. (Well,
except by you, apparently.) When you violate them you reduce readability of
the code (which is waaaaay more important than saving a micro-erg on typing).
When you communicate about source code, say on Usenet, you facilitate
communication by adhering to the conventions. "When in Rome, ..."

Windows is somewhat case sensitive.

 

[Lew]

I suppose I should use the hideous K&R style dangly bracket convention as well?

Hmm, perhaps not. I think I'll stick with the way I code C++ thanks

How singularly arrogant.

 

[boltar2003]

case sensitive, it will say 'file not found' if the case is wrong, and if
it isn't, it will say 'class format error', because the file hello.class
contains a class called Hello, and java is case-sensitive internally.

So you can't even rename a class file? Gawd almighty.

Also, get back to utl!

Meh, thats just one of the stopovers on my pub crawl around usenet.

B2003

 

[boltar2003]

The coding conventions are well documented and universally followed. (Well,

No offense, but any coding conventions that go into such anal detail as
when and how to capitalise names and where to place brackets I'm really not
interested in adhering to. Java is a free form language, ergo I'll use what
form pleases me. Not the one they decided on in a bought-out-of-bankrupcy
company 15 years ago.

Toodle pipski!

B2003

 

[Lew]

So you can't even rename a class file? Gawd almighty.

That is a leap. Of course you can rename a class file, as long as you rename
the class to match it.

The match-up of class to file names is a convenience for the Java tools. It
allows the directory structure to mirror the package structure. It is what it is.

There are other ways to implement compilation units in Java but they are
rarely used.

This poses a problem for you because ...?

 

[Lew]

No offense, but any coding conventions that go into such anal detail as
when and how to capitalise names and where to place brackets I'm really not
interested in adhering to. Java is a free form language, ergo I'll use what
form pleases me. Not the one they decided on in a bought-out-of-bankrupcy
company 15 years ago.

My, my!

Let us know how that works for you.

Programming is a human enterprise. The conventions are there to make life
easier for people. Apparently you aren't interested in making life easier for
people.

 

[boltar2003]

This poses a problem for you because ...?

Not a problem , just seems a bit odd thats all.

B2003

 

[boltar2003]

Programming is a human enterprise. The conventions are there to make life
easier for people. Apparently you aren't interested in making life easier for
people.

I'm interested in making life easier for myself first and foremost. Why should
others take priority when I'll be the one writing and no doubt maintaining
the code?

Anyway , with any luck I'll be able to persuade my bosses that downgrading
to Java is a poor idea and this'll all be moot.

B2003

 

[Tom Anderson]

Here's one standard layout and associated command lines for a prototypic
"foo" project:

${PROJECTS}/foo/
|- build/classes/
|- src/com/lewscanon/foo/
|- Foo.java

Lew is suggesting is a highly sensible layout. I post only to mention that
there is a popular variant that makes it slightly more complicated:

foo/
build/
classes/
src/
main/
/com/lewscanon/foo/
Foo.java
test/
/com/lewscanon/foo/
FooTests.java

The idea is to keep unit test code in a completely separate folder
hierarchy to the main code. That way, during development you can compile
the whole lot:

javac -g -Xlint -d build/classes/ $(find src -name \*.java)

And for a release, just the main code:

javac -d build/classes/ $(find src/main -name \*.java)

Which is handy.

Whether you use the simpler or more fiddly versions, you usually place
other directories like so (at least, i think so - i welcome corrections):

foo/
build/
classes/
src/ -- described elsewhere
resources/ -- resources which should be on the classpath, structured as src/
lib/ -- JARs on which your code depends
bin/ -- launch scripts (not really standard?)

Some styles put resources inside src directory, but separated from actual
source code. Maven likes to do this:

foo/
src/
main/
java/
resources/
test/
java/
resources/

And so you'll see that an awful lot. It seems overly complicated to me,
though. I like my src directory to contain source code and nothing but.

Typical build commands for the former setup:

# build and run in development

cd $PROJECTS/foo
rm -rf build
mkdir -p build/classes
javac -g -Xlint -d build/classes $(find src -name \*.java)
# run the unit tests:
java -cp build/classes:resources/main:resources/test:lib/bar.jar:lib/baz.jar:lib/junit.jar org.junit.runner.JUnitCore com.lewscanon.foo.FooTest
# run the app:
java -cp build/classes:resources/main:lib/bar.jar:lib/baz.jar com.lewscanon.foo.Foo

# build for release

cd $PROJECTS/foo
rm -rf build
mkdir -p build/classes
mkdir -p build/jar
javac -d build/classes $(find src/main -name \*.java)
cp -pr resources/main/* build/classes
jar cf build/jar/foo.jar -C build/classes *

Note that this is off the top of my head, so E&OE!

tom

 

[Nigel Wade]

I'm interested in making life easier for myself first and foremost. Why should
others take priority when I'll be the one writing and no doubt maintaining
the code?

Because you came here for help. Here, your ego counts for nothing. If you insist
on going your own way then you are free to do so on your own time. But if you
want us to spend our time helping you then you must meet us half way. If you
can't be bothered to do even that, then why do you think we'd be bothered to
provide you with help?

Anyway , with any luck I'll be able to persuade my bosses that downgrading
to Java is a poor idea and this'll all be moot.

B2003

You seem bound and determined to keep burning those bridges...

 

[boltar2003]

(e-mail address removed) wrote:
Because you came here for help. Here, your ego counts for nothing. If you

I asked one question which had nothing to do with coding styles anyway.

insist
on going your own way then you are free to do so on your own time. But if you
want us to spend our time helping you then you must meet us half way. If you
can't be bothered to do even that, then why do you think we'd be bothered to
provide you with help?

I hate to break the news to you , but I won't expecting you guys to be on
standby solving every little problem I have while I cut and paste dozens of
lines of code so how I write that code is none of your concern.

You seem bound and determined to keep burning those bridges...

I'd mine the damn things if I could. Much quicker.

B2003

 

[Lew]

I'm interested in making life easier for myself first and foremost.

That pretty much wraps it all up and puts a bow on it right there.

 

[Tom Anderson]

I'm interested in making life easier for myself first and foremost. Why should
others take priority when I'll be the one writing and no doubt maintaining
the code?

Anyway , with any luck I'll be able to persuade my bosses that downgrading
to Java is a poor idea and this'll all be moot.

I certainly hope so.

tom

 

[Arved Sandstrom]

I'm interested in making life easier for myself first and foremost. Why should
others take priority when I'll be the one writing and no doubt maintaining
the code?

You could be fired, decide to quit, take ill, or get whacked by a car.
Or on a more positive note, the operation you work for expands, you get
promoted, and some newly hired peon has to deal with what you wrote. You
see why it's a singularly unhelpful notion to think of that code as
"your" code?

Anyway , with any luck I'll be able to persuade my bosses that downgrading
to Java is a poor idea and this'll all be moot.

Hopefully you won't tell them that you based this recommendation on your
aversion to Java's coding conventions. Seeing as how every other
language out there has them too, and good programmers follow them.

Considering that 24 hours ago you were stumped when attempting to run a
single compiled class on the command line you might want to learn
something of the language before deciding that it stinks.

AHS

 

[markspace]

foo/
build/
classes/
src/
main/
/com/lewscanon/foo/
Foo.java
test/
/com/lewscanon/foo/
FooTests.java

The idea is to keep unit test code in a completely separate folder
hierarchy to the main code.

When NetBeans does this, it puts your test code in a separate directory
from src:

$ ls -R
..:
build build.xml dist manifest.mf nbproject src test

<<SNIP>>

../src:
regextester

../src/regextester:
Main.java RegexTester.java gui

../src/regextester/gui:
HelpDialog.form OptionsWindow.form RegexPanel.form UiRxOptions.java
HelpDialog.java OptionsWindow.java RegexPanel.java help.text
HelpPanel.form RegexOptionsPanel.form UiContext.java
HelpPanel.java RegexOptionsPanel.java UiRegex.java

../test:
regextester

../test/regextester:
gui

../test/regextester/gui:
RegexPanelTest.java



Just pointing out there are at least a couple of patterns here, and it's
probably user preference which one gets chosen. Any given project
should probably be consistent, though, and use one or the other.

(Yeah, I know, only one test file. The little program is 90% GUI forms
and interfaces, so there isn't much to test. It looks worse than it is. )

 

[Lew]

When NetBeans does this, it puts your test code in a separate directory
from src:

Some of us do it that way even by hand. I have a "template" CVS project on my
hard drive which I can "cvs export" and rename to start off any simple Java
project.

<<SNIP>>

./src:
regextester

./src/regextester:
Main.java RegexTester.java gui

./src/regextester/gui:
HelpDialog.form OptionsWindow.form RegexPanel.form UiRxOptions.java
HelpDialog.java OptionsWindow.java RegexPanel.java help.text
HelpPanel.form RegexOptionsPanel.form UiContext.java
HelpPanel.java RegexOptionsPanel.java UiRegex.java

./test:
regextester

./test/regextester:
gui

./test/regextester/gui:
RegexPanelTest.java

Just pointing out there are at least a couple of patterns here, and it's
probably user preference which one gets chosen. Any given project
should probably be consistent, though, and use one or the other.

(Yeah, I know, only one test file. The little program is 90% GUI forms
and interfaces, so there isn't much to test. It looks worse than it is.
)

But of course you really do have many test cases, and showed only one in order
simply to make a point. Why show the entire directory when one example file
suffices?

Yeah, that's the ticket.

Excellent example, BTW.