Discussion:
IDE suggestion
(too old to reply)
Schizoid Man
2013-02-24 11:08:36 UTC
Permalink
Hello,

I've just inherited a beat-up old Mac that I'm keen to use to learn Java. It
runs Mac OS X Tiger 10.4.11 and I'm keen to use a lightweight IDE, so
nothing like Eclipse or NetBeans. Can anyone a suggest a decent free one?

Thank you.
John B. Matthews
2013-02-24 20:00:51 UTC
Permalink
Post by Schizoid Man
I've just inherited a beat-up old Mac that I'm keen to use to learn
Java. It runs Mac OS X Tiger 10.4.11 and I'm keen to use a
lightweight IDE, so nothing like Eclipse or NetBeans. Can anyone a
suggest a decent free one?
I don't know about lightweight, but I have a vague memory of NetBeans
6.5.1 running on Tiger: <http://www.netbeans.info/downloads/dev.php>

See also <http://mactracker.ca/>.
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Lew
2013-02-24 20:23:38 UTC
Permalink
Great Suzi Quattro reference.
Post by John B. Matthews
Post by Schizoid Man
I've just inherited a beat-up old Mac that I'm keen to use to learn
Java. It runs Mac OS X Tiger 10.4.11 and I'm keen to use a
lightweight IDE, so nothing like Eclipse or NetBeans. Can anyone a
suggest a decent free one?
Both Eclipse and NetBeans should run fine on that machine. What do you
mean by "lightweight"?

Lightest weight is a text editor plus Ant plus command line, which works
just fine. I use emacs if in that mode, but vi{,m} or whatever plain text
tool you use is just fine.
Post by John B. Matthews
I don't know about lightweight, but I have a vague memory of NetBeans
6.5.1 running on Tiger: <http://www.netbeans.info/downloads/dev.php>
See also <http://mactracker.ca/>.
The aforementioned IDEs are just Java programs. They do give a lot of bang
for the megabyte.

Everyone should know how to do Java command-line/scripted anyway.
--
Lew
Schizoid Man
2013-02-24 20:40:14 UTC
Permalink
Post by Lew
Both Eclipse and NetBeans should run fine on that machine. What do you
mean by "lightweight"?
Something that has a few basic IDE features such as intellisense, and some
basic debugging. Since I'm learning Java and don't require the enterprise
features yet, I think NetBeans and Eclipse might be a bit over-engineered.
Lew
2013-02-24 22:51:36 UTC
Permalink
Post by Schizoid Man
Post by Lew
Both Eclipse and NetBeans should run fine on that machine. What do you
mean by "lightweight"?
Something that has a few basic IDE features such as intellisense, and some
basic debugging. Since I'm learning Java and don't require the enterprise
features yet, I think NetBeans and Eclipse might be a bit over-engineered.
Both those IDEs are modular and ship in versions without the Enterprise features.

You might want to actually take a look at their respective web sites and feed some
hard data into that decision engine.
--
Lew
Roedy Green
2013-02-25 19:27:15 UTC
Permalink
On Sun, 24 Feb 2013 20:40:14 -0000, "Schizoid Man"
Post by Schizoid Man
Something that has a few basic IDE features such as intellisense, and some
basic debugging. Since I'm learning Java and don't require the enterprise
features yet, I think NetBeans and Eclipse might be a bit over-engineered.
see http://mindprod.com/jgloss/ide.html to get a list of options.
--
Roedy Green Canadian Mind Products http://mindprod.com
One thing I love about having a website, is that when I complain about
something, I only have to do it once. It saves me endless hours of
grumbling.
Steven Simpson
2013-02-24 21:31:14 UTC
Permalink
Post by Lew
Lightest weight is a text editor plus Ant plus command line, which works
just fine.
I came to the conclusion that Ant is insufficient without an
error-detecting editor (as in an IDE). If class Foo uses class Bar,
class Bar could be changed in a way that causes an error in Foo, yet Ant
will not detect that Foo needs to be recompiled in order to see the
error, which goes unnoticed until runtime, or until Foo is re-compiled.

