Re: Software Development: maintenance vs. hardcore coding

From: Chris Smith (cdsmith_at_twu.net)
Date: 06/28/04 

Date: Mon, 28 Jun 2004 09:13:54 -0600

Stephen Kellett wrote:
> > Who prevents you to write #ifdef in your Java sources
> > and pre-process your Java sources via a C pre-processor?
>
> Too much effort. Support should be part of the language. Maintenance
> should be thought of at the language design stage.

This, really, comes down to a question of how badly you want
preprocessing. I agree that the C preprocessor is poorly suited for
Java -- particularly given that you'd have to be very careful to pass
proper options to prevent it from outputting debug helpers for the C
compiler. However, other preprocessors (especially m4, IMO) could be
far more suited, and even far more capable.

Another alternative, probably more commonly used in practice, is to use
ant and @TOKEN@. If you define a token to "//" for some set of builds,
then you can prefix conditional lines with that token to exclude the
line from those builds. This is, for example, how the PostgreSQL JDBC
driver is able to build for multiple versions of the JDBC API, which are
by and large not compatible across versions from the perspective of an
implementor.

Since very few people really build Java projects in the realy world by
invoking javac directly, I seriously doubt that you'd encounter great
difficulty incorporating these external tools into your build. Really
that would be no different from the C preprocessor, except that the C
and C++ languages are built to assume you'll use the preprocessor, and
act as an integrated build tool by invoking it for you in mant
circumstances.

> Another problem with Java, which is a design and maintenance issue:
>
> Lack of support for enumerations, unless thats been added for Java 2
> (and I've missed it - which is possible, given that I mainly write C++).

It's being added for 1.5, which should be released some time this year.
Many people are in agreement with you that it's been too long in coming. 

-- 
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Relevant Pages

  • Re: Cpp Considered Harmful
    ... > One is to present the 'raw' interface of the template to the user. ... easier than they can parse the underlying language itself. ... resulting from the preprocessor, it merely has to preprocess it. ... > Using JBuilder, and the Java counterpart, I can fly through XML ...
    (comp.lang.cpp)
  • Re: Cpp Considered Harmful
    ... ordering, template declaration instantiation, etc.. ... I think you have a serious misunderstanding of the preprocessor. ... Parsing Java is quite a bit simpler than parsing C++. ... >> source code much easier than they can parse the underlying language ...
    (comp.lang.cpp)
  • Re: Cpp Considered Harmful
    ... That is why assertions are preproccessed away in production code. ... What I've seen done with Java IDEs has shown me that they can ... In C++, because of the preprocessor, you cannot really be sure that what ... that you apparently want to enforce coding policy by language design. ...
    (comp.lang.cpp)
  • Re: J# or C# which when ?
    ... language features for .NET 2.0. ... recently are not Java compatible. ... though there are some limitations (like no JNI support) on that -- but ... compile both to .NET and modern JVMs, if you're willing and able to ...
    (microsoft.public.dotnet.vjsharp)
  • Re: parser
    ... really not interested in a language pissing contest. ... hint, it is generally not Java (although, the runtime and sometimes the ... support into my existing C-VM without too much additional work (and the JIT ... could probably use much of the already existing machinery). ...
    (comp.programming)
Loading