Speed Up Compilation -article request

[Martijn Mulder]

Hello,

From the Windows XP command line, I use javac.exe version 1.6.0_21 to
compile my java-code and java.exe version 1.6.0_21 to execute it. Then I
change the code and run the cycle again.

How can I optimize this process?

 

[Martin Gregorie]

Hello,

From the Windows XP command line, I use javac.exe version 1.6.0_21 to
compile my java-code and java.exe version 1.6.0_21 to execute it. Then I
change the code and run the cycle again.

How can I optimize this process?

Use a .cmd or .bat file to run both compile and test.

 

[Evans]

Hello,

From the Windows XP command line, I use javac.exe version 1.6.0_21 to
compile my java-code and java.exe version 1.6.0_21 to execute it. Then I
change the code and run the cycle again.

How can I optimize this process?

Have you heard of 'Ant'? Give it a try, it does all the tedious manual
steps required to develop Java software. You should really check it
out as it will save you tons of time. http://ant.apache.org/manual/index.html

Good luck
Evans
http://jroller.com/evans

 

[Tom Anderson]

From the Windows XP command line, I use javac.exe version 1.6.0_21 to
compile my java-code and java.exe version 1.6.0_21 to execute it. Then I
change the code and run the cycle again.

How can I optimize this process?

Use an IDE with an incremental compiler, like Eclipse.

If you want to work from the command line, you can use Eclipse in headless
mode, but it's a pain.

tom

 

[Lew]

Use a .cmd or .bat file to run both compile and test.

Wouldn't a build.xml file be better still?

Besides being tuned to the peculiarities of the Java command-line environment,
Ant is standard and relatively easy to use for the usual project
configurations. (There are some not so very enamored of Ant; I'm not in that
camp. Ant does have some limitations that in practice have not bothered me
personally.)

build.xmls have the virtue of integrating well with the very helpful IDEs out
there.

 

[markspace]

Hello,

From the Windows XP command line, I use javac.exe version 1.6.0_21 to
compile my java-code and java.exe version 1.6.0_21 to execute it. Then I
change the code and run the cycle again.

How can I optimize this process?

Use 'Ant'. It would be possible to use the old Unix 'make' command, but
Ant has better options specifically for Java. Yes, both are available
for Windows.

And Tom's suggestion to use an incremental compiler with an IDE is also
good. That will speed up your work again. Both NetBeans and Eclipse
use Ant as a base for their build systems.

 

[Kevin McMurtrie]

Use 'Ant'. It would be possible to use the old Unix 'make' command, but
Ant has better options specifically for Java. Yes, both are available
for Windows.

And Tom's suggestion to use an incremental compiler with an IDE is also
good. That will speed up your work again. Both NetBeans and Eclipse
use Ant as a base for their build systems.

Ant inherits the incremental build feature from the Java compiler. The
important thing is to make sure that the Java compiler gets a list of
all executable entry points all at once. Calling it with one file at a
time can take all day.

The suggestion to use an IDE is the best. Eclipse, when configured
properly, does an incremental build in 100 to 1000 ms. An IDE debugger
can also take advantage of the JVM's limited ability to replace methods
while debugging.

 

[Arne Vajhøj]

From the Windows XP command line, I use javac.exe version 1.6.0_21 to
compile my java-code and java.exe version 1.6.0_21 to execute it. Then I
change the code and run the cycle again.

How can I optimize this process?

Other have already suggested IDE and ant.

I would like to add that the time spend on javac and java
should be very small compared to the time it takes to
figure out what code to write.

Arne

 

[Owen Jacobson]

Ant inherits the incremental build feature from the Java compiler. The
important thing is to make sure that the Java compiler gets a list of
all executable entry points

This is, unfortunately, not sufficient for correct compilation. Because
of reflection, some classes may be reachable by some code paths in ways
the compiler can't detect and therefore won't automatically compile.
Better to pass the complete list of source files than to let the
compiler try to guess -- fortunately, this is what most build tools
(including maven and ant) do.

This also applies when writing a library rather than a freestanding
program, obviously.

-o

 

[jaap]

Op 14-08-10 21:59, schreef RedGrittyBrick:

