Руководство по Java 9 для тех, кому приходится работать с legacy-кодом

https://techbeacon.com/legacy-developers-guide-java-9
  • Перевод
Добрый вечер, коллеги. Ровно месяц назад мы получили контракт на перевод книги "Modern Java" от издательства Manning, которая должна стать одной из наших самых заметных новинок в будущем году. Проблема «Modern» и «Legacy» в Java настолько остра, что необходимость такой книги довольно назрела. Масштабы бедствия и способы решения возникающих проблем в Java 9 кратко описаны в статье Уэйна Ситрина (Wayne Citrin), перевод которой мы и хотим вам сегодня предложить.

Раз в несколько лет, с выходом новой версии Java, докладчики на JavaOne начинают смаковать новые языковые конструкции и API, хвалить их достоинства. А ретивым разработчикам тем временем не терпится внедрить новые возможности. Такая картина далека от реальности – она совершенно не учитывает, что большинство программистов заняты поддержкой и доработкой уже существующих приложений, а не пишут новые приложения с нуля.

Большинство приложений – в особенности коммерческие — должны быть обратно совместимы с более ранними версиями Java, в которых не поддерживаются все эти новые супер-пупер возможности. Наконец, большинство заказчиков и конечных пользователей, особенно в сегменте больших предприятий, настороженно относятся к радикальному обновлению Java-платформы, предпочитая выждать, пока она окрепнет.

Поэтому, как только разработчик собирается попробовать новую возможность, он сталкивается с проблемами. Вы бы стали использовать у себя в коде методы интерфейсов по умолчанию? Возможно – если вы счастливчик, и вашему приложению не требуется взаимодействовать с Java 7 или ниже. Хотите использовать класс java.util.concurrent.ThreadLocalRandom для генерации псевдослучайных чисел в многопоточном приложении? Не выйдет, если ваше приложение должно работать одновременно на Java 6, 7, 8 или 9.

С выходом нового релиза разработчики, занятые поддержкой унаследованного кода, чувствуют себя как дети, вынужденные таращиться на витрину кондитерского магазина. Внутрь их не пускают, поэтому их удел — разочарование и фрустрация.

Итак, есть ли в новом релизе Java 9 что-нибудь для программистов, занятых поддержкой унаследованного кода? Что-то, способное облегчить им жизнь? К счастью — да.

Что приходилось делать при поддержке legacy-кода то появления Java 9

Конечно, можно впихнуть возможности новой платформы в унаследованные приложения, в которых нужно соблюдать обратную совместимость. В частности, всегда есть возможности воспользоваться преимуществами новых API. Однако, может получиться немного некрасиво.

Например, можно применить позднее связывание, если вы хотите получить доступ к новому API, когда вашему приложению также требуется работать со старыми версиями Java, не поддерживающими этот API. Допустим, вам требуется использовать класс java.util.stream.LongStream, появившийся в Java 8, и вы хотите применить метод anyMatch(LongPredicate) этого класса, но приложение должно быть совместимо с Java 7. Можно создать вспомогательный класс, вот так:

