早上一到办公室，运维妹子就开给我说，我的一个接口又报错了。是的，又报错了。我开始在脑海里思考问题的可能性，可能性就是，不应该啊，怎么系统跑着跑着跑偏了？？
然后我就问了一下idc同事，昨天系统做什么修改了吗。在等待回复的同时，我开始找日志看问题在哪里，只见日志上赫然写着：java.lang.NoSuchMethodError，没这个方法，你在搞笑吗，我系统昨天还运行得好好的，然后idc的同时给我说，昨天替换了两个po的class文件，好了，大致方向找到了，开始寻找原因所在。
首先去看了一下同事提交的修改代码，看到我的那个方法是在的，setDetailIdz()，同事修改的只是po里面字段的类型，是的，这个po是我年轻的时候写的，po的数据类型写的是long基础类型（捂住嘴巴，不让眼泪掉下来），同事只是改成了Long包装类型，我再去调这个方法的时候，怎么就不存在了呢，我又把服务器上的文件拿下来看了一下编译版本，确定了版本是无误的，然后就陷入了沉思，jdk1.5开始，不是有自动装箱拆箱吗，为什么在我这里就不管用了呢，我们正式环境的jdk刚好是jdk1.5（捂住嘴巴，不让眼泪掉下来）啊。
开始整理思路，方法存在的（其实是方法名存在），但是报方法不存在的问题，肯定是方法重载的问题，相同的方法，参数个数或者类型不同，而我的参数就一个，就是id，那肯定就是类型不同，为什么不同的，都是long，而且有自动装箱拆箱，而且之前方法参数是long，我传的参数是Long，就能正常跑起来，自动拆箱肯定是有效的。现在我传的是Long，方法参数也是Long，连自动拆箱都不用了，反而报错了...难道我不用拆箱，系统也给我拆箱了，突然觉得自己发现了新大陆，肯定是系统傻逼给我自作主张拆箱了，那么，真相只有一个，就是自动装箱拆箱是编译期间就决定了的，然后同事替换PO的class之后，不需要拆箱，而我的代码由于是之前编译的，依然做了拆箱，导致参数类型不同：java.lang.NoSuchMethodError
为了验证我的思路，我又去服务器上拿了自己的代码，反编译出来，setDetailId(detailId.longValue())，确实是编译阶段做的自动拆箱，然后我又把同事的代码发到测试环境，我的代码还是用之前的版本，报了相同的错误，我又把自己的class用同事的po代码重新编译了一次，放在测试环境，正常运行。问题就告一段落了。
于是我又陷入了沉思，心中暗自窃喜，又学到了，然后就去搜了一下语法糖相关的知识，知道了语法糖相关的解语法糖都是在编译期间进行的，是编译时特性。