2008-09-19 3 views
7

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

ответ

22

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

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

+0

Я согласен, и типы, основанные на дженериках, только улучшают его. – 2008-09-19 17:32:45

2

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

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

1

java.util очень Util. Зачем?

  • Коллекции. Многие из них!
  • Дата и время классы
  • Text сканер
  • Dependency Injection утилита (с Java 6)
  • таймер резьбы
  • случайных чисел
  • Паттерн Наблюдатель есть
  • Java свойства
+0

Не могли бы вы подробно остановиться на «Инъекции зависимостей», пожалуйста? – OscarRyz 2009-01-05 23:30:57

+0

API Date оставляет желать лучшего ... В следующий раз, когда мне нужно работать с датами, я предполагаю, что буду использовать Joda Time. – 2009-01-06 02:25:16

3

javax.naming

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

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

10

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

4

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

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

1

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

1

java.util.regex

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

3

Отражение. Некоторые из них находятся в java.lang.reflect, а некоторые - в java.lang (в основном Class и ClassLoader).

1

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

3

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

1

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

9

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

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

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

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

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

0

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

2

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