public classLongStreamHelper {
     private static Class longStreamClass;
     private static Class longPredicateClass;
     private static Method anyMatchMethod;

     static {
          try {
               longStreamClass = Class.forName("java.util.stream.LongStream");
               longPredicateClass = Class.forName("java.util.function.LongPredicate");
               anyMatchMethod = longStreamClass.getMethod("anyMatch", longPredicateClass):
          } catch (ClassNotFoundException e) {
               longStreamClass = null;
               longPredicateClass = null;
               anyMatchMethod = null
          } catch (NoSuchMethodException e) {
               longStreamClass = null;
               longPredicateClass = null;
               anyMatchMethod = null;
          }

          public static boolean anyMatch(Object theLongStream, Object thePredicate) 
               throws NotImplementedException {
               if (longStreamClass == null) throw new NotImplementedException();

               try {
                    Boolean result 
                         = (Boolean) anyMatchMethod.invoke(theLongStream, thePredicate);
                    return result.booleanValue();
               } catch (Throwable e) { // lots of potential exceptions to handle. Let’s simplify.
                     throw new NotImplementedException();
               }
          }
     }

Есть способы упростить эту операцию, либо сделать ее более общей, либо более эффективной – идею вы уловили.

Вместо того, чтобы вызывать theLongStream.anyMatch(thePredicate), как вы поступили бы в Java 8, можно вызвать LongStreamHelper.anyMatch(theLongStream, thePredicate) в любой версии Java. Если вы имеете дело с Java 8 – это сработает, но, если с Java 7 – то программа выбросит исключение NotImplementedException.

Почему это некрасиво? Потому что код может чрезмерно усложниться, если требуется обращаться ко множеству API (на самом деле, даже сейчас, с единственным API, это уже неудобно). Кроме того, такая практика и не типобезопасна, поскольку в коде нельзя прямо упомянуть LongStream или LongPredicate. Наконец, такая практика гораздо менее эффективна, из-за издержек, связанных с рефлексией, а также из-за дополнительных блоков try-catch. Следовательно, хотя и можно так сделать, это не слишком интересно, и чревато ошибками по невнимательности.

Да, вы можете обращаться к новым API, а ваш код при этом сохраняет обратную совместимость, но с новыми языковыми конструкциями вам это не удастся. Например, допустим, что нам нужно использовать лямбда-выражения в коде, который должен оставаться обратно-совместимым и работать в Java 7. Вам не повезло. Компилятор Java не позволит указать версию исходного кода выше целевой. Так, если задать уровень соответствия исходного кода 1.8 (т.е., Java 8), а целевой уровень соответствия будет 1.7 (Java 7), то компилятор вам этого не позволит.

Вам помогут разноверсионные JAR-файлы

Сравнительно недавно появилась еще одна отличная возможность использовать новейшие возможности Java, позволяя при этом приложениям работать со старыми версиями Java, где такие приложения не поддерживались. В Java 9 такая возможность предоставляется как для новых API, так и для новых языковых конструкций Java: речь о разноверисонных JAR-файлах.

Разноверсионные JAR-файлы почти не отличаются от старых добрых JAR-файлов, но с одной важнейшей оговоркой: в новых JAR-файлах появилась своеобразная «ниша», куда можно записывать классы, использующие новейшие возможности Java 9. Если вы работаете с Java 9, то JVM найдет эту «нишу», станет использовать классы из нее и игнорировать одноименные классы из основной части JAR-файла.

Однако, при работе с Java 8 или ниже, JVM неизвестно о существовании этой «ниши». Она игнорирует ее и использует классы из основной части JAR-файла. С выходом Java 10 появится новая аналогичная «ниша» для классов, использующих наиболее актуальные возможности Java 10 и так далее.

В JEP 238 – предложении на доработку Java, где описаны ращновенсионные JAR-файлы, приводится простой пример. Допустим, у нас есть JAR-файл с четырьмя классами, работающими в Java 8 или ниже:

JAR root

      - A.class
      - B.class
      - C.class
      - D.class

Теперь представим, что после выхода Java 9 мы переписываем классы A и B, чтобы они могли использовать новые возможности, специфичные для Java 9. Затем выходит Java 10, и мы вновь переписываем класс A, чтобы он мог использовать новые возможности Java 10. При этом, приложение по-прежнему должно нормально работать с Java 8. Новый разноверсионный JAR-файл выглядит так:

JAR root
      - A.class
      - B.class
      - C.class
      - D.class
      - META-INF

           Versions

                - 9
                   - A.class
                   - B.class

               - 10
                   - A.class

JAR-файл не только приобрел новую структуру; теперь в его манифесте указано, что этот файл разноверсионный.

Когда вы запускаете этот JAR-файл на Java 8 JVM, он игнорирует раздел \META-INF\Versions, поскольку даже не подозревает о нем и не ищет его. Используются лишь оригинальные классы A, B, C и D.

При запуске под Java 9, используются классы, находящиеся в \META-INF\Versions\9, причем, они используются вместо оригинальных классов A и B, но классы в \META-INF\Versions\10 игнорируются.

При запуске под Java 10 используются обе ветки \META-INF\Versions; в частности, версия A от Java 10, версия B от Java 9 и используемые по умолчанию версии C и D.

Итак, если в вашем приложении вам нужен новый ProcessBuilder API из Java 9, но нужно обеспечить, чтобы приложение продолжало работать и под Java 8, просто запишите в раздел \META-INF\Versions\9 JAR-файла новые версии ваших классов, использующие ProcessBuilder, а старые классы оставьте в основной части архива, используемой по умолчанию. Именно так проще всего использовать новые возможности Java 9, не жертвуя при этом обратной совместимостью.

В Java 9 JDK есть версия инструмента jar.exe, поддерживающая создание разноверсионных JAR-файлов. Такую поддержку также обеспечивают и другие инструменты, не входящие в JDK.

Java 9: модули, повсюду модули

Система модулей Java 9, (также известная под названием Project Jigsaw) – это, несомненно, крупнейшее изменение в Java 9. Одна из целей модуляризации — усилить действующий в Java механизм инкапсуляции, чтобы разработчик мог указывать, какие API предоставляются другим компонентам и мог рассчитывать, что JVM будет навязывать инкапсуляцию. При модуляризации инкапсуляция получается сильнее, чем при применении модификаторов доступа public/protected/private у классов или членов классов.

Вторая цель модуляризации – указать, каким модулям необходимы для работы другие модули и еще до запуска приложения заблаговременно убедиться, что все необходимые модули на месте. В таком смысле модули сильнее традиционного механизма classpath, поскольку пути classpath заблаговременно не проверяются, и возможны ошибки из-за отсутствия необходимых классов. Таким образом, некорректный classpath может быть обнаружен уже тогда, когда приложение успеет проработать достаточно долго, либо после того, как оно будет много раз запущено.
Вся система модулей большая и сложная, и ее подробное обсуждение выходит за рамки этой статьи (Вот хорошее, подробное объяснение). Здесь я уделю внимание именно тем аспектам модуляризации, которые помогают разработчику при поддержке унаследованных приложений.

Модуляризация – хорошая штука, и разработчик должен стараться разбивать новый код на модули, когда это только возможно, даже если остаток приложения (пока) не модуляризован. К счастью, это легко сделать благодаря спецификации о работе с модулями.

Во-первых, JAR-файл становится модуляризован (и превращается в модуль) с появлением в нем файла module-info.class (скомпилированного из module-info.java) у корня файла JAR. module-info.java содержит метаданные, в частности, название модуля, пакеты которого экспортируются (т.e., становятся видны извне), каких модулей требует данный модуль и некоторая иная информация.

Информация в module-info.class видна лишь в случаях, когда JVM ищет ее – то есть, система трактует модуляризованные JAR-файлы точно как обычные, если работает со старыми версиями Java (предполагается, что код был скомпилирован для работы с более старой версией Java. Строго говоря, требуется немного похимичить, и все равно указывать в качестве целевой версии module-info.class именно Java 9, но это реально).

Таким образом, у вас должна остаться возможность запускать модуляризованные JAR-файлы с Java 8 и ниже при условии, что в иных отношениях они также совместимы с более ранними версиями Java. Также отметим, что файлы module-info.class можно, с оговорками, помещать в версионируемых областях разноверсионных JAR-файлов.

В Java 9 существует как classpath, так и путь к модулю. and a module path. Classpath работает как обычно. Если поставить модуляризованный JAR-файл в classpath, он тратуется как любой другой JAR-файл. То есть, если вы модуляризовали JAR-файл, а ваше приложение еще не готово обращаться с ним как с модулем, его можно поставить в classpath, он будет работать как всегда. Ваш унаследованный код должен вполне успешно с ним справиться.

Также отметим, что коллекция всех JAR-файлов в classpath считается частью единственного безымянного модуля. Такой модуль считается самым обычным, однако, всю информацию он экспортирует другим модулям, и может обращаться к любым другим модулям. Таким образом, если у вас еще нет модуляризованного Java-приложения, но есть некие старые библиотеки, которые тоже пока не модуляризованы (и, вероятно, никогда не будут) – можно просто положить все эти библиотеки в classpath, и вся система будет нормально работать.

В Java 9 есть путь к модулям, работающий наряду с classpath. При использовании модулей из этого пути JVM может проверять (как во время компиляции, так и во время выполнения), все ли необходимые модули на месте, и сообщать об ошибке, если каких-то модулей не хватает. Все JAR-файлы в classpath, как члены безымянного модуля, доступны модулям, перечисленным в модульном пути – и наоборот.

Не составляет труда перенести JAR-файл из classpath в путь модулей – и пользоваться всеми преимуществами модуляризации. Во-первых, можно добавить файл module-info.class в файл JAR, а затем поставить модуляризованный JAR-файл в путь модулей. Такой новоиспеченный модуль все равно сможет обращаться ко всем оставшимся JAR-файлам в classpath JAR, поскольку они входят в безымянный модуль и остаются в доступе.

Также возможно, что вы не хотите модуляризовать JAR-файл, либо, что JAR-файл принадлежит не вам, а кому-то еще, так что модуляризовать его сами вы не можете. В таком случае JAR-файл все равно можно поставить в путь модулей, он станет автоматическим модулем.

Автоматический модуль считается модулем, даже если в нем нет файла module-info.class. Этот модуль одноименен тому JAR-файлу, в котором содержится, и другие модули могут явно затребовать его. Он автоматически экспортирует все свои публично доступные API и читает (то есть, требует) все прочие именованные модули, а также безымянные модули.

Таким образом, немодуляризованный JAR-файл из classpath можно превратить в модуль, вообще ничего для этого не делая. Унаследованные JAR-файлы автоматически превращаются в модули, просто в них не хватает некоторй информации, которая позволяла бы определить, все ли нужные модули на месте, либо определить, чего не хватает.

Не каждый немодуляризованный JAR-файл можно переместить в путь модулей и превратить его в автоматический модуль. Существует правило: пакет может входить в состав всего одного именованного модуля. То есть, если пакет находится более чем в одном JAR-файле, то всего один JAR-файл с этим пакетом в составе можно превратить в автоматический модуль. Остальные могут остаться в classpath и войти в состав безымянного модуля.

На первый взгляд, описанный здесь механизм кажется сложным, но на практике он весьма прост. На самом деле, речь в данном случае лишь о том, что можно оставить старые JAR-файлы в classpath или переместить их в путь модулей. Можно разбить их на модули или не делать этого. А когда ваши старые JAR-файлы будут модуляризованы, можно оставить их в classpath или переместить в путь модулей.

В большинстве случаев все должно попросту работать, как и раньше. Ваши унаследованные JAR-файлы должны прижиться в новой модульной системе. Чем больше вы модуляризуете код, тем больше информации о зависимостях требуется проверять, а недостающие модули и API будут обнаруживаться на гораздо более ранних этапах разработки и, возможно, избавят вас от больших кусков работы.

Java 9 «делает сама»: Модульный JDK и Jlink

Одна из проблем с унаследованными Java-приложениями заключается в том, что конечный пользователь может не работать с подходящей средой Java. Один из способов гарантировать работоспособность Java-приложения – предоставить среду выполнения вместе с приложением. Java позволяет создавать приватные (многократно распространяемые) JRE, которые можно распространять в пределах приложения. Здесь рассказано, как создать приватную JRE. Как правило, берется иерархия файлов JRE, устанавливаемая вместе с JDK, нужные файлы сохраняются, а также сохраняются опциональные файлы с тем функционалом, который может понадобиться в вашем приложении.

Процесс немного хлопотный: необходимо поддерживать иерархию установочных файлов, быть при этом внимательным, поэтому вы не пропускаете ни одного файла, ни одного каталога. Само по себе это не повредит, однако, все-таки хочется избавиться от всего лишнего, поскольку эти файлы занимают место. Да, легко поддаться и совершить такую ошибку.

Так что почему бы не перепоручить эту работу JDK?

В Java 9 можно создать самодостаточную среду, добавляемую к приложению – и в этой среде будет все необходимое для работы приложения. Больше не придется волноваться, что на пользовательском компьютере окажется не та среда для выполнения Java, не придется беспокоиться о том, что вы сами неправильно собрали приватную JRE.

Ключевой ресурс для создания таких самодостаточных исполняемых образов – это модульная система. Модуляризовать теперь можно не только собственный код, но и сам Java 9 JDK. Теперь библиотека классов Java – это коллекция модулей, из модулей же состоят и инструменты JDK. Система модулей требует указывать модули базовых классов, которые необходимы в вашем коде, и при этом вы указываете необходимые элементы JDK.

Чтобы собрать все это вместе, в Java 9 предусмотрен специальный новый инструмент под названием jlink. Запустив jlink, вы получаете иерархию файлов – именно тех, что нужны для запуска вашего приложения, ни больше, ни меньше. Такой набор будет гораздо меньше стандартной JRE, причем, он будет платформо-специфичным (то есть, подбираться для конкретной операционной системы и машины). Поэтому, если вы захотите создать такие исполняемые образы для других платформ, потребуется запустить jlink в контексте установки на каждой конкретной платформе, для которой вам нужен такой образ.

Также обратите внимание: если запустить jlink с приложением, в котором ничего не модуляризовано, у инструмента просто не будет нужной информации, позволяющей ужать JRE, поэтому jlink ничего не останется, кроме как упаковать целую JRE. Даже в таком случае вам будет немного удобнее: jlink сам упакует для вас JRE, поэтому можете не волноваться о том, как правильно скопировать файловую иерархию.

С jlink становится легко упаковать приложение и все, что необходимо для его запуска – и можете не волноваться, что сделаете что-нибудь неправильно. Инструмент упакует только ту часть среды исполнения, которая требуется для работы приложения. То есть, унаследованное Java-приложение гарантированно получит такую среду, в которой оно окажется работоспособным.

Встреча старого и нового

Одна из проблем, возникающих при поддержке унаследованного Java-приложения заключается в том, что вы оказываетесь лишены всех плюшек, появляющихся при выходе новой версии. В Java 9, как и в предшествующих версиях, появилась целая куча великолепных новых API и языковых возможностей, но разработчики (наученные горьким опытом) могут предположить, что попросту не смогут ими воспользоваться, не нарушив обратной совместимости с более ранними версиями Java.

Следует отдать должное проектировщикам Java 9: по-видимому, они это учли и хорошо поработали, чтобы предоставить эти новые возможности и тем разработчикам, которым приходится поддерживать старые версии Java.

Разноверсионные JAR-файлы позволяют разработчикам применять новые возможности Java 9 и выносить их в отдельную часть JAR-файла, где более ранние версии Java их не заметят. Таким образом, разработчику легко писать код для Java 9, оставить старый код для Java 8 и ниже и предоставить среде исполнения выбор – какие классы она сможет запустить.

Благодаря модулям Java, разработчику проще проверять зависимости, достаточно писать все новые JAR-файлы в модульном виде, а старый код оставлять немодуляризованным. Система очень щадящая, она ориентирована на постепенную миграцию и практически всегда поддерживает работу с унаследованным кодом, который «слыхом не слыхивал» о модульной системе.

Благодаря модульному JDK и jlink, можно с легкостью создавать исполняемые образы и гарантированно обеспечивать приложение такой средой исполнения, в которой будет все необходимое для работы. Ранее такой процесс был чреват множеством ошибок, но современный инструментарий Java позволяет его автоматизировать – и все просто работает.

В отличие от предыдущих релизов Java, в Java 9 вы можете свободно пользоваться всеми новыми возможностями, а если имеете дело со старым приложением и должны гарантировать его поддержку – то сможете удовлетворить потребности всех ваших пользователей, независимо от того, горят ли они желанием обновляться до самой актуальной версии Java.

Издательский дом «Питер»

197,83

Компания

Поделиться публикацией
Комментарии 30
    0
    >Благодаря модульному JDK и jlink, можно с легкостью создавать исполняемые образы и гарантированно обеспечивать приложение такой средой исполнения, в которой будет все необходимое для работы. Ранее такой процесс был чреват множеством ошибок, но современный инструментарий Java позволяет его автоматизировать – и все просто работает.

    Ага, ага. Наверное поэтому выход Java 9 впервые за много лет поломал даже такие сравнительно простые вещи, как maven или gradle. Которые до этого почти не зависели от версии JDK, а просто работали. И многие разработчики откровенно побаиваются переходить на Java 9, которая во-первых, устарела еще до того, как на нее обновились (да-да, EOL даже не на носу, а уже наступил), а во-вторых, именно потому, что слишком многое поломали, а при этом обещанные преимущества почему-то далеко не очевидны.
      –3
      Мне кажется, что именно из-за страха совместимости oracle и убила java, синтаксис которой отстает на десятилетия. Лично мне безразлична совместимость, если бы её потеря ознаменовалась тем фурором, который java произвела в 95. Но увы, мне кажется, что java даже это не поможет, так как его сейчас только android держит, который лет через пять прекратит свое существование. если бы пятнадцать лет назад я его рекомендовал, то сегодня бы даже не подумал бы об этом. Изучение его сегодня только усугубит-замедлит развитие программиста, а сама разработка превратить увлекательное дело в кошмар.
        +1
        так как его сейчас только android держит, который лет через пять прекратит свое существование.
        Откуда инфа? О том, что андроид должен «в тыкву» превратится?

        Или это переиначивание популярного лозунга 90х «Windows Must Die!»… который как-то не привёл вот прям к смерти Windows через 5 лет?

        P.S. О корпоративных системах я вообще молчу, там сейчас даже Cobol востребован… иначе никто бы вещи типа Cobol 2014 не выпускал…
          0
          Где-то читал, что google создает новую ОС Fuchsia, которая, к тому же заменит ещё и Android. Плюс oracle судится с google из-за технологий, что, как мне кажется, в свете недавних событий свзанных с модой судится с google, будет его только мотивировать.
            0
            В этой ОС уже работают обычные Android приложения и она в первую очередь пойдет на замену Chrome OS. Для разработчиков останется надолго Anroid Studio, Java language, Java API, Gradle, а то, что внутри мало кто видит.
              0
              Что значит «уже работают»? Вы же понимаете что это сделано для более мягкой замены одного на другое и после этой самой замены исчезнет в никуда? И это Вы думаете что в первую очередь на замену, а в google не такие простачки, как мы с Вами. Неуже ли Выдумаете, что В их планах нет пункта конкуренции с macos и windows? Неужели Вы думаете что они не видят успеха ОС windows 10, которая ставится, как на desctop, так и mobile?

              Если они реально сделают это ОС, то сразу же можно забыть о android. Нет android, зачем java? Вы бы стали без android советовать своему младшему брату учить java?

              И да, студия и все остальное останется, Вы наверное слишком «в лоб» интерпретируете слово «смерть», так как после замены android, все так и будет продолжаться. Все кроме одного — советовать учить java уже не будут. Хотя я уже не вижу в ней смысла, тем более, если это первый язык.
                0
                Неужели Вы думаете что они не видят успеха ОС windows 10, которая ставится, как на desctop, так и mobile?
                Ммм…
                2008й год: Windows Mobile владеет 12% рынка, десятки партнёров среди производителей и операторов, MS Office для мобильников существует только под неё
                2018й год: разработка Windows 10 Mobile свёрнута, все партнёры от Microsoft отказались, Microsoft Andromeda существует где-то на выставках, но никому особо не интересна
                Вы этот успех имеете в виду? Угробить компанию — да, не удалось, только парнёра (Nokia), но в остальном, да, это успешное разрушение всего, что у Microsoft было…

                Если они реально сделают это ОС, то сразу же можно забыть о android.
                Нет, если Баллмер укусит Ларри и тот сделать такую чушь, то можно будет забыть о Google. Android как раз выживет, хотя да, LG и Samsung могут по-первости наломать дров.

                Все кроме одного — советовать учить java уже не будут.
                Посмотрим. Хочу только напомнить, что Fuchsia — это уже не первая попытка. До этого была ставка на web-технологии и ChromeOS. ChromeOS осталась, да, а вот Web-технологии «замели под коврик» и сейчас там самые популярные приложения — от Android'а.
                  0
                  Вот это я лохонулся :) Не знал что windows 10 mobile свернута… Но суть не в этом, а в том что единая система, это будущие, так же как и кросплатформенные приложения.
                    0
                    Никому не дано предсказать будущее. Но одно можно сказать точно: отказ от Android-приложений — добром не кончится.
                      0
                      Это скорее единая экосистема, ибо кодовая база разная у всех версий Windows (десктопная, RT, Mobile, IoT, CE).
                      По-настоящему кроссплатформенной была Ubuntu Touch. Но что-то тоже не взлетела.
                        0
                        Нет, там как раз была попытка сделать одну кодовую базу для всего. И даже вроде как получилось. Вот только одна беда: это заняло столько времени, что оно оказалось никому не нужным.

                        С Ubuntu Touch произошла те же история, по большому счёту.

                        Судьба рынка смартфонов решалась примерно в 2008-2010м годах. И тогда у всех разработчиков было «на руках» только лишь что-то сырое и маловразумительное.

                        Но те, кто с тем, что было вышел на рынок и обеспечил поддержку на новых моделях (Apple и Google) выжили, а те, кто решил, что можно заставить разработчиков всё переписать с нуля 2-3-4 раза (Maemo/Meego/Tizen, Microsoft, etc) — нет.
                          0
                          Не было у них таких попыток. Их идея была в предоставлении универсального прикладного API, что раньше выглядело как WinRT, а сейчас — UWP.
                          У них это получилось настолько, что с упоминанием «UWP» гуглится аж целых 4 вакансии по Москве.
                            0
                            Не было у них таких попыток.
                            Как это не было? Вы уж врите, но не завирайтесь.

                            В Windows Phone 8используется новая архитектура Windows NT, которая используется в настольных операционных системах Microsoft. Из-за смены ядра устройства под управлением Windows Phone 7.x, построенной на ядре Windows CE, не могут обновиться до Windows Phone 8.

                            А дальше, уже в Windows 10 — да, UWP. После того, как все эти Windows CE и Windows RT с другой кодобазой отошли в мир иной.

                            У них это получилось настолько, что с упоминанием «UWP» гуглится аж целых 4 вакансии по Москве.
                            А вот это как раз и является следствием того, что смысла в них никакого: Windows на смартфонах умерла, а на десктопе есть полно других технологий, гораздо более популярных.
                +1
                Где-то читал, что google создает новую ОС Fuchsia, которая, к тому же заменит ещё и Android.
                Создаёт. Но тут та же история, что и у Microsoft'а: вначале была создана тяп-ляп игрушка, а потом всё, начиная с ядра, переписали.

                Плюс oracle судится с google из-за технологий, что, как мне кажется, в свете недавних событий свзанных с модой судится с google, будет его только мотивировать.
                Мотивировать — может быть, отказаться от Java — вряд ли. Microsoft тоже от Win32 пытался отказаться, как от тяжкого наследия прошлого: .NET, Avalon, всё такое.

                В конечном итоге пришлось «сдаться» и продолжить развивать то, к чему люди привыкли.

                Так что независимо от того, чем кончится история с Fuchsia, одно можно сказать точно: Android приложения и через 5 и через 10 лет в тыкву не превратятся.

                Смерть «классической» Windows мало кто и заметил…
              0
              Простите… рекомендовал андроид 15 лет назад? 18-15=03. Андроид вышел в 2008. И не думаю, что в ни в 2008, ни 2009 и т.п. вы бы его не рекомендовали(наверно до версии 2.3), ибо это был ад.
                0
                Прошу прощения что внес путаницу. Я имел ввиду java.
                0
                oracle убила java? Я что-то пропустил? Или похоже вы что-то пропустили. Неужели еще встречаются люди, которые не слышали слово Hadoop?
                  +1
                  Уже 18 лет слушаю истории о том, что Java умирает.
                  image
                    0
                    Ага. Особенно в контексте андроида хорошо зашло. Который, на мой взгляд, наоборот показал, что на java (хоть изначально и в виде странного далвика) можно сделать огромную экосистему, и написать кучу прикладного софта. Причем у Sun для desktop-ов это как раз и не получилось в такой же степени.

                    Удивительно, как можно видеть и читать одно и тоже, а выводы делать совершенно противоположные.
                      0
                      Сейчас ещё активизировались те, кто пророчат смерть Java в свете появления Kotlin (:
                        0
                        Ну это такое. Всё равно что пророчить смерть C в свете появления C++. Да, какое-то количество разработчиков переберётся, но они — часть той же экосистемы.
                      0
                      Пока жив хоть один проект на java, то java будет жив. Я не говорю что он уже умер, я говорю что он в скором времени умрет, привел аргументы, а во втором посте привел подтверждения. Но это обычные предположения, возможно, которые и не воплотятся в реальность. И к тому же, давайте быть реалистами. Если подобные события через несколько лет действительно будут иметь место, то это не будет означать, что в тот же день империя oracle развалится по кирпичику. Есть люди, которые до сих пор пишут на Smalltalk и не понимают о какой смерти идет речь. Смерть языка, это когда его перестают учить, а не писать на нем.
                        +2
                        Вы думаете, что java живёт одним андроидом? Энтерпрайза ещё больше, и если отвалится андроид, java этого не заметит
                          0
                          >Смерть языка, это когда его перестают учить, а не писать на нем.

                          Не, ну вот например, java 6 — это где-то 2009 год, то есть почти 10 лет назад. И при этом можно найти кучу совсем не мелких проектов, которые все еще рассчитаны на работу под этой версией. То есть, на сегодня даже Java 6 не умерла совсем — хотя если вы скажете, что это не полноценная жизнь потому что нет развития, я думаю все согласятся.

                          >Если подобные события

                          Вы про какие? Отказ от андроида? Так вы поймите простую вещь — нельзя заменить андроид, и при этом забыть про множество приложений для него. Не будет совместимости — никто такую ОС не купит.
                  0
                  я как бекенд-разработчик вупор не вижу пользы от модульности жавы на бекенде, 9ая жава не принесла почти ничего ногово, только кучу геморроя с модулями
                    0
                    Аналогично. Это никогда не было востребовано в моем окружении. Если спросить нормального человека, чего он реально хочет для уменьшения сложности, он вероятно скажет — хочу чтобы установка выглядела как одна команда «поставить из репозитория». Как это и делается с Open JDK. Но на это oracle вероятно не пойдет. А модули эти для сервер сайда — одни лишние ненужные телодвижения.

                    >не принесла почти ничего ногово
                    Ну, это тоже преувеличение. Я бы не против попробовать graal, например.
                    0
                    Модульность это продолжение одной из самых крутых фич JVM — jar-ников. Нужна доп. либа? Скачал, закинул в classpath, и пользуешься. Теперь пришло время управлять видимостью и на этом уровне — API показываем, реализацию — нет, например. Плюс, как видно из развивающегося AOT направления и очевидного удобства сборки приложений в одну исполняемую единицу (как в go), JVM также идет к этой цели, и модульность играет в этом не малую роль. Для обычного ынтырпрайз польза как минимум в двух вещах: 1) выявление конфликтов зависимостей на этапе сборки; 2) как уже было выше, возможность поставки true standalone-приложений, даже без Java на целевой машине. Просто к этому надо привыкнуть, т.к. по сути именно тех возможностей, что дает модульность нет, пожалуй, ни у одной экосистемы разработки.
                      0
                      > 1) выявление конфликтов зависимостей на этапе сборки;

                      А оно нам нужно? Не, в смысле не само по себе, а скажем OSGI его выявляет на этапе деплоя в контейнер, то есть на самом позднем — и это более чем адекватно. А чтобы выявить на этапе сборки — нужно на этапе сборки знать все эти зависимости, а это далеко не так просто, потому что вы далеко не всегда контролируете работающее приложение.

                      >2) как уже было выше, возможность поставки true standalone-приложений, даже без Java на целевой машине.

                      Не, это конечно неплохо — но только далеко не везде нужно и тем более не везде важно.

                      Вот скажем IDEA поставляется вместе с Java внутри, а скажем Eclipse без — и что, кого-то это волнует? Уж поверьте, это будет последнее, что я лично стану оценивать, выбирая между двумя равноценными приложениями.

                      Ну и потом — true standalone-приложения это далеко не весь спектр приложений вообще. Например, тот же андроид или enterprize — две очень большие разницы, и при этом ни там, ни там эта фича на сегодня без надобности.
                      0

                      с java 9 и её обязательной модульностью… да, с одной стороны, полностью standalone приложения весят меньше за счет выкидывания неиспользуемой библиотеки, с другой… а с другой — множество таких приложений весят больше за счет дублирования зависимостей.


                      плюс поломалось все то, что работало под 8-… плюс, пишем либо под 8, либо под 9… плюс необходимость дполнительно описывать модуль и линковать...


                      нет, это не совсем то, что нужно. нужен менеджер репозиториев типа maven на уровне инсталляшек, вот как во всех линухах все эти rpm, apt,yast… чтобы все необходимые jar,dll,rpm или что-то--там--неважно--что загружалось и ставилось автоматически при установке софта, при этом по возможности разделяя между собой совместно используемые библиотеки, в идеале — реально загружая только diff/patch.

                        –2

                        и, раз уж в комментариях упомянули maven, то позвольте оффтоп: ну почему сборка maven намного быстрее сборки gradle? волею судеб будучи вынужден работать за слабым и немного умирающим компом, пришлось (хочется верить, что временно) отказаться от gradle в пользу maven именно из-за скорости, а еще и потому, что gradle-демон отжирает оперативку даже когда не нужен. в итоге даже один тяжелый gradle-проект не смог собраться на таком увечном железе, наглухо подвесив всю ОСь...

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое