Java is a good tool, but it seems like noone ever mentions the 'dark side'
Below I summarize a bunch of nits in Java that I find annoying.
tree.html
almost always lists java.lang.Object
as the base class, yet that link is not live.
doc/api
directory.
doc/api
directory needs to be
accessible. This could either be a link in the local directory, or a
URL back to the master on www.javasoft.com
.
@see
link in a file, then you have to run
javadoc
on both files at once to get the link to show up.
javac
compiler looks inside doccomments for the
@deprecated
tag and prints warnings accordingly
In jdk1.1, javadoc takes a @deprecated tag.
If this tag is present in the doc comment of a method that overrides a method that has a @deprecated tag, then the compiler will not print deprecation warnings.
For example, PlotBox.java uses the mouseUp() method.
If I build with:javac -deprecated PlotBox.java
Then I get
PlotBox.java:758: Note: The method boolean mouseUp(java.awt.Event, int, int) in class java.awt.Component has been deprecated, and class plot.PlotBox (which is not deprecated) overrides it. public boolean mouseUp(Event evt, int x, int y) {If I add an @deprecated doctag:
/** * Set the starting point for an interactive zoom box. * Set the starting point for an interactive zoom box. * @deprecated As of JDK1.1 in java.awt.component * but we need to compile under 1.0.2 for netscape3.x compatibility. */ public boolean mouseDown(Event evt, int x, int y) { // deprecatedThen javac no longer complains about mouseDown being deprecated. This means that the javac compiler is looking inside doc comments and using the information inside to print warnings. This is sort of bogus to me. In every other language I've used, comments are opaque. See the jdk1.1 deprecation page for more information.
lib
or
utils
directory and place all the code that they are
borrowing in it. The problem is that if the borrowed code
imports
classes in the same package, then the CLASSPATH
will be wrong if it set to a single top level directory.
lib/stuff
subdirectory, thinking I can refer to those classes as
lib.stuff.Foo
and lib.stuff.Bar
.
However, if Foo.java
contains
imports stuff.Bar
, then I won't be able to compile these
files unless my CLASSPATH includes the lib
subdirectory.
cxh at eecs