Чому Java 8 не включає незмінні колекції?

Команда Java здійснила велику роботу, усуваючи бар'єри для функціонального програмування на Java 8. Зокрема, зміни в колекціях java.util виконують велику роботу з ланцюжка перетворень на дуже швидкі потокові операції. Зважаючи на те, наскільки добре вони виконали додавання першокласних функцій та функціональних методів у колекції, чому вони повністю не змогли надати незмінних колекцій чи навіть незмінних інтерфейсів колекції?

Не змінюючи жодного існуючого коду, команда Java могла б у будь-який час додати незмінних інтерфейсів, таких самих, як і ті, що змінюються, за вирахуванням методів "встановити" та змусити існуючі інтерфейси поширюватися з них, як це:

                  ImmutableIterable
     ____________/       |
    /                    |
Iterable        ImmutableCollection
   |    _______/    /          \   \___________
   |   /           /            \              \
 Collection  ImmutableList  ImmutableSet  ImmutableMap  ...
    \  \  \_________|______________|__________   |
     \  \___________|____________  |          \  |
      \___________  |            \ |           \ |
                  List            Set           Map ...

Зрозуміло, такі операції, як List.add () та Map.put (), в даний час повертають булеве або попереднє значення для даного ключа, щоб вказати, чи вдалася операція чи не вдалася. Незмінні колекції повинні були б розглядати такі методи як фабрики та повертати нову колекцію, що містить доданий елемент - що несумісне з поточним підписом. Але це можна вирішити, використовуючи іншу назву методу, як ImmutableList.append () або .addAt () та ImmutableMap.putEntry (). Отримане багатослів’я було б більш ніж переважене на користь роботи з незмінними колекціями, а система типів запобігла б помилкам викликати неправильний метод. З часом старі методи можуть бути застарілими.

Виграші незмінних колекцій:

• Простота - міркування про код простіше, коли основні дані не змінюються.
• Документація - якщо метод приймає незмінний інтерфейс колекції, ви знаєте, що він не збирається змінювати цю колекцію. Якщо метод повертає незмінну колекцію, ви знаєте, що ви не можете її змінити.
• Паралельність - незмінні колекції можна безпечно ділити по нитках.

Як хтось, хто скуштував мови, які передбачають незмінність, повернутися на Дикий Захід бурхливих мутацій дуже важко. У колекціях Clojure (абстракція послідовностей) вже є все, що надають колекції Java 8, плюс незмінність (хоча можливо використання додаткової пам’яті та часу завдяки синхронізованим спискам зв’язків замість потоків). Scala має як змінні, так і незмінні колекції з повним набором операцій, і хоча ці операції прагнуть, виклик .iterator надає лінивий погляд (і є інші способи ліниво оцінити їх). Я не бачу, як Java може продовжувати конкурувати без незмінних колекцій.

Чи може хтось вказати мені на історію чи дискусію з цього приводу? Звичайно, це десь публічно.

Тому що незмінні колекції абсолютно потребують спільного використання для використання. В іншому випадку кожна окрема операція кудись купляє цілий інший список. Мови, які повністю незмінні, як Haskell, генерують дивовижні кількості сміття без агресивних оптимізацій та обміну. Маючи колекцію, яка може бути використана лише з <50 елементами, не варто розміщувати в стандартній бібліотеці.

Більше того, незмінні колекції часто мають принципово іншу реалізацію, ніж їх колеги, що змінюються. Розглянемо, наприклад ArrayList, ефективний незмінний ArrayListзовсім не буде масивом! Його слід реалізувати за допомогою збалансованого дерева з великим коефіцієнтом розгалуження, Clojure використовує 32 IIRC. Зробити змінні колекції "непорушними", просто додавши функціональне оновлення - це помилка продуктивності настільки ж, як і витік пам'яті.

Крім того, обмін не є життєздатним на Java. Java надає занадто багато необмежених гачків для змінності та рівності еталонів, щоб зробити обмін "просто оптимізацією". Напевно, вас би трохи роздратувало, якби ви могли змінити елемент у списку, і зрозуміли, що ви просто змінили елемент у інших 20 версіях цього списку, які ви мали.

