Java должен рассматривать массивы как объекты?

Да. Но я имею мнение, что Java не должен иметь никаких примитивов вообще. Я думаю, что примитивы в Java являются повреждением от чистоты языка. Все в Java должно быть объектами. Выделяются ли объекты на стеке, или "куча" должна быть деталью реализации JVM не конструкция языка. Но я думаю, что мое мнение могло бы быть более радикальным, чем большинство.

Перед автоупаковкой, имея дело с примитивами и объектами было очень громоздким.

Если массивы были объектами и могли бы быть автоупакованы (и generisized!), у нас могло быть что-то как

Array<Integer> myArray = new Integer[];
myArray.add(8);
int x = myArray[0];
....

или

Array<Class<? extends MyBaseObject>> myArray = {ExtendedObject.class}
ExtendedObject object = myArray[0].newInstance();
....

Те методы начинают очень много походить на рубин или идиомы Python. К сожалению, Вы не добираетесь, чтобы сделать это в Java (жаль, что Вы не могли).

Для одного, как другие указали, классы наборов делают это для Вас. Для другого, myarray.sort () не так хорошо, потому что можно создать массивы объектов, для которых не была определена сортировка. Предположим, что я имею

 Foo[] foos; 

И Нечто не Сопоставимо. Что происходит на foos.sort ()? Мы определенно не хотели бы иметь его, только работают на примитивы

int[] ints; 
ints.sort(); //legal
Object[] objects;
objects.sort(); //illegal

и у Вас, конечно, не могло быть компилятора, только позволяют синтаксис для сопоставимых объектов. И после того как Вы добираетесь до чего-то как

 myarray.add(new Foo());

это - вид бессмысленных, поскольку массивы в Java не growable.

Было бы хорошо, если распечатывание массива не дало Вам что бесполезный

([I'm an array(*&(*

мусор, все же.

Прежде чем я отвечу за, ДОЛЖЕН, я сказать Вам состояние этой проблемы.

В Java массивы считают объектами - можно сохранить их в Списке, например. Однако они - специальные объекты в этом, они наследовались Объекту, но не инстанцированы или получены доступ с тем же синтаксисом (спасибо за исправление Peter). Они настойчиво оптимизируются JVM для очевидных проблем производительности, и таким образом способ, которым хранится массив, зависит от реализации.

Таким образом, аргумент Sun был бы то, что, если они дали объектный API для массива, он мог бы потребовать, чтобы определенные аппаратные средства, программное обеспечение или другие функции спецификации существовали.

Единственный реальный интерфейс для массивов является статическим методом System.arrayCopy или Массивом.* статические методы, которые наиболее эффективно скопируют в массивы.

В ответ на ДОЛЖЕН; это было решено, хотя стандарт будет лучше, чем ответ: используйте ArrayList.

Да, я полагаю, что массивам нужно определить API вне того, указанного на самом языке. В частности, это является раздражающим это a Foo[] не реализует Iterable<Foo>. Да, я знаю, что легко перенести его - но это является раздражающим, к которому Вы имеете.

.NET получает это главным образом правильное, с Array введите, который является главным образом для неуниверсального доступа и различных универсальных интерфейсов, которые, как считают, реализованы фактическими массивами. Например:

IList<int> intList = new int[10];

(Помогает, что дженерики.NET справляются с типами примитивов лучше, чем Java.)

Единственные недостатки, которые я видел этого подхода, - то, что массивы могут быть ковариантными в.NET, но нормальные дженерики не, и что вещи становятся немного сбивающими с толку с массивами non-zero-based и прямоугольными антенными решетками.

Как в стороне, различные люди назвали массивы примитивами в этом потоке. В то время как у них, конечно, есть специальная обработка, они не определяются, чтобы быть примитивами. От спецификации языка разделите 4.2:

Тип примитива предопределяет язык программирования Java и называет его зарезервированное слово (§3.9):

PrimitiveType:
        NumericType
        boolean

NumericType:
        IntegralType
        FloatingPointType

IntegralType: one of
        byte short int long char

FloatingPointType: one of
        float double

Это не ПЛОХАЯ идея. Вещь - это, был уже сделан на Наборах. Попытайтесь расширить ArrayList, если Вы хотите сойти с ума.

Я полагаю, что это очень трудно реализовать, не повреждая совместимость на многих уровнях.

• Обработки JVM выстраивают мало по-другому, чем другие объекты. Создание/инициализация отличается: никакого конструктора не вызывают, с одной стороны. Как Вы хотели бы добавить новые методы? Если бы путем добавления суперкласса, Вы вызвали бы его конструктора?
• Массивы знают тип элемента во времени выполнения, дженерики не делают. Если бы Вы хотели добавить новый суперкласс для всех массивов (как Вы предложенный в исходном вопросе), то Вы сделали бы его универсальным? Также имейте в виду, что массивы являются ковариантными в Java, дженерики не.
• Массивы зафиксировали набор методов/полей, указанных в Спецификации языка Java (все методы от Объектов, которые являются explicitely, названным в JLS, поле длины). Добавление новых участников, вероятно, повредит существующие клиенты в зависимости от этого. (т.е. массивы не являются Вашим случайным классом),
• Сериализация массива была бы, вероятно, затронута также
• Я уверен, что существует больше деталей реализации, которые сделали бы это чрезвычайно трудно :-(
• Программы, скомпилированные для работы с новыми методами, не работали бы над более старым JVMs. Что хуже, в зависимости от реализации, программы, скомпилированные для старого JVMs, не могут работать с измененными массивами на новом JVMs.

Я хотел бы иметь методы непосредственно в "Классе массива", я не думаю, что возможно реализовать его теперь.

Для тех, кто пропустил предыдущее сообщение, которое было закрыто. Некоторые другие примеры включают

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<Integer> 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.set(array, 3, 7);
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 (....)

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();

Мне лично нравится идея всего являющегося объектом, и это было уже сделано в smalltalk, например. Однако последствия создания всего, даже methods/funcitons объект являются очень далеко идущими (взгляните на smalltalk для наблюдения то, что я имею в виду). Будучи последовательным в приложении "все - объект" - результаты правила на языке, который не смотрит ничто как C (или Java) больше.

Java был очень сознательно разработан, чтобы быть доступным программистам C, и он успешно выполнился в этом, но это не на самом деле очень объектно-ориентировано по сравнению с smalltalk. Это - наследие, поскольку вариант C обнаруживается повсеместно, как в массивах и том, что существуют примитивы.

Таким образом для ответа на вопрос ДОЛЖНО, я сказать "нет", потому что Java больше не будет Java с тем изменением. Как другие указали, существуют другие классы, которые позволяют Вам справиться с задачами, которые, возможно, были сделаны с массивом в C использующие объекты в Java, но избавиться от примитивных типов данных и массивов в целом - задача, лучше оставленный другому языку, по моему скромному мнению.

Одна причина я верю этому, была бы не, настолько трудно то, что можно добавить методы косвенно путем изменения Объекта (Реальный взлом, который я согласовываю, но это показывает, что работает) Путем добавления методов для Возражения, следующий код

int[] ints = {5, 4, 3, 2, 1};
System.out.println("ints= "+ints);
ints.sort();
System.out.println("after sort() ints= "+ints);
ints = ints.add(6);
System.out.println("after add(6) ints= "+ints);

Печать

ints= [5, 4, 3, 2, 1]
after sort() ints= [1, 2, 3, 4, 5]
after add(6) ints= [1, 2, 3, 4, 5, 6]

Это работает с Java 5 и 6, и и компилятор и IDE обработали это, как я ожидал.