Comments 50
Дождались!
Всегда лень было качать для этого апачевскую библиотеку или копировать их код
Ого, неужели, глядишь, лет через восемь и перегрузку операторов добавят?
Статья вышла бы больше, если бы вы, например, рассказали разницу между strip() и уже существующим trim().
А вообще ничего страшного, в Java 12 String просто взорвётся новыми методами. Это так, пробный камень.
А вообще ничего страшного, в Java 12 String просто взорвётся новыми методами. Это так, пробный камень.
Это чем же он там взорвётся?
Пока что шесть новых методов ищется:
- align, indent — JDK-8200434
- unescape — JDK-8202442
- detab, entab — JDK-8210717
- transform — JDK-8203442
Согласен про strip — тоже не увидел разницу между trim. Вот нагуглил: stackoverflow.com/questions/51266582/difference-between-string-trim-and-strip-methods-in-java-11
Вкрадце — trim плохо работает с Unicode, воспринимает как пробельные символы только символы с кодом ≤20, но на самом делел в Unicode их много. Поэтому добавили Unicode версию trim — strip.
Хотя на мой взгляд очень спорное решение — почему просто trim не исправили?!
Вкрадце — trim плохо работает с Unicode, воспринимает как пробельные символы только символы с кодом ≤20, но на самом делел в Unicode их много. Поэтому добавили Unicode версию trim — strip.
Хотя на мой взгляд очень спорное решение — почему просто trim не исправили?!
почему просто trim не исправили?!
Вы что, хипстер? Миллиард существующих программ сломается. Java — не тот язык, где можно вот так просто взять и исправить.
Спасибо, добавил. Отличия действительно есть.
вот тоже стало интересно зачем стрип, если есть трим.
UPD уже не актуально
UPD уже не актуально
Вообще да, в Java маловато встроенных возможностей по манипуляции со строками. Одобряю.
Про разные реализации для Latin-1 и юникодовских строк нет смысла писать, не упомянув Compact Strings.
А они, кстати, новинка для тех, кто переходит с Java 8.
Можно дурацкий вопрос — почему после Java 8 (или 9, что там было?) вышла сразу версия 11?
Тогда почему когда я искал последнюю версию Java, чтобы установить (JRE), на сайте самой свежей значилась версия 9? Это было примерно в январе-феврале текущего года. И то там при этом номер апдейта был так мал, что создавалось ощущение, что она только-только вышла.
А сами как думаете?
Не знаю. На сайт заходил с Win 7 x64, не думаю, что там стоит автодетект версии ОС.
Только не надо говорить, что между версиями 9 и 10 прошло меньше года: версия 7 вышла ближе к осени 2011-ого, а версия 8 — в районе начала 2014-ого. 6-ая же вообще чуть ли не в начале 2006-ого появилась на свет. Промежутки должны по идее быть хотя бы примерно равными :)
Только не надо говорить, что между версиями 9 и 10 прошло меньше года: версия 7 вышла ближе к осени 2011-ого, а версия 8 — в районе начала 2014-ого. 6-ая же вообще чуть ли не в начале 2006-ого появилась на свет. Промежутки должны по идее быть хотя бы примерно равными :)
Так и есть — «хром покусал», версии теперь будут менять кажется раз в пол-года.
Ого. Интересно
JRE более выпускать не будут
Раз, два.
Вот это просто рукалицо. Они правда думают, что теперь работать станет проще? Я про всю эту возню с JLink. Как по мне, старый подход хоть и требовал ради красоты оборачивать программу в exe-шник, но во-первых, для этой цели были сторонние продукты с GUI, и даже бесплатные; новый же требует ввода команд в консоль, и на выходе получается… батник (с кучей файлов .class рядом). Офигеть, блин.
За всех не скажу, но лично я никакими сторонними (мы ведь IDE не считаем, ведь так?) тулами с GUI для этого никогда не пользовался — maven «наше все»… обвешался плагинами для компиляции и сборки, отконфигурировал и собрал бандл эм, ну вы поняли (надо меньше возиться с npm).
Удобно или нет — покажет время.
Ну и таки да — у нас перед глазами есть IntelliJ IDEA, PhpStrom и т.д., они без установленного jre спокойно работают (на сколько я знаю).
Удобно или нет — покажет время.
Ну и таки да — у нас перед глазами есть IntelliJ IDEA, PhpStrom и т.д., они без установленного jre спокойно работают (на сколько я знаю).
Ну может они с собой его тянули, я без понятия.
Я не настолько опытный Java разработчик. Рассказываю свой кейс (как я пишу код где-то начиная со 2 курса для своих проектов):
Сначала веду разработку в NetBeans. Картинки в проект как ресурсы обычно не импортирую: сначала не знал как, потом узнал, но решил, что и не особо надо. Мой код загружает их из подкаталога.
В коде есть две специальных функции: первая получает путь установки программы, вторая — путь к папке с картинками. Программа может быть установлена куда угодно, но есть два требования: имя последней папки с exe файлом не должно быть изменено, имя папки с картинками внутри неё тоже не должно быть изменено (мало ли кто ручками изменит).
При этом код написан так, что пути определяются корректно и при запуске jar файла, лежащего в подкаталоге dist, и при запуске exe файла, лежащего на уровень выше.
Плюс я обычно включаю в дистрибутив папку src с исходниками, ибо не жалко.
Обёртку над jar делаю с помощью exe4J, чтобы включить иконку, информацию о версии и авторе, и прочее.
Потом генерирую сторонним софтом инсталлятор, копирующий файлы программы в выбранный пользователем каталог и создающий ярлыки. В последнее время предпочитаю Smart Install Maker (раньше использовал Wise Installation Studio 9, но там всё очень криво, если пользователь удаляет программу вручную из системы, программу из списка установленных потом практически не убрать, если нет под рукой оригинального инсталлятора нужной версии моего продукта).
Теперь, я так понимаю, мне придётся делать обёртку над bat скриптом, а заодно тащить с собой часть JDK, которая хоть и немного, но тоже что-то весит. Нафига так было делать — большой вопрос.
Я не настолько опытный Java разработчик. Рассказываю свой кейс (как я пишу код где-то начиная со 2 курса для своих проектов):
Сначала веду разработку в NetBeans. Картинки в проект как ресурсы обычно не импортирую: сначала не знал как, потом узнал, но решил, что и не особо надо. Мой код загружает их из подкаталога.
В коде есть две специальных функции: первая получает путь установки программы, вторая — путь к папке с картинками. Программа может быть установлена куда угодно, но есть два требования: имя последней папки с exe файлом не должно быть изменено, имя папки с картинками внутри неё тоже не должно быть изменено (мало ли кто ручками изменит).
При этом код написан так, что пути определяются корректно и при запуске jar файла, лежащего в подкаталоге dist, и при запуске exe файла, лежащего на уровень выше.
Плюс я обычно включаю в дистрибутив папку src с исходниками, ибо не жалко.
Обёртку над jar делаю с помощью exe4J, чтобы включить иконку, информацию о версии и авторе, и прочее.
Потом генерирую сторонним софтом инсталлятор, копирующий файлы программы в выбранный пользователем каталог и создающий ярлыки. В последнее время предпочитаю Smart Install Maker (раньше использовал Wise Installation Studio 9, но там всё очень криво, если пользователь удаляет программу вручную из системы, программу из списка установленных потом практически не убрать, если нет под рукой оригинального инсталлятора нужной версии моего продукта).
Теперь, я так понимаю, мне придётся делать обёртку над bat скриптом, а заодно тащить с собой часть JDK, которая хоть и немного, но тоже что-то весит. Нафига так было делать — большой вопрос.
Метод возвращает результат запроса, содержит ли данная строка какие-то символы, кроме пробелов.
То есть, если мы исполним такой код:
String blank = " ";
Boolean isBlank = blank.isBlank();
Результат будет:
true
возможно я чего-то не понимаю, но покажите мне где в этом примере содержится символ кроме пробела
«Внутри самого метода существует две реализации — для латинских символов и для строки в кодировке UTF-16.»
Эта UTF-16 где-нибудь реально используется, или такой же труп, как 1251?
Эта UTF-16 где-нибудь реально используется, или такой же труп, как 1251?
Судя по тому, что я слышал, это как раз кодировка будущего, но я могу ошибаться.
Это кодировка темного идиотского прошлого.
Никакой совместимости с ASCII. Для программиста она — абсолютный вынос мозга. Как Вы будете программы на UTF-16 писать? Все программы пишутся в 8-и байтной ASCII. Не поэтому ли в виндах до сих пор остается такое говно мамонта, как cp1251, которая совместима с ASCII по первой половине?
Попробуйте распарсить utf-8 и utf-16 в k&r си, чтобы это все работало как на be, так и на le, а потом сравните, что у вас вышло. Хотя из под фреймворков, написанных с использованием фреймворков, написанных с использованием фреймворков, ..., и прочих земляных червяков это незаметно:-)
Да, utf-16 не поддерживает кодовых точек выше 10FFFF, причем с выпадением геморроя, если выше базовой плоскости (0000-FFFF), в отличие от utf-8, которая на регулярной основе поддерживает до FFFFFFFF.
Никакой совместимости с ASCII. Для программиста она — абсолютный вынос мозга. Как Вы будете программы на UTF-16 писать? Все программы пишутся в 8-и байтной ASCII. Не поэтому ли в виндах до сих пор остается такое говно мамонта, как cp1251, которая совместима с ASCII по первой половине?
Попробуйте распарсить utf-8 и utf-16 в k&r си, чтобы это все работало как на be, так и на le, а потом сравните, что у вас вышло. Хотя из под фреймворков, написанных с использованием фреймворков, написанных с использованием фреймворков, ..., и прочих земляных червяков это незаметно:-)
Да, utf-16 не поддерживает кодовых точек выше 10FFFF, причем с выпадением геморроя, если выше базовой плоскости (0000-FFFF), в отличие от utf-8, которая на регулярной основе поддерживает до FFFFFFFF.
Когда Java сама себя начнет собирать из исходников, написанных на utf-16, не прибегая к услугам ASCII-софта, тогда и поговорим.
Так она вроде собирается с помощью G++, не? Не очень понимаю, как это относится к теме. Я сам поддерживаю UTF-8, да и не только я, вот сайт хороший есть о ней. Но что поделаешь, в джаве UTF-16, придётся жить с этим.
Насчет String.lines. Не лучше ли было бы сделать метод String.splitAsStream?
Согласен.
А смысл?
Ведь уже есть Pattern::splitAsStream().
Именно там я и подсмотрел название. Почему тогда не сделать Pattern::lines?
Почему у String есть метод split, а splitToLines, который бы возвращал массив — нет? Да потому что это очень конкретный случай. Плюс руки пока ни у кого не отвалились передать 4 символа
Например, нужно разбить длинную строку с разделителем ',' и всё это в стримом получить (ленивость и экономия памяти желательны, как и лаконичность кода). Если посмотрите JDK-8200425, в котором String::lines обсуждали, то там и показано как многословно всё это получается. Только вот решение было сделано для одного конкретного случая. Мне это не понятно.
Почему у String есть метод split, а splitToLines, который бы возвращал массив — нет? Да потому что это очень конкретный случай. Плюс руки пока ни у кого не отвалились передать 4 символа
`\n`, ну или `\R` как аргумент String::split. Никто же не добавляет Math::pow2 чтоб в квадрат возводить. Пальцем у виска покрутят, если такое предложить.Например, нужно разбить длинную строку с разделителем ',' и всё это в стримом получить (ленивость и экономия памяти желательны, как и лаконичность кода). Если посмотрите JDK-8200425, в котором String::lines обсуждали, то там и показано как многословно всё это получается. Только вот решение было сделано для одного конкретного случая. Мне это не понятно.
А новая функция strip() символы '\u00A0', '\u2007', '\u202F' определяет как пробелы?
Спрашиваю потому, что сталкивался с такой проблемой: старые реализации Character.isWhitespace данные символы пробелами не считали, хотя по факту это пробелы.
Спрашиваю потому, что сталкивался с такой проблемой: старые реализации Character.isWhitespace данные символы пробелами не считали, хотя по факту это пробелы.
В Java когда нибудь появиться строковые шаблоны?
Sign up to leave a comment.
Java 11: новое в String