Android N Java 8 기능 (Jack 컴파일러) 및 Kotlin interop

Android N Java 8 기능 (Jack 컴파일러) 및 Kotlin interop

---

업데이트 3. KOTLIN은 이제 Android 개발을 위해 공식적으로 지원 됩니다. Google 제공. YAAAAAAAAS!

업데이트 2 : JetBrains가 장기적으로 Android 용 Kotlin을 지원하는 데 정말 전념하고있는 것 같습니다 . 나는 행복한 kotlin 사용자입니다 :).

업데이트 : JetBrains의 Hadi Hariri 는이 주제에 대한 몇 가지 정보를 공개 할 것이라고 언급했습니다 . 일단 업데이트되면이 게시물을 업데이트하겠습니다.

=== 사용 중단 된 항목 다음 ===

Google은 몇 가지 흥미로운 기능이 포함 된 곧 출시 될 Android N에 대한 미리보기를 출시했습니다. 가장 주목할만한 것은 부분적인 Java 8 언어 지원 입니다. 이것은 Google이 작업중인 새로운 Jack 도구 모음 으로 인해 가능합니다 .

javac 또는 kotlinc를 사용하는 현재 툴체인 :
javac ( .java-> .class)-> dx ( .class-> .dex)
kotlinc ( .kt-> .class)-> dx ( .class-> .dex)

새로운 Jack 툴체인 :
Jack ( .java-> .jack-> .dex)

저는 Google이 Jack 을 Android 개발을위한 기본 도구 모음 으로 만들기 위해 앞으로 나아갈 것이라고 가정 합니다. 업데이트 : Jack 은 이제 더 이상 사용되지 않습니다 . Yas.

제 질문은이 새로운 툴체인이 앞으로 Android 개발을위한 kotlin 사용자 로서 저에게 어떤 영향을 미칠 까요? "과거에 갇혀"가 될까요?

---

면책 조항 : 나는 Jack에서 일합니다

이것은 당신에게 영향을 미치지 않습니다. Kotlin의 컴파일러는 Jack / Jill이 잘 가져올 수있는 Java 6 바이트 코드를 생성합니다.

---

@Pavel Dudka

Jack-컴파일러입니다. javac와 비슷하지만 약간 다른 일을합니다.

보시다시피 Jack은 Java 소스 코드를 Dex 파일로 직접 컴파일합니다! 더 이상 중간 * .class 파일이 없으므로 dx 도구가 필요하지 않습니다!

하지만 기다려! 내 프로젝트에 타사 라이브러리 (.class 파일 모음으로 제공됨)를 포함하면 어떻게됩니까?

그리고 그때 Jill이 등장합니다.

Jill은 클래스 파일을 처리하고 Jack 컴파일러의 입력으로 사용할 수있는 특수 Jayce 형식으로 변환 할 수 있습니다.

자 이제 잠시 물러서서 생각해 보겠습니다. 우리가 그토록 중독 된 멋진 플러그인은 어떻게 될까요? 그들은 모두 .class 파일이 필요하며 Jack 컴파일러에는 더 이상 파일이 없습니다.

다행히 Jack은 즉시 사용할 수있는 중요한 기능 중 일부를 제공합니다.

• Retrolambda-필요하지 않습니다. Jack은 람다를 제대로 처리 할 수 ​​있습니다.
• Proguard-이제 Jack에 구워 졌으므로 난독 화 및 최소화를 계속 사용할 수 있습니다.

장점 :

Jack은 Java 프로그래밍 언어 1.7을 지원하고 아래에 설명 된 추가 기능을 통합합니다.

• Predexing

  JACK 라이브러리 파일을 생성 할 때 라이브러리의 .dex가 생성되어 .jack 라이브러리 파일 내에 pre-dex로 저장됩니다. 컴파일 할 때 JACK은 각 라이브러리의 pre-dex를 재사용합니다. 모든 라이브러리는 pre-dexed입니다.

• 증분 컴파일

  증분 컴파일은 마지막 컴파일 이후에 수정 된 구성 요소와 해당 종속성 만 다시 컴파일됨을 의미합니다. 변경 사항이 제한된 구성 요소 집합으로 만 제한되는 경우 증분 컴파일이 전체 컴파일보다 훨씬 빠를 수 있습니다.

• 재 포장

  JACK은 jarjar 구성 파일을 사용하여 재 패키징을 수행합니다.

• Multidex 지원

  dex 파일은 65K 메서드로 제한되므로 메서드가 65K 이상인 앱은 여러 dex 파일로 분할해야합니다. (multidex에 대한 자세한 내용은 '65K 이상의 메서드로 앱 빌드'를 참조하세요.)

단점 :

