Если бы вы могли существенно изменить библиотеки путей к классам Java, какие решения вы бы приняли?

Question

Если бы у вас была возможность значительно изменить / обновить библиотеки путей к классам Java, что бы вы добавили / обновили / изменили / осудили / удалили?

Answer 1

Я бы добавил CheckedException на том же уровне, что и RuntimeException (сделайте так, чтобы людям «приходилось» ловить исключения)

Я бы удалил все устаревшие API.

Я бы удалил старые классы коллекций, такие как Vector и Dictionary.

Я бы загрузил лодку классов исключений в IOException.

Я бы заменил столько же public static final int X; константы, как я мог с перечислениями.

Answer 2

• Реструктурируйте все различные аспекты библиотеки классов, далеких от настоящего времени, до монолитных, в отдельные модули с более низкими взаимозависимостями. Это потребовало бы разделения интерфейсов и предоставления реализаций по умолчанию в отличительные иерархии классов (аналогично тому, что уже существует для SAX API). Обоснование: разрешить развертывание с урезанными библиотеками классов и дополнительно включить сторонние замены и расширения некоторых центральных аспектов (крипто, сетевые протоколы, i18n, ...).

• Переработайте все классы коллекций и некоторые классы java.lang в гораздо меньшие строительные блоки, которые можно собрать в более гибкие и более мощные структуры данных (в соответствии с философией классов Google Collections). Это предложило бы намного больше контекстно-независимых поведенческих интерфейсов, таких как CharSequence или Comparable.

• Предоставление большего количества специфичных для платформы (Extension-) API и реализаций, которые охватывают столько, сколько разумно для поддерживаемых платформ (и растут вместе с ними), и принимают, что код, использующий эти классы, не будет переносимым без дополнительных усилий от разработчика. Это предназначено для создания нетривиального программного обеспечения, способного конкурировать с нативным программным обеспечением с точки зрения удобства использования, полезности и общего воспринимаемого качества. Эти API, например, разрешают доступ к блочным устройствам, терминалам vt100, реестру Windows и т. Д.

• Перепроектируйте Swing многослойным способом (т.е. управляйте поверх базовых строительных блоков поверх API графических примитивов) и сделайте его намного более полиморфным. Т.е. единый интерфейс Action с одним методом perform вместо множества специальных интерфейсов Listener. Кроме того, я бы предложил оболочку, которая инкапсулирует нативные компоненты GUI (в духе моего предыдущего предложения).

• Попробуйте найти лучший способ справиться с ограничениями доступа, связанными с безопасностью, для сред песочницы, которые не ограничивают общую гибкость многих важных классов. В настоящее время языковые функции, изначально предназначенные для целей проектирования, сильно используются в целях безопасности, что привело к довольно статичным и неполиморфным классам и API-интерфейсам, поскольку их можно было бы открыть из песочницы, если бы они были более открытыми (и подход все еще не был достаточно безопасным много раз).

• Предоставляет менее наивную систему сериализации, которая поддерживает слабые ссылки, имеет обнаружение ошибок и поддерживает эволюцию классов.

Answer 3

Я бы избавился от Object.hashCode и вместо этого определил бы интерфейсы Hashable / Hasher.(Но я бы сохранил System.identityHashCode (Object), потому что, несмотря на его накладные расходы, он делает что-то очень полезное, что невозможно сделать любым другим способом.)

Я бы избавился от Object.equals и определил Equatable/ Экваториальные интерфейсы вместо.(Но с лучшими именами, если бы я мог управлять этим.)

Я бы избавился от Object.clone.Я мог бы сохранить его как метод для классов массивов.

Я бы избавился от Object.finalize и заменил бы его чем-то, что наивные программисты на C / C ++ не заметят, пока не приобретут достаточный опыт, чтобы знать, чтофинализация - почти всегда неправильное решение.

Я бы избавился от System.gc ();

Я бы заменил неуклюжий глобальный материал System.in/out/err чем-то, чтоиспользовались Readers / PrintWriters, и это было / могло быть легко "ограничено" потоком или группой потоков.

Я бы убрал возможность примитивной блокировки любого объекта (... ОК, не строго изменение библиотеки).

Я бы попытался выяснить, как реализовать безопасные версии thread.stop / suspend / resume ... даже если бы это означало реализацию Isolates в JVM J2SE.