Directory Structure for java

[Lew]

The IDE is Eclipse, or else a damn good reason why not. There are such
reasons, but they're rare (and if you think Netbeans had one, that's
surely dead in the water now)

Nonsense. NetBeans is an excellent IDE. I use both.

Declaring that one is better than the other, or making categorical remarks
that either is "surely dead in the water now", is tantamount to making a
similar remark about vi vs. emacs. It's a silly argument. A goose who
imprints on an ultralight aircraft will never view another goose as its
mother, but it can still learn to migrate.

 

[Andy Dingley]

That's an oxymoron.  Someone writing a Java program perforce is "Java people",
of one experience level or another.

Well "oxymoron" is one term (or something like that) for some of the
people I have writing "Java" and stuffing this output into my project
trees... I have business analysts and worse playing at being coders.
Nor do I get to control the quality of their output as well I as might
for the in-house coders over whom I do have some little leverage.

Addressing your main point, that "it" (a simple analysis of source files) is a
good start toward or even yields a "full list" of class dependencies, that is
really not generally true.

It's the full list unless you've used some of a reasonably small set
of language constructs, These constructs aren't generally used by
naive Java coders. These constructs are also identifiable by source
code scans. You can no longer tell what the full dependency set is,
but at least you can tell whether you can tell.

 It is far more common than not for compilation to
depend on JAR files without source on hand,

So what? If the source isn't on hand, they're a nice simple external
axiom and you won't be changing or recompiling them.

 

[Andy Dingley]

Nonsense.  NetBeans is an excellent IDE.  I use both.

I don't care how much you like it, as of a few weeks ago I care how
much Larry Ellison likes it.

A goose who imprints on an ultralight aircraft will never view another goose as its
mother, but it can still learn to migrate.

But if that goose is already cooked, it ain't flying anywhere.

 

[Lew]

So what? If the source isn't on hand, they're a nice simple external
axiom and you won't be changing or recompiling them.

Would that were so.

I recently compiled source under Java 6 that used JDBC and had been built
under Java 5 successfully. The java.sql APIs changed between versions, and
the source no longer compiled because it didn't fully implement the interfaces
any more. Simply examining the source to be compiled did not and could not
have revealed that changed dependency.

The trouble is that the "nice simple external axiom" can change when you get
that latest upgrade to it, and your local source code cannot tell you that.

 

[Joshua Cranmer]

I don't care how much you like it, as of a few weeks ago I care how
much Larry Ellison likes it.

And, for IDEs, what matters most is how much the programmer likes it. I
don't know who this Larry Ellison is, so what he thinks matters as much
to me as the current turbidity of the Nile River.

The people who write Java use NetBeans, so it's got to be good enough
for someone to use. And people also write Java with Eclipse, JCreator,
Intelli IDEA, JGrasp (shudder), or even vim or plain old notepad (double
shudder).

 

[Lew]

I don't care how much you like it, as of a few weeks ago I care how
much Larry Ellison likes it.

NetBeans just today put out version 6.7 RC1. Apparently Larry-boy hasn't hurt
it yet.

I hear you saying that the sky is falling, Chicken Little, but as Mark Twain
might remark, rumors of NetBeans's death are still premature.

 

[Lew]

And, for IDEs, what matters most is how much the programmer likes it. I
don't know who this Larry Ellison is, so what he thinks matters as much
to me as the current turbidity of the Nile River.

The people who write Java use NetBeans, so it's got to be good enough
for someone to use. And people also write Java with Eclipse, JCreator,
Intelli IDEA, JGrasp (shudder), or even vim or plain old notepad (double
shudder).

Methinks Andy was speculating that with their acquisition of Sun, Oracle might
withhold support for NetBeans in favor of, I don't know, JDeveloper perhaps,
with an implicit corollary that JDeveloper is no good compared to Eclipse.

I'm downloading JDeveloper 11g Update 2 just to check it out. Perhaps I'll
like it.
<http://www.oracle.com/tools/jdev_home.html>

 

[Mike Schilling]

The nature of C and C++ is that you can't have circular dependencies
in the include files.

Sure you can; there's even a standard idiom to deal with it:

a.h:
#define A_INCLUDED
#ifndef B_INCLUDED
#include b.h
#endif

b.h:
#define B_INCLUDED
#ifndef A_INCLUDED
#include a.h
#endif

 

[Andreas Leitgeb]

