Сучасний огляд Java [закрито]

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

Найчастіше цитується причина неповноцінності Java в тому, що вона набагато повільніше, ніж інші мови, що складені на самому світі, як, наприклад, C ++. Багато людей критикують ігрового дизайнера Notch (який розробив Minecraft) за використання Java через його очевидну відсутність у відділі продуктивності. Я знаю, що Java була набагато повільнішою в той час, але після цього було багато вдосконалень, особливо компіляція JIT.

Я хотів би сьогодні отримати деякі об'єктивні думки щодо Java як мови. Тож моє запитання має 4 частини.

1. Продуктивність.

   а. Як сьогодні швидкість Java порівнюється з C ++?

   б. Чи можна було б створити сучасний заголовок AAA за допомогою Java?

   c. У яких областях Java повільніше, ніж C ++, якщо вона взагалі? (тобто розбивка чисел, графіка або просто все навколо)

2. Чи вважається Java тепер складеною мовою чи інтерпретованою мовою?

3. Які основні недоліки Java, які були усунені з перших днів?

4. Які основні недоліки Java ще не вирішено?

Редагувати:

Тільки для уточнення я не роблю цю Java проти C ++, очевидно, в середньому c ++ буде трохи швидше, ніж Java. Мені просто потрібно щось порівняти Яву з точки зору зрілості як мови на даний момент часу. Оскільки c ++ існував назавжди, я думав, що я став би хорошим пунктом порівняння.

а. Як сьогодні швидкість Java порівнюється з C ++?

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

Однак я б сказав, що Java GC повинен працювати швидко в будь-якій ситуації. Народний розподільник, однак, можна замінити на той, який є більш підходящим. Нещодавно я поставив запитання на тему SO, чому C # Dictionaryможе виконати (0,45 мс на моїй машині) порівняно з еквівалентомstd::unordered_mapякий виконується на (10 мс на моїй машині). Однак, просто замінивши розподільник і хешер на більш відповідні, я скоротив цей час виконання до 0,34 мс на моїй машині - тридцяту частину початкового часу роботи. Ви ніколи не могли сподіватися виконати таку спеціальну оптимізацію за допомогою Java. Прекрасним прикладом, де це може по-справжньому змінити, є нарізка різьби. Бібліотеки власних потоків, такі як TBB, забезпечують кешування потоків алокаторів, які значно швидше, ніж традиційні алокатори, при роботі з багатьма виділеннями на багатьох потоках.

Зараз багато людей будуть говорити про вдосконалення JIT та про те, як про JIT є більше інформації. Звичайно, це правда. Але це навіть далеко не близьке до того, що може підключити компілятор C ++ - тому що компілятор має, порівняно, нескінченний час і простір, в якому можна запустити, з точки зору часу виконання остаточної програми. Кожен цикл і кожен байт, який JIT витрачає на роздуми про те, як найкраще оптимізувати свою програму, - це цикл, який ваша програма не витрачає на виконання та не може використовувати для власних потреб в пам'яті.

Крім того, завжди знайдуться випадки, коли компіляція та JIT-оптимізація не зможуть довести певних оптимізацій, особливо у випадку таких речей, як аналіз втечі. У C ++, то в якості значення в стеку в будь-якому випадку , компілятор не повинен виконувати його. Крім того, є прості речі, як-от суцільна пам'ять. Якщо ви виділите масив на C ++, то ви виділите єдиний суміжний масив. Якщо ви виділите масив у Java, то він зовсім не суміжний, оскільки масив заповнений лише покажчиками, які могли вказувати куди завгодно. Це не тільки обсяг пам'яті та час на подвійні непрямі, але й кеш-накладні витрати. Така річ - це те, коли мовна семантика Java просто нав'язує, що вона повинна бути повільнішою, ніж еквівалентний код C ++.

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

б. Чи можна було б створити сучасний заголовок AAA за допомогою Java?

Я припускаю, що тут ви маєте на увазі "гру", а не шанс. По-перше, вам доведеться писати все з нуля, як майже всі існуючі бібліотеки та цільову інфраструктуру C ++. Хоча це не робить неможливе саме по собі, воно, безумовно, може внести вагомий внесок у нездійсненне. По-друге, навіть двигуни C ++ навряд чи можуть вписатися в крихітні обмеження пам’яті існуючих консолей - якщо JVM навіть існують для цих консолей, - а гравці ПК очікують трохи більше на їх пам’ять. Створення ефективних ігор AAA досить складно в C ++, я не бачу, як цього можна досягти в Java. Ніхто ніколи не писав гру AAA зі значним часом, проведеним мовою, що не складається. Більше того, це було б просто дуже схильне до помилок. Детерміновані знищення є важливими при роботі, наприклад, з ресурсами графічного процесора - і на Java, ви '

