compling for java 1.4.2 using java 1.5
 

I use java 1.5 because of azureus but my university uses 1.4.2. I s there a way I can compile program i've built using 1,5 to work on 1,4,2. Occsionally I get errors from the compiler saying it cant recognise classes when they are in the same package. This only happens if I've compiled it using 1.5.

Are you using eclipse as your IDE? You can select how you want code compiled and there's a heap of options for 1.4 and 1.5. I don't even bother trying to remember them now, I just make sure it compiles and then let maven take care of the build/test/deploy stuff.

Sure:

ah sorry I use netbeans

It totally doesn't matter if you use NetBeans or Eclipse or the command line:

1. "Under the covers", Netbeans and Eclipse both use the command line "javac".

2. You, too, must be familiar with the command line (even if you choose not to use it).

3. Knowing about "-source <version>" (by typing "javac -help" ... or reading
the previous post), then you know what to change in the IDE.

4. In the NetBeans 4.1 IDE, for example, you can do this:
[Project Window],
<Right Click>MyProject,
Properties..., Build, Compile,
Additional compiler options: "-source 1.4"

Look at the project properties(right-click on the project node), you can specify the source level(ie 1.5 or 1.4)

That's an excellent example of the problem with just blindly following IDEs, instead of also having at least some familiarity with the command-line equivalent: some stuff is in this GUI, other stuff is in the other GUI, and a lot of stuff isn't in any GUI whatsoever.

My original advice still stands:
1. Spend 30 seconds in a command prompt and familiarize yourself with "javac -help" and "java -help" compile and execute options

2. Use the "Project, Properties, Additional Compiler options" for *all* of your custom flags.

It's less you have to rememeber,
It insures all your custom settings will be "documented" in one place
It ALSO lets you handle OTHER options that the GUI DOESN'T happen to provide

IMHO .. PSM

I don't blindly follow anything - it comes down to where the complexity in the environment is. When you have multiple developers, all contractors so turnover is high, you set up the environment to minimise the cost of getting someone up to speed.

Here, that means an IDE configured by default to use the correct settings and CVS repository, automated build/test and deployment tools (Ant, JUnit and Maven) and documented procedures for using them all. The developer checks out the code for the project they're working on, does the work according to the spec they're given, uses the build tools to check it builds and passes the tests and checks it back into CVS. All through the preconfigured IDE. The test team export it from CVS, deploy it using maven, run the system tests and report to me.

This way, I'm responsible for 5 developers, 300,000+ lines of code (not huge, but it's still fun) and we all get to have a lunch hour instead of arguing over which command line switches provide the best tweak. The only time we've talked about command line switches on the last 3 of my projects is at the start when we set up the environment so the developers don't have to.

Hey, gilead - I wasn't criticizing you. In fact, I think we're in complete agreement.

You *don't* "empower" somebody by telling them about some stupid checkbox nested 5 levels deep in a menu that's going to be in a completely different place in the next version anybody, and then stopping there.

On the one hand, we (the developers) *know* what the checkbox means: so we can *find* it in that hypothetical next release of the IDE, or we can work around it if the IDE doesn't happen to support it.

On the other hand, we (the project leads/project managers) set up the configuration - DOCUMENT and BASELINE that configuration, and whether it's a checkbox or a command switch is irrelevant. Because everything "just works", as far as the developer is concerned.

Again:

My apologies paulsm4, I'd like to blame lack of coffee here (Sunday morning in Australia) :)