fjord Dremmmm fjordв том то и дело что массив заполняется до 4, и по идее пятый элемент должен быть null, но выдается 0
100 пудов, надо лучше книжки читать
Blazkowicz правильно писал "null это не тип, а значение по умолчанию. Только у int оно 0, а не null"так я и читаю )) и по ходу чтения возникают вопросы
получается что
тоже получает значение по умолчанию 0, однако если сделать
то компилятор скажет что переменная b не проинициализированна, а
инициализирует массив нулями?
при объявлении переменной типа int в классе она инициализируется нулем, при объявлении массива int они инициализируются нулями, при объявлении локальной переменной int (внутри метода) она инициализируется случайным значением, мусором, бывшим в памяти при выделении места под переменную, и чтобы избежать ошибок, компилятор проверяет, чтобы это "случайное значение" не использовалось. В книгах все это давно описано. Читать, читать и читать.

Blazkowicz Зашедшийпри объявлении локальной переменной int (внутри метода) она инициализируется случайным значением, мусором, бывшим в памяти при выделении места под переменную

Откуда дровишки?
Собственно в спецификации JVM это никак не упоминается, там просто выставлено ограничение на использование неинициализированных локальных переменных, но был такой баг в Symantec JIT-compiler. Последний позволял через редактирование байт-кода использовать неинициализированные локальные переменные, в том числе, например, и ссылки на объекты. В итоге указатели показывали куда попало. Баг починили, конечно :)

Вроде про это как раз:
Some remarks:
1. I use boolean, and for 32-bit-values double checking is ok, even in the link.

2. The inspection do not bother me, they reports too many warnings. But we have the goal to get only green code without warnings. And since 833 it reports doublechecking.

3. The JVM-Spec requires that its not allowed to use a noninitialized object, it do not allow a use (= a store)
of this uninitialized object
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#9839

I've tested it (with bcel): the byte code verifier refuse with an "Expecting to find object/array on stack"-exception, if you try to store an object to a field before the initialization:

new #1 // java.lang.Object
dup
putstatic #2 // a static field
invokespecial #1 // Constructor



Same with nonstatic fields, but ok with local variables
(because that cant be accessed from another thread [or threat ;-) ])

So the Symantec JIT-compiler is not correct. Consider, if the constructor takes long value, you may access the object before initialization, or with malicious byte code you can create invalid strings (place in the bytecode between new and invokespecial a Thread.sleep which is ok).