Какая Ваша любимая область Java API?

Question

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

Answer 1

Мой любимый Java API - это Структура коллекций.Я ловлю себя на том, что постоянно использую его вместо того, чтобы внедрять свои собственные реализации, и это очень приятно и просто в использовании.Он состоит из нескольких полезных и взаимозаменяемых реализаций высокопроизводительных структур данных и алгоритмов, а также нескольких удобных методов для обертывания вокруг них дополнительной функциональности.

Учебное пособие Джоша Блоха можно найти здесь: http://java.sun.com/docs/books/tutorial/collections/index.html

Answer 2

Моя любимая часть API, безусловно, java.lang.У него есть такой класс, который называется String, который позволяет вам легко манипулировать массивами символов.Любой программист, серьезно относящийся к написанию хорошего Java-кода, должен проверить это.

Answer 3

java.util.параллельный это имеет решающее значение для моей жизни.Мы занимаемся довольно большим количеством многоядерного программирования, и идея попытаться реализовать все наши задачи с использованием старых необработанных потоков просто вызывает у меня дурноту.

Хорошим примером того, где пакет параллелизма действительно облегчает нашу жизнь, является пул специализированных структур данных, которые он предоставляет.Мое личное любимое блюдо - это CopyOnWriteArrayList Список объектов копирования.Мы довольно часто используем его в ситуациях, когда задача отображения считывает данные из кэша для обновления экрана, в то время как другая задача берет информацию из сети для обновления кэша.Обычно это было бы приглашением к столкновениям, Исключения ConcurrentModificationExceptions и тому подобные ужасы.Используя CopyOnWriteArrayList, задача записи создаст новую копию данных, если ей потребуется добавить данные, тем самым гарантируя, что у читателя всегда будет действительный (хотя и потенциально устаревший) набор данных для отображения.

Как говорит javadoc,

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

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

Answer 4

Определенно, Фреймворк Коллекций.Он используется постоянно, независимо от того, используете ли вы Java на стороне сервера или клиента, графический или нет.Он прост в использовании.Большинство классов структуры данных имеют как непатентованную, так и универсальную версию (лучше всего использовать вторую, но есть устаревший код, который в значительной степени использует первую), но они в значительной степени идентичны с точки зрения API, отличного от параметров класса.В .NET две версии могут иметь разные имена / API, и это может привести к большой путанице.Мне также нравится, как платформа Java Collections использует алгоритмы в виде статических методов (напримерCollections.sort(collectionVar)), а не как методы экземпляра.В .NET они используют методы экземпляра, и по какой-то причине не каждая структура данных имеет вид ... Структура коллекций также очень богата, и вы можете найти как простые, так и специализированные структуры данных (напримерLinkedHashMap, который сохраняет порядок вставки).

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

Answer 5

javax.именование

http://java.sun.com/javase/6/docs/api/javax/naming/package-summary.html

Java - отличная технология системной интеграции из-за своей переносимости, а JNDI хорошо справляется с абстрагированием от сложностей первого контакта с удаленной системой.

Answer 6

Размышление.Кое-что из этого есть в java.lang.отражать и некоторые в java.lang (в основном Class и ClassLoader).

Answer 7

Стримы.Потоки в Java намного проще понять и реализовать, чем их аналоги в C ++ (мнение), и обычно легко увидеть, основываясь на именах потоков, которые поставляются с API, что поток собирается сделать для вас.

Answer 8

Я большой поклонник JPA в Java EE.Это сократило объем работы, которую мне нужно выполнить как для больших приложений (которые использовали бы EJBS), так и для небольших приложений.

Вторым близким является JAAS, API безопасности, вот ссылка для Java SE JAAS : http://java.sun.com/javase/technologies/security/

Answer 9

Пока что пакет API java.util.regex является моим любимым, потому что он избавил меня от необходимости изобретать велосипед во многих случаях, когда дело доходит до поиска и использования фрагментов строк для различных целей.

Answer 10

java.util очень удобен.Почему?

• Коллекции.Их много!
• Классы даты и времени
• Сканер текста
• Утилита внедрения зависимостей (начиная с Java 6)
• Поток таймера
• Случайные числа
• Паттерн наблюдателя налицо
• Свойства Java

Answer 11

java.util.jar - Помогает с загрузкой файлов .jar в загрузчик классов для плагинов моего приложения!Мне это нравится.

Answer 12

java.util.регулярное выражение

Есть и другие пакеты, без которых я не могу жить, но пакет регулярных выражений должен быть на верхнем уровне "величайших дополнений к java" - определенно на одном уровне с коллекциями.

Answer 13

я согласен с комментарием "Отражение".безусловно, это самая полезная / мощная часть Java API

Answer 14

Вспоминая мои дни работы на Java, самым интересным API для использования был java.util.параллельный, просто потому, что он предоставляет хорошо продуманные и простые в использовании строительные блоки для параллельной обработки.

Answer 15

InheritableThreadLocal всю дорогу !!!Просто так много возможностей написать запутанный код, а моток веревки, чтобы повеситься, кажется, никогда не иссякнет.