Is my conclusion incorrect? Am I using Ant correctly?:

% cat build.xml
<project default="compile">
<target name="compile">
<mkdir dir="classes" />
<javac srcdir="src" destdir="classes"
listfiles="yes" includeDestClasses="true"
includeAntRuntime="false" />
</target>

<target name="clean">
<delete dir="classes" />
</target>
</project>
% cat src/Foo.java
public class Foo {
public static void main(String[] args) throws Exception {
new Bar();
}
}

% cat src/Bar.java
public class Bar { }

% ant clean
Buildfile: /scratch/simpsons/Scratch/Coding/antfail2/build.xml

clean:
[delete] Deleting directory /scratch/simpsons/Scratch/Coding/antfail2/classes

BUILD SUCCESSFUL
Total time: 0 seconds
% ant
Buildfile: /scratch/simpsons/Scratch/Coding/antfail2/build.xml

compile:
[mkdir] Created dir: /scratch/simpsons/Scratch/Coding/antfail2/classes
[javac] Compiling 2 source files to /scratch/simpsons/Scratch/Coding/antfail2/classes
[javac] /scratch/simpsons/Scratch/Coding/antfail2/src/Bar.java
[javac] /scratch/simpsons/Scratch/Coding/antfail2/src/Foo.java

BUILD SUCCESSFUL
Total time: 0 seconds
% java -cp classes Foo
% sed -e 's/class/abstract class/' -i src/Bar.java
% cat src/Bar.java
public abstract class Bar { }

% ant
Buildfile: /scratch/simpsons/Scratch/Coding/antfail2/build.xml

compile:
[javac] Compiling 1 source file to /scratch/simpsons/Scratch/Coding/antfail2/classes
[javac] /scratch/simpsons/Scratch/Coding/antfail2/src/Bar.java

BUILD SUCCESSFUL
Total time: 0 seconds
% java -cp classes Foo
Exception in thread "main" java.lang.InstantiationError: Bar
at Foo.main(Unknown Source)
% touch src/Foo.java
% ant
Buildfile: /scratch/simpsons/Scratch/Coding/antfail2/build.xml

compile:
[javac] Compiling 1 source file to /scratch/simpsons/Scratch/Coding/antfail2/classes
[javac] /scratch/simpsons/Scratch/Coding/antfail2/src/Foo.java
[javac] /scratch/simpsons/Scratch/Coding/antfail2/src/Foo.java:3: error: Bar is abstract; cannot be instantiated
[javac] new Bar();
[javac] ^
[javac] 1 error

BUILD FAILED
/scratch/simpsons/Scratch/Coding/antfail2/build.xml:6: Compile failed; see the compiler error output for details.

Total time: 0 seconds
--
ss at comp dot lancs dot ac dot uk
Roedy Green
2013-03-01 08:18:59 UTC
Permalink
Post by Steven Simpson
I came to the conclusion that Ant is insufficient without an
error-detecting editor (as in an IDE). If class Foo uses class Bar,
class Bar could be changed in a way that causes an error in Foo, yet Ant
will not detect that Foo needs to be recompiled in order to see the
error, which goes unnoticed until runtime, or until Foo is re-compiled.
I don't think ant has anything to do with it. It just hands all the
source files to javac.exe, and javac.exe makes the decision on what
needs to be recompiled. I do an ant clean if I have been doing any
fiddling with cross class static finals, since the literal values get
burned into the code, and will not be refreshed until recompilation.

Other than that, normally everything comes out in the wash.

Usually what happens is you change source, that triggers a recompile,
then everyone sees the new version. If there is an error, and you
ignore it, presumably others may get an old class file, but I don't do
that. I do so many recompilations ahead of time in IntelliJ that even
if a change were missed, it would get picked up on the next ANT clean
recompile.

A clean compile is called for:
1. before final test
2. before distribution
3. when you detect behaviour that makes no sense

