Re: Question for Java Gurus

From: Chris Smith (cdsmith_at_twu.net)
Date: 05/20/04 

Date: Thu, 20 May 2004 11:49:52 -0600

Ryan Stewart wrote:
> > Clearly, that mechanism differs in practice depending on the environment
> > and tools, as I explained before. Yes you need to specify the location
> > of code in all cases, but in my experience more people are tripped up by
> > the mechanism of doing that, rather than by the need to do it in the
> > first place.

> Still, how do IDE's compile code? They call javac, just as you would from
> the command line. You just don't see it happening.

Sometimes that's true. On the other hand, I use Eclipse, which contains
its own compiler and doesn't use javac at all. I'm not aware of any
ability to use Eclipse's compiler from the command line, and I doubt
there exists code to parse a "-classpath" command line option or to read
the CLASSPATH environment variable from within Eclipse.

So you say:
> unless, as you said earlier, you're using
> some odd compiler that decides to implement it differently. But then it
> would just be the same thing under a different name, I think.

As for whether Eclipse's compiler works in a similar way, there are
perspectives from which it does, and perspectives from which it doesn't.
It certainly offers the same basic choices (add a JAR file or a
directory of classes) at its core, and there are *some* of the same
problems that could trip people up (for example, I could see someone
accidentally adding a directory to an Eclipse user library configuration
and expecting all the JAR files in that library to be added), but there
are others that simply don't apply (such as whether to use ; or : as a
path separator, or most importantly where to set an environment variable
in your specific operating system so that it's consistently available).

Given that Eclipse is probably one of the most commonly used Java
compilers out there, I don't think it's quite fair to characterize non-
classpath implementations of compilers as a fringe case. Instead, it
makes sense to admit that the mechanism of locating code is pretty much
unspecified, and that some tool sets use CLASSPATH as their
implementation because it's the only suggestion provided by the (non-
normative section of the) specification. It then makes sense to treat
the characteristic of calling javac behind the scenes as an
implementation detail... one that might or might not be there, and that
could be easily changed in the future without changing the expected
behavior of the environment.

Speaking of virtual machines, you have an initially stronger argument in
that most common virtual machines use something like CLASSPATH (except
that some third-party implementations lack Sun's rt.jar special case, so
you have to locate the system classes and include them in the CLASSPATH-
equivalent mechanism, so there are still differences). Except that this
is exactly when non-application code (such as servlets, applets,
midlets, etc.) and applications packaged as executable JAR files start
to be an exception, so that worrying about classpath is largely limited
to applications distributed as a bundle of loose class files.

> This is why some people
> (including myself) recommend doing a little compiling on your own, just so
> you can see what's going on behind the scenes and have a frame of reference
> for what the IDE is actually doing.

But this is assuming that the IDE is using javac as its compiler, and/or
that you're running your code as an application.

I certainly don't mean to overstate my case. I don't want to encourage
new developers to grab Eclipse, or any other environment that adds too
much complexity to be easily used. I just think a sort of cult
following has grown around the advice to avoid IDEs when learning, and
it reflects unfairly on options like BlueJ, which is designed for
learning and does an excellent job of it; or on simple environments like
JCreator, for that matter, which is simple enough to help Java students
without adding extra matters to confuse things.

Simply put, although I think many IDEs get in the way of learning, I
don't think that'd true even remotely because they save you from
CLASSPATH hassles. CLASSPATH hassles are the opposite of good education
in programming, not its goal, and any way you can find to avoid them is
progress. 

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

Relevant Pages

  • Re: Question for Java Gurus
    ... its own compiler and doesn't use javac at all. ... the CLASSPATH environment variable from within Eclipse. ... classpath implementations of compilers as a fringe case. ...
    (comp.lang.java.programmer)
  • Re: Question for Java Gurus
    ... its own compiler and doesn't use javac at all. ... the CLASSPATH environment variable from within Eclipse. ... classpath implementations of compilers as a fringe case. ...
    (comp.lang.java.help)
  • Re: What is Forth?
    ... the target, and then tell me why those aren't advantages for seaForth. ... But now there is Forth hardware, ... support both a Forth development environment and the target application. ... My only point was that he said he wanted to put Forth compiler into ...
    (comp.lang.forth)
  • Re: Project Idea.
    ... There is an Oberon compiler for the 68HC11 that took 4 months for a ... This language is more powerful and has fewer production in the EBNF ... is a nice development environment minus sources available there. ... A backup picture for the CPU board is available at ...
    (alt.lang.asm)
  • Re: Extent of definitions in environments (Was: First draft ...)
    ... written a macro that expands to an eval-when. ... The compiler creates an evaluation environment with FORM ... (cons 'progn (duplicate form))) ...
    (comp.lang.lisp)