> <cut />

If you can't use an IDE, then running Ant or Make etc from inside your
editor has to be the next best thing.

Eclipse runs very easy, you can simply inzip the files and let it run.
You can use it on nearly every computer.

Jaap

 

[Lew]

schreef RedGrittyBrick:
For certain values of "the next best". For delivery and deployment it's one
of the worst things because it potentially locks you in to a particular
version of a particular IDE.

An Ant build forces you to have all the dependencies for the project at hand
and does not introduce additional dependencies. It works the same regardless
of the different IDEs used. It consolidates the build and path information
into one or a small number of build descriptor files, not scattered among
various ".project" or ".settings" files with auto-shifting content. With
judicious use of (downward-) relative paths and environment variables, the
build.xml liberates you from hard-coded drives or paths.

Project after project where I've worked has had build and deployment issues
that arise from the seductive apparent convenience of sharing IDE-specific
metadata. These issues have included test suites that work differently in the
test environment from the developers', long hours of manual labor translating
IDE-specific project dependencies into deployment-time build scripts,
conflicting JARs, broken builds (ones that don't compile), and huge time
investment to upgrade a project to a newer IDE version.

IDE-specific project files should be eliminated from the project's build
protocols with extreme prejudice.

 

[Martin Gregorie]

Wouldn't a build.xml file be better still?

Yes - but only if he needs something more complex than he described.
Ant's build.xml is a lot harder to set up correctly than a simple shell
script, though of course it does more. Its a pity there isn't something
more like "make for Java" than ant - a makefile for a C program is
inherently easier to create than the functionally equivalent build.xml
for a similar Java program.

build.xmls have the virtue of integrating well with the very helpful
IDEs out there.

I don't use 'em. I'm quite happy with an editor I like and a command
line, though I do use ant for all but very trivial compilations.

 

[Martin Gregorie]

Use 'Ant'. It would be possible to use the old Unix 'make' command, but
Ant has better options specifically for Java. Yes, both are available
for Windows.

Make works OK for simple Java compilations but tends to trip over the
relationships between Java sources: their interrelationships are rather
more complex than those encountered with C. It was falling over these
when specifying a conventional build tree that drove me, kicking and
screaming, to learn to use ant for Java.

 

[Tom Anderson]

Op 14-08-10 21:59, schreef RedGrittyBrick:


Eclipse runs very easy, you can simply inzip the files and let it run.
You can use it on nearly every computer.

I've held off running Eclipse on my home computer, but this comment
inspired me to try it. It's an EeePC 1001HA - a 1.6 GHz Atom N270 with 1
GB of memory and a 1024x600 screen. Eclipse Helios installs and does in
fact run. It takes time to start up and to warm up after that (eg the
first time displaying the 'new class' dialogue is painfully slow, but fine
after that), and it takes a fair while to display the autocompletion menu
for String and similarly well-endowed classes.

Time will tell if i prefer it to GEdit. It's nowhere near as responsive,
but having refactorings is a killer. What i'd really like is a good java
plugin for GEdit, but i digress.

tom

 

[Tom Anderson]

schreef RedGrittyBrick:

For certain values of "the next best". For delivery and deployment it's one
of the worst things because it potentially locks you in to a particular
version of a particular IDE.

To a particular IDE, yes. To a particular version? I've been looking at
Eclipse metadata files since 3.3, and they haven't changed much. More
specifically, the .project and .classpath haven't changed at all, as far
as i can tell (caveat: we have quite simple projects, just java projects
with the java builder). Some of the more mysterious files in the workspace
global directories (eg variablesAndContainers.dat) have, but not hugely,
and you don't share those anyway, so it's largely irrelevant.

I think there's a NetBeans plugin that lets it read Eclipse .project and
..classpath files, but i don't know how up to date it is, and i wouldn't
want to rely on it. It would be really nice if IDE vendors could
standardise on metadata files, to avoid this lockin problem, and also
enable all sorts of new tools, but i realise that's a pipe dream.

I can't comment on the stability of other IDEs' metadata files.

An Ant build forces you to have all the dependencies for the project at
hand and does not introduce additional dependencies.

Doing your build with ant introduces ant as a dependency, and nothing
else. Doing your build with Eclipse introduces Eclipse as a dependency,
and nothing else. I don't see the difference.

It consolidates the build and path information into one or a small
number of build descriptor files, not scattered among various ".project"
or ".settings" files with auto-shifting content.

I don't see this as an advantage, but rather, as a significant
disadvantage. The build information is better off stored in multiple small
files, one per module, than consolidated in one big file. This is the case
regardless of IDE, build system, etc.

Project after project where I've worked has had build and deployment
issues that arise from the seductive apparent convenience of sharing
IDE-specific metadata. These issues have included test suites that work
differently in the test environment from the developers', long hours of
manual labor translating IDE-specific project dependencies into
deployment-time build scripts, conflicting JARs, broken builds (ones
that don't compile), and huge time investment to upgrade a project to a
newer IDE version.

I'm sorry to hear that. Projects i've worked on have used IDE-specific
build processes, and that hasn't caused any pain. Indeed, we've *reduced*
the amount of pain we feel by using more of it. For instance, at one
point, we maintained Eclipse-independent classpath metadata, so we could
run code from the command line as part of the build. This was painful. We
then wrote some code to parse Eclipse's files to extract the information
automatically. This made things a lot easier and more reliable, because we
let Eclipse do the heavy lifting of keeping that data correct.

I'd be interested to hear more about the instances you mention. Why were
the development and test test suites different? Why did you have to
translate the IDE build into another form (which i can see you might need)
by hand? How would you have avoided having conflicting JARs by not sharing
IDE metadata? How was an IDE responsible for a broken build? What did you
have to do when upgrading your IDE?

IDE-specific project files should be eliminated from the project's build
protocols with extreme prejudice.

Duplication should be eliminated from the project's build protocols with
extreme prejudice. You're using an IDE, so maintaining an IDE-independent
build process is duplication.

tom

 

[Roedy Green]

From the Windows XP command line, I use javac.exe version 1.6.0_21 to
compile my java-code and java.exe version 1.6.0_21 to execute it. Then I
change the code and run the cycle again.

How can I optimize this process?

use ANT. It loads the compiler only once. Compilation is no longer the
bottleneck for me. It is jarring.

 

[RedGrittyBrick]

I've held off running Eclipse on my home computer, but this comment
inspired me to try it. It's an EeePC 1001HA - a 1.6 GHz Atom N270 with 1
GB of memory and a 1024x600 screen. Eclipse Helios installs and does in
fact run. It takes time to start up and to warm up after that (eg the
first time displaying the 'new class' dialogue is painfully slow, but
fine after that), and it takes a fair while to display the
autocompletion menu for String and similarly well-endowed classes.

I'm impressed that a modern IDE is usable on a computer designed for
surfing the web inexpensively.

Looking forward to Call Of Duty framerates and Photoshop filter timings
on 24MP images. ;-)

 

[RedGrittyBrick]

schreef RedGrittyBrick:

For certain values of "the next best".

Those where the context is rapid cycle of write, compile, run?

 

[Tom Anderson]

I'm impressed that a modern IDE is usable on a computer designed for
surfing the web inexpensively.

Looking forward to Call Of Duty framerates and Photoshop filter timings
on 24MP images. ;-)

