1. 注解是否会从接口或父类继承？ #

这个得分场景讨论，不能一概而论：

• 类级别注解：如果注解本身标注了@Inherited元注解，子类会继承父类的该注解，但要注意——接口的类级别注解不会被实现类继承，@Inherited只作用于类与类之间的继承关系，不支持接口到实现类的注解传递。
• 方法/字段级别注解：不管有没有@Inherited，子类重写父类方法、或是实现接口方法时，都不会继承父类/接口方法上的注解。Java原生规范里，方法、字段这类成员的注解是没有默认继承逻辑的，哪怕给方法注解加了@Inherited也无效。

2. 针对Somethingable接口的具体问题 #

先看你给出的代码：

interface Somethingable {
    @Foo
    void doSomething();
}

实现类的doSomething()是否会继承@Foo？ #

答案是不会。因为@Foo是方法级别的注解，而且即便@Foo标注了@Inherited，该元注解也只对类注解生效，方法注解的继承在Java原生规则里是不被支持的，接口方法的注解自然也不会传递给实现类的对应方法。

是否需要重新编写该注解？ #

如果你的业务逻辑要求实现类的doSomething()方法也拥有@Foo注解，那必须手动在实现类的方法上重新添加@Foo——Java原生没有自动继承方法注解的机制，除非借助第三方框架的扩展（比如自定义注解处理器），但原生环境下只能手动添加。

若注解可继承，这种做法是否属于不良开发实践？ #

首先要明确：方法注解本身不可继承，这里我们假设讨论的是类级别注解可继承的场景——这不能直接定义为不良实践，得看具体使用场景：

• 合理场景：比如Spring的@Component，父类添加后子类自动被识别为组件，能减少重复代码，提升开发效率，这种用法是很实用的。
• 风险场景：如果注解带有特定业务逻辑或配置属性，继承后可能导致子类意外继承父类的行为。比如父类加了@Transactional，子类所有方法默认被事务管理，但子类中某些方法其实不需要事务，就会引发不必要的性能损耗或逻辑问题。

总的来说，使用可继承的注解时，要确保子类确实需要继承父类的注解逻辑，避免隐式行为带来意外bug。如果是方法注解，强行通过非常规手段实现“继承”，反而会增加代码复杂度和可读性问题，一般不推荐。

内容的提问来源于stack exchange，提问作者SystemGlitch