Writing Java-friendly Kotlin code (Phần 4-End)

Internal visibility Chúng ta cũng cần chú ý đến các vấn đề với Internal visibility. Trong bytecode chúng sẽ trở thành publics, nhưng với một cái tên dài thì code không hề đẹp. Nó đã được xử lý, tuy nhiên không có khả năng hiển thị trong java Internal visibility, và chúng ta không nên sử dựng gọi ra một cách tuỳ tiện. Hãy xem xét ví dụ Retrofit sau:

// Retrofit.kt
internal fun validate(): Retrofit
......
// When linking lib as a separate module with sources. 
// IntelliJ won't let you compile.
final Retrofit retrofit =
    new Retrofit.Builder()
        .baseUrl("https://api.domain.com")
        .client(new Client())
        .build()
        .validate$production_sources_for_module_library_main();
......
// When linking lib as a JAR file. Compiles successfully.
final Retrofit retrofit =
    new Retrofit.Builder()
        .baseUrl("https://api.domain.com")
        .client(new Client())
        .build()
        .validate$library_main();

Null-checks Thật tuyệt khi thấy bytecode của Kotlin lib của chúng ta được tăng thêm.

• @Nonnull và @Nullable chú thích phản ánh các kiểu Kotlin hiện tại.
• Kiểm tra null cho tất cả các tham số nonnull và các giá trị trả lại trong public API.

Những người đi trước sẽ giúp consumers của chúng tôi khi coding trong IDE, sau đó sẽ bắt lỗi sai khi runtime. CHÚ Ý: Nó có thể xảy ra vấn đề là bạn đã từng sử dụng cờ biên dịch -Xno-param-assertions và -Xno-call-assertions để tắt kiểm tra null thời gian chạy (ví dụ, bởi vì 100% là Kotlin và bạn hoang tưởng về hiệu năng chi phí của các kiểm tra trên Android). Trong trường hợp đó, bạn nên chắc chắn rằng các cờ này không được sử dụng để biên dịch thư viện.

Inline functions Inline functions sẽ có thể truy cập được bằng Java như các phương thức thông thường. Tất nhiên, họ sẽ không inlined bởi trình biên dịch. Đồng thời, Inline functions với các tham số kiểu reified sẽ không hiển thị trong Java, bởi vì nếu không thực sự inlining chúng sẽ không làm việc. Unit Nếu chúng ta có chức năng với đơn vị trả về lambdas, chúng tôi sẽ ép buộc người dùng Java giải quyết. Bởi vì Đơn vị, tương tự như Void, là một loại thực tế, và trình biên dịch Java sẽ yêu cầu các giá trị lambda như vậy phải có một kiểu trả về thực tế.

ReverserUtils.forEachReversed(list, it -> {
  System.out.println(it);
  return null;
});

Typealiases: Ở đây đơn giản là: không có typealiases có thể truy cập từ Java. Đó không phải là một vấn đề lớn, mặc dù các loại thực tế vẫn còn đó, và người dùng Java đã được sử dụng để kiểu tên dài với generics kèm theo. Hy vọng bài đăng này sẽ giúp bạn thực hiện chuyển đổi tốt với Kotlin trong các nền tảng Java của mình và cũng sẽ giúp mở rộng việc sử dụng Kotlin của bạn để viết các thư viện mã nguồn mở hữu ích trong khi không bắt buộc phải từ bỏ tất cả các Java / Groovy / Closure / vv.