Tagged: Software Deconstructionist

Dr. Deprecator Prescriptions: important things that you should know about obsolete Java API (JEP 277)

Did you ever asked yourself why Cloneable or, for example, Serializable interfaces are not deprecated?
OpenJDK team has a special man Stuart Marks who call himself as Dr. Deprecator. He is «Software Deconstructionist» and few days ago he made a great talk about API evolution and upcoming removing of some obsolete code in Java 9.
Doctor Deprecator
Thanks to Yoshio Terada for a photo.

The most important idea from presentation is that «Deprecated» code may be separated into four categories:
“Condemned” – will be removed or disabled in a future release (no moral connota, on). For example, from Java 9 already removed java.util.logging.LogManager.addPropertyChangeListener()
“Dangerous” – using this may introduce bugs or data loss. For example, String.getBytes() may loss for anything other than ASCII
“Superseded” – not dangerous, not going away, but new code should use something different. For example Vector, Date classes.
“Unimplemented” – some things unconditionally throw an exception at runtime (e.g. UnsupportedOperatioonException). This enables warnings at compile time. For example: class ImmutableList implements List, so should implement mutator methods add() and remove()

See this presentation

Yesterday was created JEP 277: Enhanced Deprecation

Discussion on Redit

What Might a New @Deprecated Look Like?

Annotation Library

RFC: #[deprecated] for Rust that was inspired by this JEP

JEP 277 “Enhanced Deprecation” is Nice. But Here’s a Much Better Alternative

Deprecation service in code

For example, Tapestry uses a special DeprecationWarning service which tracking usage of deprecated API. See usage example.
You may create something similar yourself.

In Python


Example of usage

    @deprecated_method(deprecated="1.6", removed="1.8",
    def verify(self, user, realm, password):
        """verify password for user"""
        return self.check_password(user, realm, password)