Android开发：sourceCompatibility与targetCompatibility的作用及移除可行性

为什么要使用sourceCompatibility和targetCompatibility？ #

这两个配置是Java/Kotlin编译链里的基础约束，核心作用分两点：

• sourceCompatibility：限定你写代码时能用的语法版本。比如设成1.8，编译器就会阻止你用Java 9及以上的语法（比如模块声明、私有接口方法），避免团队写出低版本环境不支持的语法。
• targetCompatibility：控制编译后生成的字节码兼容版本。比如设成1.8，生成的字节码会符合Java 8的字节码规范，确保能在支持该规范的ART虚拟机上稳定运行，不会出现字节码版本不兼容的崩溃。

开启核心库脱糖后，这两个配置真的没用吗？ #

你测试时代码能在Android 5.1和13上跑，是因为核心库脱糖和这俩配置负责的是不同层面的兼容：

• 核心库脱糖（Core Library Desugaring）只处理高版本Java核心库API的兼容，比如把Java 8的Stream、Optional转换成低版本Android能识别的实现，但它管不了语法层面的问题。
• 这俩配置管的是语法和字节码版本的约束。你没遇到问题，大概率是代码里没用到超出默认兼容版本的语法，或者IDE/编译工具默认帮你补了基础配置，但这不代表它们没用。

能不能移除这两个配置？ #

不建议直接移除，理由很实在：

1. 语法防错：没有sourceCompatibility的限制，团队成员可能随手用了高版本语法（比如Java 17的switch模式匹配），等到编译或跑在低版本设备上才报错，排查起来麻烦。
2. 编译一致性：不同开发环境、CI/CD环境的默认编译版本可能不一样，明确配置能避免出现“本地能跑，CI编译失败”的情况。
3. 脱糖的边界：脱糖不处理语法糖的兼容，比如Java 8的Lambda表达式，虽然脱糖能支持它的运行，但如果没指定sourceCompatibility=1.8，编译器根本不让你写Lambda代码。
4. 未来扩展性：如果后续项目要引入依赖、升级语言版本，明确的兼容性配置能让你更清晰地掌控兼容范围，不会乱成一团。

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