Name: yyT116575 Date: 03/28/2001


java version "1.3.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-beta-b15)
Java HotSpot(TM) Client VM (build 1.3.1beta-b15, mixed mode)

Java has long had a sort of standard "naming convention" for methods to fit the
form of myMethodName(). However, I believe since it's beginning, the Java API
has included a few methods that are exceptions to this rule. Though the actual
names of these methods don't matter when programs are run, and they especially
don't matter if run through an obfusicator, I feel these problems make these
official releases of the JDK feel a lot of "official."

Let me give my specific examples of this problem, and perhaps some solutions...

PrintStream.println() would be much more appropriately named to
PrintStream.printLine(). This would more match the appropriately named
BufferedReader.readLine(). Since this method is used so much (in calls like
System.out.println()), it shows up a lot, and acts as a constant reminder to
these inconsistancies. If things like this were fixed it would give a much
more solid feel to the JDK. All that would have to be changed is have (for
each version of the println() method) rename this method to printLine(). Then
create a method println() that calls the correctly named printLine(). Then the
println() methods could be deprecated. The reason for having println() call
printLine() is we do not want there to be a performance hit (for having to call
2 methods) for those using the non-deprecated methods. Here is (kinda) what
the code would look like, at least for the String version of the printLine()
method...

public void printLine(String s)
{
    // all the code that used to be in println()
}
public void println(String s)
{
    printLine(s);
}

In addition, System.arraycopy() does not follow the method naming standard.
Another problem is perhaps this sort of method would be more at home in
java.util.Arrays rather than java.lang.System. Someone once explained to me
that the way these arrays would be copied depends on the system you are running
it on. Fine. But how come it doesn't follow the standard naming convention?
This is what I propose (with ideas from Jonathan Finn on the www.javalobby.org
message board): keep System.arraycopy() in tact so old code still runs, but
deprecate the method. Then, add the the following method to java.util.Arrays
class:

public static void copy(Object src,
                        int src_position,
                        Object dst,
                        int dst_position,
                        int length)
{
    System.arraycopy(src, src_position, dst, dst_position, length);
}

Jonathan Finn also mentioned this other version of the copy method that would
be needed. He proposed a copy method in the java.util.Arrays class that would
take just a src and a dst Array to copy, having code something like the
following (since this is very often what arraycopy() is used for):

public static void copy(Object src, Object dst)
{
    System.arraycopy(src, 0, dst, 0, ((Object[])src).length);
}

I understand that it might not be desirable to have methods that just call
other methods instead, especially if those other methods might go away after
being deprecated. Instead all this code can just be copied over to the new
method. Also, if there is some inherent reason arraycopy() should stay in
System, could it not at least be renamed to arrayCopy() to fit the Java naming
standard (which Sun says they back). I feel this would add a nice level of
coherency that the API might be lacking.

One last example I thought of was having the length of an Array retrieved
through ".length". In order to match other similar calls of other Objects,
wouldn't this be better named ".getLength()"?

As I said, these seem to not be a big deal. However, I feel for an official
release of an SDK, it would be nice to have these things ironed out. I also
know it could make for a hastle for people to change their old code, but this
wouldn't be needed if the old methods worked too, and were just deprecated.
Also, some might say that this just adds bloat to the already large instead of
the JRE, but I think if they really think about what's added, it's hardly
anything. Maybe an extra second of download time when getting the install?
Hardly a big deal, especially for the the added coherency I feel it adds.
Kinda reminds me of debates of whether the United States should adopt the
metric system: everyone knows it would be better if we did, but we don't want
to have to get used to the new system...
(Review ID: 119644)
======================================================================