Summary
Umbrella issue to inventory the deprecated API surface still shipped by Storm, and to remove what is already marked for removal.
At 3.0.1-SNAPSHOT the codebase carries 92 @Deprecated annotations, 10 of which declare forRemoval = true. Seven of those were flagged since = "2.0.0" and have therefore survived a full major boundary, so the removal window they announced has already passed. Deprecated-but-alive code keeps dead configuration keys discoverable, forces callers to guess which of two paths is current, and quietly grows the surface every release.
Current forRemoval sites
| Location |
since |
storm-client/.../Config.java:138, :1619, :1650 |
2.0.0 |
storm-client/.../cluster/IStormClusterState.java:156, :184, :191, :198, :205 |
2.0.0 |
storm-client/.../security/serialization/BlowfishTupleSerializer.java:37 |
2.8.6 |
storm-server/.../DaemonConfig.java:287 |
3.1.0 |
Scope
- Inventory — enumerate every
@Deprecated element, recording module, since, declared replacement, and whether it is public API.
- Classify — for each entry, one of: remove now, keep and set
forRemoval with a target version, or undeprecate because it is still the supported path.
- Remove — drop the entries whose window has closed, together with their tests, documentation, and default configuration entries.
- Document — record every removal in the release notes and the upgrade guide.
Guidelines
- Removal of public API lands only on a major version; anything else is deferred, not silently kept.
- Every surviving
@Deprecated element carries both since and a forRemoval decision, and names its replacement in Javadoc.
- One sub-task per module or coherent group, each independently reviewable and revertable.
- Configuration keys are removed from
defaults.yaml and validation in the same change that removes the constant.
Sub-tasks
Sub-tasks will be filed as separate issues and linked here.
Summary
Umbrella issue to inventory the deprecated API surface still shipped by Storm, and to remove what is already marked for removal.
At
3.0.1-SNAPSHOTthe codebase carries 92@Deprecatedannotations, 10 of which declareforRemoval = true. Seven of those were flaggedsince = "2.0.0"and have therefore survived a full major boundary, so the removal window they announced has already passed. Deprecated-but-alive code keeps dead configuration keys discoverable, forces callers to guess which of two paths is current, and quietly grows the surface every release.Current
forRemovalsitessincestorm-client/.../Config.java:138,:1619,:1650storm-client/.../cluster/IStormClusterState.java:156,:184,:191,:198,:205storm-client/.../security/serialization/BlowfishTupleSerializer.java:37storm-server/.../DaemonConfig.java:287Scope
@Deprecatedelement, recording module,since, declared replacement, and whether it is public API.forRemovalwith a target version, or undeprecate because it is still the supported path.Guidelines
@Deprecatedelement carries bothsinceand aforRemovaldecision, and names its replacement in Javadoc.defaults.yamland validation in the same change that removes the constant.Sub-tasks
storm-client—Configkeysstorm-client—IStormClusterStatemethodsstorm-client—BlowfishTupleSerializerstorm-server—DaemonConfigkeys@Deprecatedelements without aforRemovaldecisionSub-tasks will be filed as separate issues and linked here.