c. У яких областях Java повільніше, ніж C ++, якщо вона взагалі? (тобто розбивка чисел, графіка або просто все навколо)

Я б точно пішов на багатоборство. Принципово-посилальний характер усіх об'єктів Java означає, що у Java набагато більше непрямих та посилань у ній, ніж у C ++ - приклад, який я наводив раніше з масивами, але також стосується, наприклад, усіх об'єктів-членів. Якщо компілятор C ++ може шукати змінну члена за постійний час, час виконання Java повинен слідувати за іншим вказівником. Чим більше ви будете отримувати доступ, тим повільніше це станеться, і JIT нічого з цим не може зробити.

Якщо C ++ може звільнити та знову використати частину пам'яті майже миттєво, у Java вам доведеться чекати колекції, і я сподіваюся, що цей фрагмент не вийшов із кешу, і, по суті, потрібна більше пам'яті, означає менший кеш-пам'ять та ефективність підкачки. Потім подивіться на семантику таких речей, як бокс та розпакування. У Java, якщо ви хочете посилатися на інт, вам доведеться динамічно розподіляти його. Це властивий відхід порівняно з семантикою С ++.

Тоді у вас є проблема з дженериками. На Java ви можете оперувати загальними об'єктами лише завдяки успадкуванню часу виконання. У C ++ шаблони мають буквально нульові накладні витрати - щось не може відповідати Java. Це означає, що весь загальний код на Java за своєю суттю повільніше, ніж загальний еквівалент у C ++.

І тоді ви приходите до Невизначеної поведінки. Усі ненавидять його, коли їх програма виставляє UB, і всі хочуть, щоб її не існувало. Однак UB принципово дозволяє оптимізувати, які ніколи не можуть існувати на Java. Погляньте на цю публікацію, що описує оптимізацію на основі UB. Невизначення поведінки означає, що реалізація може зробити більше оптимізацій та зменшити код, необхідний для перевірки на умови, які не визначені в C ++, але визначені в Java.

Принципово семантика Java диктує, що мова йде повільніше, ніж C ++.

Чи вважається Java тепер складеною мовою чи інтерпретованою мовою?

Він насправді не вписується ні в одну з цих груп. Я б сказав, що кероване - це справді окрема категорія, хоча я б сказав, що це, безумовно, більше схожа на інтерпретовану мову, ніж на компільовану мову. Що ще важливіше, існує майже дві основні керовані системи, JVM та CLR, і коли ви говорите "керовані", це досить чітко.

Які основні недоліки Java, які були усунені з перших днів?

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

Які основні недоліки Java ще не вирішено?

Їх дженерики дуже-дуже слабкі. Загальна інформація про C # є значно сильнішою, хоча, звичайно, не є досить шаблонами. Детерміновані руйнування - ще одна значна нестача. Будь-яка форма лямбда / закриття також є головною проблемою - ви можете забути функціональний API на Java. І, звичайно, завжди є питання ефективності, для тих напрямків, які їм потрібні.

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

1а. Швидкість: швидкість, яку ви отримуєте або від C ++, або від Java, як правило, буде залежати менше від мови та її реалізації, ніж від майстерності програмістів, які її використовують. Зрештою, C ++, ймовірно, може вигравати за швидкість частіше, ніж ні, але відмінності в коді, який ви пишете, є важливим.
1б. Так, певно. У той же час, C ++ вже налагоджений, і я сумніваюся, що більшість ігрових студій бачать достатню перевагу, щоб перешкодити переходу на Java.
1с. Ретельна відповідь на це, можливо, може заповнити великий обсяг. C ++, як правило, краще з обмеженими ресурсами. Java отримує більше користі від (наприклад) наявності в наявності багато «запасної» пам’яті.
2. Повільне виконання та повільне збирання сміття, мабуть, були б двома найбільш очевидними. Бібліотека раннього вікна (AWT) була досить незграбною - Swing був серйозним покращенням.
3. Багатослівність. Відсутність перевантаження оператора. Використання збору сміття. Відсутність багаторазового успадкування. Java Generics надзвичайно обмежена порівняно з шаблонами C ++.

