Name: gm110360 Date: 12/12/2001


java version "1.4.0-beta3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b84)
Java HotSpot(TM) Client VM (build 1.4.0-beta3-b84, mixed mode)

I would like to suggest five small features to be added to the jre APIs.

1.) There are 3 system-properties that help to abstract from OS specific path
and file patterns:
- path.separator
- file.separator
- line.separator

The java.io.File class contains static fields as a short cut to path.separator
and file.separator, but none for line.separator.
Therfore, if I need to use the latter property, I always have to use
System.getProperty("line.separator") which is more hard to remember than
File.lineSeparator.
I think adding the static fields lineSeparator and lineSeparatorChar to the
File class would be consistent with the approach so far, would be very little
work to do and I would like it very much.

---

2.) I am missing one further ting within the java.io.File class:
It contains the methods: canRead(), canWrite() and setReadOnly().
So I can set a file to be readonly, but I cannot set it back to read-write.
It happened quite some times that I have missed this feature in a certain
situation. I would add a method setReadOnly(boolen state) [ or setReadWrite(),
setWriteable() or s.th.]

---

3.) I've been working with the prefs package a lot and I like it very much.
However I would be more than happy, if a platform independent 100% java
Preferences implementation would be included in every java platform.
Personally, I looked at the FileSystemPreferences Implementation that comes
with the linux jdk version. I also modified it to be 100% java and use it on my
windows machine. Users shouldn't be forced to write into that ugly windows
registry, only learn how to deal with 10 different kinds of directory concepts
while moving from one platform to the other. The Registry preferences should be
included with the windows distribution, but ONE 100% java default
implementation should have to be part of every J2SE1.4 platform that would run
on most devices. I would vote for a file-system based implementation.

---

4.) I have talked to a lot of developers about the collections classes and
everybody just loves them and so do I. However, everyone I talked with had more
or less the same problems with the following (minor, but very inconvenient)
issues:

- the Comparator interface is a very nice invention, but I do not understand
what sense the "is consistent with equals" issue makes!
Why do SortedSets and SortedMaps rely on the objects implementation of equals()
even if a comparator class is provided. This is REALLY INCONVENIENT and
disturbs me and a lot of other developers out there a lot.
If a Set or List implementation is instantiated with a comparator, then it
should internally use the term (obj1.compare(obj2) == 0) to determine whether
to object are equal and use the object equals method only if no comparator is
present.
Also, to allow for easy customizability of hashed implementations, one should
derive a further interface from Comparator that also has a hashCode(Object obj)
signature.
That way, I could implement several consistent complete orderings for one type
of object. At the moment this is not possible, because an object can only have
ONE equals method an ONE hashCode() method.

Because a Comparator provides a valid notion for equality, it should be
possible to instantiate Sets with a comparator, in some cases taking only an
interface that can also compute hashCodes. At the moment all Set
implementations can only deal with the built-in notion of object equality
provided by the object's methods equals() and hashCode()

---

5.) Last but not least I would like to request a feature within the Set class.
As explained within request 4, it is desireable to be able to define several
possible orderings for one object-type. If two objects are equal according to
one specific ordering should determine, whether they can both be inserted
within a set or not. Additionally, it would be quite useful to have a method
within the Set class that returns an object within the set that equals an
object provided, although that sounds weird at first.

The methods signature might be: public Object getElement(Object ref)
If the Set contains an Object that is equal to the Object provided, then the
object within the set should be returned. This is useful because two objects
can be equal although they are physically two different objects!

Look at the following a real ecommerce example:
Lets say, we have a class Shipment that has the fields itemCount and shipmentId.
Furthermore, two real-life shipments are equal, if they have the same
shipmentId.
Therefore the hashCode() and equals() methods are implemented based on the
shipmentId field only.

Within a situation where one might read in an xml file listing shipment
positions, it might be that the same shipment is listed several times, each
time with another itemCount, because a shipment is transfered as a substructure
of an invoice.

Lets say shipment 1 has 4 items, 3 of which were billed on invoice 1 and one
was billed on invoice 2.

Than a file might be transmitted that looks like this:
<invoice>
 <invoice-id>1</invoice-id>
 <shipment>
  <shipment-id>1</shipment-id>
  ... further shipment information
  <item-count>3</item-count>
 </shipment>
</invoice>
<invoice>
 <invoice-id>2</invoice-id>
 <shipment>
  <shipment-id>2</shipment-id>
  ... further shipment information
  <item-count>1</item-count>
 </shipment>
</invoice>

While reading in one shipment structure, one Shipment object is being filled
with data and a set of shipments shall be created, holding all shipments.
Within the xml file, shipment 1 is listed twice, but after the file import
there should only be ONE Shipment record with the id 1 within the set.
Also, during the import process, the item-count for one shipment should be
incremented.
The code might look like this:

Set shipments = new HashSet();
while(loop-criteria)
{
 Shipment shipmentPosition = readNextShipment(xmlFile);
 if(!shipments.add(shipmentPosition))
 {
   Shipment temp = shipments.get(shipmentPosition);
   temp.setItemCount(temp.getItemCount() + shipmentPosition.getItemCount())
 }
}

The shipmentPosition object might be equal to another shipment that was
previously stored away into the set, according the the equality defined by both
of them having the same shipmentId value.
If the current shipment cannot be added to the set, than this means that an
equal shipment is already a member of the set. In this case, I need to be able
to ACCESS this member and increment its itemcount by the one of the current
shipmentPosition.
I know well, that I could either use other Set's methods like getTailSet
(ref).first() or could use a HashMap that holds the shipmentId as a key and the
Shipment as a value.
However by adding a get method and a notion for customized equality to a Set,
one could use Sets in many situations, where the use of Maps would be awkward.
If a SortedSet like TreeSet can take a comparator, to allow for a customizeable
ordering of elements, then it would also be consistent to implement a usual Set
like HashSet with a comparator that provides a notion for equality. Again, this
cannot be achieved by the existing Comparator interface in hash-based
implementations of sets, but one could define a subinterface of Comparator,
that also has a method for computing the hashCode of an object.

iterface CompleteOrdering extends Comparator
{
 public int hashCode(Object obj);
}
(Review ID: 135666)
======================================================================