По данным голландской исследовательской компании Tiobe с точки зрения общей популярности, Java занимала 5-е место в 1997 году, 1-е в 2007 году и 2-е в сентябре 2012 года. На момент написания этой статьи на Amazon на английском языке было написано более 2000 книг по программированию и почти 300 000 потоков Stackoverflow, связанный с Java. Однако, как однажды сказал Джордж Оруэлл: «Тот, кто побеждает в данный момент, всегда будет казаться непобедимым». Но непобедима ли Java или начинает умирать? Это вопрос, который задают все больше и больше сейчас.
По моему скромному мнению, проблемы Java можно разделить на три категории:
- Подъем альтернативных языков
- Масштабируемость / многоядерные процессоры
- Возвращение толстого клиента.
Давайте уточним …
Подъем альтернативных языков
Альтернативные языки можно разделить на две группы: те, которые работают на JVM (Scala, Groovy и т. Д.) И те, которые не работают (Python, Ruby). Интересно, что первая группа довольно большая . Языки, которые работают на JVM, не являются взаимоисключающими для Java и в некотором смысле усиливают ее, напоминая нам о том, что JVM представляет собой замечательный кусок разработки программного обеспечения. Команды разработчиков могут получить дополнительную выразительность в нишевом языке, таком как Groovy, но могут по-прежнему обращаться к Java, когда им нужна какая-то классная библиотека Java или просто требуется дополнительная производительность. Помните, что преимущества Groovy 2.0 ускоряют его, но он все еще не так быстр, как Java .
Что касается функций, предоставляемых некоторыми из этих языков, которых нет в Java, то это так, но это не всегда так. Посмотрите на дорожную карту для Java 8 и функции, которые она будет включать. Так же, как Java EE 5 и 6 взяли идеи из Spring / Seam, язык Java в своем 8-м основном выпуске будет брать идеи из других языков. Например, функции Lambdas будут облегчать буквальные функции. Java 8 Lamdas будет иметь поддержку для вывода типов, и, поскольку они являются просто литералами, можно будет передавать их (и возвращать) точно так же, как литерал String или любой анонимный объект.
Это означает, что вместо написания реализации Comparator для передачи в утилиту сортировки Collections для сортировки списка строк, в Java 8 мы просто сделаем:
|
1
|
Collections.sort(list, (s1, s2) -> s1.length() - s2.length()); |
Таким образом, альтернативные языки JVM точно не выбивают Java из игры. Это все еще там, но на вечеринке с лучшим выбором музыки и на вечеринке, где гости побуждают своих хозяев быть лучшими.
Масштабирование на многоядерных платформах
Что касается многоядерности и JVM — мы все знаем, что с JVM, работающим на одном ядре, можно было создавать потоки в самом первом выпуске Java. Но эти потоки не выполнялись параллельно, процессор переключался между ними очень быстро, чтобы создать впечатление, что они работают параллельно. JStack может сказать вам, что 50 потоков имеют состояние «работоспособно» на вашем одноядерном компьютере, но это просто означает, что они либо запущены, либо имеют право на запуск. С многоядерными процессорами можно получить истинный параллелизм. JVM решает, когда выполнять потоки параллельно.
Так в чем здесь дело? Во-первых, несмотря на то, что параллелизм и потоки были особенностью Java с самого начала, языковая поддержка была ограничена, то есть команды разработчиков писали много собственного кода для управления потоками, что могло очень быстро стать ужасным. Это значительно облегчилось в JDK 1.5 благодаря появлению ряда функций управления потоками в пакете java.util.concurrent . Во-вторых, чтобы добиться лучшего параллелизма, нужно было что-то еще. Это произошло в Java 7 с платформой Fork / Join Дуга Ли, в которой используются умные методы, такие как кража работы и двусторонние очереди, для повышения параллелизма. Тем не менее, даже с этой платформой разложение (и реорганизация) данных по-прежнему является задачей, которая должна быть выполнена программистом.
Функциональное программирование дает нам еще одну возможность выполнять вычисления на наборах данных параллельно.
Например, в Scala вы просто передаете функцию, с которой хотите работать, и сообщаете scala, что вы хотите, чтобы вычисление распараллеливалось.
|
1
|
outputAnswer((1 to 5).par.foreach(i => longComputation)) |
И угадай что? То же самое будет доступно в Java 8.
|
1
|
Array.asList(1,2,3,4,5).parallel().foreach(int i ->heavyComputation()) |
Поскольку масштабируемость и производительность являются архитектурными родственниками, стоит отметить, что во многих экспериментах Java по-прежнему работает на других языках. Отличная игра Computer Language Benchmark показывает, что Java превосходит многие языки. Он забивает Perl, PHP, Python3, Erlang во многих тестах, опережает Clojure, C # почти во всех тестах и уступает только C ++ по показателям производительности. Теперь тесты производительности не могут охватить все, и контекст всегда будет иметь некоторую предвзятость, которая благоприятствует одному языку по сравнению с другим, но, исходя из этих тестов, Java не является медленным тренером.
Возвращение толстого клиента
С момента появления AJAX Дуг Крокфорд рассказывал людям, как использовать JavaScript, и с появлением превосходного выбора библиотек JavaScript, толстый клиент действительно вернулся. Закройте глаза и представьте, как бы выглядело и выглядело классное одностраничное веб-приложение, такое как gmail, если бы оно было просто тонким клиентским веб-фреймворком на основе Spring MVC, JSF или Struts — вы просто не можете превзойти производительность хорошо спроектированного толстого клиента.
Одно из преимуществ в том, что JavaScript намного сложнее быть хорошим, чем думают некоторые. Чтобы по-настоящему понять замыкания, модули и различные лучшие практики JavaScript, нужно гораздо больше думать, чем разбираться в веб-среде, такой как Spring MVC и Struts. Кроме того, создание одностраничного веб-приложения (опять же, такого как gmail) не только требует отличного понимания JavaScript, но и понимания того, как работает веб. Например, браузеры не помещают запросы Ajax в историю браузера. Таким образом, вы должны сделать что-то умное с идентификаторами фрагментов, если вы хотите, чтобы кнопки «назад» и «вперед» были полезными и значимыми для пользователя.
Здесь, вероятно, есть место для гибридного подхода, который использует как веб-фреймворк, так и JavaScript и, конечно, некоторые библиотеки JavaScript. Это дает разработчикам структуру для создания приложения, а затем возможность использовать JavaScript, JQuery или любую другую классную библиотеку, подходящую для важных частей приложения, которые необходимо изобразить. В подходе настоящего толстого веб-клиента не должно быть никакого HTML-запроса с сервера (что означает отсутствие JSP), единственное, что возвращается с сервера, это данные (в форме JSON). Однако, используя гибридный подход, вы можете упростить переход от тонкого к толстому, и вы все равно можете поместить свои библиотеки JavaScript в CDN, вы просто не сможете воспользоваться всеми преимуществами полноценного веб-клиентского подхода.
Резюме
Таким образом, у Java были некоторые плохие моменты. AWT был спешной работой, у Swing были проблемы с производительностью, ранние итерации EJB были громоздкими, а JSF проблематичным по сравнению с другими фреймворками, такими как Struts и Spring MVC. Но даже сегодня чрезвычайно инновационные проекты, такие как Hadoop, создаются с использованием Java. Он по-прежнему пользуется огромной поддержкой со стороны сообщества открытого кода. Эта поддержка не только помогла Java, но и продемонстрировала Java некоторые ее проблемы и вещи, в которых она нуждается, чтобы стать лучше. Java показала, что она способна развиваться дальше, и хотя другие языки бросают ей вызов, я не думаю, что игра еще не закончена. Само собой разумеется, многое из будущего Java будет зависеть от Oracle, но будем надеяться, что в любом случае победителем станет технология.
Ссылки по теме
- Yammer и их миграция в скалу
- Джеймс Гослинг рассказывает о состоянии и будущем Java на техническом выступлении Google
- Статья от Oracle, описывающая Fork и Join в Java 7
- Эрик Бруно: Создание многоядерных приложений Java
- Эдгардо Эрнандес: Параллельная обработка в Java
- IEEE десятка языков программирования
- JDK 8 загрузок
- Статья Java Code Geeks о Fork Join
- Good Fork Присоединяйтесь к статье Эдварда Харнеда
- Fork / Join бумага от Дуга Ли
- Fork / Join Java обновляет информацию от Дуга Ли
- Scala Java Myths — отличная статья Урса Питера и Сандера ван дер Берга
Ссылка: Java мертва или непобедима? от нашего партнера JCG Алекса Стейвли в блоге Techlin в Дублине .