Dunno about CoD, but i should be able to get nethack running kind of okay.

tom

--
The players listen very carefully and respectfully to all that the clever
men have to say about what is to happen in the next generation. They
players then wait until all the clever men are dead, and bury them
nicely. Then they go and do something else. -- The Napoleon of Notting
Hill, G. K. Chesterton

 

[Lew]

To a particular IDE, yes. To a particular version? I've been looking at

Yep. Upgrading from Rational Application Developer (Eclipse based, BTW) from
version 6 to version 7 for a team was a nightmare of metadata-file editing on
a large team a few years ago.

Eclipse metadata files since 3.3, and they haven't changed much. More

It doesn't take "much" if the "not much" is involved in your particular case.

specifically, the .project and .classpath haven't changed at all, as far
as i can tell (caveat: we have quite simple projects, just java [sic] projects
with the java [sic] builder). Some of the more mysterious files in the
workspace global directories (eg variablesAndContainers.dat) have, but
not hugely, and you don't share those anyway, so it's largely irrelevant.

"You don't share those anyway" - making my point that IDE-specific files can
be very bad to share.

I think there's a NetBeans plugin that lets it read Eclipse .project and
.classpath files, but i don't know how up to date it is, and i wouldn't
want to rely on it. It would be really nice if IDE vendors could
standardise on metadata files, to avoid this lockin problem, and also
enable all sorts of new tools, but i realise that's a pipe dream.