Слід додати, що деякі (усі?) Ці недоліки (особливо використання сміття, але й інші) багато хто сприймають як переваги Java. Єдиним можливим винятком буде його багатослівність. Ситуація на багатослів’я трохи повільно покращується, але ви, звичайно, не дуже часто бачите змагання з гольф-кодом, які виграють Java, і в звичайному коді він також використовує досить багато коду. Я підозрюю, що є щонайменше декілька, хто вважає це більш зрозумілим і зрозумілим, тому це, мабуть, може сприйматися і як перевага.

1. Щодо продуктивності;
   1. З чистою швидкістю виконання коду Java приблизно дорівнює прямому C ++. Але Java, як правило, використовує набагато більше пам’яті - частково тому, що вона базується на GC, частково тому, що її дизайн приділяє більше уваги простоті та безпеці, ніж ефективності. Через проблеми з кешем, більше пам'яті перекладається на меншу швидкість. Набагато нижче в порівнянні з високо налаштованому C ++.
   2. Якщо ви припускаєте, що заголовок AAA повинен працювати на межі можливого, використовуючи поточне обладнання, ні. Принаймні, не на стороні клієнта. Я хотів би зробити ставку на те, що в деяких заголовках AAA вже використовується Java для частин інфраструктури.
   3. Все, де ви працюєте з великими наборами даних та на C ++, можна оптимізувати для доступу до них кешований спосіб.
2. Він компілюється в байт-код і JIT-компілюється під час виконання. Складене проти Інтерпретоване - хибна, застаріла дихотомія.
3. & 4. Занадто багато речей, щоб їх перелічити, і на більшості з них буде розбіжність.

По-перше, деякий контекст, мій C ++ дуже іржавий, тому більшість мого досвіду роботи з Java стосується мого останнього досвіду роботи з C #, який у порівнянні з яблуками набагато більше порівняно.

1. Швидкість

а. Як сьогодні швидкість Java порівнюється з C ++?

Я думаю, що це найкраще відповідає на питання ТА, Чому у Java була репутація повільності? але я також вважаю, що все це розфарбовано в блозі Джеффа Етвуда, Gorilla vs. Shark . ^{Завдяки Péter & Christopher}

б. Чи можна було б створити сучасний заголовок AAA за допомогою Java?

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

Нещодавно я бачив ряд ігор, в яких згадується, що вони завантажують середовище Python, коли вони завантажуються, і я підозрюю, що коні на курси є сильною мотивацією, якщо ви хочете отримати свій титул вчасно в сезон свят (наприклад) .

c. У яких областях Java повільніше, ніж C ++, якщо вона взагалі? (тобто розбивка чисел, графіка або просто все навколо)

Ви можете писати неякісний код будь-якою мовою, але деякі мови полегшують правильний вибір, а інші, швидше за все, дозволяють собі підняти ваші власні петарди . Java потрапляє до першої категорії, C ++ однозначно потрапляє в другу.

