Kotlin 填坑记之 Metadata
最近用 KAPT 来生成 Kotlin 代码，遇到了一个头疼的问题，生成的 Kotlin 代码需要调用源 Kotlin 代码中被 Annotation 标注的属性，理论上讲，直接用 . 操作符来调用属性不就行了吗？然而，事情并没有想象的那么简单。
最近用 KAPT 来生成 Kotlin 代码，遇到了一个头疼的问题，生成的 Kotlin 代码需要调用源 Kotlin 代码中被 Annotation 标注的属性，理论上讲，直接用 . 操作符来调用属性不就行了吗？然而，事情并没有想象的那么简单。
是个 Java/Android 工程师都知道，用 == 比较其实是比较的两个对象是否是同一个实例，比较实例其实就是比较内存地址是否相等，当我们在打印一个 Object 的时候，默认就会输出 [email protected] 这样的字符串，@ 后面的这一串，则是 Object 实例在内存中的地址。众所周知，由于 JVM 的垃圾回收机制，会导致实例在运行时内存中的位置被垃圾回收器移动，那么问题来了，当实例被移动位置后，Object 的 hashCode() 会变吗？
当开发一个 Android Library 时，如果还同时还要提供相应的 __Gradle Plugin__，对于 Gradle 新手来说，要在一个 Gradle 工程中同时集成 Android Library__，__Gradle Plugin 和 Example App 三个模块，并不是一件很容易的事，主要的问题在于 Android App 模块中无法引用同一个工程中的 Gradle Plugin 模块，这是因为 Gradle Plugin 需要先于所有的工程进行配置和编译，所以，很多工程师都会将 Gradle Plugin 作为一个独立的工程进行开发和发布，这对于频繁地开发和调试 Gradle Plugin 的工程师来说，是非常的痛苦，每次修改了 Gradle Plugin 都要先发布到 __Maven Local__，然后再跨工程进行调试，效率极低，那有什么优雅的解决方案呢？
在移动互联网蓬勃发展的时代，出现了很多现代化的编程语言，Write Once and Run Anywhere 早已不再是 Java 所独有的特性，然而在 Android 系统推出之前，想要在嵌入式 Linux 系统之上比较方便的开发 GUI 程序还真不是一件简单的事情，虽然有 Qt、GTK 等强大的 GUI 开发框架，但是用 C/C++ 语言开发始终不可避免的要面临的一个问题——内存管理，尽管 C++ 有强大的 boost 库（已在 2011 年成为 C++11 的标准库）提供的智能指针能很好的解决内存的问题，但对于采用 C 语言来开发 GUI 的 GTK 来说，就不是那么容易了，尤其是对于要用 C 语言来开发应用程序的开发者来说，如何让内存管理变得更容易便成为了一个经久不衰的话题。
正在开车呢，收到一条微信：“森哥，这段代码为啥输出是 0？…”，由于开着车，实在没功夫回信息，过了一会儿，又收到一条微信：“森哥，字节码大神，说下原理呗？[捂脸表情]”
正静坐思考人生，突然意识到加入 Coupang 已经一年了，从头到尾捋了一遍，脑海里冒出来一个词 —— 度日如年，此「度日如年」并非彼「度日如年」，一切都是相对的，这儿正好相反。在 Coupang 这短短的一年的收获已远远超过之前几年，也不知道是因为运气好，还是自己的决策对，用我老板的话说 —— 你们想要知道下次是哪家公司上市，就看 Johnson 去哪儿 😁 恐怕我也是为数不多的连续经历三次 IPO 的人之一，不过回想当初的决定，还真是无比的坚难。
Booster 又双叒叕发布了新的版本—— v3.5.0，本次更新内容如下：
ServiceLoader 性能优化，使用方法： 1 | val services = ServiceLoader.load(Service::class.java).iterator() // iterator() 是必要的 |
Booster 又双叒叕发布了新的版本—— v3.4.0，本次更新内容如下：
ClassParser ，开发者可以选择使用 ASM 或者 Javassist 或者其它的 class 文件解析器