Javac/ANT is so fast compared with what we used to do, loading javac
for each source module and fiddling with MAKE.
--
Roedy Green Canadian Mind Products http://mindprod.com
One thing I love about having a website, is that when I complain about
something, I only have to do it once. It saves me endless hours of
grumbling.
Steven Simpson
2013-03-01 12:30:45 UTC
Permalink
Post by Roedy Green
Post by Steven Simpson
I came to the conclusion that Ant is insufficient without an
error-detecting editor (as in an IDE). If class Foo uses class Bar,
class Bar could be changed in a way that causes an error in Foo, yet Ant
will not detect that Foo needs to be recompiled in order to see the
error, which goes unnoticed until runtime, or until Foo is re-compiled.
I don't think ant has anything to do with it. It just hands all the
source files to javac.exe, and javac.exe makes the decision on what
needs to be recompiled.
That only happens if the output directory is included in the classpath.
Is Ant invoking javac this way? 'ant -v' shows this:

[javac] Compilation arguments:
[javac] '-d'
[javac] '/scratch/simpsons/Scratch/Coding/antfail2/classes'
[javac] '-classpath'
[javac] '/scratch/simpsons/Scratch/Coding/antfail2/classes'
[javac] '-sourcepath'
[javac] '/scratch/simpsons/Scratch/Coding/antfail2/src'
[javac] '-g:none'

(Note that source files are not listed here, so it's not the complete
set of arguments. We can't directly tell which source files are passed
from this statement.)

The includeDestClasses attribute of <javac> controls this, and defaults
to "true", though I was also setting it explicitly to its default. I
set it to false, and got:

[javac] Compilation arguments:
[javac] '-d'
[javac] '/scratch/simpsons/Scratch/Coding/antfail2/classes'
[javac] '-classpath'
[javac] ''
[javac] '-sourcepath'
[javac] '/scratch/simpsons/Scratch/Coding/antfail2/src'
[javac] '-g:none'