a.h:
#define A_INCLUDED
#ifndef B_INCLUDED
#include b.h
#endif

b.h:
#define B_INCLUDED
#ifndef A_INCLUDED
#include a.h
#endif

This doesn't enable circular dependencies, though.

If you include this a.h into a file x.c, then b.h (included
through a.h) will *not* know the rest of the contents of a.h
behind the #include "b.h". Ditto the other way round.

Btw., the typical idiom is to have inside each includefile xyz.h:
#ifndef xyz_h
#define xyz_h
// contents
#endif
(rather than depend on the includING files to agree on the
protecting symbol.)

PS: The name of the included file must be in "double-quotes.h"
or in <angle-brackets.h>.

 

[Andy Dingley]

The people who write Java use NetBeans, so it's got to be good enough
for someone to use. And people also write Java with Eclipse, JCreator,
Intelli IDEA, JGrasp (shudder), or even vim or plain old notepad (double
shudder).

You missed out jEdit, which is how I write most of mine (I'm not a
coder, I bounce between many projects doing trivial fixes / hacks /
tweaks and jEdit loads faster than Eclipse).

NetBeans is a great IDE and I'd suggest that both it and Eclipse are
the two IDEs that do have the lead over all the others, on account of
the level of embedded in-your-face support they offer for continuous
integration. Speaking as someone who has to extract best-practice work
on big projects from out of raw graduates and naive Java coders, then
we need this sort of support. It doesn't matter that Stallman created
the world in 7 days using emacs and a pointy stick, it's about how to
get useful work out of people at less than that skill level.

The two things I don't like about NetBeans are:
* an assumption that it's an integrated vertical stack of product, not
just an IDE. You buy into the "NetBeans stack" and have to(sic) use
the whole lot. Dumb, I know, but you can buy the beer and I'll tell
you why this hurts.
* concerns over its future, when Eclipse is already the bigger market
share and no0one yet knows what Oracle are going to do with NetBeans,
Glassfish etc.

 

[Andy Dingley]

I recently compiled source under Java 6 that used JDBC and had been built
under Java 5 successfully.  The java.sql APIs changed between versions, and
the source no longer compiled because it didn't fully implement the interfaces
any more.  Simply examining the source to be compiled did not and could not
have revealed that changed dependency.

So it now had a dependency on a _different_ jar (6 not 5). Then you
hit a compilation error when you compile your own source. That's not
the same problem as the make-like issue of whether individual source
files need to attempt re-compilation. You've switched JDKs here - it's
a reasonable bet that everything does! (and then you pick up the
pieces, like this one.)

I work on a multi-thousand class project. We blast the build/classes/
tree and let javac get on with doing the lot. Doesn't take long at
all. When you're in the IDE, Eclipse handles the make-like aspect of
this and does incremental compilation for you. Maybe a clean compile
of the whole tree first thing in the morning. This all just isn't a
problem any more - compilation is fast, that's not what we spend our
days waiting for.

 

[Mike Schilling]

This doesn't enable circular dependencies, though.

If you include this a.h into a file x.c, then b.h (included
through a.h) will *not* know the rest of the contents of a.h
behind the #include "b.h". Ditto the other way round.

Btw., the typical idiom is to have inside each includefile xyz.h:
#ifndef xyz_h
#define xyz_h
// contents
#endif
(rather than depend on the includING files to agree on the
protecting symbol.)

PS: The name of the included file must be in "double-quotes.h"
or in <angle-brackets.h>.

Thanks. It's been awhile (obviously), but at any rate, it is common
to have circular dependencies, and for the same reasons that java
does.

 

[Andreas Leitgeb]

but at any rate, it is common to have circular dependencies,
and for the same reasons that java does.

Circular dependencies in C are avoided by proper separation
between headers and implementation.

If you ever get into the problem of needing circular inclusion,
then there probably exists a method (or more) that you had rather
put into a .c file rather than implement inline in the .h

While it is possible to have a.h eventually include b.h and b.h
eventually include a.h this will *never* solve circular dependencies.

 

[Dan Smithers]

Thanks Tom

On Mon, 1 Jun 2009, Dan Smithers wrote:

That's the plus side. The minus is that it complicates the app - rather
than having one JAR, you have several. Mind you, if your app uses
third-party libraries, those have to be supplied anyway, so this may not
be such a big deal.

It uses a C++ library that we have already written - and others.