Як вони говорять, з великою силою виникає велика відповідальність (не кажучи вже про здатність повністю викрутити кучу * 8 ').

2. Чи вважається Java тепер складеною мовою чи інтерпретованою мовою?

Я не можу сказати, що більшість людей вважає це таким, але багато людей знають різницю між складеними та інтерпретованими мовами, і не жили в печері протягом останніх 20 років, також знали б, що JIT ( Just-in -Time ) компілятор є важливою частиною екосистеми Java, тому, ймовірно, більше шансів вважатись складеною в ці дні.

3. Які основні недоліки Java вирішуються з перших днів?

Я досить недавно перетворююсь на Java, тому у мене мало контексту щодо того, як вона розвивалася. Але цікаво відзначити, що є такі книги, як Java: Гарні частини, які прагнуть спрямовувати людей у ​​напрямку тих частин мови, яким слід віддати перевагу в ці дні, і відволікати людей від тих областей, які є, або повинні бути, застарілий.

4. Які основні недоліки Java ще не вирішено?

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

Приїхавши на Java з C # і переглянувши сторінку порівняння Вікіпедії , для мене це виділяються:

Те, що мені не вистачає на Java, порівняно з C #

• Властивості , особливо автоматичні властивості. Вони значно спрощують побудову та підтримку інтерфейсів .
• Замикання / лямбда . Я дуже розчарувався, коли почув, що підтримка Java знову відштовхується . ^{Нарешті, у Java 8 є закриття / лямбда, але час, який знадобився, свідчить про мою заяву про повільне прийняття.}
• Виведення типу ( var) може здатися синтаксичним цукром, але коли у вас складні загальні типи, він може зробити код набагато зрозумілішим, видаливши безліч нікчемних дублювань.
• Часткові класи справді допомагають зберігати автоматично згенерований код (скажімо, від будівельника графічного інтерфейсу) окремо від написаного коду програміста.
• Типи значень , іноді є аргументи щодо використання легкої ваги structнад повним класом.
• Методи розширення можуть зробити системи складними, якщо надмірно використовуватися, але чудово підходять для вказівки на канонічний спосіб реалізації чогось для класу, якщо це потрібно.
• Непідписані типи , іноді цей додатковий біт може змінити значення. * 8 ')

Що я не пропускаю в Java, порівняно з C #

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

Як такий, навіть порівнюючи яблука з яблуками, вважається, що Java відстала.

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

Я можу вказати на джерело, яке може допомогти відповісти на першу частину вашого питання. Мови програмування розстрілюють http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php - досить гарне джерело, щоб побачити, наскільки швидкі мови порівнюються між собою. Вони навіть можуть бути відфільтровані за різними категоріями, щоб побачити, в яких регіонах мови працюють краще, ніж інші. Ява набагато швидша, ніж це було кілька років тому.

1) Суворо кажучи про UX, який я отримую з Java, він відчуває себе повільно. Я не можу тобі сказати, чому насправді. Я ще не стикався з настільним додатком на базі Java, який не відчуває себе повільно і має більш швидку альтернативу , що не стосується Java. При цьому, Java може бути дуже швидкою з чистою обчислювальною швидкістю, і Інтернет є повним орієнтирами, щоб довести це. Однак час завантаження додатків Java та чутливість їх графічних інтерфейсів ще мають покращити IMHO. Можливо, ти міг би це зробити;)
Зрештою, швидкість - це не стільки проблема. Мало того, що апаратне забезпечення стає все швидшим та швидшим, але й більшість людей все ще дбає про це на диво мало, доки програмне забезпечення робить, що воно повинно робити, і співвідношення витраченого часу на взаємодію з витраченим часом на очікування є розумним.

2) Ця відмінність стала настільки розмитою останнім часом, що для неї насправді мало значення.

3 + 4) Насправді в Java відбулося досить багато змін. Деякі люди вже стверджують, що ці зміни загрожували суто спрощеній філософії Java, використовуючи чужі функції. Справді важко сказати об’єктивно, що таке недолік і яка сила. Для мене Java є надмірно багатослівним, обмежувальним та бідним у можливостях, тоді як інші люди вважають ці самі риси приємною однозначністю, безпекою та чіткістю.
Тому, хоча саме ці речі змушують мене не використовувати Java, я не думаю, що просто додавання речей, які я сумую в Java, є гарною ідеєю. Є багато мов, які мені подобається бігати на JVM і нахиляти Java, щоб бути ближче до них, просто перемогло б призначення Java.

Це питання переваги

Справа в Java полягає в тому, що він розроблений, щоб запобігти вам стріляти в ногу. Благородна справа, але з усіма обмеженнями, які вона нав'язує на вас, малоймовірно, що ви подорожуєте над однією зі своїх безпечних ніг, не можете підтягнути себе, зв’язавши руки за спину задля власної безпеки і нарешті померте, бо ти ламаєш череп. : D
У чомусь Java була відповіддю на C ++, що дає вам достатню кількість мотузок, щоб не тільки повісити себе, а й увесь світ. Це все те мотузка, що робить його таким привабливим для ковбоїв. Вся ця свобода і вся ця сила.

Так просто кажучи, це справді лише питання переваги.

Але справа в тому, що C ++ як альтернатива Java, ви можете вибирати власні обмеження. Або по-справжньому зірватися з усім контролем, який ви маєте, ризикуючи зовсім заплутати своїх однолітків:

Я бачив, як "cout" зміщував "Hello world" разів ліворуч і зупинявся прямо там.
- Стів Гонедес

Саме тому Java вирішила не пропонувати оператору перевантаження. Звичайно, це заважає людям заблукати свій код шляхом множення покажчиків функцій зі списками. Але в той же час це заважає іншим проводити геометричні / алгебраїчні обчислення зі звичайними операторами. (v1 * v2 / scale) + (v3 * m)насправді набагато зрозуміліше, ніж v1.multiply(v2).divide(scale).add(v3.multiply(m)). Я бачу, чому це може відкласти людей, які займаються 3d графікою та обчисленнями.