Це також виключає величезні класи дуже життєво важливих оптимізацій для ефективної незмінюваності, спільного використання, потокового синтезу, ви називаєте це, незмінність порушує його. (Це було б хорошим гаслом для євангелістів ФП)

Колекція, що змінюється, не є підтипом незмінної колекції. Натомість колекції, що змінюються та змінюються, є нащадками читаних колекцій. На жаль, поняття "читабельні", "лише для читання" та "незмінні", здається, розмиваються разом, хоча вони означають три різні речі.

• Читаючий базовий клас колекції або тип інтерфейсу обіцяє, що можна читати елементи та не надає жодних прямих засобів зміни колекції, але не гарантує, що код, що отримує посилання, не може передавати або маніпулювати ним таким чином, щоб дозволити зміни.

• Інтерфейс колекції, що доступний лише для читання, не містить нових членів, але повинен бути реалізований лише класом, який обіцяє, що немає способу маніпулювати посиланням на нього таким чином, щоб мутувати колекцію і не отримувати посилання на щось що могло це зробити. Однак це не обіцяє, що колекція не буде модифікована чимось іншим, що має посилання на внутрішні органи. Зауважте, що інтерфейс колекції, що доступний лише для читання, може не в змозі запобігти реалізації мутаційними класами, але може вказати, що будь-яка реалізація або клас, похідний від реалізації, що дозволяє мутувати, вважається "незаконною" реалізацією або похідною від реалізації .

• Незмінна колекція - це та, яка завжди буде зберігати однакові дані, поки існують будь-які посилання на неї. Будь-яка реалізація незмінного інтерфейсу, який не завжди повертає однакові дані у відповідь на конкретний запит, порушується.

Іноді корисно мати сильно пов'язані змінювані і незмінні типи колекцій , які й реалізують або випливають з того ж «читаного» типу і мають читаються типу включають в себе AsImmutable, AsMutableі AsNewMutableметоду. Така конструкція може дозволити виклик коду, який хоче зберігати дані в колекції AsImmutable; цей метод зробить захисну копію, якщо колекція є змінною, але пропустіть її, якщо вона вже непорушна.

Java Collections Framework надає можливість створювати колекцію лише для читання, використовуючи шість статичних методів у класі java.util.Collections :

• unmodifiableCollection (Колекція c)
• unmodifiableList (Список списку)
• незмінна карта (карта м)
• unmodifiableSet (Набір)
• немодифікуєтьсяСортирована карта (Сортирована карта)
• unmodifiableSortedSet (сортується набір)

Як хтось зазначив у коментарях до оригінального запитання, повернені колекції не можуть вважатися непорушними, оскільки, хоча колекції не можуть бути змінені (жодні учасники не можуть бути додані або вилучені з такої колекції), фактичні об'єкти, на які посилається колекція може бути змінено, якщо їх тип об'єкта дозволяє.

Однак ця проблема залишатиметься незалежно від того, повертає код один об'єкт, чи колекцію об'єктів, що не змінюються. Якщо тип дозволяє мутувати його об'єкти, то це рішення було прийняте в дизайні типу, і я не бачу, як зміна в JCF могла це змінити. Якщо незмінність важлива, то члени колекції повинні бути незмінними.

Це дуже гарне запитання. Мені подобається розважати думку про те, що з усього коду, написаного на Java і працює на мільйонах комп'ютерів по всьому світу, щодня, цілодобово, близько половини загальних циклів годин потрібно витрачати нічого, не роблячи нічого іншого, окрім створення копій колекцій, що є безпечними повертається функціями. (І сміття збирає ці колекції через мілісекунди після їх створення.)

Процент програмістів java знає про існування unmodifiableCollection()родини методів Collectionsкласу, але навіть серед них багато хто просто не турбуються.

І я не можу їх звинувачувати: інтерфейс, який прикидається читанням-записом, але викине, UnsupportedOperationExceptionякщо ви помилитесь, використовуючи будь-який із його методів «запису», - це зовсім зле!

Тепер інтерфейс, як у Collectionякому не було б add(), remove()а clear()методи не будуть інтерфейсом "ImmutableCollection"; це буде інтерфейс "UnmodifiableCollection". Насправді, ніколи не може бути інтерфейсу "ImmutableCollection", оскільки незмінність - це характер реалізації, а не характеристика інтерфейсу. Я знаю, це не дуже зрозуміло; дозволь пояснити.