You could always build two targets, an all-in-one-JAR app, and the
reusable parts as separate JARs.

I'm finding out that javac compiles all the files together in contrast
to the compile - link process of C++ compilers. I'll look at the
separation when I have got something working again.

If the images are being loaded as resources (through the
Class.getResource* methods), then they need to be on the classpath too
(bit weird, but that's how it goes). Do:

yes it is using Class.getResource

java -cp build:icons VTASystem

presumably ; not :

Assuming that the resource references are written relative to the
project root (/icons/foo.png, /icons/JPEGS/bar.jpg, etc), and that
you're running that command from the project root.

No they aren't. There is a single directory of icons that is used
throughout the code. It works if I compile in the source directory, but
I don't like that.

If you're just running, this isn't really easier than using a separate
classpath entry that points to the resource root, but it's convenient
when you make a JAR.

I'm trying out ant. I have a basic build.xml that compiles and makes the
jar, but I still get the problem loading the image resource.

Is there a way of setting up variables for the javac command? something
like

<property name="JFLAGS" value="-O -g -deprecation"/>
<javac srcdir="." destdir="build">
<compilerarg value=${JFLAGS}/>
</javac>

I've tried this but it doesn't work. Am I still thinking too much like make?

How do I set up resource directories for the jar command?

thanks

dna

 

[Dan Smithers]

How do I set up resource directories for the jar command?

I've worked this bit out:

<jar jarfile="${dist}/${ant.project.name}.jar">
<fileset dir="${build}"}/>
<fileset dir="resources" includes="**/*.jpg"/>
</jar>

I had to create a new directory resources and move the icons in there to
get the paths to work. I now have a working jar file! and the classes too!

Thanks for your suggestions.

dan

 

[Tom Anderson]

yes it is using Class.getResource


presumably ; not :

Possibly - i only use unix platforms, where it's a : - is it a ; on
windows?

No they aren't. There is a single directory of icons that is used
throughout the code.

Hold on - could you give an example of exactly what the resource paths
look like? If they have a leading slash, they're relative to the project
root (actually, the classpath root - see below), and if they don't,
they're relative to the class on which getResource was called. From what
you say, it sounds a lot like the former.

It works if I compile in the source directory, but I don't like that.

It shouldn't matter where you compile from, only where you run from.

The thing is, when you ask for a resource /foo/bar, the JVM goes through
all the classpath entries and looks for a file called
%CLASSPATH_ENTRY%\foo\bar (using a windows-style expression there!). So,
for it to find your icons, you need to have set the classpath to include
the directory which holds your icons directory. I suspect that when you
run from different places, you're somehow not doing that.

I'm trying out ant. I have a basic build.xml that compiles and makes the
jar, but I still get the problem loading the image resource.

Is there a way of setting up variables for the javac command? something
like

<property name="JFLAGS" value="-O -g -deprecation"/>
<javac srcdir="." destdir="build">
<compilerarg value=${JFLAGS}/>
</javac>

I've tried this but it doesn't work. Am I still thinking too much like make?

Pass - i'll leave this to someone who knows ant better than me to answer.

How do I set up resource directories for the jar command?

Copy the resources into the build directory, using an ant copy task,
before jarring as normal.

tom

 

[Tom Anderson]

Yes. The point is that the dependencies in C or C++ can be captured a
simple analysis of source files. That's not true in Java.

Are you saying that the dependencies can't be identified by an analysis of
the source files, or that the analysis isn't simple?

I seem to remember we've had this discussion before ...

tom

 

[Tom Anderson]

It's the full list unless you've used some of a reasonably small set of
language constructs, These constructs aren't generally used by naive
Java coders. These constructs are also identifiable by source code
scans. You can no longer tell what the full dependency set is, but at
least you can tell whether you can tell.

What constructs are you talking about?

tom

 

[Lew]

Tom Anderson suggested:

presumably ; not :

Very presumptuous. In much of my Java work that assumption would be false.

 

[Dan Smithers]

Possibly - i only use unix platforms, where it's a : - is it a ; on
windows?

yes - or \; under cygwin

Hold on - could you give an example of exactly what the resource paths
look like? If they have a leading slash, they're relative to the project
root (actually, the classpath root - see below), and if they don't,
they're relative to the class on which getResource was called. From what
you say, it sounds a lot like the former.

with a leading slash
getResource("/icons/foo.png");