Nice but unnecessary. Just have the metadata files be irrelevant. Besides,
even standardizing on the format doesn't solve the problem - these files
contain hard-coded path information and the like that is specific to each
developer, not just the project or the brand of IDE.

Lew:

tom:
Doing your build with ant introduces ant as a dependency, and nothing
else. Doing your build with Eclipse introduces Eclipse as a dependency,
and nothing else. I don't see the difference.

Eclipse (or whatever) adds a lot more complexity in its dependency. Ant does
not introduce under-the-hood changes to your metadata files automagically.
Eclipse does. Ant does not require multiple entries for dependencies into
multiple configuration files. Eclipse does. Ant doesn't assume the presence
of an entire infrastructure of JARs (org.eclipse.blahdiblah.packagestuff.jar).
Eclipse does. Ant is invoked from the command line and is independent of
the IDE used to build them. Eclipse is not. Ant dependencies are limited
pretty much to "use the tool". Eclipse dependencies are pernicious and
pervasive. Ant is upwardly compatible. Eclipse is not. Ant is
user-extensible with simplicity. Eclipse is not. Ant is geared specifically
to deployment. Eclipse is geared to construction and is more general. Ant is
the standard build tool. Eclipse is not.

The differences are myriad.

Lew:

tom:
I don't see this as an advantage, but rather, as a significant
disadvantage. The build information is better off stored in multiple
small files, one per module, than consolidated in one big file. This is
the case regardless of IDE, build system, etc.

All right. Use multiple build files then. Advantage: Ant. Regardless of
IDE, project structure, etc.

... Projects i've worked on have used IDE-specific
build processes, and that hasn't caused any pain. Indeed, we've
*reduced* the amount of pain we feel by using more of it. For instance,
at one point, we maintained Eclipse-independent classpath metadata, so
we could run code from the command line as part of the build. This was
painful. We then wrote some code to parse Eclipse's files to extract the
information automatically. This made things a lot easier and more
reliable, because we let Eclipse do the heavy lifting of keeping that
data correct.

Except that you still have things like class paths specified in up to four
places per project with Eclipse - "build path", "project dependencies", "EAR
dependencies" and "aspects". There may be others. Eclipse, like Ant, doesn't
do the heavy lifting; it captures the decisions made by humans.

I'd be interested to hear more about the instances you mention. Why were
the development and test test suites different? Why did you have to

God knows. For some reason instead of using the JUnit test framework they
invoked test code via 'main()'. I didn't create the process. Excuse me, the
"process".

translate the IDE build into another form (which i can see you might
need) by hand? How would you have avoided having conflicting JARs by not

Because we didn't have custom tools to translate the IDE files into Ant files.

sharing IDE metadata? How was an IDE responsible for a broken build?
What did you have to do when upgrading your IDE?

I forget the details, but it involved replacing lines in certain configuration
files to reflect new features in the newer IDE version.

Since IDE metadata was formed project by project by different developers in
isolation from each other, often they each would choose JAR versions
independently and thus occasionally conflictingly. With a centralized build
process those conflicts are noticed earlier in the process, and listed in the
build.xml file(s) where they're far more visible. Emergently this gives Ant
an edge for conflict resolution.

Lew:

tom:
Duplication should be eliminated from the project's build protocols with
extreme prejudice. You're using an IDE, so maintaining an
IDE-independent build process is duplication.

Is it your argument that having more than one developer is duplication, since
each have a separate working copy of the project?

Since I don't favor an IDE-based build process, an IDE-independent build
process would have nothing to duplicate, so therefore it is not duplication.