Припустимо, хтось передає вам такий інтерфейс колекції, доступний лише для читання; чи безпечно передати його в іншу нитку? Якби ви точно знали, що це справді непорушна колекція, то відповідь буде «так»; на жаль, оскільки це інтерфейс, ви не знаєте, як він реалізований, тому відповідь має бути " ні" : оскільки всі ви знаєте, це може бути немодифікований (для вас) перегляд колекції, яка насправді є зміною, (як, наприклад, те, що ви отримуєте з Collections.unmodifiableCollection()), тому спроба прочитати з нього, коли інший потік модифікує, призведе до читання пошкоджених даних.

Отже, те, що ви описали по суті, - це набір інтерфейсів колекції не "Immutable", а "Unmodifiable". Важливо розуміти, що "Немодифікується" просто означає, що той, хто має посилання на такий інтерфейс, не може змінювати базову колекцію, і їм заважають просто тому, що в інтерфейсі відсутні будь-які способи модифікації, а не тому, що базовий збірник обов'язково є незмінним. Основна колекція може бути цілком змінна; у вас немає знань і контролю над цим.

Для того щоб мати незмінні колекції, вони мали б бути класами , а не інтерфейсами!

Ці класи незмінних колекцій повинні бути остаточними, так що коли вам дають посилання на таку колекцію, ви точно знаєте, що вона буде вести себе як незмінна колекція, незалежно від того, що ви, або хто-небудь інший, хто має посилання на неї, можуть робити з цим.

Отже, для того, щоб мати повний набір колекцій у java (або будь-якій іншій декларативній імперативній мові), нам знадобиться наступне:

1. Набір незмінних інтерфейсів колекції .

2. Набір змінних інтерфейсів колекції , що розширюють незмінні.

3. Набір класів колекцій, що змінюються, що реалізують інтерфейси, що змінюються, а також розширення також незмінні інтерфейси.

4. Набір незмінних колекційних класів , що реалізують незмінні інтерфейси, але в основному передаються як класи, щоб гарантувати незмінність.

Я все це реалізував для розваги, і я використовую їх у проектах, і вони працюють як шарм.

Причина, чому вони не є частиною виконання Java, мабуть, тому, що вважалося, що це буде занадто багато / занадто складно / занадто важко зрозуміти.

Особисто я вважаю, що те, що я описав вище, навіть недостатньо; Ще одна річ, яка, здається, потрібна - це набір змінних інтерфейсів і класів для структурної незмінністі . (Що може бути просто названо "Жорстким", тому що префікс "StrukturlyImmutable" занадто проклятий.)

Незмінні колекції можуть бути глибоко рекурсивними, порівняно з іншими, а також не безпідставно неефективними, якщо рівність об’єктів забезпечується secureHash. Це називається меркливим лісом. Це може бути в колекції або в їх частинах, як (самоврівноважуване бінарне) дерево AVL для відсортованої карти.

Якщо всі об'єкти java в цих колекціях не мають унікального ідентифікатора або деякого бітстрингу до хешу, колекція не має нічого хешувального, щоб однозначно називати себе.

Приклад: На моєму ноутбуці 4x1,6 ГГц я можу запустити 200K sha256s в секунду найменшого розміру, який підходить для 1 хеш-циклу (до 55 байт), порівняно з 500K HashMap Ops або 3M ops у хешбелі довгих. 200K / log (collectionSize) нових колекцій в секунду досить швидко для деяких речей, де важлива цілісність даних та анонімна глобальна масштабованість.

Продуктивність. Колекції за своєю природою можуть бути дуже великими. Копіювання 1000 елементів у нову структуру з 1001 елементами замість того, щоб вставити один елемент, просто жахливо.

Паралельність. Якщо у вас є кілька потоків, вони можуть захотіти отримати поточну версію колекції, а не версію, передану 12 годин тому, коли нитка запускалася.

Зберігання. З незмінними об'єктами в багатопотоковому середовищі ви можете покласти десятки копій «одного» об’єкта в різні точки його життєвого циклу. Немає значення для об’єкта Календар або Дата, але коли його колекція 10 000 віджетів, це вб'є вас.