ITEC120-ibarland (incl. office hrs)—info—lectures—labs—hws—java.lang docs—java.util docs
lab14: implementing Comparable; other IDEs
Nov.22 (Wed):
You can work on today's lab individually, or in pairs, as you like.
-
Make a copy of your class Treasure.
(Or, you can make a copy of the posted solution (.jar).)
This week's lab won't be directly used in hw07,
although you'll need the precise concept (implementing an interface)
worked on in this lab.
-
Have your Treasure class
implement Comparable.
We'll say that one Treasure is “less” than another if it
weighs less.
Test your compareTo method.
(See lecture notes for
our example of making class Dog implements Comparable.
-
Refine your compareTo so that in the case of
two equally-heavy Treasures,
the Treasure whose name comes first alphabetically
is considered “less”.
(Remember, Strings themselves already implement Comparable.)
If they have the same weight and same name, then compareTo returns 0.
-
Optional:
Implement .equals to jibe with this:
two Treasures are .equals if they
have the same weight and same name (regardless of their description).
Doing this has a good side and a bad side:
-
If you don't do this,
you are in the weird position that it's conceivable to have
two Treasures t1 and t2
such that (t1.compareTo(t2) == 0),
and yet !(t1.equals(t2)).
- If you do this,
people using your class Treasure
need to be careful about whether they use ==
(“are identically equal”) and
.equals (“look similar”).
Note that often we're in this undesirable situation:
we'd like to be able to sort a list of Treasures
by weight (or by name, or by some other criterion —
or by different criteria depending on the context!).
On the other hand, implementing compareTo defines
a single natural ordering on Treasures, which may put
us add odds with .equals.
The solution:
Don't have Treasures compare themselves, but instead
call sort and pass it (as an input)
an entirely separate method which (“statically”) takes two
Treasures and compares them.
-
Modify your test-method
— which already contains a list-of-Treasures —
so that it calls the pre-defined (static) method
java.util.Collections.sort,
passing it your list.
Display the list before and after sorting it.
(Be sure to test
a list which includes two items with the same weight but different names,
Treasures with an empty-string as a name, etc.1.)
ITEC120-ibarland (incl. office hrs)—info—lectures—labs—hws—java.lang docs—java.util docs
Nov.24 (Fri):
Other IDEs
Contents:
- a method called main
- Other IDEs
A method called main
When we run our program from inside of BlueJ, we can
create instances,
and call whatever method we like.
(Often, we might have a static test-method which we call.)
But if we're not inside of BlueJ, and we want to run a program,
there is a question:
What method should the computer first call, to get your program rolling?
The answer: main.
This is just a convention, because without BlueJ we're kinda impoverished
about being able to specify which method we want to call;
the slightly crude solution is
“always call a method named
public static void main( String[] args )”.
(Why static? For that matter, why public?
Why void?)
The array-of-Strings corresponds to any command-line arguments
the program is called with, if you are running your program from
a linux shell.
The command line is a rather archaic way of starting a program,
as 99.9% of all programs double-clicked on.
In those cases, args will be an array of length 0.
To do:
Write a public static void main( String[] args ) method
for your Treasure class.
Have it print out
"args is an array of size " + args.length + ": " + java.lang.Arrays.toString(args)".
Just have it call your test method.
Stand-alone applications
Optional:
Alas, this section is something we can't yet use:
stand-alone Java applications are useless unless they create
their own GUI windows and frames,
which we haven't talked about. (This is covered in ITEC220.)
The computer runs a java program by finding the appropriate class,
and running that class's main method.
Of course, one class might rely on several other classes.
So in practice, Java programs are often distributed as “java archive files”
(“.jar”).
The jar file contains all the classes needed to run your program,
as well as one bit of additional information:
of all the classes inside the jar file, which one2
has the main
method to really gets your program rolling?
From BlueJ,
Project > Create jar file….
It will ask you to specify which class contains the main to
start your entire program.
Save the file as, say, myProgram.jar
If our java file put up its own windows, we could run it by double-clicking.
However, since it just uses System.out.println, we have
to run it from the command line:
Open a terminal or DOS window, go to the directory where you save your
jar file,
and type java -jar myProgram.jar.
Note that if you add extra words —
java -jar myProgram.jar some extra args,
then your program's main will be
passed an array with three Strings, "some",
"extra", and "args".
Other IDEs
Beside BlueJ, there are other Integrated Development Environments
which you can use to write your program.
While BlueJ strives for a simple, uncluttered interface (at the expense
of not including every bell and whistle),
IDEs such as JBuilder and have more complicated interfaces, which contain
more advanced features.
(Note that in every IDE, there are two initial tasks:
Create a project, and then create a file within that project.
I've heard that JCreator might let you start out by creating a file,
and automatically creates a surrounding project for you, which is handy.)
Uncommon, Good features of BlueJ:
- You can call any method, and create any object.
Most IDEs only let you call a class's public static void main(String[] args), and you can't make objects or call methods without writing a
test function.
- Code Pad.
This rules! Otherwise, if you wanted to see what
"hello".comparesTo("Hello") returns, you'd have
to write an entire function for that.
- Inspect, from an object's pop-up menu.
To be able to have several objects and see what is inside each one
and how the innards change as you call methods is a great, novel feature.
- When learning,
it provides a visual reminder of the difference between classes and
methods, and the fact that static methods/variables
are accessed through the class, not through individual instances.
Uncommonly poor features of BlueJ:
- It can't indent worth a dang.
- If there's a compiler error,
it does highlight the offending line, but doesn't
tell you which character is where the error is first noticed.
- Not much editor support for typing code (see strengths of
other IDEs, below).
- Slightly buggy.
I occasionally have to re-start BlueJ to get something to work;
sometimes javadoc-generation fails.
Features of BlueJ that are okay, compared to other IDEs:
- Compiler error messages are often extremely uninformative.
These messages are actually generated by the underlying compiler,
and all the different IDEs tend to use the same compiler,
so they all share this flaw equally.
(And the solution is, compilers should give more human-intuitive
error messages! This is an HCI (Human-Computer Interaction) problem.)
- javadoc generation.
I don't like how I can't view the program simultaneously as looking
at its javadoc3,
but I like the emphasis that there are two fundamental views of
a class: as an implementor, and as a user
(where the interface is everything).
- The debugger is fine, although it doesn't allow more sophisticated
behaviors like
“stop at line 20, only if numItems > 20”
or
“stop at line 20 the fiftieth time you reach it.”.
These are rarely needed features, but can be important when you do need them.
Some strong features of other IDEs
- Always compiling your program in the background,
to quickly catch mistakes.
- better auto-indenting (e.g. in Eclipse, an correct indentation
menu item; you want to select your entire program text before
choosing this item, and I think it should be automatic;
maybe there is some way to set that?)
- When you type an open-brace or open-paren, it will
immediately generate the matching close-brace/paren.
- Automatically generating javadoc for getters and setters
- Automatically generating getters and setters for fields?
(Not sure how many IDEs do this, and how to easily
specify which field should have public getters, and which should
have public setters.)
- When starting a javadoc comment,
Eclipse will auto-fill in the names of any existing parameters.
- You can customize the font-coloring of keywords, constants, etc..
- pop-up menus for the names of methods and class libraries.
On the other hand,
I know of no other IDEs with BlueJ's above-listed strengths.
To do:, optional:
work through a
JCreator tutorial,
or
an
eclipse tutorial
From Windows' start button,
fire up either eclipse or JBuilder.
JBuilder is free, and eclipse has a free non-professional version.
There are other free/cheap Java IDEs out there as well; just ask google.
1Note
that we're really testing your compareTo method,
not the sort method somebody else wrote.
So you don't need to test an empty list, a list of just one item,
a list of all items being identically equal (==), a list of items
all being conceptually equal (.equals), and so on. back
2
Note that many classes can have main methods -- often
those are the test drivers -- but only one class's main
is the start-the-whole-program main.
back
3Actually, I just realized this is no problem:
If you choose BlueJ's “document project”, it pulls
up the documentation in a separate web browser. back
ITEC120-ibarland (incl. office hrs)—info—lectures—labs—hws—java.lang docs—java.util docs
radford.edu