История изменений

Очень просто: сейчас все приложения используют Spring. Мы просто добавляем делаем метод контейнера delete и вызываем его на всех @Autowired переменных, когда в цепочке закончится последний под-метод проаннатированный как @UnmanagedResources (аннотация будет работать аналогично @Transactional, скоуп ресурсу допустим можно будет указывать опцией - закрываться сразу после первого же @UnmanagedResources-метода или после последнего метода в цепочке)

У него уже есть вполне детерминированный «тройной конструктор» (1 - конструктор класса в Java, 2 - init-method в XML, 3 - аннотация @PostConstruct в Java). Он уже может удалять бины со скопом singleton с помощью DefaultListableBeanFactory.destroySingleton и .removeBeanDefinition (и создавать их назад через .registerSingleton). @PreDestroy срабатывает детерминированно в момент исключения бина из контейнера.

Вопрос, что делать с бинами со скопом prototype (аналогом обычных переменных) - либо сделать для них кастомную обработку @PreDestroy, либо симулировать «особые прототипы» поверх синглтонов с автогенерящимися именами (но тогда придется подшаманить в @Autowired чтобы оно связывало не только непосредственно по имени, но и искало имя+автогенернный_префикс, либо в виртуальной таблице переменных).

При этом и @PostConstruct, и @PreDestroy - это часть стандарта JSR-250, поэтому метафора понятна примерно всем.

Короче, проблем нет никаких. Но и смысла тоже не видно никакого :)

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

Очень просто: сейчас все приложения используют Spring. Мы просто добавляем делаем метод контейнера delete и вызываем его на всех @Autowired переменных, когда в цепочке закончится последний под-метод проаннатированный как @UnmanagedResources (аннотация будет работать аналогично @Transactional, скоуп ресурсу допустим можно будет указывать опцией - закрываться сразу после первого же @UnmanagedResources-метода или после последнего метода в цепочке)

У него уже есть вполне детерминированный «тройной конструктор» (1 - конструктор класса в Java, 2 - init-method в XML, 3 - аннотация @PostConstruct в Java). Он уже может удалять бины со скопом singleton с помощью DefaultListableBeanFactory.destroySingleton и .removeBeanDefinition (и создавать их назад через .registerSingleton). @PreDestroy срабатывает детерминированно в момент исключения бина из контейнера.

Вопрос, что делать с бинами со скопом prototype (аналогом обычных переменных) - либо сделать для них кастомную обработку @PreDestroy, либо симулировать «особые прототипы» поверх синглтонов с автогенерящимися именами (но тогда придется подшаманить в @Autowired чтобы оно связывало не только непосредственно по имени, но и искало имя+автогенернный_префикс, либо в виртуальной таблице переменных).

При этом и @PostConstruct, и @PreDestroy - это часть стандарта JSR-250, поэтому метафора понятна примерно всем.

Короче, проблем нет никаких. Но и смысла тоже не видно никакого :)