ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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"
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
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:
Quote:
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.