29-njy dereje. Dereje derejesindäki söhbetdeşlik soraglaryna jogaplar

Name boldy autoboxing?

Awtoboksirlemek, degişli asyl nusga görnüşleriniň (degişlilikde ,,,,,,,,) bolmazdan, örtük synplarynyň obýektlerini (Baýt, Gysga, Nyşan, Integer, Uzyn, Float byte, Double short) aç-açan başlamagyň mehanizmidir. synp konstruktoryny aç-açan ulanmak .charintlongfloatdouble

Awtoboksirlemek, bir primiti gönüden-göni örtük synpyna bellenende (" =" operatory ulanyp) ýa-da primitiw usulyň parametrlerine (meselem, "örtük synpy") geçende ýüze çykýar. Ilkinji görnüşleriň üýtgeýjileri we jemleýji wagt yzygiderliligi (sözme-söz we finalmanyly sözler) “örtük synplaryna” awtomatiki usulda ýerleşdirilip bilner. Bu ýagdaýda asyl nusga görnüşiniň üýtgeýjisini başlamak üçin söz sözleri sintaktik taýdan dogry bolmaly.

Ilkinji görnüşleriň üýtgeýänlerini awtoboksirlemek, asyl nusganyň görnüşine - “örtük synpynyň” görnüşine takyk laýyklygy talap edýär. Mysal üçin, üýtgeýjini awtoboks etmäge synanyşmak byte, Shortilki bilen aç-açan çykyş etmezden, byte->shortdüzme ýalňyşlygyna sebäp bolar.

Ilkinji görnüşli yzygiderliligi awtoboksirlemek, has giň araçäklere mümkinçilik berýär. Bu ýagdaýda düzüji başlangyç görnüşleriň gönüden-göni giňelmegini / daralmagyny başarýar. Üýtgetme iki basgançakda bolup geçýär:

1. Asyl başlangyç görnüşiň gabygyň synpyna gabat gelýän başlangyç görnüşine gönüden-göni giňelmegi (daralmagy) (öwürmek üçin int->Byteilki düzüjiniň intdaralmagy byte)

2. ilkinjini degişli “örtük synpyna” (düzüjiniň awtopaklary byte->Byte) awtomatiki ýüklemek. garamazdan, bu ýagdaýda goşmaça iki çäklendirme bar:

• “örtük” üçin başlangyç bellemek diňe “ =” operatorynyň kömegi bilen amala aşyrylyp bilner (beýle primitiw usuly aç-açan guýmazdan usul parametrlerine geçirip bilmersiňiz)

• çep operanyň görnüşi ondan uly bolmaly däl Character, sag operandyň görnüşi ondan uly bolmaly däldir , ( intuzaldylmagyna / çäklendirilmegine rugsat berilýär we diňe daraltmak ,, beýleki ähli wariantlar aç-açan görnüşi talap edýär)byte <-> shortbyte <-> charshort <-> char
byte <- intshort <- intchar <- int

Дополнительная особенность целочисленных "классов-оберток" созданных автоупаковкой констант в диапазоне -128 +127 , в то что они кэшируются JVM. Потому такие обертки с одинаковыми значениями будут являтся linkми на один an object.

Зачем используется autoboxing?

Я процитирую лекцию:

Насколько ты помнишь, в Java есть How типы, унаследованные от класса Object, так и примитивные типы. Но, How оказалось, такая удобная вещь How коллекции и generic’и могут работать только с типами, унаследованными от Object.

Альтернативы autoboxing?

Не нашел ответа, но запостил на StackOverFlow.

Исходя из этой дискуссии, получается, что альтернатива autoboxing`у это использование примитивных типов, так How использовние autoboxing`a снижает производительность. Вывод: использовать autoboxing только там где это необходимо.

Написана статья про Autoboxing: Autoboxing: Traps and Advantages

Типы-обертки для примитивных типов mutable or immutable?

Immutable, так How примитивные an objectы тоже immutable. Whatбы работать How с Mutable типом есть класс MutableInteger, и.т.д.

Как примитивные типы приводятся к непримитивным аналогам?

На этот и последующий вопросы хорошо отвечает вот эта статья: Автоупаковка и распаковка в Java

Это заключение из нее: автоупаковка является механизмом для скрытого преобразования примитивных типов данных в соответствующие классы-оболочки (an objectы). Компилятор использует метод valueOf() чтобы преобразовать примитивные типы в an objectы, а методы IntValue(), doubleValue() и т.д., чтобы получить примитивные типы из an object (то есть обратное преобразование). Автоупаковка преобразует логический тип boolean в Boolean, byte в Byte, char в Character, float в Float, int в Integer, long в Long, short в Short. Распаковка происходит в обратном направлении.

Как непримитивные типы приводятся к примитивным?

Выше ответил.

Как сравниваются примитивные и непримитивные типы?

В лекции это подробно рассматривается, но я нашел так скажем тоже самое, но другими словами.

В Java есть два способа сравнивать an objectы на equalsство, == и метод equals().

== используется для примитивных типов. Для an objectов «==» это исключительно сравнение ссылок. Для остальных случаев нужно использовать метод equals(). Кроме того метод hashCode() служит (в теории) для той же цели. Хорошим тоном считается, если вы переопределor equals() и hashCode(). После инициализации неких an objectов a и b должно выполняться правило:

Если выражение a.equals(b) вернет true, то a.hashCode() должен быть equals b.hashCode().

Всегда ли создается новый an object при операции autoboxing?

Это в лекциях есть:

Когда мы присваиваем переменной типа Integer meaning типа int, при этом вызывается метод Integer.valueOf: функция valueOf не всегда создает новый an object типа Integer. Она кэширует значения от -128 до 127.

Если передаваемое meaning выходит за эти пределы, то новый an object создается, а если нет, то нет.

Если мы пишем new Integer(), то гарантированно создается новый an object. Если мы вызываем Integer.valueOf(), явно or при autoboxing, то этот метод может вернуть для нас How новый an object, так и отдать an object из кэша, если переданное число лежит в диапазоне от -128 до 127.

Как работает кэширование при операции autoboxing?

Ответил в вопросе выше, на всякий случай создал вопрос на StackOverFlow, но там отвечают тоже самое

Для Howих типов и/or значений работает кэширование?

В восьмом вопросе. Если у кого – то есть соображения на тему трех последних вопросов, то напишите в комментариях.