development environments (non-integrated)

[Jacob]

I am doing a research project on development environments
using the Unix philosophy of development (see for instance
http://www.faqs.org/docs/artu/ch01s06.html) with the hypothesis
that an environment of small, simple, exchangable tools
might outperform the use of heavyweight IDEs.

I am setting up a test environment and am planning to do
performance measurments (in terms of # keystrokes, time, robustness)
on typical development scenarios like check-outs, bug-report-fix-test-
deploy-cycles, create development area for new user etc, management
reporting etc.

An initial task includes defining the term "development environment"
and exactly what it covers (operating system, version control system,
programming language, editor, compiler, debugger, test environment,
build system, bug tracking, document handling, project control and
so on).

The environment must be scalable to 10+ developers and at least a
million lines of code. The current state of my setup is as follows
(including short rationale for each choice):

OS: Linux - fast, secure, availability of development tools, free.

VCS: Subversion - State of the art, simple, robust, free.

Language: Java&JDK - Versatile, multi-platform, well-documented,
easy to use, free.

Compiler: Jikes - Fast.

Deployment: JavaWebStart - Simple, fast, user-friendly.

Tools scripting: Python - Simple, well suited, state of the art, free.

Code documentation: Doxygen - Feature-rich, high quality documents, good
error reporting.

Editor: Whatever the developer prefers - Efficient, developer
satisfaction.

Unit testing: JUnit - State or the art.

Bug tracking: Flyspray - Simple, good quality, free.

Building: Make - Simple, versatile, free.

Coverage: Cobertura - Simple, fast, report quality, free.

Document collaboration: twiki - Simple, free.

I'd like feedback on the selection, and experience with these and
alternative tools.

I do miss tools for code metrics, debugging, profiling, and
project management (hours, calendar, resources, time estimates
etc) among others. Also, no particluar project process (like RUP)
w/tools, has been chosen. Suggestions and experience appreciated.

Thanks.

PS: Excuse me for being slightly off topic.

 

[Daniel Dyer]

OS: Linux - fast, secure, availability of development tools, free.

VCS: Subversion - State of the art, simple, robust, free.
Agreed.

Language: Java&JDK - Versatile, multi-platform, well-documented,
easy to use, free.

Compiler: Jikes - Fast.

Fast, but not up-to-date. Development stagnated for a while, and even now
there hasn't been a release in 16 months. If you want Java 5 support you
will probably have to settle for javac. Previous versions that I used
were fast but often buggy, and there seems to be a lot of unresolved
issues with the last release.

Tools scripting: Python - Simple, well suited, state of the art, free.

What are you using the scripting language for?

Code documentation: Doxygen - Feature-rich, high quality documents, good
error reporting.

Why not Javadoc?

Unit testing: JUnit - State or the art.

I'd argue that TestNG is much more state of the art. JUnit 4.0 might not
be so bad when it gets released.

Building: Make - Simple, versatile, free.

Apache Ant is the de facto standard in Java land, though some people will
tell you that it is evil (see the thread "make not needed" from last week).

PS: Excuse me for being slightly off topic.

You could also try comp.lang.java.softwaretools.

Dan.

 

[Roedy Green]

I'd argue that TestNG is much more state of the art. JUnit 4.0 might not
be so bad when it gets released.

for other possibilities, see http://mindprod.com/jgloss/testing.html

 

[Jacob]

Fast, but not up-to-date.

I am developing on 1.5 and rely on a robust compiler, and at the moment
I am actually using javac. I used to use jikes, and thought it were
finally up to speed on 1.5. If that's not the case I'll stick with
javac. Are there other alternatives? What about the the gcj?

What are you using the scripting language for?

Simple administration tasks, like extracting a clean version from
the VCS and build everything from scratch every hour. Make does the
bulk of the job, but it needs to be kicked from somewhere.

Why not Javadoc?

I prefer the layout of Javadoc and it simplifies a lot to have
it as part of the language tools, but when comparing features
Doxygen seems far ahead (class hierarchy diagrams being one).
Check the rich options set of the Doxyfile and compare it to the
rather limited options of javadoc.

I'd argue that TestNG is much more state of the art. JUnit 4.0 might
not be so bad when it gets released.

I'll check TestNG as I don't really like JUnit that much.
The API is wide and documentation is bad; Both hints of
a badly structured project.

Apache Ant is the de facto standard in Java land, though some people
will tell you that it is evil (see the thread "make not needed" from
last week).

Ant is not evil, but perhaps a bit to complex to fit my philiosophy,
and make is far more versatile. In short: For all the tasks
a development environment consists of you'll need make anyway.
So then you might as well use it for building too.

 

[Thomas Weidenfeller]

I am doing a research project on development environments
using the Unix philosophy of development (see for instance
http://www.faqs.org/docs/artu/ch01s06.html) with the hypothesis
that an environment of small, simple, exchangable tools
might outperform the use of heavyweight IDEs.

If done right, and if given to the right people, yes.

Tools scripting: Python - Simple, well suited, state of the art, free.

State of the art is not an argument. Particular not in your scenario.
Because, IDEs are officially the "state of the art", but you have
explicitly set out to do it differently, because state of the art is not
what you want.

Admit it, you want Python, because you know Python.

I would consider more of the classic Unix tools. The whole bunch of awk,
sed, m4, etc. If that isn't to your (or your user's) liking, Perl.

Code documentation: Doxygen - Feature-rich, high quality documents, good
error reporting.

Ok, Doxygen is more powerful than e.g. JavaDoc, but JavaDoc is the
standard tool, comes with the JDK, and is simply the thing most Java
programmers use. Doxygen is largely compatible with JavaDoc (Doxygen
treats JavaDoc markup as a subset of its markup syntax). So if it later
turns out that JavaDoc is really not up to the task, you can still
change to Doxygen later.

Editor: Whatever the developer prefers - Efficient, developer
satisfaction.

Still, for the novices, provide a "standard" one for your environment,
and provide the necessary integration (check out, check in from the
editor, start of the build system, on-error got-to, etc.).

Unit testing: JUnit - State or the art.

Again, I would not use the term "state of the art" Regarding
testing, see also my remarks for the Wiki below.

Building: Make - Simple, versatile, free.

Good, but not without some problems when it comes to Java. Prepare for
some extra work. The big problem is dependency declarations. java source
code often has circular dependencies, but make doesn't like if you
declare circular dependencies. You have to group your source code into
clusters, where each cluster has internal dependencies, but the clusters
form a DAG. Or you rely on javac's feature to find and compile
dependencies by itself (up to a certain limit), if set up right.

Document collaboration: twiki - Simple, free.

Hmm, do you mean "project collaboration", or how do you want to link
that to Doxygen/JavaDoc documentation?

If you want to link testing and a wiki, maybe FitNess is for you
http://fitnesse.org/

I do miss tools for code metrics, debugging,

http://www.lambdacs.com/debugger/debugger.html

Last time I looked at it very interesting debugging concept, but not
complete. Probably complete now.

I do miss tools for code metrics, debugging, profiling, and
project management (hours, calendar, resources, time estimates
etc) among others. Also, no particluar project process (like RUP)
w/tools, has been chosen. Suggestions and experience appreciated.

The usefulness of a particular project management tools depends very
much on the management process you apply. Maybe dotProject (written in
PHP for a LAMP environment, not in some .NET stuff) is useful for you:
http://www.dotproject.net

PS: Excuse me for being slightly off topic.

IMHO you are very much on topic.

/Thomas

 

[Roedy Green]

I am developing on 1.5 and rely on a robust compiler, and at the moment
I am actually using javac. I used to use jikes, and thought it were
finally up to speed on 1.5. If that's not the case I'll stick with
javac.

the key for speed with JavaC is to use Ant so it loads once and
recompiles the universe.

For debugging there is the compiler internal to Eclipse which is
blinding fast.

 

[Chris Uppal]

I am doing a research project on development environments
using the Unix philosophy of development (see for instance
http://www.faqs.org/docs/artu/ch01s06.html) with the hypothesis
that an environment of small, simple, exchangable tools
might outperform the use of heavyweight IDEs. [...]
I do miss tools for [...]

One important thing that strikes me as missing from your list of tools (and
also from your list of programmer activities), is anything which will aid code
browsing. Something that can answer questions like, "where is this class
referred to?", "what overrides are there of this method?", "where is this
method called?", "what code uses this constant?", "which classes implement this
interface", etc. Answering such questions (with or without tool support) is a
major part of programming; it's central to code /reading/ and comprehension,
so if you don't have support then it'll skew your results.

Unfortunately, the only browsing tools I know of for Java are the rather clunky
search features built into some IDEs. I know of nothing that will work as a
standalone tool or will integrate into an editor ("which editor?" one asks ;-).
That doesn't mean there aren't any, though. Maybe someone can suggest
something.

-- chris

 

[Roedy Green]

Unfortunately, the only browsing tools I know of for Java are the rather clunky
search features built into some IDEs. I know of nothing that will work as a
standalone tool or will integrate into an editor ("which editor?" one asks ;-).
That doesn't mean there aren't any, though. Maybe someone can suggest
something.

I have see two such tools, Juliet and JGuru

Both left me wanting to rewrite them, extending the basic idea.

 

[Thomas Kellerer]

Unfortunately, the only browsing tools I know of for Java are the rather clunky
search features built into some IDEs. I know of nothing that will work as a
standalone tool or will integrate into an editor ("which editor?" one asks ;-).
That doesn't mean there aren't any, though. Maybe someone can suggest
something.

There is ctags and it integrates e.g. into TextPad. It can be used to jump to
methods and classes. I'm not really familiar with ctags, but I assume its output
could also be used for the other "queries"

Thomas

 

[im]

Unfortunately, the only browsing tools I know of for Java are the rather clunky
search features built into some IDEs. I know of nothing that will work as a
standalone tool or will integrate into an editor ("which editor?" one asks ;-).
That doesn't mean there aren't any, though. Maybe someone can suggest
something.

http://sourcenav.sourceforge.net/
I find Source Navigator very useful. I use it for code browsing only, but
technically it is an IDE, so that may disqualify it for your purposes
The UI is probably not too intuitive by today's standards, it takes some
time to learn it, but it is fast and effective. It is included in some
Linux distributions and available for windows.

Imre

 

[Roedy Green]

There is ctags and it integrates e.g. into TextPad. It can be used to jump to
methods and classes. I'm not really familiar with ctags, but I assume its output
could also be used for the other "queries"

the features I would like are:

1. find me a constructor or factory for this kind of object, broadly
defining factory.

2. Now I have a Blot object, what method in the known universe will
eat one, not many, then how about next level superclass?

3. who implements this Interface? Thankfully Javadoc now includes
this.

4. who subclasses this class? Again Javadoc now tracks this.

 

[Thomas Weidenfeller]

One important thing that strikes me as missing from your list of tools (and
also from your list of programmer activities), is anything which will aid code
browsing. Something that can answer questions like, "where is this class
referred to?", "what overrides are there of this method?", "where is this
method called?", "what code uses this constant?", "which classes implement this
interface", etc. Answering such questions (with or without tool support) is a
major part of programming; it's central to code /reading/ and comprehension,
so if you don't have support then it'll skew your results.

To a certain extend the documentation generated by JavaDoc can answer
these questions. However, the documentation is static (needs to be
generated first), and doesn't answer all of them.

If you have a large amount of code, you probably anyhow need to first
generate some database or index. Which leads to the next useful tool in
this area: ctags and/or etags. They are primarily intended to support
source code navigation inside editors. Which can answer some of the
above mentioned questions. E.g. a ctags version on speed can be
found at http://ctags.sourceforge.net/

("which editor?" one asks ;-).

One which supports tag files for source code navigation (e.g. vi, emacs,
nedit)

/Thomas

 

[Stefan Ram]

the features I would like are:

What I am looking for is:

Given a source tree with several packages and source files:

Print all source files sorted topologically by their
interdependency, for example:

Layer 0
Entries depend on no other source files, except source files
from this layer 0
./alpha/beta/Gamma.java
./alpha/delta/Epsilon.java
./zeta/eta/Theta.java

Layer 1
Entries depend on no other source files, except source files
from this layer 1
./alpha/beta/Iota.java

Cycles
The following source file was excluded from consideration
to avoid a cyclic dependency
./alpha/kappa/Lambda.java

 

[jeanlutrin]

I am doing a research project on development environments
using the Unix philosophy of development (see for instance
http://www.faqs.org/docs/artu/ch01s06.html) with the hypothesis
that an environment of small, simple, exchangable tools
might outperform the use of heavyweight IDEs.

I am setting up a test environment and am planning to do
performance measurments (in terms of # keystrokes, time, robustness)
on typical development scenarios like check-outs, bug-report-fix-test-
deploy-cycles, create development area for new user etc, management
reporting etc.

Interesting project!

I just want to add that they're not mutually exclusive: I'm using
IntelliJ IDEA as my "heavyweight" Java IDE but with one keyboard
shortcut I'm on a Unix terminal window and with another keyboard
shortcut I'm on a traditional Unix "text editor". For most things I
"simply" use IntelliJ IDEA (using an heavily modified Emacs
keymapping and and custom Emacs plugin for IntelliJ) but then
sometimes I just need to do an operation that's better done using
the "old Unix way": then I just temporarly switch to "simpler" tools.

Recently I had one such case: I was charged to modify some code
I didn't write. The task was tedious and repetitive and too complex
to be done by the "simple" search and replace provided by IntelliJ
IDEA. One keystroke and I'm out of IntelliJ IDEA, then a little
bit of perl and sed magic and the work was done.

Why restrict your development environment to one or the other
when you can have the best of both world?



That said, I think the best development setup allows programmer
to use whatever tools they want: for example for code editing nothing
should prevent one developer to use IntelliJ IDEA, another one Eclipse,
another one vi, another one (X)Emacs and those like me who don't
fear holy wars should be able to have several of these openend
simultaneously (and using the same font and the same color scheme

Many companies are insisting on having a single development setup
but there are also quite some where the developers are free to choose
and use whatever fits them most. There was an article on
theserverside.com less than a year ago about the Java development
going on at Walmart: this is such a company where everybody can
choose what tool they use to work on the (Java) project.

Good luck on your research,

Jean


P.S : I like your measurment in keystrokes: to me the mouse has
always been an anti-pattern for (non-visual) programming

 

[Daniel Dyer]

Simple administration tasks, like extracting a clean version from
the VCS and build everything from scratch every hour. Make does the
bulk of the job, but it needs to be kicked from somewhere.

Probably better to use a specialised continuous integration solution for
this, such as Cruise Control or Luntbuild.

Ant is not evil, but perhaps a bit to complex to fit my philiosophy,
and make is far more versatile. In short: For all the tasks
a development environment consists of you'll need make anyway.
So then you might as well use it for building too.

I use Ant. It's not perfect, but it does enough to dispute your assertion
that "you'll need make anyway".

Also, as Roedy pointed out, if you use Ant you will get better performance
from javac and other tools written in Java than you would with make. Each
separate invocation of javac (and the other tools like jar, javadoc,
javah, etc.) in a make file incurs VM initialisation overhead. Ant by
default runs each task in the same VM that Ant runs in, thus avoiding the
JVM start-up penalties.

Dan.

 

[Jacob]

State of the art is not an argument. Particular not in your scenario.
Because, IDEs are officially the "state of the art", but you have
explicitly set out to do it differently, because state of the art is not
what you want. Admit it, you want Python, because you know Python.

Given that you need a scripting language for assembling
the environment tools, then, yes, I want that scripting
language to be "state of the art".

This is due to maintainance and in order to easily get
people that knows the technology. I didn't know Python
when I started, but knew that it was "lightweight" and
could fulfill the task.

I would consider more of the classic Unix tools. The whole bunch of awk,
sed, m4, etc. If that isn't to your (or your user's) liking, Perl.

This suite of tools is one of the reason Linux is the preferred
OS in the first place. But what I *don't* want to use is bash,
sh or csh or their likes (which I do know quite well).
Python is choosen to replace these traditional Unix shells.
(And Perl is *not* an option. Never!

Ok, Doxygen is more powerful than e.g. JavaDoc, but JavaDoc is the
standard tool, comes with the JDK, and is simply the thing most Java
programmers use. Doxygen is largely compatible with JavaDoc (Doxygen
treats JavaDoc markup as a subset of its markup syntax). So if it later
turns out that JavaDoc is really not up to the task, you can still
change to Doxygen later.

Compared to Doxygen, JavaDoc is not up to the task already.
Unfortunately. There is so much valuable information that
could potentially been there, but you have to admit, it hasn't
really evolved much since the start back in '96.
(That said, I dislike Doxygen too, especially the layout)

Still, for the novices, provide a "standard" one for your environment,
and provide the necessary integration (check out, check in from the
editor, start of the build system, on-error got-to, etc.).

True. Emacs comes to mind...

Good, but not without some problems when it comes to Java. Prepare for
some extra work. The big problem is dependency declarations. java source
code often has circular dependencies, but make doesn't like if you
declare circular dependencies. You have to group your source code into
clusters, where each cluster has internal dependencies, but the clusters
form a DAG. Or you rely on javac's feature to find and compile
dependencies by itself (up to a certain limit), if set up right.

I already have a simple make setup that handles about half a million
LOCs smoothly. It outperforms Ant by any standard. But of course
it takes some effort to assemble it in the fist place (it's public btw).

Hmm, do you mean "project collaboration", or how do you want to link
that to Doxygen/JavaDoc documentation?

The assumption is that there is a web server running and that
there is a single entry point to the development tools, status,
logs etc. Part of this site will be a collaboration area where
"other" information will live, such as external documents, analysis
documents, MOMs, etc. Twiki should fulfill this task.

If you want to link testing and a wiki, maybe FitNess is for you
http://fitnesse.org/

First impression: Several things "integrated". I don't want tools
to be "integrated".

http://www.lambdacs.com/debugger/debugger.html

Strange site. Silly slogan. This is where I'd rather go
"state of the art". What about DDD?

The usefulness of a particular project management tools depends very
much on the management process you apply. Maybe dotProject (written in
PHP for a LAMP environment, not in some .NET stuff) is useful for you:
http://www.dotproject.net

This seems very close to what I want.
First impression though: Ugly GUI.

 

[Jacob]

One important thing that strikes me as missing from your list of tools (and
also from your list of programmer activities), is anything which will aid code
browsing. Something that can answer questions like, "where is this class
referred to?", "what overrides are there of this method?", "where is this
method called?", "what code uses this constant?", "which classes implement this
interface", etc. Answering such questions (with or without tool support) is a
major part of programming; it's central to code /reading/ and comprehension,
so if you don't have support then it'll skew your results.

Good point.

There seems to be a few "plugins" for emacs, in particular ECB
(http://ecb.sourceforge.net/) looks impressive (from the screenshots
at least). I have no experience with it. Anyone?

How whould you rate the support for these features in IDEs like IntelliJ,
Eclipse, NetBeans or VisualStudio?

 

[Jacob]

the key for speed with JavaC is to use Ant so it loads once and
recompiles the universe.

Using Ant doesn't change the speed of javac. Whatever build tool
that is used should be configured so that it gives javac the
smallest workload possible. And Ant might not be the most clever
in that respect...

For debugging there is the compiler internal to Eclipse which is
blinding fast.

Eclipse bundles many different tools/tasks and is therefore not
target for my study.

 

[Daniel Dyer]

One important thing that strikes me as missing from your list of tools
(and
also from your list of programmer activities), is anything which will
aid code
browsing. Something that can answer questions like, "where is this
class
referred to?", "what overrides are there of this method?", "where is
this
method called?", "what code uses this constant?", "which classes
implement this
interface", etc. Answering such questions (with or without tool
support) is a
major part of programming; it's central to code /reading/ and
comprehension,
so if you don't have support then it'll skew your results.

Real programmers use grep

Dan.

 

[Daniel Dyer]

for other possibilities, see http://mindprod.com/jgloss/testing.html

I've been name checked on the Java Glossary, I've finally made it in the
Java world

Are you sure your readers are interested in my preferences?

Dan.