I have written a page here on using arrays as proper objects with their own methods instead of relying on helper classes like Arrays, Arrays and ArrayUtils.
ints.sort(); // instead of Arrays.sort(ints);
// instead of int[] onemore = ArrayUtils.add(ints, 8);
int[] onemore = ints.add(8);
I am sure I am not the first with this idea but I have had trouble searching for others who have written about this before.
Can anyone help me with some references on this topic?
Can you add comments if you have a reference on why this is a bad idea or a good idea if you have one?
Link deleted. Adding main points
This follows from the idea of Project Coin
OVERVIEW
Provide a two sentence or shorter description of these five aspects of the feature:
FEATURE SUMMARY: Should be suitable as a summary in a language tutorial.
Treat array as objects with their own methods rather than values to be passed to helper methods. This leads to more natural coding and gives the methods more immediacy. e.g. through code completion.
MAJOR ADVANTAGE: What makes the proposal a favorable change?
It bring OO programming to arrays , supporting methods already available and written.
MAJOR BENEFIT: Why is the platform better if the proposal is adopted?
Object Orientated consistency for arrays.
MAJOR DISADVANTAGE: There is always a cost.
Someone has to write it and test it.
ALTERNATIVES: Can the benefits and advantages be had some way without a language change?
Call helper methods.
EXAMPLES
Show us the code!
SIMPLE EXAMPLE: Show the simplest possible program utilizing the new feature.
int[] ints = {5,4,3,2,1};
ints.sort(); // instead of Arrays.sort(ints);
int pos = ints.indexOf(5); // instead of Arrays.asList(ints).indexOf(5); or ArraysUtils.indexOf(ints, 5);
ints.reverse(); // instead of Arrays.reverse(ints);
Array array = ints; // cast to super class.
int length = array.getLength(); // instead of Array.getLength(array);
Object n = array.get(3); // instead of Array.get(array, 3);
array.set(3, 7); // instead of Array.
Object obj = array;
System.out.println(obj); // prints [5,4,7,2,1] instead of having to if (obj instanceof int[]) System.out.println(Array.toString((int[]) obj)); else if (....)
ADVANCED EXAMPLE: Show advanced usage(s) of the feature.
int[] ints = {5,4,3,2,1};
int[] ints2 = ints.copyOf(2);
int[] ints3 = ints.subArray(2,4);
ints.sort(myComparator);
List<Integer> list = ints.asList();
Set<Integer> set = ints.asSet();
long total = ints.sum();
double avg = int.average();
int max = ints.max();
int max2 = ints.max(myComparator);
http://commons.apache.org/lang/api/org/apache/commons/lang/ArrayUtils.html
int[] onemore = ints.add(8); // instead of ArrayUtils.add(ints, 8);
int[] moreInts = ints.addAll(ints2); // instead of ArraysUtils.addAll(ints, ints2);
int[] oneless = int.remove(3); // instead of ArrayUtils.remove(ints, 3);
Integer[] integers = int.toObject();
int[] intsAgain = integers.toPrimitive();
DETAILS
SPECIFICATION: Describe how the proposal affects the grammar, type system, and meaning of expressions and statements in the Java Programming Language as well as any other known impacts.
A class such as java.lang.Array would need to be added as the parent of all arrays. Subclasses for specific int[], boolean[] might also be needed. The grammar shouldn't be dramatically different.
COMPILATION: How would the feature be compiled to class files? Show how the simple and advanced examples would be compiled. Compilation can be expressed as at least one of a desugaring to existing source constructs and a translation down to bytecode. If a new bytecode is used or the semantics of an existing bytecode are changed, describe those changes, including how they impact verification. Also discuss any new class file attributes that are introduced. Note that there are many downstream tools that consume class files and that they may to be updated to support the proposal!
In the provides a new parent for arrays could be used, the compilation would be the same as it is now. However, it is the JVM which would need to accept that an array has a different super class.
TESTING: How can the feature be tested?
Check the new methods do the same things as the helper methods. (Should be simple if indeed they just call the same helper methods)
LIBRARY SUPPORT: Are any supporting libraries needed for the feature?
This should be added to the rt.jar
REFLECTIVE APIS: Do any of the various and sundry reflection APIs need to be updated? This list of reflective APIs includes but is not limited to core reflection (java.lang.Class and java.lang.reflect.*), javax.lang.model.*, the doclet API, and JPDA.
The super class for an array would need to return java.lang.Array or the like instead of java.lang.Object. However, again this may be a change for the JVM rather than the rt.jar code.
OTHER CHANGES: Do any other parts of the platform need be updated too? Possibilities include but are not limited to JNI, serialization, and output of the javadoc tool.
The change should be reflected in the javadoc.
MIGRATION: Sketch how a code base could be converted, manually or automatically, to use the new feature.
Replace calls to Arrays.xxx(array, args) to array.xxx(args);
COMPATIBILITY
BREAKING CHANGES: Are any previously valid programs now invalid? If so, list one.
Calls to hashCode() and equals() would be changed if every method were taken. This may be unacceptable in which case these methods could be left as they are rather than call Arrays.hashCode() or Arrays.equals();
EXISTING PROGRAMS: How do source and class files of earlier platform versions interact with the feature? Can any new overloadings occur? Can any new overriding occur?
No.
REFERENCES
EXISTING BUGS: Please include a list of any existing Sun bug ids related to this proposal.
This is what I am looking for help on, bug reports or other references