Java 9: ​​хорошие, плохие и приватные методы интерфейса

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

Birdman (2014) Алехандро Г. Иньярриту

Платформа

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

• JSR 376 : модульная система, известная как Jigsaw
• JEP 222 : jshell
• JEP 238 : несколько выпусков JAR
• JEP 282 : jlink
• JEP 158 : унифицированная регистрация

Платформа, очевидно, становится все более зрелой. Это хорошая тенденция.

JDK

Вторая тенденция, наблюдаемая после Java 6 , показывает, что JDK, представляющий собой набор классов и интерфейсов, разработанных, разработанных и поддерживаемых Oracle , расширяется с каждым новым выпуском. В Java 9 они добавили и расширили, помимо прочего, следующее:

• JEP 221 , 224 225 , 261 : обработка Javadoc (расширенная)
• JEP 268 : каталоги XML (новый)
• JEP 262 : ввод / вывод изображения TIFF (новый)
• JEP 251 : изображения с несколькими разрешениями (новый)
• JEP 110 : клиент HTTP 2.0 (новый)
• JEP 236 : парсер для Nashorn (расширенный)

Конечно, некоторые функции должны быть реализованы в самом JDK, например поддержка Unicode ( JEP 267 ), специфичные для платформы функции рабочего стола ( JEP 272 ), подсказки Spin-Wait ( JEP 285 ), компактные строки ( JEP 254 ) и API процесса. ( JEP 102 ). Их реализация зависит от базовой платформы и должна предоставляться вместе с JVM.

Но что делает клиент HTTP 2.0 в JDK вместе с JAX-RS , JPA , JAX-WS , JDBC и многими другими вещами, которые, на мой взгляд, должны находиться как можно дальше от Oracle? Они не привязаны к конкретной платформе и могут быть гораздо лучше спроектированы сообществом открытого кода как независимые пакеты. Я считаю, что объединять их под одной торговой маркой-монстром — ошибка.

Я думаю, что крупные корпорации только убивают рынок программного обеспечения, а не делают его лучше из-за финансовых и политических мотивов, которым они подвергают его. Это именно то, что происходит с JDK. Благодаря монополии Oracle ей не хватает гибкости и динамичности роста. Другими словами, мы застряли на том, что Oracle и его большие друзья считают правильным .

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

Язык

Java была разработана Джеймсом Гослингом в Sun Microsystems в 1995 году как объектно-ориентированный язык. Было много опасений по поводу этого утверждения об объектной ориентации, и я также не уверен, что Java — это больше ОО, чем процедурный. Однако это официально объектно-ориентированный.

Было много процедурных функций, унаследованных Java от C / C ++, начиная с его первой версии, включая статические методы , NULL , наследование реализации и т. Д. Это не был идеальный объектно-ориентированный язык, и он, как я понимаю, не будет Это. Ключевой идеей было создать что-то, что можно было бы написать один раз и запустить где угодно . Однако язык также имел большое значение, а не только JVM. Это было просто и сексуально.

В 2004 году Java 5 сделала серьезный шаг вперед и улучшила язык, добавив обобщенные элементы , цикл for-each, varargs и статический импорт. Однако были введены аннотации и перечисления, которые помогли языку перейти от объектной парадигмы к чему-то совершенно другому и процедурному.

Java 7 добавила try-with-resource в 2011 году, что было хорошим шагом в соответствии с парадигмой ООП.

Java 2014 добавила лямбда-выражения в 2014 году, что было отличной возможностью, но абсолютно не имеет отношения к ООП. Lambda и Streams API превратили Java в сочетание объектной, процедурной и функциональной парадигм. Методы по умолчанию также были добавлены к интерфейсам, которые превратили типы в библиотеки кода. Типы в библиотеки! Это даже хуже, чем наследование реализации , если вы спросите меня.

Теперь Java 9 сделала следующее «улучшение» интерфейсов, позволив им иметь приватные методы. Частные статические методы в типах! Ты можешь в это поверить? Каким будет следующий шаг? Атрибуты, в Java 10, я думаю.

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

Фабричные методы для коллекций ( JEP 269 ). Вместо того, чтобы вводить новые конструкторы и позволять нам делать это:

… В Java 9 они создали больше статических методов и заставили нас сделать это:

«Меньше конструкторов, больше статических методов!» Кажется, это философия тех, кто представил этот JEP. Излишне говорить, что это полностью противоречит самому духу объектно-ориентированного программирования. Объекты должны создаваться конструкторами, а не статическими методами, независимо от того, что говорит Джошуа Блох. Статические методы делают момент new использования оператора невидимым для нас, и поэтому код менее удобен для сопровождения — мы просто не знаем точно, какой класс создан, и каковы реальные аргументы его ctor.

Кстати, с Cactoos вы можете сделать это правильно:

Это ООП.

Новые методы в InputStream . В уже перегруженный класс InputStream были добавлены три новых метода: readNBytes() , readAllBytes() и readAllBytes() . Теперь мы должны сделать это, когда мы хотим, чтобы входной поток скопировал в выходной поток:

Это одна из самых типичных ошибок, которые делают молодые программисты ООП: они делают свои интерфейсы большими. Просто потому, что им нужно больше функциональности. Я думаю, что принцип разделения интерфейса является частью знаменитого SOLID и ему уже много лет. Что с тобой, Оракул? Каким будет следующий шаг? В Java 10 у нас также будут saveToFile() и printToConsole() ? Как насчет emailToAFriend() ?

Вот как вы можете сделать то же самое с IOUtils утилит IOUtils из commons-io :

Это не идеально , но лучше. Наиболее объектно-ориентированным способом является использование объектов, а не служебных классов и статических методов. Вот как это работает в Cactoos :

Это ООП.

На мой взгляд, Java становится все хуже , и это тенденция. Значит ли это, что пора уходить? Нет! Неважно, насколько ты уродлив, мы всегда будем любить тебя, Java!

Вы также можете найти эти посты интересными: каждый частный статический метод является кандидатом в новый класс ; Гибкость означает низкое качество ; Почему дизайн InputStream неправильный ; Наследование — это процедурный метод повторного использования кода ; Временная связь между вызовами методов ;