Java вирішила накладати сміття, тоді як в C ++ ви можете вибрати. Ви дійсно можете копати весь шлях вниз і наблизитися до обладнання. Ви можете щільно запакувати дані в структури. Можна виконувати темну магію, наприклад швидкий зворотний квадратний корінь . За допомогою шаблонів ви можете виконувати деякі найскладніші та найяскравіші метапрограмування на землі. Але це також означає, що ви можете загубитися і витратити години налагоджуючи всі створені вами безладдя або переглянувши абсолютно негідні помилки компілятора.
Але якщо ви маєте дисципліну використовувати лише ті частини мови, якими ви справді володієте, ви можете писати код C ++ так само безпечно, як і код Java, але у вас є можливість поступово просуватися вперед.

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

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

Збір сміття - це велика річ. Кожен так часто GC заблокує все інше на кілька сотень мілісекунд (залежно від розміру купи) та зробить основну колекцію. Це добре, якщо у вас немає обмежень у часі, але якщо запізнення означає збій, це шоу-пробка. Ви можете витратити гроші на Java в режимі реального часу та ОС у режимі реального часу, але ви можете просто використовувати GCC та стандартний Linux, і у вас цих проблем не виникне.

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

3) Недоліки, які були виправлені.

Кілька років тому на Яву було багато гніву. Більшість Java-програмістів - це веб-серверні програмісти, і вони зійшли з розуму від багатослів’я Java. Так деякі мови, як Рубі, стали популярними, і Java почала слабшати. Однак з новими примітками та рамками, як сплячий та весняний, люди перестали скаржитися і повернулися до Яви.

4) Поточні недоліки

Апаратне забезпечення все багатоядерне. Хоча Java може робити багатопотокові, вона базується на C, яка є послідовною мовою, а функціональність для її багатопотокової не менш елегантна. До речі, це не просто критика Java, а майже всі мови. Потрібен якийсь зовсім інший спосіб мислення коду. Можливо, функціональне програмування - це шлях майбутнього.

Я начебто відреагував на це питання, оскільки він дасть оманливі та багато в чому нерелевантні відповіді:

б. Чи можна було б створити сучасний заголовок AAA за допомогою Java?

Кожен може погодитись, що назви AAA було б складно створити за допомогою Java і що я не знаю фактичних прикладів. Однак, враховуючи характер AAA, який передбачає багато речей (оскільки це дійсно заплутаний термін, що походить від маркетингу), тож краще запитати наступне:

Чи можливо створити сучасний заголовок з розумним успіхом за допомогою Java?

Відповідь " Так, можна. " Однак фактична частина рівняння успіху більшою мірою ґрунтується на вашій наполегливості та везінні (або прихильності до zeitgeist), але це виходить за межі цього сайту.

Сертифікована область швидкості зводиться до компілятора проти компілятора. Не мова проти мови. У компіляції JIT можуть бути переваги, оскільки вона може оптимізувати характеристики машин, на яких вона працює. Порівняйте компільований J + C ++ та Java для порівняння компілятора "яблука до яблук".

Але є деякі речі, де сама мова Java обмежує її власну продуктивність.

1. виділення на стек. Java не може цього зробити. Для невеликих фіксованих розмірів у нерекурсивному рішенні це часто ідеально. Ви також можете уникнути роздроблення купи.

2. не віртуальні функції. Java не може цього зробити. Усі виклики методів отримують постійне звернення навіть тоді, коли їх не планується перекривати.

Можливо, якісь інші речі, але це все, що я можу придумати вгорі голови.

1) нерелевантні та аргументовані для завантаження.
Мало того, що на Java можуть бути створені основні програми, такі системи постачаються щодня і до цих пір керують більшістю великих компаній у світі.
2) дітто.
Прочитайте специфікацію JVM і знаєте. Java ніколи не була інтерпретованою мовою.
3) дітто.
Прочитайте 15-річні нотатки до випуску. Нам неможливо розібратися, які ви вважаєте «основні вади», які потрібно усунути.
4) дітто.
Основним недоліком, з яким слід звернути увагу, є JCP, який схильний втручатися в основні мови та бібліотеки без будь-якої іншої видимої причини, ніж отримати ім'я Somoene на JSR, щоб вони могли написати книгу з авторським розмиттям, що "вони були керівник JSR-666 ». Сподіваємось, про це піде реструктуризація Оракула JCP.
Ви, здається, просто хочете розпалити тут мовну війну і підтвердити свої забобони щодо Яви іншими людьми, оскільки ви самі не можете знайти реального виправдання для неї.