От Java 1.4 до Java 6: какой-нибудь автоматизированный инструмент для обновления устаревшего кода?

Question

Наша система будет обновлена ​​до платформы, которая включает замену Java 1.4 на Java 6.

В идеале, мы хотели бы использовать автоматизированный инструмент для введения обобщений и перечислений в код везде, где это возможно, и затем, очевидно, мы рассмотрим изменения. Есть ли какой-нибудь инструмент, который вы бы порекомендовали для этого?

Answer 1

автоматизированный инструмент для внедрения дженерики и перечисления к коду везде, где это возможно

Этот вид инструмента известен как "программист". Когда он будет доступен в полностью автоматизированном виде, вы останетесь без работы (и, вероятно, проведете свои дни в качестве забавного отвлечения на ваших новых повелителей роботов).

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

Answer 2

IntelliJ IDEA предлагает вам специальный инструмент для генерирования устаревших коллекций.

Answer 3

Я не уверен, что "генерировать" старую кодовую базу обязательно будет хорошей идеей:

• Это не улучшит производительность, потому что такие же классы происходят (за кулисами), когда вы используете обобщенные типы, как когда вы используете необработанные типы с явными приведениями типов.

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

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

Answer 4

Майкл прав в том, что это не может быть сделано автоматически. Учитывая это, вы можете рассмотреть поэтапный подход, при котором вы начнете с генерации ваших API / интерфейсов (например, между подсистемами), приведя коллекции в этот момент к правильному типу. Вы также можете добавить утверждения, чтобы убедиться, что эти приведения были действительны, а затем могли быть удалены после тестирования.

Очевидно, что приведение не является идеальным, но это означает, что вы можете обновить API на ранней стадии (при условии, что это система на основе API), а затем "исправить" внутренние компоненты позже.