• Jack은 Transform API를 지원하지 않습니다. 수정할 수있는 중간 Java 바이트 코드가 없으므로 여기서 언급하지 않은 일부 플러그인은 작동을 멈 춥니 다.
• Annotation processing is not currently supported by Jack, so if you heavily depend on libraries like Dagger, AutoValue, etc., you should think twice before switching to Jack. EDIT: As pointed out by Jake Wharton, Jack in N Preview has annotation processing support, but it is not exposed yet through Gradle.
• Lint detectors which operate on a Java bytecode level are not supported.
• Jacoco is not supported - well, I personally find Jacoco questionable (it doesnt really show what you want to see), so can totally live without it
• Dexguard - enterprise version of Proguard is not currently supported

---

Google is not going to push Jack as the default tool, but Jack and Jill.
Compiling .class files to dex with Jill is here to stay. Otherwise, you can say goodbye to jar/aar libraries.

Whether Jack or Jill will be slower is still up for debate. The Android team hopes that jack will be faster than the current build process, but that's not the case right now

Furthermore, Jack and Dex are available in the open, nothing prevents the kotlin team from writing a tool emiting .jack or .dex files from kotlin sourcecode.

---

UPDATE (03/16/2017)

Luckily, Jack is dead and so it won't affect Kotlin developers.

---

If Jack is the future then you will get stuck in the past with Kotlin. Currently Jack doesn't support plugins that can compile non-Java source into Dalvik bytecode. And even if it did JetBrains would need to add a new backend to the Kotlin compiler which is not a trivial task. So you will have to use Kotlin with Jill and it's going to be something very similar to the toolchain you use now.

As you can see in the image below even if it's impossible to explicitly turn off Jack you'll still be able to convert the project to a library project to use Jill. And the application project will just reference this library project.

The only way I see how Kotlin can work with Jack, which probably will not be implemented, is adding a Java backend to the Kotlin compiler, i.e. a backend that generates Java code like Xtend. In this case code generated by the Kotlin compiler can be processed by Jack as any other Java code.

But at the moment we don't know exactly what Jack will support when it's released. Maybe something will change dramatically and adding Kotlin support to Jack will become possible.

---

As said in the blog post (Kotlin's Android Roadmap) that appeared today:

Right now there are some issues that prevent Jack from handling Kotlin-generated bytecode correctly (196084 and 203531), but we plan to work together with the Google team to either resolve the issues or provide workarounds on our side. Once this is done, we’ll be able to translate only changed class files using Jill during incremental compilation, as opposed to translating all class files every time (which is the only possible behavior in the old Android tooling).

So Kotlin will eventually support Jack & Jill and get benefits from it.

---

As per latest google announcement -

We've decided to add support for Java 8 language features directly into the current javac and dx set of tools, and deprecate the Jack toolchain. With this new direction, existing tools and plugins dependent on the Java class file format should continue to work. Moving forward, Java 8 language features will be natively supported by the Android build system. We're aiming to launch this as part of Android Studio in the coming weeks, and we wanted to share this decision early with you.

We initially tested adding Java 8 support via the Jack toolchain. Over time, we realized the cost of switching to Jack was too high for our community when we considered the annotation processors, bytecode analyzers and rewriters impacted. Thank you for trying the Jack toolchain and giving us great feedback. You can continue using Jack to build your Java 8 code until we release the new support. Migrating from Jack should require little or no work.

So we need not worry about jack toolchain becoming default toolchain for android development. You can continue to use kotlin or use normal javac/dx set of tools.

Source : Future of Java 8 Language Feature Support on Android

---

I've already found this blog post from the official Kotlin's blog: : Kotlin’s Android Roadmap

There you would find a part which tells that:

The next thing we plan to do to improve Android build performance is providing an integration with Android’s new Jack and Jill toolchain. Right now there are some issues that prevent Jack from handling Kotlin-generated bytecode correctly (196084 and 203531), but we plan to work together with the Google team to either resolve the issues or provide workarounds on our side. Once this is done, we’ll be able to translate only changed class files using Jill during incremental compilation, as opposed to translating all class files every time (which is the only possible behavior in the old Android tooling).

So as @LukasBergstrom said, there won't be any problem with "stucking in the past" ;-)

Reddit이 주제와 관련된 토론 도 확인할 수 있습니다 . Jack 및 Jill과 함께 Kotlin의 상태는 어떻습니까?

즐거운 코딩입니다.

---

Kotlin 블로그 에 따르면 1.1-beta2 새로운 기능 섹션을 출시했습니다.

Jack 도구 모음이 활성화 된 경우 Android 프로젝트 빌드 지원 (jackOptions {true});

참고 URL : https://stackoverflow.com/questions/35919849/android-n-java-8-features-jack-compiler-and-kotlin-interop