let's use some newly-learned programming concepts to clean up and improve our original version.  Time is short, so this won't take you as much time as the last one -- promise.

PART I:

All files (java, test data, documentation, etc.)

Keep the basic class structure the same.  But put the files in a  new package, named baseball2.
 
Make Player an abstract class ( if you haven't already).  Give it an appropriate constructor, and make sure that constructor gets called from the subclasses.   Think about which methods should be abstract (if any) and which should be concrete (and which should be defined only in the subclasses). 

All of the data fields on the file are strings. For the previous project, it was fine to leave them as strings.  For this project, you might have to convert some of them to numbers.  You are welcome to use the Message Board to share ways of doing this (even short examples of code are fine).

The player and team data files remain the same, though we may supply updated versions of those files (with the same format).

Provide the following new features (the old ones should continue to work).  See method specifications in the new (baseball2) ILeague.java file.
Most Valuable PLayer Candidates.  List players in descending order of "value" (in baseball terms), that is, the most valuable are listed first.  We define value as follows: all pitchers are more valuable than any hitter.  Within the hitter category, value is determined by batting average (higher is better).  Among pitchers, value is determined by ERA (lower is better).
All-Star Ballot.  Every year baseball fans have the opportunity for vote for their favorite players, categorized by position... except pitchers, who are not on the ballot (they are picked by the game's managers).  List all players (except pitchers), in order of their positions.  The positions should be in alphabetical order by position codes.  Within a given position, list the players in alphabetical order (in the usual way).

As before, League should include a main method which causes the files to be read in and several test operations to be performed: enough to show that your program basically works on all the required methods, including the new ones.  Your main should not require any user input.   You should not use any data files other than ones like those specified.

Hand in the files electronically by the due date at the top of this page. 

In addition, write a short technical description (at most one page, but a paragraph will probably do) of your program and how it works. As usual on any written part, unless you handwriting is exceptionally clear, please type it!
Add to this a class/interface hierarchy diagram.  Include on it all classes and interfaces directly mentioned in your program, regardless of origin (i.e., whether you wrote them, we wrote them, Sun wrote them, etc.)  It is fine for this to be handwritten (if you are curious, play around with the Violet tool for drawing UML diagrams, linked from the Calendar page). Turn all paperwork in (hardcopy) at the next class (whether quiz section or lecture) after the electronic due date above. 

Big Hints: The java.util package defines a Comparator interface with a single method, compare.  The Collections.sort method has a version which lets you pass a Comparator object to it, to determine the order of objects (as opposed to using their compareTo method).  Look up both of these concepts and feel free to discuss on the Message Board.
Another hint: you may (or may not) find the instanceof operator useful.

Get started early and have fun!