So that attribute does what it says on the tin. I repeated my test run
(see end of message) to see if it made any difference. However, again
only Bar is recompiled, so Ant is still showing the behaviour I
mentioned - javac is only being offered the source files that have changed.
Post by Roedy Green
Javac/ANT is so fast compared with what we used to do, loading javac
for each source module and fiddling with MAKE.
Certainly, there's no point trying to use Make to pass one file at a
time to javac. If you have a dependency sequence A->B->C, and you make
a change to B and decide to recompile, C is going to get compiled as an
implicit class anyway (unless you add the destination directory to the
classpath, which we've already seen misses things), and you might need A
compiled anyway. You may as well just compile A if any of the source
files for A, B or C have changed. IOW, if it's so fast, just do a clean
build every time.



Here's the corrected test run...

% cat build.xml
<project default="compile">
<target name="compile">
<mkdir dir="classes" />
<javac srcdir="src" destdir="classes"
listfiles="yes" includeDestClasses="false"
includeAntRuntime="false" />
</target>

<target name="clean">
<delete dir="classes" />
</target>
</project>
% cat src/Foo.java
public class Foo {
public static void main(String[] args) throws Exception {
new Bar();
}
}

% cat src/Bar.java
public class Bar { }

% ant clean
Buildfile: /scratch/simpsons/Scratch/Coding/antfail2/build.xml

clean:
[delete] Deleting directory /scratch/simpsons/Scratch/Coding/antfail2/classes

BUILD SUCCESSFUL
Total time: 0 seconds
% ant
Buildfile: /scratch/simpsons/Scratch/Coding/antfail2/build.xml

compile:
[mkdir] Created dir: /scratch/simpsons/Scratch/Coding/antfail2/classes
[javac] Compiling 2 source files to /scratch/simpsons/Scratch/Coding/antfail2/classes
[javac] /scratch/simpsons/Scratch/Coding/antfail2/src/Bar.java
[javac] /scratch/simpsons/Scratch/Coding/antfail2/src/Foo.java

BUILD SUCCESSFUL
Total time: 0 seconds
% java -cp classes Foo
% sed -e 's/class/abstract class/' -i src/Bar.java
% cat src/Bar.java
public abstract class Bar { }

% ant
Buildfile: /scratch/simpsons/Scratch/Coding/antfail2/build.xml

compile:
[javac] Compiling 1 source file to /scratch/simpsons/Scratch/Coding/antfail2/classes
[javac] /scratch/simpsons/Scratch/Coding/antfail2/src/Bar.java

BUILD SUCCESSFUL
Total time: 0 seconds
% java -cp classes Foo
Exception in thread "main" java.lang.InstantiationError: Bar
at Foo.main(Unknown Source)
% touch src/Foo.java
% ant
Buildfile: /scratch/simpsons/Scratch/Coding/antfail2/build.xml

compile:
[javac] Compiling 1 source file to /scratch/simpsons/Scratch/Coding/antfail2/classes
[javac] /scratch/simpsons/Scratch/Coding/antfail2/src/Foo.java
[javac] /scratch/simpsons/Scratch/Coding/antfail2/src/Foo.java:3: error: Bar is abstract; cannot be instantiated
[javac] new Bar();
[javac] ^
[javac] 1 error

BUILD FAILED
/scratch/simpsons/Scratch/Coding/antfail2/build.xml:6: Compile failed; see the compiler error output for details.

Total time: 0 seconds
--
ss at comp dot lancs dot ac dot uk
Roedy Green
2013-03-10 01:35:08 UTC
Permalink
Post by Steven Simpson
That only happens if the output directory is included in the classpath.
I have not done it any other way with ANT.

Even if you put them somewhere else, JavaC has to know that place. I
would be surprised it if got suddenly stupid about recompile. However,
I have not done any experiments and it sounds like you have.
--
Roedy Green Canadian Mind Products http://mindprod.com
Software gets slower faster than hardware gets faster.
~ Niklaus Wirth (born: 1934-02-15 age: 79) Wirth's Law
Steven Simpson
2013-03-10 09:09:50 UTC
Permalink
Post by Roedy Green
Post by Steven Simpson
That only happens if the output directory is included in the classpath.
I have not done it any other way with ANT.
Even if you put them somewhere else, JavaC has to know that place.
It does in both Ant configurations. Here's the default:

[javac] Compilation arguments:
[javac] '-d'
[javac] '/scratch/simpsons/Scratch/Coding/antfail2/classes'
[javac] '-classpath'
[javac] '/scratch/simpsons/Scratch/Coding/antfail2/classes'
[javac] '-sourcepath'
[javac] '/scratch/simpsons/Scratch/Coding/antfail2/src'
[javac] '-g:none'

Here's includeDestClasses="false":

[javac] Compilation arguments:
[javac] '-d'
[javac] '/scratch/simpsons/Scratch/Coding/antfail2/classes'
[javac] '-classpath'
[javac] ''
[javac] '-sourcepath'
[javac] '/scratch/simpsons/Scratch/Coding/antfail2/src'
[javac] '-g:none'

The output directory (as set by -d) is the same in both cases. Only the
classpath has changed.
Post by Roedy Green
I
would be surprised it if got suddenly stupid about recompile.
I don't know what you mean by stupid, but the behaviour is indeed different:

1. With "-d X -cp X:Y:Z", the compiler checks the timestamp of
X/Foo.class against Foo.java, and only recompiles Foo if Foo.java is
newer (in which case, let's say that Foo passes the test).
2. With "-d X -cp Y:Z", the compiler compiles Foo.java regardless.

For the reasons stated in my first post, I don't trust behaviour #1.
Post by Roedy Green
However,
I have not done any experiments and it sounds like you have.
In my last post, I determined that Ant <javac> has #1-like behaviour.
When Ant invokes javac, Ant performs the test described in #1, and only
submits source files to javac for classes which pass the test. Under
the default Ant configuration, javac then performs the same test, which
always passes, because Ant has filtered the input to include only those
classes which will pass. The tests performed by javac are redundant
when invoked by Ant.

Under the alternative configuration, javac is instructed not to perform
the tests, but the result is the same because Ant is still performing them.

So #1-like behaviour seems to be unavoidable with the Ant <javac> task.
--
ss at comp dot lancs dot ac dot uk
Loading...