
Portuguese: 
Olá!
Esta é a apresentação
"A linguagem de programação
Kotlin ama o Java".
Sou Nicole Borelli, engenheira
de programas ao desenvolvedor no Android.
Meu nome é Murat. Sou mediador
de desenvolvedores no Android.
Meu nome é Wenbo.
Sou desenvolvedor Android
na equipe de apps do Google Home.
Falaremos sobre
a interoperabilidade entre Kotlin e Java.
Como se uma linguagem
não fosse o bastante,
agora temos duas.
Mesmo que não tenham
a intenção de usá-las em conjunto,
vocês podem usar a biblioteca,
que é escrita na outra linguagem.
Pode ser que usem
as duas ao mesmo tempo.

Spanish: 
Hola.
Esta presentación se llama: El lenguaje
de programación Kotlin adora Java.
Soy Nicole Borelli, ingeniera en
programas para desarrolladores de Android.
Me llamo Murat.
Soy asesor de desarrollo de Android.
Me llamo Wenbo.
Soy desarrollador de Android
en el equipo de Aplicaciones Google Home.
Y hablaremos sobre la interoperabilidad
entre Kotlin y Java.
Como si tener un lenguaje
no fuera suficiente,
ahora tenemos dos.
Y aunque tal vez no tengan la intención
de usarlos juntos, podrían estar usando
su biblioteca, que está escrita
en el otro lenguaje.
Así que quizá sí usan los dos a la vez.

Korean: 
[음악 재생 중]
안녕하세요
'Kotlin 프로그래밍 언어는
Java를 사랑해' 시간이에요
저는 Android 개발자 프로그램 엔지니어인
니콜 보렐리입니다
저는 무랏입니다
Android 개발 Android 개발 홍보 담당이고요
저는 원보입니다
Google Home 앱팀의
Android 개발자입니다
좋아요
저희는 Kotlin과 Java Interop에 대한
이야기를 하려고 합니다
네, 마치 언어가 하나도 없었고
그 상태로는 부족했던 것처럼
이제는 두 가지 언어가 생겼습니다
그리고 여러분이
두 언어를 함께 사용하려는
의도가 없다 하더라도
아마도 다른 언어로 작성된
라이브러리를 사용하고 있을 거예요
두 가지 언어를
동시에 사용하는 거죠

English: 
[MUSIC PLAYING]
NICOLE BORELLI: Hi!
So this is Kotlin Programming
Language Loves Java.
I'm Nicole Borelli, developer
programs engineer on Android.
MURAT YENER: I'm Murat.
I'm develop advocate on Android.
WENBO ZHU: I'm Wenbo.
I'm a Android developer on
the Google Home Apps team.
NICOLE BORELLI:
And yeah-- so we're
going to be chatting to you
about Kotlin and Java Interop.
MURAT YENER: Yep-- so as if
we didn't have one language
and it wasn't enough, now
we have two languages.
And even though if you
don't have any intention
to use them together,
you might be
using your library, which is
written in the other language.
So you might be using
two at the same time.

Chinese: 
大家好 这里是 Kotlin ♡ Java
我是 Android 开发者项目工程师 Nicole Borelli
我是 Murat Android 开发推广工程师
我是 Wenbo Google Home Apps 团队开发者
今天和大家聊一聊关于 Kotlin 和 Java 互操作的问题
我们已经有了一种编程语言 现在又来了一种
虽然大家未必想把它们放在一起来使用
但大家可能会用到用另一种语言写成的代码库 
所以 大家都有可能会同时使用这两种语言

Indonesian: 
-Hai!
Jadi, ini adalah sesi
Bahasa Pemrograman Kotlin Cinta Java.
Saya Nicole Borelli, 
program developer engineer di Android.
-Saya Murat.
Saya developer advocate di Android.
-Saya Wenbo.
Saya developer Android
untuk tim Aplikasi Google Home.
-Dan kami akan
membahas Kotlin dan Java Interop.
-Jadi, sepertinya
satu bahasa saja tidak cukup,
kini kita punya dua bahasa.
Meskipun Anda
tidak bermaksud untuk
menggunakan keduanya
secara bersamaan, mungkin Anda akan
menggunakan library
yang tertulis dalam bahasa lain.
Jadi Anda mungkin menggunakan
kedua bahasa secara bersamaan.

Japanese: 
［音楽］
こんにちは！
「Kotlinプログラミング言語は
Javaが大好き」の単元です
私はAndroid開発プログラム
エンジニアのニコル
Androidデベロッパー
アドボケイトのムラトです
Google Homeアプリチームの
Android開発者 ウェンボーです
それでは
KotlinとJava Interopについて
お話ししていきます
一つの言語では
十分でなかったので
私たちは二つの言語を
持つようになりました
両方いっぺんに使いたくなければ
他の言語で書かれた
ライブラリを使うこともできます
二つを同時に使ってもいいのです

Korean: 
시작하기 전에
새로운 Android 로고에 맞춰서
Android 모자를 쓸게요
[웃음]
슬라이드 양이 많아요
그러면 먼저
Java 프로그래밍 언어를
Kotlin에서 호출하는 것부터 시작해볼게요
첫 번째는 null 허용 여부입니다
이 주제를 보면 말 그대로
많은 물음표를 띄우실 텐데요
두 언어가 서로
다르기 때문이죠
Java는 Kotlin과 달리
기본적으로 값에 null이 허용됩니다
Kotlin에서
Java 함수를 호출하면
Kotlin은 함수가 null 값을
반환하거나 수신할 수 있는지
전혀 알지 못합니다
그렇기 때문에
기본적으로 물음표나
느낌표를 추가해야 합니다

Portuguese: 
Antes de começar, para combinar
com o novo logotipo do Android,
vou usar meu chapéu.
Temos muitos slides.
Vejamos primeiro como
chamar o Java a partir do Kotlin.
Primeiro item: nulidade.
Com certeza vão aparecer muitos
pontos de interrogação, literalmente.
As duas linguagens são diferentes.
O Java tem nulidade padrão para valores,
o que não é o caso do Kotlin.
Assim, se chamarmos
uma função Java do Kotlin,
o Kotlin não tem ideia se a função
pode retornar ou receber valores nulos.
É por isso que precisamos adicionar
pontos de interrogação ou de exclamação

Japanese: 
話の前に 
新しいAndroidロゴに従い
Androidハットを被ります
［笑い］
スライドがたくさんあるので——
まずは Kotlinからの
Javaプログラミング言語です
最初は Null許容性についてです
これは文字通り 多くの「？」を
生んでると思います
二つの言語は異なるため——
Javaはデフォルトでnullを
許容しますが Kotlinはしません
ですから Kotlinから
Java機能を呼び出そうとすると
Kotlinはその機能が
null値を返せるのか——
受けるのかわからないのです
そのため 基本的には
「？」か「！」を加えて

Chinese: 
在开始之前 为了配合 Android Logo
我先戴上我的 Android 小帽子
我们准备了很多幻灯片
首先 我们来看看如何使用 Kotlin 来调用 Java 编程语言
首先 可空性
我想 很多人看到这个词的时候会满脸写满问号
因为这两种语言是不同的
Java 默认拥有数值可空性 而 Kotlin 没有
所以 如果你使用 Kotlin 来调用 Java 功能
Kotlin 不会知道 这个功能能不能返回或收到空值
所以 你才需要添加问号或感叹号 来告诉 Kotlin

English: 
Before I start, to be compliant
with the new Android Logo,
let me put on my Android hat.
[LAUGHTER]
So we have lots of slides.
So let's jump in first with
calling Java programming
language from Kotlin.
So first thing-- nullability.
I'm pretty sure this brings lots
of question marks, literally.
Well, because two
languages are different,
Java has default nullability
for values and Kotlin doesn't.
So if you're calling a
Java function from Kotlin,
Kotlin has no idea if the
function can return or receive
null values.
That's why, basically, you
need to add question marks
or explanation marks,
to basically tell Kotlin

Spanish: 
Antes de comenzar, y para ser compatible
con el nuevo logotipo de Android,
permítanme ponerme mi gorro de Android.
Tenemos muchas diapositivas.
Primero invocaremos
el lenguaje de programación
Java desde Kotlin.
Lo primero será la compatibilidad
con el valor NULL.
Estoy seguro de que esto genera muchos
signos de interrogación, literalmente.
Bueno, debido a que
los dos lenguajes son diferentes,
Java tiene compatibilidad predeterminada
con valores NULL y Kotlin no.
Entonces, si están invocando
una función Java desde Kotlin,
Kotlin no tiene idea si la función
puede devolver o recibir valores NULL.
Esto se debe a que, básicamente,
necesitan agregar signos de interrogación
o de exclamación para decirle a Kotlin

Indonesian: 
Sebelum memulai,
agar patuh dengan Logo Android yang baru,
izinkan saya pakai
topi Android ini dulu.
Slide kami cukup banyak.
Pertama, mari kita bahas
pemanggilan bahasa pemrograman Java
dari Kotlin terlebih dahulu.
Yang pertama adalah nullability.
Saya yakin hal ini
memunculkan banyak tanda tanya.
Kita tahu bahwa
kedua bahasa ini berbeda,
Java memiliki nullability default 
untuk nilai, sedangkan Kotlin tidak.
Jadi, jika Anda
memanggil fungsi Java dari Kotlin,
Kotlin tidak tahu apakah
fungsi dapat mengembalikan atau menerima
nilai null.
Inilah alasan mengapa Anda 
perlu menambahkan tanda tanya
atau tanda penjelas,
untuk memberi tahu Kotlin

Chinese: 
有可能会出现空值
这样会让你非常伤心 仿佛自己犯下了什么大错
然后你的代码基上就充满了问号
幸运的是 这个问题其实很好解决
你只需注解好所有的公共 API 
也就是非原始参数 字段 返回值
给它们加上注解 告诉 Kotlin 它们不是空值
我们有一个可空性注解列表
我们通常使用 JetBrain 注解
Android 注解也不错
JSR-305 不推荐使用
需要 flag 才能让它和 Java 9 模块系统协作
来看一个例子

Japanese: 
Kotlinにnull値の発生を
伝える必要があります
これは何だか
気分の悪いものです
何か間違ったことを
しているような感じで
突然 コードベース全体に
「？」が付くんです
幸い これは簡単に修正できます
非プリミティブ型のパラメータ
フィールド、戻り値などの——
パブリックAPIすべてに
アノテーションを付けます
それにより Kotlinに
それらがnullではないと伝えます
null許容性の
アノテーション一覧があります
通常使うのはJetBrainアノテーション
Androidのアノテーションも使えます
JSR-305はお勧めしません
Java 9モジュールシステムで
動かすには フラグが必要です
例を見てみましょう
ここに 文字列のコレクションを
受け取り

Indonesian: 
bahwa nilai null dapat terjadi.
Dan hal ini membuat Anda resah,
seakan-akan Anda
melakukan kesalahan besar.
Dan tiba-tiba, basis kode Anda
dipenuhi dengan tanda tanya.
Untungnya masalah ini
sangat mudah untuk diselesaikan.
Yang harus Anda lakukan
adalah menganotasi semua
API publik,
yang merupakan parameter non-primitif,
field dan return,
lalu anotasi semuanya
untuk memberi tahu
Kotlin bahwa semua itu tidak null.
Kami punya daftar
anotasi nullability.
Kami biasanya
menggunakan anotasi JetBrain.
Anotasi Android
juga tidak apa-apa.
JSR-305 dihentikan.
Anda butuh penanda untuk 
membuatnya berfungsi dengan
sistem modul Java 9.
Mari kita lihat contohnya.
Jadi di sini kami memiliki
metode yang menerima

Portuguese: 
para informar ao Kotlin
que pode haver um valor nulo.
Isso dá uma sensação ruim,
como se estivéssemos fazendo
algo terrivelmente errado.
De repente,
há pontos de interrogação
em toda a base do código.
Felizmente,
isso é muito fácil de corrigir.
Basta anotar todas as APIs públicas,
que são parâmetros não primitivos,
campos e retornos, para informar ao Kotlin
que elas não são nulas.
Temos uma lista de anotações de nulidade.
Normalmente,
usamos as anotações do JetBrain.
As anotações do Android também servem.
O JSR-305 não é recomendado.
Você precisa de um sinalizador
para fazer funcionar
com o sistema de módulo do Java 9.
Vejamos um exemplo.

English: 
that a null value can happen.
And this really
makes you feel bad,
like you're doing
something terribly wrong.
And suddenly you end up
with question marks all
over your code base.
Luckily, this is actually
very easy to fix.
What do you need to do
is basically annotate all
the public APIs, which are
non-primitive parameters,
fields, and returns,
and annotate
them to tell Kotlin that
they can they are not null.
We have a list of
nullability annotations.
We usually use the
JetBrain annotations.
Android's annotations
are also fine.
JSR-305 is discouraged.
And you need a flag to make
it work with the Java 9
module system.
Let's see an example.
So here, we have a
method which receives

Korean: 
Kotlin에 null 값이
발생할 수 있다고 알려주는 거죠
이런 방식은
썩 내키지 않습니다
잘못된 방식으로
일하는 듯한 느낌을 받아요
그리고 갑자기
코드 베이스 전체에
물음표가 가득하게 됩니다
다행히 이런 문제는
아주 쉽게 고칠 수 있어요
기본적으로 이렇게 하면 됩니다
비원시 매개변수, 필드, 반환 등의
공개 API에 주석을 다는 겁니다
이렇게 주석을 달아서
Kotlin에 null이 아니라는 걸 
알려주는 거죠
저희에겐 null 허용 여부
주석 목록이 있어요
보통 JetBrains 주석을 사용하죠
Android의
주석도 괜찮습니다
JSR-305는 추천하지 않아요
Java 9 모듈 시스템에서
사용할 수 있게 하려면
플래그가 필요해요
예시를 살펴보겠습니다
여기에 나와 있는 메서드는

Spanish: 
que puede darse un valor NULL.
Y esto realmente
no les hace sentir bien,
es como si estuvieran haciendo
algo terriblemente mal.
Y, de pronto, terminan con
signos de interrogación en todo
su código principal.
Por fortuna, esto es realmente
muy fácil de corregir.
Lo que tienen que hacer
es anotar todas las API públicas,
que son parámetros,
campos y valores devueltos
no primitivos, y anotarlos
para decirle a Kotlin
que pueden no ser NULL.
Tenemos una lista de anotaciones
de compatibiildad con valor NULL.
Usualmente usamos
las anotaciones de JetBrain.
Las anotaciones de Android
también funcionan.
No les sugerimos JSR-305.
Y necesitan un marcador para que funcione
con el sistema de módulos Java 9.
Veamos un ejemplo.
Aquí tenemos un método que recibe

Indonesian: 
kumpulan elemen string
dan mengembalikan serangkaian string.
Pada kasus ini, Kotlin
tidak tahu apakah input atau outputnya
bisa berupa null.
Untuk memanggil fungsi ini dari
Kotlin, Anda harus memberi tahu
bahwa null 
diharapkan untuk kasus ini.
Jika kita
menambahkan anotasi not null,
pemanggilan fungsi ini
dari Kotlin menjadi lebih baik.
Selanjutnya, kami punya prefiks
properti, yakni getter dan setter.
Jika menggunakan gaya Java Bean,
Anda tidak akan mengalami banyak masalah.
Jika Anda memiliki metode
argumen null yang dimulai dengan get,
Kotlin tahu bahwa ini adalah getter.
Dan Anda dapat 
mengaksesnya lewat nama properti.
Sama halnya jika
Anda punya satu metode argumen
yang namanya dimulai dengan set,

Japanese: 
一連の文字列を返す
メソッドがあります
このケースでは 入力または出力が
nullで良いのか——
Kotlinには判断できません
Kotlinからこの機能を呼び出すには
「nullの可能性がある」と
伝える必要があります
null以外のアノテーションを追加して
Kotlinから機能を呼び出せば
もっといいと思います
次に getterとsetterという
プロパティ接頭辞があります
Java Beanスタイルをお使いの場合は
特に問題はありません
getで始まる
null引数メソッドがある場合
Kotlinはgetterだと判断し
プロパティ名でアクセスできます
また 名前がsetで始まる
単一の引数メソッドがある場合

Spanish: 
una colección de elementos de cadena
y devuelve un conjunto de cadenas.
Y, en este caso, Kotlin no tiene
idea de si la entrada o la salida
puede ser NULL.
Y para invocar esta función desde Kotlin,
tienen que decir:
"OK, estos esperando un valor NULL
en este caso".
Si proseguimos y agregamos
anotaciones que no sean NULL,
invocar esta función
desde Kotlin es mucho más fácil.
Después tenemos prefijos de propiedad,
que son recuperadores y colocadores.
Entonces, si están usando el
estilo JavaBean,
no tienen muchos problemas aquí.
Si tienen un método de argumento
NULL que comienza con get,
Kotlin sabe que se trata
del recuperador
y pueden acceder a él
por el nombre de la propiedad.
En forma similar, si tienen
un método de argumento único
cuyo nombre comienza con set,

Portuguese: 
Aqui temos um método que recebe
um conjunto de elementos de string
e retorna um conjunto de strings.
Neste caso, o Kotlin não tem a informação
se a entrada ou a saída podem ser nulas.
Para chamar essa função do Kotlin,
é necessário informar
que um valor nulo é esperado neste caso.
Se adicionarmos anotações não nulas,
chamar essa função do Kotlin
fica muito mais simples.
Agora temos os prefixos de propriedade:
getters e setters.
Se usarem o estilo Java Bean,
vocês não terão
muitos problemas com isso.
Caso tenham um método
de argumento nulo que comece com "get",
o Kotlin entenderá que é o getter.
E é possível acessá-lo
com o nome da propriedade.
De forma semelhante,
com um método de argumento único
que comece com "set",
o Kotlin entende que se trata do setter.

English: 
a collection of string elements
and returns a set off strings.
And in this case, Kotlin has no
clue if the input or the output
can be null.
And to call this function from
Kotlin, you need to tell--
OK, I'm expecting
null in this case.
If we go ahead and add
not null annotations,
then calling this function
from Kotlin becomes very nicer.
Next, we have property prefixes,
which are getters and setters.
So if you're using
Java bean style,
basically you don't
have much issues here.
If you have null argument
method which starts with get,
Kotlin knows, this
is the getter.
And you can access it
over the property name.
Similarly, if you
have a single argument
method, which the
name starts with set,

Chinese: 
这里有一个方法 它接收一组字符串
并返回一组字符串
在本例中 Kotlin 不知道输入和输出是否可以为空
为了使用 Kotlin 调用这个功能
你需要表明 在这里是否会有空值
如果我们添加非空注释
那么 就很容易使用 Kotlin 调用这个功能
接下来 是属性前缀 也就是 getter 和 setter
如果你使用的是 Java bean 样式
就不会遇到太大的问题
如果你的空参数方法是以 get 开头的
Kotlin 会知道这就是 getter
你可以通过属性名来访问它
类似地 如果是由 set 开头的单一参数方法
Kotlin 也会知道它是 setter

Korean: 
문자열 요소 컬렉션을 수신하고
문자열 세트를 반환합니다
이 경우 Kotlin은 입력이나 출력이
null이 될 수 있는지
전혀 알 수 없어요
Kotlin에서 이 함수를 호출하려면
직접 지정해서 알려줘야 하죠
이 경우에는
null 값이 됩니다
계속 진행해서
NotNull 주석을 추가하고
Kotlin에서 이 함수를 호출하면
훨씬 나은 결과물이 나옵니다
다음은 속성 접두사
getter와 setter입니다
Java bean 스타일을
사용하고 있는 경우
기본적으로
문제가 별로 없습니다
get으로 시작하는
null 인수 메서드가 있다면
Kotlin에서
getter라는 걸 알죠
여러분은 속성 이름을 통해
여기에 액세스할 수 있어요
마찬가지로
단일 인수 메서드가 있고
이름이 set으로 시작되면

English: 
Kotlin knows, this
is the setter.
And you can, again, set
over the property name.
And as expected, is
works a similar way.
So just follow the
Java bean style.
And everything should work.
Next, the keywords-- well,
languages have result words
and that's perfectly normal.
Actually, Java did
a very good job
with not introducing
a new keyword
and not breaking
the previous code.
Java 9 and 10 aside, the last
breaking change to happen
was edition of enum keyword
with Java 5, which was in 2005.
And the change before that was
a third key word with Java 1.4,
which was in 2002.
But Kotlin is a new language.
And it has its own keywords,
such as fun, is, in.

Portuguese: 
E, mais uma vez, é possível configurar
com o nome da propriedade.
Como esperado,
isso funciona de forma semelhante.
Basta seguir o estilo Java Bean
e tudo funcionará.
Agora, as palavras-chave.
As linguagens têm palavras de resultado,
isso é normal.
O Java fez um ótimo trabalho
ao não introduzir uma nova palavra-chave
e não interromper o código anterior.
Com exceção do Java 9 e 10,
a última alteração interruptiva
ocorreu com a adição da palavra-chave
"enum" no Java 5, em 2005.
E a alteração anterior a essa
foi a palavra-chave "assert"
no Java 1.4, em 2002.
No entanto, o Kotlin é uma linguagem nova.
Ele tem palavras-chave próprias,
como "fun", "is" e "in".

Chinese: 
然后你就可以通过属性名直接赋值
如大家所想 is 的工作原理也和它们类似
只要遵循 Java bean 样式 一切都会正常工作
接下来是 关键字
很多语言都会有保留的关键字 这非常正常
Java 没有加入新的关键词
也没有破坏之前的代码 这就很好
抛开 Java 9 和 10 不谈
Java 上一次破坏性的改动还要追溯到
2005年在 Java 5 中加入的 enum 关键字
在那之前 2002年 Java 1.4 加入了 assert 关键字
但是 Kotlin 是个新语言 它有自己的关键字 
fun is in 这些关键词

Indonesian: 
Kotlin tahu bahwa ini adalah setter.
Dan Anda juga dapat
mengaksesnya lewat nama properti.
Seperti yang kita tahu,
cara kerjanya kurang lebih sama.
Jadi, cukup ikuti gaya Java bean.
Dan semuanya akan berfungsi baik.
Selanjutnya kata kunci
bahasa memiliki kata hasil
dan hal itu normal.
Java mengambil
tindakan yang sangat tepat
dengan memilih untuk tidak 
memperkenalkan kata kunci baru
dan tidak merusak kode sebelumnya.
Di samping Java 9 dan 10,
perubahan merusak terakhir yang terjadi
adalah kata kunci enum
dengan Java 5, yang terjadi di tahun 2005.
Dan perubahan sebelumnya 
adalah kata kunci ketiga dengan Java 1.4,
yang terjadi pada tahun 2002.
Tetapi, Kotlin adalah bahasa baru.
Bahasa ini punya
kata kunci sendiri, seperti fun, is, in.

Korean: 
Kotlin에서
setter라는 것을 압니다
그리고 동일하게
속성 이름을 통해 설정할 수 있죠
그러면 예상했던 대로
비슷한 방식으로 작동할 겁니다
그러니까 그냥
Java bean 스타일을 따르세요
그러면 모든 게 작동할 거예요
다음은 키워드입니다
언어에는 결과어가 있죠
그게 정상입니다
사실 Java는
아주 잘 작동한 겁니다
새 키워드를 도입하지 않고
이전 코드를
훼손하지도 않았죠
Java 9와 10을 제외하고
가장 최근의 획기적인 변화는
2005년의 Java 5를 포함한
enum 키워드 에디션이었어요
그리고 그 이전의 변화는
Java 1.4의 세 번째 키워드였는데요
2002년이었죠
하지만 Kotlin은 새로운 언어입니다
자체적인 키워드가 있죠
fun, is, in 등이에요

Spanish: 
Kotlin sabe que se trata del colocador.
Y nuevamente pueden definirlo
por el nombre de la propiedad.
Y, como era de esperar,
funciona de un modo similar.
Así que sigan el estilo JavaBean
y todo debería funcionar.
Ahora, palabras clave: los lenguajes
tienen palabras de resultados
y eso es perfectamente normal.
En realidad, Java hizo
un muy buen trabajo
al no introducir
una palabra clave nueva
que arruinara el código anterior.
Dejando a un lado a Java 9 y 10, el último
cambio relevante que se registró
fue en la edición de la palabra clave enum
con Java 5, en 2005.
Y el cambio anterior a ese fue una tercera
palabra clave con Java 1.4, en 2002.
Pero Kotlin es un lenguaje nuevo.
Y tiene sus propias palabras clave,
como fun, is o in.

Japanese: 
Kotlinはsetterだと判断し
同様に プロパティ名でセットできます
そして 予測される通り
同様に機能します
つまり
Java Beanスタイルに従えば
すべてうまくいくはずです
次に キーワードです
言語には結果の単語があり
これはまったく正常です
Javaは
新しいキーワードを導入せず
以前のコードを壊さないという
非常に良い働きをしています
Java 9と10を別にすれば
最後の大きな変更は——
enumキーワードを導入した
2005年のJava 5でした
その前の変更は 
第三のキーワードを導入した
2002年のJava 1.4です
しかし Kotlinは新しい言語で
独自のキーワードを持っています
fun、is、inなどです

Chinese: 
在 Java 中可用 但在 Kotlin 中就不行了
如果你的函数或参数使用了这些关键词
那么你在使用 Kotlin 调用它们的时候
可能就会遇到麻烦
我们来看一个例子
假如你有一个方法 名叫 is
这名字很差劲 但是 它在 Java 中是可用的
所以 理论上确实可以这样做
但是 如果你想用 Kotlin 来调用它
就会出问题 因为 is 是一个保留词
你的最好解决方案就是 重命名你的方法
在本例中 这就是最好的方法了
但是 最终你可能会用到一个被广泛使用的代码库
那你也许就没办法再重命名里面的方法了
这时 Kotlin 里的调用者 
如果没有单引号 就无法完成调用
所以 用户需要这个单引号

Japanese: 
これらのキーワードは
KotlinではなくJavaで有効です
もしこれらのキーワードを使う
関数やパラメータがあると
Kotlinで呼び出すのに
問題があったかもしれません
例を見てみましょう
「is」というメソッドがあるとします
ひどい名前ですが 
Javaでは有効です
理論上は使えます
しかし これをKotlinから
呼び出そうとすると
問題が発生します
「is」は結果のワードだからです
一番良いのは
メソッドの名前を変えることです
このケースでは
確実にそれがベストです
しかし最終的には 広く適応して
使えるライブラリが必要でしょう
それから関数の名前を
変更できない場合があります
このケースでは
Kotlinからの呼び出し元は
「is」なしでは呼び出せません

Spanish: 
Y estas palabras clave son válidas
en Java pero no en Kotlin.
Entonces, si tienen una función
o un parámetro
que utiliza estas palabras clave,
podrían tener algunos problemas
para invocarla desde Kotlin.
Veamos un ejemplo.
Imaginen que tienen
un método que se llama is,
un nombre horrible, pero válido en Java.
Entonces, técnicamente, pueden hacer eso.
Pero si quieren invocarla desde Kotlin,
tendrán algunos problemas,
porque is es una palabra de resultado.
Bueno, lo mejor que pueden
hacer es cambiarle el nombre a su método.
En este caso,
sí, definitivamente es lo mejor.
Pero podrían tener una biblioteca
de amplia adopción y uso
y tal vez no puedan cambiar
el nombre a sus funciones.
En ese caso, lo que sucede
es que un invocante desde Kotlin
no podrá invocar sin is.
Entonces, sus usuarios necesitan ese is

Indonesian: 
Kata kunci ini valid
di Java, tetapi tidak di Kotlin.
Jadi, jika Anda memiliki
fungsi atau parameter
yang menggunakan kata kunci ini,
Anda mungkin mengalami masalah
saat memanggilnya dari Kotlin.
Mari kita lihat contohnya.
Misalnya Anda 
memiliki metode bernama is,
namanya buruk
memang, tetapi valid di Java.
Jadi secara teknis,
Anda bisa menggunakannya.
Tetapi jika ingin
memanggilnya dari Kotlin,
Anda akan mengalami masalah,
penyebabnya karena is adalah kata hasil.
Solusi terbaiknya adalah
mengganti nama metode Anda.
Dalam kasus ini,
sepertinya ini contoh paling tepat.
Tapi, Anda mungkin menggunakan 
library yang diadaptasi secara luas.
Dan Anda mungkin
tidak dapat mengganti nama fungsi Anda.
Jika demikian, 
yang terjadi adalah pemanggil dari Kotlin
tidak dapat memanggil tanpa [...]..
Jadi pengguna Anda memerlukan [...]

English: 
And these keywords are valid
in Java but not in Kotlin.
So if you have a function
or a parameter which
uses these keywords, you might
have some issues calling it
from Kotlin.
Let's see an example.
Let's imagine you have
a method called is,
which is a terrible
name, but valid in Java.
So technically, you can do that.
But if you want to
call this from Kotlin,
then you have some issues,
because is is a result word.
Well, the best thing you can
do is rename your method.
In this case, yes, it's
definitely the best case.
But in the end, you might
have a widely-adapted and used
library.
And you might not be able
to rename your functions.
In that case, what happens
is a caller from Kotlin
will not be able to call
without [INAUDIBLE]..
So your users need
that [INAUDIBLE]

Portuguese: 
Essas palavras-chave
são válidas no Java, mas não no Kotlin.
Se tiverem uma função ou um parâmetro
que use essas palavras-chave,
talvez ocorram problemas
ao chamá-los do Kotlin.
Vejamos um exemplo.
Suponhamos que haja
um método chamado "is",
um nome péssimo, mas válido no Java.
Tecnicamente, isso é possível.
No entanto,
se quiserem chamá-lo do Kotlin,
vocês terão problemas,
porque "is" é uma palavra de resultado.
O melhor a se fazer
é renomear o método.
Neste caso,
essa é definitivamente a melhor opção.
Porém, talvez vocês tenham
uma biblioteca bem adaptada e usada.
Assim, pode não ser possível
renomear as funções.
Nessa situação,
um autor da chamada do Kotlin
não poderá chamar
sem os sinais de acento grave.
Assim, os usuários precisam disso

Korean: 
이런 키워드는 Java에서 유효하지만 
Kotlin에서는 유효하지 않습니다
그래서 여러분의
함수나 매개변수에
이런 키워드가 있는 경우
Kotlin에서 호출했을 때
문제가 발생할 수 있어요
예를 하나 살펴봅시다
is라는 메서드가 있다고
생각해보세요
형편없는 이름이지만
Java에서는 유효하죠
기술적으로 가능합니다
하지만 Kotlin에서
이 메서드를 호출하려는 경우
문제가 발생합니다
is가 결과어가 아니기 때문이죠
최선의 방법은
메서드 이름을 다시 지정하는 것입니다
이 경우에는
이게 최선의 방법이죠
하지만 결국에는
많이 조정되어 사용되는 라이브러리가
생길 수 있습니다
함수의 이름을
다시 지정하지 못할 수 있어요
이 경우 Kotlin의 호출자인
is가 백틱 없이는
호출할 수 없는 경우가
발생할 거예요
따라서 사용자가
결과어 키워드에

Japanese: 
ユーザーは結果のキーワードに
アクセスするために
「is」が必要です
これは選択肢の一つで
ユーザーを損なうものではありません
しかし セミコロンを取り除くのに
とても時間がかかりました
ですから
ライブラリを機能させるために
新しい文字を
導入しないでください
名前を変更できる限り
それを使ってください
次の話題へ行きましょう
拡張機能や拡張プロパティで
Anyクラスの名前を
使用しないでください
実際には メンバメソッドと
パラメータが優先されますが
かなり混乱しやすいです
コードがどう続くのか
本当にたどりにくいです
次の話題は
演算子のオーバーロード
Javaには演算子の
オーバーロードはありません
Kotlinにはあります

Korean: 
액세스하려면
백틱이 필요합니다
이건 물론 선택 사항입니다
사용자를
방해하는 것은 아니에요
하지만 저희는
정말 많은 시간을 들여서
세미콜론을 없애려고 했습니다
그러니 그냥 라이브러리를
작동하게 할 목적으로
새 문자를 추가하지는 말아주세요
이름을 다시 지정할 수 있다면
그 방법을 사용하시기 바랍니다
다음은 다른 주제인데요
확장 함수와
확장 속성의 Any 이름을
되도록 사용하지 마세요
사실 member 메서드와
매개변수가 우선합니다
하지만 여전히 헷갈리죠
그리고 코드가 어떻게 실행되는지
따라가기가 힘들어요
다음 주제는
연산자 오버로드입니다
다시 말씀드리지만
Java에는 연산자 오버로드가 없어요
하지만 Kotlin에는 있습니다

English: 
to be able to access your
result word keyboards.
So that's definitely an option.
And it's not really
breaking your users.
But we really
spent a lot of time
getting rid of the semicolon.
So please, don't introduce
a new character just
to make your libraries work.
As long as you can
rename, go with that.
Next, we have another topic.
Try to avoid using the names
on any on extension functions
and extension properties.
Actually, member methods and
parameters take precedence.
But it's still very confusing.
And it's really hard to
follow how the code runs.
Next topic--
operator overloading.
Well again, Java did not
have operator overloading.
And Kotlin has.

Spanish: 
para poder acceder a sus palabras clave
de palabras de resultados.
Entonces, definitivamente es una opción.
Y no es terrible para el usuario.
Pero realmente
dedicamos mucho tiempo
para liberarnos del punto y coma.
Así que, por favor, no introduzcan
ningún caracter nuevo simplemente
para que sus bibliotecas funcionen.
Siempre que puedan
cambiar los nombres, elijan esa opción.
Ahora tenemos otro tema.
Traten de no utilizar los nombres
en ninguna función extensión
ni propiedad extensión.
En realidad, los métodos y parámetros
member prevalecen.
Pero sigue siendo muy confuso.
Y en realidad es difícil
seguir la ejecución del código.
Próximo tema:
sobrecarga de operadores.
Bueno, nuevamente, Java
no tiene sobrecarga de operadores.
Y Kotlin sí.

Portuguese: 
para conseguir acessar
as palavras-chave de resultado.
Definitivamente, essa é uma opção.
Isso não interrompe os usuários.
Mas demoramos bastante
para nos livrar do ponto e vírgula.
Então, não introduzam um novo caractere
somente para que sua biblioteca funcione.
Se vocês puderem renomear, façam isso.
Agora, temos outro tópico.
Evitem usar os nomes de "any"
em funções e propriedades de extensão.
Os métodos e parâmetros
de membro têm precedência.
Mas isso ainda é muito confuso.
É difícil acompanhar como o código opera.
Próximo tópico: sobrecarga do operador.
Mais uma vez,
o Java não tinha sobrecarga do operador.
O Kotlin tem.

Chinese: 
才能顺利调用保留关键字方法
这是一种做法
用户可以接受
不过 我们还是花了大量时间来消除这些符号
所以 请不要为了让代码库运行起来就加入新的字符
只要还能重命名 就请尽量重命名
下面是另一个话题
试着避免在任何扩展方法和扩展属性上使用 Any
其实 成员方法和参数优先级更高
但仍然会给用户造成很大困惑
很难搞清楚代码如何运行
下一个话题是 运算符重载
Java 不存在运算符重载
而 Kotlin 就有
这导致了一些副作用

Indonesian: 
agar dapat 
mengakses kata kunci hasil.
Jadi, Anda dapat menggunakan opsi itu.
Selain itu, tidak akan
mengganggu pengguna Anda.
Kami menghabiskan banyak waktu
untuk menghilangkan titik koma.
Tolong jangan 
memperkenalkan karakter baru hanya
untuk membuat library Anda berfungsi.
Selama Anda dapat 
mengganti namanya, ganti saja.
Selanjutnya, kami ada topik lainnya.
Cobalah menghindari
penggunaan nama pada properti ekstensi
dan fungsi ekstensi mana pun.
Sebenarnya, metode anggota
dan parameter akan diutamakan.
Meski begitu, masih tetap membingungkan.
Sulit untuk mengikuti cara kerja kode.
Topik selanjutnya
overloading operator.
Sekadar informasi, Java tidak
memiliki overloading operator ,
sedangkan Kotlin memilikinya.

Portuguese: 
Isso pode ter efeitos colaterais.
Primeiro, vejamos
como a sobrecarga do operador funciona.
O Kotlin converte o operador
em um nome de função.
Neste caso, digamos,
"+" torna-se um método
e recebe outro objeto.
Para exemplificar isso,
suponhamos que temos um objeto
chamado "RomanNumeral",
que representa um valor numérico na string
em algarismos romanos.
Queremos somar dois desses números
usando o sinal de adição
sem chamar um método novo.
Para fazer isso,
implementamos o método de adição.
Ele recebe outro algarismo romano,
os converte em um número,
soma os dois e os converte.
Se você usar a adição do lado do Kotlin,

Chinese: 
我们先来看看运算符重载如何工作
Kotlin 将运算符转译为了方法
在这里我们不妨假设 + 成为了方法
使用 + 并接收另一个对象
举个例子 我们想象一下 
有个对象名叫罗马数字
它用罗马数字字符串的形式来展示一个数值
我们想使用 + 符号在不调用新方法的前提下
把两个这样的数值加在一起
于是 我们就要实现一个 plus 方法
它接收另一个罗马数字 并将其转译为数字
再把它们加在一起 然后转译回去
这时如果你使用 Kotlin 的 + 运算符

Indonesian: 
Dan ini mungkin akan
menyebabkan efek samping.
Mari lihat cara 
kerja overloading operator.
Jadi, yang dilakukan Kotlin 
adalah menerjemahkan operator
menjadi nama fungsi.
Dalam kasus ini, misalnya
tanda plus menjadi metode, plus,
dan menerima objek lain.
Untuk memberikan contoh, bayangkan
kita punya objek bernama
Roman numeral, yang mewakili
nilai angka pada
string dalam angka Romawi.
Dan kita ingin menambahkan 
angka dua menggunakan tanda plus
tanpa memanggil metode baru.
Untuk melakukannya, 
kami mengimplementasi metode plus,
yang menerima 
angka Romawi lain, lalu mengubahnya
menjadi angka dan menambahkannya
kemudian dikonversi kembali.
Dan jika Anda
menggunakan plus dari sisi Kotlin,

Korean: 
이로 인해 부작용이
발생할 수도 있습니다
먼저 연산자 오버로드가
작동하는 방식을 알아봅시다
Kotlin이 실제로 하는 일은 이렇습니다
Kotlin은 연산자를
함수 이름으로 변환합니다
예를 들어 이 경우는
+가 메서드가 된다고 합시다
그리고 +에서
다른 객체를 수신하는 겁니다
예를 하나 들어보자면
이렇게 상상해보죠
RomanNumeral이라는
객체가 있다고 가정합시다
로마 숫자로 된 문자열의
숫자 값을 나타냅니다
새 메서드를 호출하지 않고
+ 기호를 사용해서
둘을 함께 더하려고 합니다
그렇게 하기 위해
+ 메서드를 구현하는데요
다른 로마 숫자를 수신한 다음
이를 숫자로 변환하고
이 둘을 함께 추가한 다음
다시 변환하는 거예요
Kotlin 측에서
+를 사용하는 경우

Spanish: 
Y esto podría tener
algunos efectos secundarios.
Primero veamos cómo funciona
la sobrecarga de operadores.
Entonces, lo que Kotlin hace en realidad
es traducir el operador y convertirlo
en un nombre de función.
En este caso, digamos,
plus se convierte en un método, plus,
y recibe otro objeto.
Para dar un ejemplo,
imaginemos que tenemos
un objeto llamado Roman numeral,
que representa un valor numérico
en cadenas de números romanos.
Y queremos sumar dos
con el signo más (plus)
sin invocar un método nuevo.
Para hacerlo, implementamos
un método plus,
que recibe otro número romano
y lo convierte
en un número romano y los suma,
volviendo a convertirlos.
Y si utilizan plus
desde el lado de Kotlin,

English: 
And this might have
some side effects.
Let's first see how
operator overloading works.
So what Kotlin actually does is
Kotlin translates the operator
into a function name.
In this case, let's say,
plus becomes a method, plus,
and receives another object.
To give an example on
this, let's imagine
we have a object called
Roman numeral, which
represents a number value
in string in Roman numerals.
And we want to add two
together by using plus sign
without calling a new method.
In order to do that, we
implement a plus method, which
receives another Roman
numeral then converts them
into a number and adds them
together-- converts them back.
And if you use plus
from Kotlin side,

Japanese: 
これにより副作用が
起こることがあります
まず 演算子のオーバーロードが
どう働くか見てみましょう
実際Kotlinが行うのは——
演算子を関数名に
翻訳することです
このケースでは
例えば plusがメソッドになり
他のオブジェクトを受け取ります
これについて例を挙げるなら——
「ローマ数字」という
オブジェクトがあり
それがローマ数字の文字列の
数値を表すとします
新しいメソッドを呼び出さずに
plus記号を使って
２つを加算したいとします
これを行うには
plusメソッドを実行し——
もう一つのローマ数字を受け取り
それを数字に変換して
足し算して元に戻します
Kotlin側からplusを使うと

Japanese: 
Kotlinはどのメソッドを呼び出すか
判断し実行します
ですから plusやminusなど——
メソッドと同じ演算子名が
ある場合は
それらが演算子と
互換性があることを確認し
誤って呼び出さないように
気を付けてください
演算子のオーバーロードについて
もう一つ
ある理由でJavaには——
演算子のオーバーロードが
ありませんでした
演算子のオーバーロードは
悪用されやすいためです
演算子を上書きする時は
有効なユースケースがあることを
確認してください
次は SAM
つまりSingle Abstract Method
1つのメソッドによる
機能的なインターフェイスです
Javaは匿名クラスで実装を書き
必要なインターフェースに
合わせて変換します
KotlinはSAMをサポートし——

Portuguese: 
ele saberá
qual método chamar e fará a operação.
Caso estejam usando
os mesmos nomes de método
para adição, subtração
ou outros operadores,
verifiquem se eles são
compatíveis com os operadores
e se vocês não os estão
invocando por engano.
Outra questão
referente à sobrecarga do operador
é que o Java não tinha essa sobrecarga
por um motivo específico:
a sobrecarga do operador
pode ser facilmente usada em excesso.
Confiram se é válido
substituir os operadores.
Em seguida, temos o SAM,
sigla em inglês de
"método abstrato único".
Ou seja,
uma interface funcional com um método.
O Java usa uma implementação anônima
e a converte na interface necessária.
O Kotlin é compatível com o SAM.
Os literais de função
são convertidos automaticamente,

Spanish: 
Kotlin sabe qué método
invocar y qué operación hacer.
Entonces, si están usando
los mismos nombres de métodos:
plus, minus u otros nombre de operadores;
asegúrense de que sean
compatibles con los operadores
y de que, básicamente,
no estén invocándolos por error.
Y otro aspecto
de la sobrecarga de operadores
es que Java, en su momento,
no tenía sobrecarga de operadores
por un motivo específico:
es fácil usar mal y excesivamente
la sobrecarga de operadores.
Asegúrense de tener un caso práctico
válido para sobrescribir los operadores.
Después tenemos SAM,
que es la sigla de Single Abstract Method;
eso quiere decir una interfaz funcional
con un método.
Java toma la implementación anónima
y la convierte en la interfaz requerida.
Y Kotlin admite SAM.

English: 
Kotlin knows which method
to call and do operation.
So make sure, if you're using
the same method names-- plus,
minus, or other operator names--
make sure they are
compatible with the operators
and you are not basically
invoking them by mistake.
And another thing about
operator overloading is--
Java, at the time, didn't
have operator overloading
for a specific reason.
Because operator overloading can
be easily abused and overused.
Make sure you have a valid
use case to overwrite
the operators.
Next, we have SAM, which
stands for Single Abstract
Method, which means a functional
interface with one method.
Java takes an anonymous
implementation
and converts it to the
interface required.
And Kotlin supports SAM.

Korean: 
Kotlin은 어떤 메서드를 호출해서
연산을 해야 할지 압니다
그래서 플러스나 마이너스
다른 연산자 이름처럼
동일한 메서드 이름을 사용하는 경우
이들이 연산자와
호환되는지 확인하고
실수로 호출해서는 안 됩니다
연산자 오버로드에 대한
또 다른 사항이 있습니다
이때 Java는 
특정한 이유 때문에
연산자 오버로드가 없었어요
연산자 오버로드는
오용과 남용이 쉽기 때문이죠
연산자를 덮어쓰려면
유효한 사용 사례가 있는지
반드시 확인하세요
다음은 SAM입니다
Single Abstract Method의 약자죠
하나의 메서드가 있는
함수형 인터페이스를 의미합니다
Java는 익명의 구현 작업을 하고
필요한 인터페이스로 변환합니다
그리고 Kotlin은 SAM을 지원합니다

Chinese: 
Kotlin 就会知道应该调用哪个方法 用哪个方法运算
如果你用的是同样的方法名称 
也就是 加 (plus) 减 (minus) 或其他运算符名称
那么请务必确保它们与运算符兼容
避免意外调用它们
关于运算符重载 还有一个问题
Java 目前没有运算符重载 是有理由的
因为运算符重载是很容易被滥用的
请务必只在合适的用例里使用运算符重载
下面 我们还有 SAM
这个缩略词的含义是 “单一抽象方法”
也就是说 带有一个方法的接口
Java 使用匿名的实现 并将其转化为需要的接口
而且 Kotlin 支持 SAM
只要参数类型符合

Indonesian: 
Kotlin tahu metode mana yang harus
dipanggil & melakukan operasi penambahan.
Pastikan jika Anda 
menggunakan nama metode yang sama,
plus, minus, atau nama operator lainnya,
pastikan nama kompatibel dengan operator
dan Anda tidak salah memanggil.
Dan yang perlu Anda tahu 
tentang overloading operator adalah
Java, pada saat itu, tidak 
memiliki overloading operator
karena alasan tertentu.
Overloading operator mudah
disalahgunakan dan digunakan berlebihan.
Pastikan Anda punya alasan yang valid
untuk mengganti operator.
Selanjutnya ada SAM,
yakni Single Abstract Method,
yang berarti antarmuka
fungsional dengan satu metode.
Java mengambil implementasi anonim
dan mengubahnya menjadi
antarmuka sesuai keperluan.
Dan Kotlin mendukung SAM.

Spanish: 
Los valores literales de la funciones
se autoconvierten
siempre que coincidan
los tipos de parámetros.
Si el parámetro que reúne
los requisitos para la conversión SAM
es parte de la invocación del método,
el parámetro debe ser el último.
Y veamos lo que sucede.
Imaginemos que tenemos
una operación
que reúne los requisitos
para la conversión SAM, y dos parámetros,
que son dos números.
Para invocar esto desde Kotlin,
lo que tenemos que hacer es,
primero, pedir el lambda,
luego, los dos números.
Sin embargo, si cambiamos
el orden de los parámetros,
repentinamente la invocación
desde Kotlin se simplifica mucho.
Y, aparentemente, lo que dije
sobre SAM no fue suficiente.
Por eso, Wenbo tiene más por agregar
a partir de su experiencia real
con la aplicación Google Home.
Gracias, Murat.

Japanese: 
無名関数はパラメータタイプが
マッチする限り自動変換されます
SAM変換の対象となる
パラメーターの場合——
メソッド呼び出しの一部ですが
パラメータは最後になります
何が起こるか見てみましょう
SAM変換を使用できる操作と——
数字である2つのパラメーターが
あるとします
これをKotlinから呼び出すには
まずLambdaでaskを使い
2つの数字を呼び出します
ところが パラメータの
順番を変えてみると
Kotlinからの呼び出しが
とても良くなります
SAMについての話は
これでは十分でないでしょう
Google Homeアプリでの実体験から
ウェンボーが
さらに話してくれます
ありがとう ムラト

Indonesian: 
Literal fungsi 
dikonversi secara otomatis selama
tipe parameter cocok.
Jika parameter,
yang memenuhi syarat untuk konversi SAM,
yang merupakan bagian 
dari pemanggilan metode,
parameter harus berada di posisi akhir.
Dan kita lihat apa yang terjadi.
Bayangkan kita memiliki operasi,
yang memenuhi syarat untuk
konversi SAM, dan dua parameter
berupa dua angka.
Untuk memanggilnya dari Kotlin,
yang harus kita lakukan adalah
meminta lambda, lalu dua angka.
Namun, jika kita 
mengubah susunan parameter,
pemanggilan dari
Kotlin tiba-tiba jadi lebih baik.
Dan sepertinya bahasan saya 
tentang SAM masih kurang.
Jadi Wenbo akan menjelaskan 
lebih lanjut apa yang dialaminya
saat menangani aplikasi Google Home.
-Terima kasih, Murat.

Korean: 
함수 리터럴은
매개변수 유형이 일치하는 한
자동 변환됩니다
매개변수가
SAM 변환 자격이 있는 경우
메서드 호출의 일부인데요
매개변수는 마지막이 되어야 합니다
어떻게 되는지 한번 보죠
SAM 변환 자격이 있는 연산과
숫자 두 개로 된
매개변수 두 개가 있다고
상상해봅시다
Kotlin에서 호출하기 위해
필요한 작업은 이렇습니다
먼저 Lambda를 요청하고
숫자 두 개를 요청합니다
하지만 매개변수의 순서를 변경하면
Kotlin에서의 호출이
금세 훨씬 좋아집니다
제가 SAM에 대해 충분히
얘기하지 않은 것 같은데요
원보가 Google Home 앱 작업에서
실제로 사용했던 사례와 함께
이 주제에 대해
더 자세히 알려줄 겁니다
고마워요, 무랏

Portuguese: 
desde que os tipos
de parâmetro sejam correspondentes.
Se o parâmetro,
qualificado para conversão SAM,
for parte da chamada do método,
ele será o último.
Vejamos o que acontece.
Suponhamos que temos uma operação
qualificada para conversão SAM
e dois parâmetros que são dois números.
Para chamar do Kotlin,
precisamos primeiro solicitar o lambda
e depois os dois números.
No entanto,
se mudarmos a ordem dos parâmetros,
a chamada do Kotlin será mais simples.
Aparentemente, o que eu falei
sobre o SAM não foi suficiente.
O Wenbo tem mais a dizer
sobre a experiência dele na vida real
no app Google Home.
Obrigado, Murat!
Sobre a conversão SAM,

English: 
Function literals are
auto-converted as long
as the parameter types match.
If the parameter, which is
eligible for SAM conversion--
it's part of the method call--
the parameter
should be the last.
And let's see what happens.
So let's imagine we
have an operation, which
is eligible for SAM conversion,
and two parameters, which
are two numbers.
To call this from Kotlin,
what we need to do
is, first, ask the lambda,
then the two numbers.
However, if we change
the order of parameters,
suddenly the call from
Kotlin becomes way nicer.
And apparently, what I talked
about SAM was not enough.
So Wenbo has more to add
from his real-life experience
from Google Home app.
WENBO ZHU: So thank you, Murat.

Chinese: 
方法就会自动完成转换
如果符合 SAM 转译标准的参数
是方法调用的一部分
该参数应该在最后
我们来看看会发生什么
假如有一个符合 SAM 转译标准的运算
以及两个参数 也就是两个数字
想要用 Kotlin 来调用它们
我们需要做的就是
首先 写好 lambda 再到后面加上这两个数字
然而 如果我们更改参数的顺序
那么 Kotlin 调用起来就好很多
显然 靠 SAM 本身是不够的
所以 有请 Wenbo 来使用
他在 Google Home 应用中的实际经验为我们补充说明
谢谢 Murat

Chinese: 
说到 SAM 转译 有些东西是大家一定要了解的
SAM 转译仅适用于 Java 到 Kotlin 
也就是说 如果我们使用一个
Kotlin 语言写了一个接口 里面有一个方法
以及一个接收这个接口实例的方法
然后使用 SAM 转译来调用它
就会得到一个编译时错误
为了解决问题 我们可以把实例传入匿名类
并由这个匿名类来实现接口
Kotlin 之所以不支持 SAM 转译 原因在于
Kotlin 将方法作为对象进行支持
所以不需要 SAM 转译
所以 如果我们改变之前提到过的方法
并使其能接收方法类型
那么我们就可以按照和 SAM 转译一样的方式来调用它
但是 如果接口是使用 Java 来写的
而方法却仍然是用 Kotlin 写的 这时会怎样呢？
这样算是和 Java 实现了互操作吗？

English: 
So speaking of SAM
conversion, I think there's
something you should know.
A SAM conversion only
works for Java and Kotlin.
So what this means
is that, if we
have defined a
interface in Kotlin
with a single matter
and a function that
takes in an instance
of this interface--
if we try to invoke this
using SAM conversion,
we will get a
compile time error.
To make this work, we
can pass in the instance
of an anonymous class, which
implements this interface.
So the reason that
SAM conversion is not
supported in Kotlin is that
Kotlin supports function types
as first-class citizens, so
SAM conversion is not needed.
So if we change the
previous function
to take in a function
type, then we
can invoke this the
same way as if we
were using a SAM conversion.
But what if the interface
is defined in Java
and the function
is still in Kotlin?
Does this count as Java Interop?

Indonesian: 
Bicara tentang
konversi SAM, sepertinya ada
hal yang perlu Anda tahu.
Konversi SAM 
hanya berfungsi untuk Java dan Kotlin.
Ini berarti,
jika kita menentukan antarmuka di Kotlin
dengan satu substansi dan satu fungsi
yang jadi instance
dalam antarmuka ini,
jika kita mencoba
memanggilnya dengan konversi SAM,
akan muncul
error waktu kompilasi.
Agar berfungsi, 
kita dapat menampilkan instance
dari kelas anonim,
yang mengimplementasi antarmuka ini.
Jadi alasan konversi SAM
tidak didukung di Kotlin
adalah karena Kotlin mendukung tipe fungsi
seperti warga kelas atas, jadi
konversi SAM tidak diperlukan.
Jika mengubah fungsi sebelumnya
untuk memahami tipe fungsi, kita
dapat memanggilnya dengan cara yang sama,
seperti saat menggunakan konversi SAM.
Tetapi bagaimana kalau
antarmuka ditentukan di Java
dan fungsi masih di Kotlin?
Apakah ini termasuk Java Interop?

Japanese: 
SAM変換と言えば
知っておくべきことがあります
SAM変換はJavaとKotlinでのみ
機能します
つまり Kotlinで
インターフェースと
このインターフェースの
インスタンスを受け取る——
関数を定義した場合
SAM変換を使用して
これを呼び出そうとすると
コンパイル時エラーが発生します
これを機能させるために
インターフェースを実装する——
匿名クラスのインスタンスを
渡します
SAM変換がKotlinで
サポートされていないのは
Kotlinは関数型を——
第一級オブジェクトとして
サポートするので
SAM変換は必要ないからです
前の関数を変更して
関数タイプを取り込む場合
SAM変換を使用する場合と
同じ方法で
これを呼び出すことができます
では インターフェースが
Javaで定義され——
関数はKotlinにある場合は？
これはJavaの相互運用に
なるのでしょうか？

Korean: 
SAM 변환에 대해서 말하자면
몇 가지 알아두셔야 할 게 있습니다
SAM 변환은 Java와
Kotlin에서만 작동해요
무슨 뜻이냐면
Kotlin의 인터페이스를 정의할 때
단일 문제와 함수를 통해서 정의하고
이 함수가 인터페이스의
인스턴스를 취하는 경우
SAM 변환을 이용해서
호출하려고 하면
컴파일 시간
오류가 발생한다는 겁니다
제대로 작동하게 하려면
인스턴스를 전달하면 됩니다
이 인터페이스를 구현하는
익명 클래스의 인스턴스를요
Kotlin에서 SAM 변환이
지원되지 않는 이유는
Kotlin이 함수 유형을
우선적으로 지원해서
SAM 변환이
필요 없기 때문이에요
그래서 함수 유형을 취하기 위해
이전 함수를 바꾸는 경우
SAM 변환을 사용하는 것과
동일한 방식으로
호출할 수 있습니다
하지만 인터페이스는
Java로 정의되어 있고
함수는 아직 Kotlin으로
정의되어 있으면 어떨까요?
Java Interop로 간주할까요?

Spanish: 
Ya que hablamos de la conversión
SAM, creo que hay
algo que tienen que saber.
Una conversión SAM
solo funciona para pasar de Java a Kotlin.
Eso quiere decir que,
si definimos una interfaz en Kotlin
con un asunto único y una función
que incorpora una instancia
de esta interfaz,
si tratamos de invocarlo
con la conversión SAM,
recibiremos un error
de tiempo de compilación.
Para que esto funcione,
podemos transferir la instancia
de una clase anónima,
que implementa esta interfaz.
Entonces, el motivo
por el que la conversión SAM
no es compatible en Kotlin
es que Kotlin admite tipos de funciones
como ciudadanos de primera clase,
así que la conversión SAM no es necesaria.
Entonces, si cambiamos la función anterior
para que incorpore un tipo de función,
podremos invocarla de la misma manera
que si estuviéramos usando
una conversión SAM.
Pero, ¿qué sucede si la interfaz
se define en Java
y la función sigue estando en Kotlin?
¿Eso se considera como
interoperabilidad con Java?

Portuguese: 
acredito que há algo
que vocês precisem saber.
Uma conversão desse tipo
só funciona na interoperação com Java.
Ou seja, se definirmos
uma interface no Kotlin
com um único método e uma função
que incorpore uma instância da interface,
ao tentar invocá-la
usando a conversão SAM,
teremos um erro
durante a compilação.
Para funcionar, podemos passar
a instância de uma classe anônima,
que implementa essa interface.
As conversões SAM
não são compatíveis com o Kotlin
porque ele aceita os tipos de função
como objetos de primeira classe.
Assim, a conversão SAM é desnecessária.
Se alterarmos a função anterior
para incorporar um tipo de função,
poderemos invocá-la
da mesma forma que faríamos
se estivéssemos usando uma conversão SAM.
Mas e se a interface
estiver definida no Java
e a função estiver no Kotlin?
Isso conta como uma interoperação Java?

Spanish: 
La respuesta sigue siendo que no,
porque, en ese momento,
siguen codificando una función de Kotlin,
que tiene la opción de incorporar
un tipo de función.
Por lo tanto, la conversión SAM
sigue no siendo compatible.
Ahora, Nicole les hablará
sobre cómo invocar Kotlin desde Java,
Gracias Wenbo.
Kotlin y cómo invocar Kotlin desde Java.
Sí: eso tiene sentido.
OK, perfecto.
Cuando inicialmente anunciamos
Kotlin como un lenguaje compatible,
recomendamos hacer
la conversión en pasos.
Es decir, si les interesa
rescribir su aplicación
en Kotlin en un solo paso,
fantástico.
La mayoría de las veces,
no podríamos hacerlo.
Entonces, recomendamos
hacerlo por pasos.

Korean: 
아직은 아닙니다
지금 시점에서는
함수 유형을
취하는 옵션이 있는
Kotlin 함수를
코딩하고 있기 때문이죠
따라서 SAM 변환은
아직 지원되지 않습니다
다음으로 니콜이 Java에서의
Kotlin 호출에 대해 설명할 겁니다
감사합니다
Java에서 Kotlin 호출하기
주제가 이렇게 되어 있죠?
좋아요
시작할게요
저희가 Kotlin을 지원 언어로
처음 발표했을 때
단계별로
변환할 것을 권장했습니다
무슨 뜻이냐면
몰론, 앱을 Kotlin으로
재작성하는 데
관심이 있는 분이 있었다면
그것도 좋죠
하지만 대부분의 경우
그렇게 할 수 없습니다
그래서 한 번에
조금씩 진행할 것을 권장했죠

Portuguese: 
A resposta ainda é não,
porque, nesse momento,
você ainda está codificando
uma função Kotlin com a opção
de usar um tipo de função.
Portanto,
a conversão SAM continua não compatível.
Agora, a Nicole falará
sobre como chamar o Kotlin do Java.
Obrigada, Wenbo!
Como chamar o Kotlin do Java.
Isso faz sentido.
Ótimo!
Quando anunciamos
o Kotlin como uma linguagem compatível,
recomendamos fazer a conversão em etapas.
Se você quisesse reescrever
seu aplicativo no Kotlin de uma vez,
tudo bem.
Mas, na maioria das vezes,
não era possível.
Assim, recomendamos fazer por partes.

Indonesian: 
Jawabannya adalah
tidak, karena saat ini,
Anda membuat kode dengan fungsi Kotlin
yang memiliki opsi
untuk mengambil tipe fungsi.
Jadi, konversi SAM masih belum didukung.
Selanjutnya, Nicole akan bahas
pemanggilan Kotlin dari Java.
-Terima kasih, Wenbo.
Kotlin dan memanggil Kotlin dari Java.
Benar, itu masuk akal.
Sempurna.
Jadi saat pertama kali mengumumkan
Kotlin sebagai bahasa yang didukung,
kami merekomendasikan untuk
mengonversi dalam beberapa langkah.
Maksud saya,
jika Anda tertarik menulis ulang 
seluruh kode aplikasi Anda di Kotlin,
itu bagus.
Namun sepertinya
kita tidak dapat melakukannya.
Jadi kami merekomendasikan 
untuk merombaknya sedikit demi sedikit.

English: 
The answer is still no,
because at this moment,
you're still coding a
Kotlin function, which
has the option to
taking a function type.
Therefore, SAM conversion
is still not supported.
And next, Nicole will talk
about calling Kotlin from Java.
NICOLE BORELLI: Thanks, Wenbo.
So yes-- Kotlin and
calling Kotlin from Java.
Yes-- that makes sense.
OK-- so perfect.
So when we initially announced
Kotlin as a supported language,
we recommended doing
conversion in steps.
I mean, if you were interested
in re-writing your app
in Kotlin all at once--
awesome.
But most of the time,
we couldn't do that.
So we recommended doing
little bits at a time.

Japanese: 
答えは やはりノーです
なぜならKotlinの関数がコーディングし
関数型を取る
オプションがあるからです
ですから SAM変換は
やはりサポートされません
ではここで ニコルが
次のトピックを話します
ありがとう ウェンボー
では KotlinとJavaからの
Kotlin呼び出しについてです
これには意味があります
オーケイ
サポートされた言語として
Kotlinを発表した時——
段階的な変換を推奨していました
Kotlinでアプリをすべて一度に
リライトできたら すごい
でも ほとんどうまく行かず
だから少しずつやるよう
お勧めしていたのです
でも ユーティリティクラスの
変換は——

Chinese: 
答案仍然是否定的 因为目前
你在编写的仍然是一个 Kotlin 方法
而它是可以接收方法的
因此仍然不支持 SAM 转译
接下来 Nicole 会和大家谈谈
使用 Java 调用 Kotlin
谢谢 Wenbo
如何使用 Java 调用 Kotlin 
这样说得通 好 好极了
我们最初是把 Kotlin 作为辅助语言发布的
我们建议大家逐步转到 Kotlin
如果大家想要用 Kotlin 重写整个应用的话
那当然更好
不过大多数时候 我们做不到这一点
所以 我们建议大家一次做一点

Japanese: 
皆さんの期待に沿う
ものかもしれません
たとえば utils.javaクラスが
あるとしましょう
これをKotlinで
変換しようと思います
こうします
この例では 一つのメソッドを取り出し
dates.ktに入れます
そして それを
拡張メソッドにしました
これはすごい
でも Javaプログラミング言語から
これを呼び出そうとすると
クラスに入れる必要があります
ですから dates.ktについて
Javaプログラミング言語の——
すべてのコードを
リファクタリングするか
ここで何かを行う必要があります
うまいことに Kotlinは
JVM名をサポートします
つまり 拡張メソッドを
使うだけなので
Kotlinの心配は要りません

Korean: 
지금은 유틸리티 클래스를 
변환하는 작업을
진행하려는 분들도 있을 거예요
Utils.java 클래스가 있다고
가정해보겠습니다
그리고 이 클래스를
Kotlin으로 변환하려고 합니다
그래서 이렇게 작업했어요
이 예시에서
메서드 하나를 가져와서
Dates.kt에 넣었습니다
그리고 이 메서드를
확장 메서드로 만들었어요
아주 좋습니다
하지만 이 메서드를
Java 프로그래밍 언어에서 호출하려면
메서드를
클래스에 넣어야 해요
그리고 이걸
DatesKt라고 부를 거예요
여기에서
Java 프로그래밍 언어 코드를
모두 리팩터링하거나
다른 작업을 해야 합니다
다행히 Kotlin은
이 Jvm Name을 지원합니다
그래서 Kotlin에서는
걱정할 필요가 없습니다
그냥 확장 메서드를
사용할 거니까요

Spanish: 
Pero ahora, quizás quieran convertir
clases de utilidades.
Digamos que tenemos
nuestra clase utils.java.
Y queremos convertirla a Kotlin.
Entonces hacemos esto.
Y, en este ejemplo,
recurrimos a nuestro método
y usamos dates.kt.
Y solo lo convertimos
en un método de extensión.
Y es maravilloso.
Pero si quisiéramos invocarlo
desde el lenguaje de programación Java,
tenemos que incorporarlo a una clase.
Entonces se llamará dates.kt,
y necesitamos reestructurar
todo nuestro código en lenguaje
de programación Java
o hacer algo aquí.
Afortunadamente, Kotlin
admite este nombre JVM.
En lo que a Kotlin se refiere,
no tenemos que preocuparnos
porque solo utilizaremos
el método de extensión.

Indonesian: 
Tetapi, mengonversi kelas utilitas
mungkin jadi hal yang ingin Anda lakukan.
Misalnya kita punya class utils.java.
Dan ingin mengonversinya ke Kotlin.
Kita akan menulis ini.
Dan pada contoh ini,
kita menggunakan satu metode
dan meletakkan [...] dates.kt.
Dan kita membuatnya jadi metode ekstensi.
Dan ini bagus.
Tetapi jika ingin memanggilnya 
dari bahasa pemrograman Java,
kita harus meletakkannya ke dalam class.
Lalu class akan
memanggil dirinya sebagai dates.kt,
ada dua pilihan:
ubah semua struktur kode Java kita
atau kita cari cara lain.
Dan untungnya Kotlin
mendukung JvmName ini.
Jadi dari Kotlin,
kita tidak perlu khawatir.
karena kita cukup
menggunakan metode ekstensi.

Chinese: 
不过现在 大家也许可以试着完成实用类的迁移
假如我们的类叫 Utils.java 吧
我们想要把它转换为 Kotlin
于是我们这样做了
在这个例子中 我们抽取了唯一的方法
并将其放进了 Dates.kt
把它变成一个扩展方法 
很好
不过 如果我们想要从 Java 语言来调用它
就需要把它放进一个类里
称为 DatesKt
接下来 我们要么重构所有 Java 代码
要么就另想办法
幸运的是 Kotlin 支持这个 JvmName
使用 Kotlin 调用 就没什么可担心的
因为我们可以直接使用扩展方法

Portuguese: 
Mas agora,
a conversão de classes utilitárias
pode ser algo interessante a se fazer.
Digamos que temos a classe Utils.java
e queremos convertê-la para o Kotlin.
Fazemos isso.
Neste exemplo, extraímos um método
e inserimos em um Dates.kt.
Fizemos isso em um método de extensão.
Ótimo.
No entanto, se quiséssemos chamar
a partir da linguagem de programação Java,
seria necessário inserir em uma classe.
Ela se chamará "DatesKt".
Precisamos
reformular todo o código Java
ou buscar uma alternativa aqui.
Felizmente, o Kotlin
é compatível com JvmName.
No Kotlin,
não temos que nos preocupar.
Basta usarmos o método de extensão.

English: 
But now, converting
utility classes
might be something that
you would want to do.
So let's say that we have
our utils.java class.
And we want to go and
convert this to Kotlin.
So we do this.
And in this example, we
pulled out our one method
and we put in a
[INAUDIBLE] dates.kt.
And we just made it into
an extension method.
And it is great.
But if we wanted to call this
from the Java programming
language, it needs to
put it into a class.
And so it will call
itself dates.kt--
which we either need to refactor
all of our Java programming
language code or we need
to do something here.
And fortunately, Kotlin
supports this JVM name.
So from Kotlin, we
don't have to worry,
because we're just going to
use the extension method.

Spanish: 
Desde el lenguaje
de programación Java,
podemos cambiar la clase
que se genera a utils.
También podríamos tener otros métodos
presentes en esta clase utils.
Entonces podríamos tener métodos
de cadena o diversos números
y esa clase de cosas.
Y es posible que queramos invocar
más de una de estas utils.
Entonces, lo que podemos hacer es agregar
esta clase multiarchivo JVM.
Y combinará todo este código
para crear una clase
llamada utils.class al final.
Y después con esto
ya implementado, nuestro código Java
permanece exactamente igual.
Otro excelente elemento
de Kotlin son las clases de datos.
Y ya escuchamos hace un momento

Portuguese: 
No Java, podemos alterar
a classe gerada para utils.
Também podemos ter outros métodos
que estavam nessa classe utils.
Podem ser métodos de string
ou números, esse tipo de coisa.
Pode ser que precisemos
chamar mais de um desses utils.
Então, também podemos adicionar
JvmMultifileClass.
Com isso, o código será combinado
para criar a classe "utils.class".
Assim, o código Java
permanece exatamente o mesmo.
Outro ótimo item
no Kotlin são as classes de dados.

Indonesian: 
Dari Java,
kita dapat mengubah 
kelas yang dibuat ke utils.
Kita mungkin juga punya metode 
lain yang berada di kelas utils ini.
Jadi kita mungkin punya 
metode string atau berbagai angka,
dan semacamnya.
Dan kita mungkin ingin
punya lebih dari satu utils.
Jadi hal lain harus dilakukan adalah
menambahkan JvmMultifileClass.
Dan tindakan ini akan
menyatukan semuanya dengan kode
untuk membuat satu
class bernama utils.class.
Dengan adanya class ini,
tidak akan ada yang berubah
pada kode Java kita.
Keunggulan lain 
yang dimiliki Kotlin adalah class data.
Sebelumnya dijelaskan bahwa

Korean: 
Java 프로그래밍 언어에서는
Utils에 생성되는 클래스를
변경할 수 있어요
이 Utils 클래스에 있었던
다른 메서드가 있을 수도 있죠
그래서 String 메서드나 다양한 숫자 등
다른 메서드가 있을 수 있어요
그리고 하나 이상의 메서드를
Utils라고 부르고 싶을 수도 있습니다
그래서 JvmMultifileClass를
추가할 수도 있어요
그리고 이 모든 것을
바이 코드로 함께 결합해서
Utils.class라는
하나의 클래스가 생성됩니다
그리고 이 모든 게 준비되면
Java 코드는
정확히 똑같이 유지됩니다
Kotlin의 또 다른 장점은
데이터 클래스입니다
앞에서
getter와 setter에 대해

Chinese: 
如果使用 Java 语言
我们可以更改那个生成的类为 Utils
在这个 Utiles 类中 我们可能还有其他的方法
我们可能会有字符串方法 或各种数字方法之类的
我们可能会需要更多这种 Utils
所以 我们还可以添加这个 JvmMultifileClass
它会通过代码来整合这一切
最后创建出一个名叫 utils.class 的类
在它就位之后 我们就无需修改 Java 代码了
Kotlin 的另一个优点就是数据类

English: 
>From the Java
programming language,
we can change the class that
gets generated to utils.
We also might have other methods
that were in this utils class.
So we might have string
methods or various numbers
and that sort of thing.
And we might want to have more
than one of these called utils.
So what we can also do is add
this JVM multi file class.
And it will combine
all of this by code
together to create one class
called utils.class at the end.
And then with this in
place, our Java code
stays exactly the same.
Another great thing in
Kotlin are data classes.
And we heard a
little bit earlier

Japanese: 
Javaプログラミング言語から
生成されるクラスを
utilsに変更できます
このutilsクラスに他のメソッドも
あるかもしれません
Stringのメソッドや
さまざまな数字なども
あるでしょう
こうしたutilsは複数あった方が
いいかもしれません
このJVMの複数ファイルの
クラスを追加することもできます
これらをすべて
コードで組み合わせて
最後にutils.classという
1つのクラスを作成します
こうすることによりJavaコードは
まったく同じまま変わりません
もう一つ Kotlinの素晴らしい点は
データクラスです
少し前に getterやsetterについて——

Portuguese: 
Ouvimos há pouco que não precisamos
nos preocupar com getters e setters.
No entanto,
se estivéssemos usando essas classes,
acessando diretamente o campo,
e as convertêssemos nas classes de dados,
teríamos os getters e setters.
Assim, no Java,
as chamadas são feitas com os getters.
Em vez disso, podemos atualizá-los
para usar "JvmField".
Assim, os campos
serão expostos diretamente,
sem a criação de getters e setters.
Isso pode ser feito para outras coisas.
Aqui não funcionará
porque há uma função por trás.
Assim, não há campo a expor.
Os "lateinits" são expostos
automaticamente como campos.
O mesmo vale para os "consts".

Chinese: 
之前我们听说 我们不应担心 getter 和 setter
但是 如果我们使用这些类
直接访问字段 把它们转译为数据类
就会有这些 getter 和 setter
那在 Java 里我们就需要用 getter 调用它们
我们可以修改它们 让它们使用 JvmField 
这样一来 无需创建 getter 和 setter 就能直接把字段暴露出去
我们在其他地方也可以这么做
这个代码其实不对 因为
它背后还有一个功能
没有需要暴露的字段
lateinit 会自动作为字段暴露 
const 也是如此

Japanese: 
もう悩まなくていいという
話がありました
でも これらのクラスを使って
フィールドに直接アクセスし
データクラスに変換する場合
getterやsetterを使います
Javaプログラミング言語から
getterを通してこれらを
呼び出す必要があります
代わりにJvmfieldを使えるように
アップデートすることもできます
これはgetterやsetterを
作成することなく——
フィールドを直接公開します
これは他のことに使えます
実はこれは機能しません
なぜなら——
背後に関数があるからです
公開されるフィールドは
ありません
lateinitが自動的に
フィールドとして公開されます
constも同じです

English: 
that we shouldn't worry
about getters and setters.
But if we were using these
classes, directly accessing
the field, and we converted
them to data classes,
we would have these
getters and setters.
And so from the Java
programming language,
we need to call these
through getters.
What we can do instead is we
can update them to use Jvmfield.
And this will expose
the field directly
without creating
getters and setters.
We can do these
for other things.
This won't actually
work, because it
has a function behind it.
So there is no field to expose.
Lateinits are automatically
actually exposed as fields
and so are consts.

Korean: 
걱정할 필요 없다는
이야기를 들으셨죠
하지만 이 클래스를 사용하고
필드에 직접 액세스하고
데이터 클래스로 변환하는 경우
getter와 setter가 있어야 합니다
Java 프로그래밍 언어에서
getters를 통해
클래스를 호출해야 해요
아니면 클래스를 업데이트해서
JvmField를 사용할 수도 있습니다
이렇게 하면
getter와 setter를 생성하지 않고
필드를 직접 노출하게 되죠
다른 곳에도
이 방식을 사용할 수 있습니다
사실은 이렇게 하면
작동하지 않을 거예요
이면에 함수가 있거든요
노출할 필드가 없는 거죠
실제로는 lateinits가
필드로서 자동으로 노출됩니다
consts도 동일하고요

Spanish: 
que no deberíamos preocuparnos
por recuperadores y colocadores.
Pero si estuviéramos utilizando
estas clases, accediendo directamente
al campo, y las convertimos
en clases de datos,
tendríamos estos
recuperadores y colocadores.
Entonces, desde el lenguaje
de programación Java
tenemos que invocarlos
a través de recuperadores.
En cambio, lo que podemos hacer es
actualizarlos para que utilicen jvmfield.
Y con esto se expondrá
el campo directamente
sin crear recuperadores ni colocadores.
Podemos hacerlo para otras cosas.
Esto en realidad no funcionará,
porque tiene una función detrás.
Entonces, no hay ningún campo que exponer.
Las lateinits en realidad
se exponen automáticamente como campos
y por eso son constantes.

Indonesian: 
kita tidak perlu khawatir
dengan getter dan setter.
Tetapi jika kita menggunakan
kelas ini, langsung mengakses field,
lalu mengonversinya menjadi class data,
kita akan memiliki getter dan setter.
Dan dari Java,
kita harus memanggilnya melalui getter.
Sebagai gantinya, kita dapat 
mengupdatenya untuk menggunakan JvmField.
Dan tindakan ini
akan langsung mengekspos field
tanpa membuat getter dan setter.
Kita dapat menggunakannya untuk hal lain.
Langkah ini tidak bekerja dengan
baik, karena ada fungsi di balik class.
Jadi tidak ada field yang diekspos.
Lateinit sebenarnya
otomatis diekspos sebagai field.
begitu pula dengan const.

Indonesian: 
Jadi, ada alasan untuk 
menggunakan JvmField pada kata kunci ini.
Oke, jadi kita punya class data lain.
Dan karena getter dan setter,
class data membuat getter dan setter
saat kita mengompilasinya.
Dan ini bagus.
Jadi kita punya nama.
Dan kita punya getName dan setName.
Kita punya likesPink,
karena kita ingin
pengguna tahu bahwa kita suka warna pink.
Tetapi ini 
membuat get jadi likesPink ketimbang
menggunakannya secara langsung.
Jadi yang kita lakukan adalah
menambahkan beberapa anotasi.
Kita dapat menggunakan JvmName.

Korean: 
여기에 Jvmfield를
사용할 필요가 없죠
좋아요
여기 다른 데이터 클래스가 있습니다
이 클래스를 컴파일링하면
getter와 setter 때문에
getter와 setter를
생성할 거예요
아주 좋죠
여기에 이름이 있고요
getName과 setName이 있어요
LikesPink가 있는데요
사용자가 분홍색을 좋아하는지
알고 싶기 때문입니다
그래서 getLikesPink를 만들었어요
직접 사용하는 것 대신에요
이렇게 하고 싶다고 가정해보죠
이런 주석 몇 개를
추가한다고 가정해볼게요
JvmName을 이용할 수 있고요

English: 
So there's reason to
use a Jvmfield on these.
OK, so we have
another data class.
And because of the getters and
setters, when we compile this,
it will create
getters and setters.
And this is great.
So we have name.
And we have getName, setName.
We have likesPink,
because we want
to know if our users
like the color pink.
But it makes this get
likesPink, rather than just
being able to use it directly.
So what we might
want to do is we
might want to add in a
couple of these annotations.
So again, we can use JvmName.

Chinese: 
所以 无需对它们使用 JvmField
还有另一个数据类
这些 getter 和 setter 
每当我们编译它的时候
它都会创建出 getter 和 setter
这很好
我们有了名称
getName setName LikesPink
因为我们想知道 用户是否喜欢粉色
但它生成的是 getLikesPink
而不是直接使用它
所以 我们可以考虑添加一些注解
我们可以使用 JvmName
比如 对于 likesPink 

Portuguese: 
Então, não há motivo
para usar um JvmField neles.
Temos outra classe de dados.
Ao compilarmos,
getters e setters são criados.
Isso é ótimo.
Temos "name", "getName",
"setName" e "likesPink",
queremos saber
se nossos usuários gostam da cor rosa.
Mas ele precisa ser "getLikesPink",
em vez de ser usado diretamente.
Podemos adicionar
algumas dessas anotações.
Mais uma vez, podemos usar "JvmName".

Japanese: 
ですから Jvmfieldを使う
理由があるわけです
では 他のデータクラスを
見てみましょう
これをコンパイルする時——
getterとsetterが作成されます
いいですね
名前があります
getNameとsetName
それから likesPink
皆さんが
ピンクが好きか知りたくて
でも 直接使うというより——
これにLikesPinkを取得させます
ここでやりたいのは——
これらのアノテーションを
いくつか追加することです
では 再び JvmNameを使います
likesPinkについては

Spanish: 
Entonces, no hay motivo para utilizar
un jvmfield en ellas.
OK, entonces tenemos otra clase de datos.
Y, debido a los recuperadores
y a los colocadores, cuando compilemos
se crearán recuperadores y colocadores.
Y eso es excelente.
Entonces tenemos name.
Y tenemos getName, setName.
Tenemos likesPink, porque queremos
saber si a nuestros usuarios
les agrada el color rosa (pink).
Pero hace que esto obtenga
likesPink, en lugar de solo
poder utilizarla directamente.
Entonces, lo que tal vez
podríamos hacer
es agregar un par de estas anotaciones.
Nuevamente, podemos usar jvmName.

Portuguese: 
Podemos dizer, para "likesPink",
queremos referenciar o getter desse jeito.
Além disso, digamos que,
em vez de "setName",
queremos chamá-lo de "changeName".
Podemos usar
a mesma anotação e inserir no setter.
Quando o Kotlin gerar o bytecode,
teremos "changeName" e "likesPink".
Wenbo, parece que este código é seu.
Sim, desculpe por interromper.
Estes slides são meus.
Quero falar
sobre a anotação estática de JVM.
Para mim, esse foi um dos primeiros itens
necessários para chamar o Kotlin no Java.
Digamos que eu tenha
uma classe de serviço definida no Java
e um método estático
para agendar esse serviço.
Eu tento converter essa classe no Kotlin.
A ferramenta de conversão automática
simplesmente insere o método estático
no objeto complementar.

English: 
And we can say, for
likesPink, we just
want to reference our
getter as likesPink.
Also, let's say that
instead of setName, we
would like it to be
called changeName.
So again, we can use
the same annotation,
put it on our setter.
And then when Kotlin generates
our by code for this,
we have changeName
and just likesPink.
Oh, so Wenbo, this
looks like your code.
WENBO ZHU: Yeah-- sorry
for jumping in like is.
These are my slides.
I'd really like to talk
about JVM static annotation
because, for me, this is
one of the first things
that I needed for
calling Kotlin from Java.
So say I have a
service class defined
in Java and a static
method to allow
me to schedule this service.
I try to convert this
class into Kotlin.
The auto conversion tool would
just put the static method
into the companion object.

Japanese: 
getterをlikesPinkとして
参照します
setNameの代わりに——
changeNameと
呼ぶことにしましょう
setterには
同じアノテーションを使います
Kotlinがこのために
コードを生成する時——
changeNameとlikesPinkができます
ウェンボー
このコードはあなたのみたいね
割り込んでしまって
すみません
これは私のスライドなんです
JavaからKotlinを呼び出すのに
必要な最初のものだったので
JVMの静的アノテーションの
話をしたかったんです
では Javaで定義した
サービスクラスと
このサービスをスケジュールする
staticメソッドがあるとします
このクラスをKotlinへ
変換してみます
自動変換ツールがstaticメソッドを
コンパニオンオブジェクトに
入れます

Chinese: 
我们就把 likesPink 作为 getter 使用
此外 我们不想使用 setName 
而是想使用 changeName
我们可以使用相同的注解
把它用在 setter 上
然后 Kotlin 为它生成字节码
这样就有了 changeName 和 likesPink
Wenbo 这个看上去像是你的代码
嗯 很抱歉就这样打断你
这几页是我的
我很想讲讲 JVM 静态注解
因为 对我来说 
在尝试使用 Java 调用 Kotlin 的过程中
这是需要优先处理的一件事
比方说 我有一个用 Java 写出的服务类
以及一个用来给服务设定日程的静态方法
我试着把这个类转译为 Kotlin
自动转译工具会直接把静态方法放置进 companion 对象

Spanish: 
Y podemos decir que, para likesPink,
solo queremos referenciar a nuestro
recuperador como likesPink.
También digamos que,
en lugar de setName,
nos gustaría que se llame changeName.
Entonces, nuevamente podemos usar
la misma anotación,
e incorporarla a nuestro colocador.
Entonces, cuando Kotlin genera
nuestro código paralelo para esto,
tenemos changeName y solo likesPink.
Oh, entonces Wenbo,
esto se parece a tu código.
Sí, perdón por meterme así.
Estas son mis diapositivas.
Quiero hablarles
sobre la anotación estática JVM
porque, para mí,
es una de las primeras cosas
que necesito para invocar
Kotlin desde Java.
Digamos que tengo
una clase service definida
en Java y un método
estático que me permite
programar este servicio.
Trato de convertir
esta clase a Kotlin.
La herramienta de conversión automática
solo incorporaría el método estático
al objeto acompañante.

Indonesian: 
Dan untuk likesPink, kita hanya
ingin merujuk getter sebagai likesPink.
Selain itu,
misalnya sebagai ganti setName,
kita ingin memanggilnya jadi changeName.
Kita dapat menggunakan anotasi yang sama
untuk diletakkan di setter.
Lalu saat Kotlin membuat kode untuk ini,
kita punya changeName dan hanya likesPink.
Wenbo, sepertinya ini kodemu.
-Ya, maaf harus memotong
seperti ini.
Ini slide saya.
Saya ingin bicara
tentang anotasi statis JVM.
Mengapa? karena ini
salah satu hal yang dibutuhkan
untuk memanggil Kotlin dari Java.
Jadi misalnya saya punya 
class layanan yang
ditentukan di Java dan metode statis
untuk memungkinkan
saya menjadwalkan layanan ini.
Saya mencoba 
mengonversi class ini ke Kotlin.
Alat konversi otomatisnya
hanya akan meletakkan metode statis
ke objek pendamping.

Korean: 
likesPink의 경우
이렇게 할 수도 있어요
getter를 likesPink로
레퍼런스하는 거죠
그리고 setName 대신에
changeName이라고
부르려고 합니다
이전과 동일하게
같은 주석을 이용할 수 있어요
setter에 넣는 거죠
그리고 Kotlin이 
바이 코드로 이걸 생성하면
changeName과
likesPink만 갖게 됩니다
원보, 이 코드를 설명해 주셔야 할 것 같아요
네, 이렇게 
끼어들어서 미안해요
이건 제 슬라이드예요
JvmStatic 주석에 대해
꼭 얘기하고 싶었어요
제 경우 Java에서
Kotlin을 호출하기 위해
가장 먼저 필요했던 것 중에
하나였기 때문인데요
Java로 정의된
서비스 클래스가 있고
이 서비스의 일정을
세울 수 있게 해주는
정적 메서드가 있어요
이 클래스를 Kotlin으로
변환하려고 합니다
자동 변환 도구는 그냥
정적 메서드를 컴패니언 객체에
넣으려고 할 거예요

Spanish: 
Pero esto no es suficiente
si estamos tratando de invocar
este método desde Java,
porque no puedo usar la invocación
de métodos estáticos idiomática.
En cambio, tengo que usar
la invocación de métodos
de instancias en el objeto acompañante.
Y, afortunadamente, Kotlin proporciona
anotación jvmStatic,
que es una forma de decirle
al compilador de Kotlin que genere
un método estático
después de la clase contenedora.
Pero aquí debemos destacar
que no podrán
obtener un análisis del rendimiento
utilizando esta anotación.
En cambio, terminarán
generando un método más.
Y la anotación jvmStatic puede aplicarse
a objetos acompañantes,
objetos nombrados, y también
objetos acompañantes de interfaces.
Volvemos contigo, Nicole.
Gracias.
Entonces, veamos:
Kotlin hace algo realmente divertido:
podemos tener parámetros predeterminados.

Indonesian: 
Namun ini tidak cukup jika kita
mencoba memanggil metode ini dari Java,
karena saya tidak dapat menggunakan
pemanggilan metode statis idiomatis.
Jadi, saya harus 
menggunakan metode pemanggilan
instance pada objek pendamping.
Dan untungnya Kotlin
menyediakan anotasi JvmStatic,
yang merupakan cara untuk
memerintah pengompilasi agar membuat
metode statis setelah menutup class.
Tetapi,
perlu diperhatikan bahwa
Anda tidak dapat melakukan
pemindaian performa dengan anotasi ini.
Jadi Anda harus membuat satu metode lagi.
Anotasi JvmStatic dapat
diterapkan ke objek pendamping,
objek bernama,
serta objek pendamping dari antarmuka.
-Saya kembalikan kepada Nicole.
-Terima kasih.
Oke.
Jadi ada yang
keren di Kotlin, yakni Kotlin
dapat memiliki parameter default.

Chinese: 
但是 如果我们想使用 Java 调用这个方法
这样做就不够好
因为我无法按惯例来调用静态方法
我需要在 companion 对象上通过实例方法来调用
幸运的是 Kotlin 提供了 JvmStatic 注解
它会让 Kotlin 编译器在完成类封装成后生成一个静态方法
不过 值得说明的是 你无法使用这个注解
来获取性能优势
你只会生成又一个方法
JvmStatic 静态注解可以用在
companion 对象 命名对象 以及接口的 companion 对象上
你继续讲 Nicole 
谢谢 我们来看看
Kotlin 有一个很有意思的功能
我们现在有了默认参数

English: 
But this is not good enough
if we are trying to call this
method from Java, because I
cannot use the idiomatic static
method call.
But rather, I need to
use the instance method
call on the companion object.
And luckily, Kotlin provides
JvmStatic annotation,
which is a way to tell
Kotlin compiler to generate
a static method after
enclosing class.
But one note here
is that you won't
be able to get performance
scan using this annotation.
But rather, you will end up
generating one more method.
And JvmStatic annotation can be
applied to companion objects,
named objects, and also
companion objects of interfaces
as well.
Back to you, Nicole.
NICOLE BORELLI: Thanks.
So let's see--
OK, so Kotlin does something
really, really fun, which is we
can have default parameters.

Japanese: 
ただ このメソッドをJavaから
呼び出そうとするには
これでは不十分です
典型的なstaticメソッドで
呼び出しできないからです
むしろ インスタンスメソッドで
コンパニオンオブジェクトを
呼び出す必要があります
幸いなことにKotlinは
クラスを囲んだ後
静的メソッドの生成を
Kotlinコンパイラに指示する——
JvmStaticアノテーションを
提供します
ただし このアノテーションでは
パフォーマンススキャンはできません
最後にはもう一つの
メソッドが生成されます
JvmStaticアノテーションは
コンパニオンオブジェクトや
名前付きオブジェクト
インターフェースのコンパニオン
オブジェクトにも適用できます
どうぞ
ありがとう
それでは…
Kotlinにはデフォルトの
パラメータがあり——
本当に楽しい働きをします

Portuguese: 
Mas isso não é bom o suficiente
se estamos tentando
chamar esse método no Java,
já que não é possível usar
a chamada do método estático idiomático.
Em vez disso, preciso usar
a chamada do método de instância
no objeto complementar.
Felizmente, o Kotlin
oferece a anotação JvmStatic,
uma forma de dizer
para o compilador do Kotlin gerar
um método estático
após a classe de inclusão.
No entanto, não será possível
verificar o desempenho com essa anotação.
Em vez disso, você gerará mais um método.
A anotação JvmStatic pode ser aplicada
a objetos complementares, nomeados
e a objetos complementares de interfaces.
De volta com você, Nicole.
Obrigada!
O Kotlin faz algo muito interessante:
podemos ter parâmetros padrão.

Korean: 
하지만 이 방법은
Java에서 메서드를 호출하려고 할 때
관용적인 정적 메서드 호출을
사용할 수 없기 때문에
충분하지 않습니다
차라리 컴패니언 객체에
인스턴스 메서드 호출을
사용해야 해요
다행히 Kotlin은
JvmStatic 주석을 제공합니다
Kotlin 컴파일러에
인클로징 클래스 후에
정적 메서드를 생성하도록
알려주는 방법이죠
하지만 여기서 주의할 점은
이 주석을 사용해서
성능 스캔을
할 수 없을 거라는 점이에요
오히려 메서드를
하나 더 생성하게 될 겁니다
JvmStatic 주석은
컴패니언 객체, 명명된 객체
그리고 인터페이스의
컴패니언 객체에도
적용될 수 있습니다
니콜, 이제 나와 주세요
고마워요
어디 봅시다...
Kotlin은 아주
재미있는 일을 하는데요
바로 기본 매개변수가
제공된다는 점입니다

Korean: 
기본 매개변수는
Java 프로그래밍 언어에서
직접 지원되지 않아요
바로 이 지점에서
앞에서 생성했던
Utils 클래스를 사용하는 거예요
하지만 인터폴레이터의
값을 전달하지 않을 겁니다
그래서 컴파일러
오류가 있을 거예요
하지만 JvmOverloads를
넣을 수 있어요
이제 Kotlin 컴파일러에
각각의 옵션 매개변수에 대해
왼쪽에서 오른쪽으로
오버로드를 생성하도록
요청할 겁니다
이름 매개변수가 있는
Kotlin에서와 동일하게
어떤 매개변수를 넣을지
까다롭게 고르는 작업은
아직 허용하지 않을 거예요
하지만 작동할 수는 있죠
여기에서 JvmName을
사용할 수도 있어요
아니면 Kotlin에서는
Bitmap.resize를 넣는 게 맞아요

Portuguese: 
Parâmetros padrão não são
compatíveis diretamente do Java.
Aqui estamos usando
a classe utils gerada anteriormente.
No entanto, o valor
do interpolador não está sendo passado.
Haverá um erro do compilador.
Mas podemos inserir o JvmOverloads.
Assim, será solicitado
que o compilador do Kotlin gere
sobrecargas para cada parâmetro opcional,
da esquerda para a direita.
No Kotlin, ainda não é possível
escolher qual parâmetro inserir,
como podia ser feito no Java
com os parâmetros de nome.
Mas funciona.
Também podemos usar JvmName aqui.
No Kotlin, faz sentido usar bitmap.resize.

Japanese: 
デフォルトのパラメータは
Javaプログラミング言語から
直接サポートされていません
ですから 先ほど生成した
utilsクラスを使います
ただし interpolatorの値は
渡していないので——
コンパイルエラーになります
でもこのJvmoverloadsを入れると
Kotlinのコンパイラに対し
オプションのパラメーターごとに
オーバーロードを
左から右へ
生成するように要求します
それでもまだ Kotlinでの
名前付きパラメータのように
nを置くパラメータを
選択することはできません
でも これは機能します
JvmNameを
ここで使うこともできます
Kotlinではbitmap.resizeが
理にかなっていますが

Chinese: 
Java 语言并不直接支持默认参数
所以 在这里 我们调用了之前生成的 utils 类
但我们并没有传入那个转译的值
所以 会出现编译错误
不过我们可以加上这个 JvmOverloads
现在它会让 Kotlin 编译器
按照从左到右的顺序 为每个可选参数生成重载
它仍然不会像 Kotlin 的参数名那样
允许你选择输入哪个参数
但是它能让这样的参数正常工作了
我们也可以在这里使用 JvmName 
在 Kotlin 中 bitmap.resize 的写法是合理的

Spanish: 
Los parámetros predeterminados
no son compatibles directamente
desde el lenguaje de programación Java.
Entonces, justo aquí, estamos
usando nuestra clase utils,
que generamos antes.
Pero no estamos transfiriendo
ese valor interpolar.
Entonces, va a haber
un error en el compilador.
Pero podemos poner
esta jvmOverloads.
Y ahora, le pedirá al compilador
de Kotlin que genere sobrecargas
para cada uno
de sus parámetros opcionales,
de izquierda a derecha.
Seguirá sin permitirles elegir
los parámetros que quieren incorporar,
como sí podían en Kotlin
con los parámetros de name.
Pero permite que esto funcione.
También podemos usar
nuestra jvmName aquí.
Entonces, en Kotlin,
en lugar de que un bitmap.resize

English: 
Default parameters
aren't supported directly
from the Java
programming language.
So right here, we're
using our utils class,
which we generated before.
But we're not passing in
that interpolator's value.
So it's going to be
a compiler error.
But we can put
this JvmOverloads.
And now this will ask the Kotlin
compiler to generate overloads
for each of their
optional parameters,
going from left to right.
It still won't allow
you to pick and choose
which parameters to
put n, like you could
in Kotlin with name parameters.
But it allows this to work.
We can also use
our JvmName here.
So instead of, in Kotlin,
having a bitmap.resize

Indonesian: 
Parameter default
tidak didukung secara langsung
dari bahasa pemrograman Java.
Jadi kami menggunakan class utils,
yang kita buat sebelumnya.
Tetapi kita tidak 
melewati nilai interpolator itu.
Jadi akan muncul error pengompilasi.
Tetapi, kita dapat 
meletakkan JvmOverloads.
Kini class akan
meminta pengompilasi Kotlin
untuk membuat overload
bagi tiap parameter opsional,
dari kiri ke kanan.
Class tetap tidak mengizinkan Anda
untuk mengambil atau memilih
parameter mana
yang ingin diletakkan di Java,
seperti yang Anda lakukan
di Kotlin dengan parameter nama.
Tetapi setidaknya masih berfungsi.
Di sini kita juga
dapat menggunakan JvmName.
Di Kotlin,
bitmap.resize masih masuk akal,

Korean: 
Java 프로그래밍 언어에서는
resizeBitmap을 넣는 게
더 정확할 수 있습니다
Kotlin에는 확인된 예외가 없어요
좋은 일이죠
Try-Catch 구문에
전체를 넣지 않아도
되니까요
하지만
Java 프로그래밍 언어에서
이걸 사용하면 오류가 발생해요
예외를 발생시키지 않았다는
메시지가 뜨겠죠
여기에서 할 수 있는 작업은
Kotlin 코드로 들어가는 거예요
그리고 Throws 주석을
추가하는 겁니다
그러면 이 주석이
저희가 생성한 바이 코드에 추가됩니다
그러면 컴파일러는 마지못해서
이 작업이 발생하는 것을 수락하겠죠

Spanish: 
tenga sentido, desde el lenguaje
de programación Java,
podría tener más sentido llamarla
resizeBitmap.
Kotlin no tiene excepciones
comprobadas, algo excelente,
porque no tienen que poner todo
en un bloque try/catch.
Pero si estamos usando esto desde
el lenguaje de programación Java,
nos arrojará un error.
Y nos dirá que no se lanza la excepción.
Entonces, lo que podemos hacer es
ir a nuestro código de Kotlin.
Y podemos agregar una anotación throws.
Entonces, lo agregará
a la generada por código.
Después el compilador aceptará de manera
reticente que esto está sucediendo.

Portuguese: 
No Java, faz mais sentido
que ele se chame "resizeBitmap".
O Kotlin não tem
exceções "checked", o que é ótimo.
Assim, não é necessário
colocar tudo em um bloco "try/catch".
No entanto, se usarmos Java,
será exibido um erro.
Veremos que a exceção não foi lançada.
Podemos entrar no código do Kotlin
e adicionar uma anotação "Throws".
Ela será adicionada
à informação gerada pelo código.
Com relutância, o compilador
aceitará que isso está ocorrendo.

Japanese: 
Javaプログラミング言語では
resizeBitmapの方が合理的です
Kotlinには
チェック例外がありません
すべてをtry-catchブロックに
入れる必要がないからです
でも これを
Javaプログラミング言語から——
使おうとするとエラーになります
これは例外が——
例外が
スローされないということです
この場合 Kotlinのコードを
使うことができます
スローのアノテーションを
追加すればいいのです
コードが生成したものに
これを追加します
するとコンパイラは
起こったことを受け入れます

Indonesian: 
tetapi untuk Java,
lebih masuk akal
jika mengganti namanya jadi resizeBitmap.
Kotlin tidak memiliki 
pengecualian yang diperiksa,
yang merupakan hal bagus,
karena Anda
tidak perlu meletakkan segalanya
di blok try catch.
Tetapi jika kita menggunakannya
dari bahasa pemrograman Java,
hal ini akan menimbulkan error.
Lalu akan memberi tahu kita
bahwa pengecualian tidak diberikan.
Jadi, yang dapat dilakukan
adalah melihat kode Kotlin kita.
Lalu menambahkan anotasi throws.
Jadi, pengecualian akan
ditambahkan ke kode yang kita buat.
Lalu pengompilasi akan menerima
bahwa hal ini terjadi.

English: 
make sense, from the Java
programming language, it might
makes more sense to have
it called resizeBitmap.
Kotlin doesn't have checked
exceptions, which is great,
because you don't have to
put everything in a try catch
block.
But if we're using this from
the Java programming language,
then it will give us an error.
And it will tell us that
the exception is not thrown.
And so what we can do though is
we can go into our Kotlin code.
And we can add a
throws annotation.
So then it will add this
to the generated by code.
And then the compiler
will reluctantly
accept that this is happening.

Chinese: 
在 Java 语言中 将其称为 resizeBitmap 更加合理
Kotlin 没有 Checked Exception 这很好
因为你没必要把所有东西都放进 try-catch 代码块里
但是 如果我们通过 Java 语言来使用它的话
它就会返回一个错误
告诉我们 这个异常未被抛出
所以 我们可以看看 Kotlin 代码
并添加 Throws 注解
然后它会把这个注解添加到生成的字节码里面
编译器也会接受这个既成事实

Japanese: 
ここでもう一つ
ウェンボーが
話したいことがあるようです
最後に 情報漏洩防止について
お話しします
Kotlinの関数を見てみると——
生成されたコードは
このようなものです
関数パラメータの名前が
この組み込みのトラックに——
文字列として渡されるのが
わかります
基本的にここで
パラメータによって渡された値が
nullでないことを確認します
Java Colorからの値を
保証できないからです
この名前は文字列として
渡されるため——
クラス名や関数名とは違って
ProGuardによって
難読化されません
従って 誰かがAPKを破ると
そこの文字列が見えてしまいます
ですから 関数パラメータ名の中に
重要な情報は置かないことを
お勧めします
また同様に処理には
変数名が必要です

Spanish: 
Ok, parece que Wenbo quiere hablarles
sobre algo más.
Sí, quiero mencionar un último detalle.
Es la característica
de prevención de filtraciones.
Si observamos la función de Kotlin,
el código generado tendrá este aspecto.
Y podemos ver que el nombre
del parámetro de la función
se transfiere como cadena
en este tracks intrínseco.
Y, básicamente, esto comprueba
aquí para asegurarnos
de que el valor transferido
por el parámetro
no sea NULL,
porque no podremos garantizarlo
desde Java Color.
Como este nombre se transfiere
como una cadena,
a diferencia de un nombre de clase
o de nombres de funciones,
no se va a ver
ofuscado por ProGuard.
Y, por lo tanto, si alguien
fuera a desglosar su APK,
vería la cadena allí.
Y, en consecuencia, no recomiendo
poner nada confidencial
dentro del nombre
de sus parámetros de funciones.
Y, en forma similar,
para los nombres de variables lateinit.

English: 
Oh-- so it looks like there's
one more thing that Wenbo would
like to talk to you about.
WENBO ZHU: So there's one last
thing I'd like to mention.
It's the feature
leak prevention.
So if we take a look
at the Kotlin function,
the generated code
will look like this.
And we can see that the name
of the function parameter
is passed in this intrinsic
tracks as a string.
And basically, this
checks here to make sure
that the value passed
in by the parameter
is not null, because we won't
be able to guarantee that
from Java Color.
Since this name is
passed in as a string,
unlike a class name
or function names,
it's not going to be
obfuscated by ProGuard.
And therefore, if someone
were to tear down your APK,
they will see the string there.
And therefore, I
do not recommend
putting anything sensitive
inside your function parameter
name.
And similarly, for [INAUDIBLE]
you need variable names.

Portuguese: 
Parece que o Wenbo
quer falar sobre mais um assunto.
Uma última coisa
que gostaria de mencionar.
É o recurso de prevenção
contra vazamento de dados.
Se analisarmos a função do Kotlin,
o código gerado será semelhante a este.
Podemos ver que o nome
do parâmetro de função foi passado
nestas verificações "Intrinsics"
como uma string.
Isso serve para verificar
se o valor passado pelo parâmetro
é diferente de nulo.
Isso não poderia ser garantido
pelo autor da chamada no Java.
Como esse nome é passado como uma string,
diferentemente de nomes
de classe ou função,
ele não será ofuscado pelo ProGuard.
Assim, se alguém for desativar seu APK,
a string será exibida.
Portanto, não é recomendável
inserir qualquer dado confidencial
no nome do parâmetro da função.
É preciso agir de forma semelhante
com nomes de variáveis "lateinit".

Korean: 
원보 씨가 여러분에게
알려주고 싶은 이야기가
하나 더 있는 것 같네요
마지막으로 한 가지만
더 말씀드릴게요
기능 누출 예방입니다
Kotlin 함수를 살펴보면
생성된 코드는
이렇게 보일 거예요
함수 매개변수의 이름이
하나의 문자열로
이 내부 트랙에
전달되는 것을 볼 수 있는데요
기본적으로
매개변수가 전달하는 값이
null이 아니라는 것을
확인하기 위한 것인데
Java Color에서는
이를 보장할 수 없기
때문이죠
이 이름은 클래스 이름이나
함수 이름과 달리
하나의 문자열로
전달되기 때문에
ProGuard에 의해
난독 처리되지 않아요
그렇기 때문에 누군가
여러분의 APK를 파괴한다면
문자열을 보게 될 거예요
그래서 저는
함수 매개변수 이름 안에
어떤 민감한 정보도
넣지 않기를
권장합니다
마찬가지로
변수 이름이 필요할 겁니다

Indonesian: 
Sepertinya ada 
satu hal lagi yang ingin dijelaskan
oleh Wenbo.
-Jadi ada 
satu hal lagi yang ingin saya jelaskan,
yakni pencegah kebocoran fitur.
Jika kita melihat fungsi Kotlin,
kode yang dibuat
akan terlihat seperti ini.
Kita dapat melihat
bahwa nama parameter fungsi
ditampilkan
di jalur intrinsik sebagai string.
Pemeriksaan ini memastikan
bahwa nilai yang
ditampilkan oleh parameter
tidak null, karena kita 
tidak dapat menjaminnya
dari Java Color.
Karena nama ini
muncul sebagai string,
tidak seperti
nama class nama fungsi,
ProGuard tidak akan
kebingungan saat melihatnya.
Jadi, jika seseorang
membedah APK Anda,
mereka akan melihat string-nya.
Jadi, sebaiknya jangan
meletakkan data sensitif di dalam
nama parameter fungsi Anda.
Selain itu, Anda butuh
nama variabel untuk [...].

Chinese: 
似乎 Wenbo 还有一件事要讲
我还想最后提一个事情：预防功能泄露
我们来看 Kotlin 方法
生成代码是这个样子的
可以看到 方法的参数名称 作为字符串
传入了这个检查参数的方法里
用来检查 确保由参数传入的数值不为空
因为我们无法通过 Java 来保证这一点
因为这个名称是作为字符串传入的
与类名和方法名不同
它不会被 ProGuard 混淆
所以 如果有人想解包你的 APK
他们就会看到那里的字符串
所以 我不推荐大家把敏感信息放进方法的参数名里
至于 lateinit 变量名

Portuguese: 
Eles também são usados
pelas verificações "Intrinsics"
para garantir a inicialização adequada.
Então, também podem vazar seu recurso.
Outro exemplo
é o nome da função de extensão.
Como a Nicole mostrou
nos slides anteriores,
as funções de extensão
se resolvem por métodos estáticos
em que um tipo de receptor
é passado como parâmetro.
O nome do parâmetro
será gerado como um cifrão
seguido pelo nome da função.
Também é importante tomar cuidado
para que o nome da função de extensão
não contenha dados secretos.
Há diversas outras
verificações "Intrinsics".
Acredito que uma boa forma
de aprender sobre elas seja
verificar o código-fonte
da classe "Intrinsics".
Uma última observação:
em vez de simplesmente renomear tudo,
usem a regra do ProGuard
"assumenosideeffects".
Com ela, o ProGuard removerá
as verificações "Intrinsics".

Japanese: 
それらも適切に初期化されている
ことを確認するため——
組み込みチェックで
使用されるので
情報を潜在的に
リークする可能性があります
もう一つの例は拡張機能名です
ニコルがスライドでお見せしたように
拡張機能は
静的メソッドで解決され
レシーバーの型が
パラメータとして渡されます
パラメータの名前は
ドル記号として生成されます
ですから拡張機能名に注意して
そこには大事な情報を
入れないようにしてください
他にも組み込みチェックは
たくさんあります
それについて学ぶには——
組み込みクラスのソースコードを
調べてみるのがいいと思います
最後に すべてをリネームする他に
ProGuardの
assumenosideeffectsを利用して
ProGuardに組み込みチェックを
削除させることもできます

Spanish: 
También las usan
las comprobaciones intrínsecas
para asegurarse que se inician
correctamente y, por lo tanto,
tienen el potencial
de filtrar su característica también.
Otro ejemplo es el nombre
de la función de extensión.
Como ya les mostró Nicole
en diapositivas anteriores,
las funciones de extensión se resuelven
en métodos estáticos,
independientemente de que se transfiera
un tipo de receptor como parámetro.
Y el nombre del parámetro
se generará como un signo de dólar:
este nombre de función de signo de dólar.
Por lo tanto, también
tienen que controlar
el nombre de la función
de extensión para asegurarse
de que no tenga ningún secreto.
En realidad hay muchas
otras comprobaciones intrínsecas.
Y creo que una buena manera
de aprender sobre ellas
es comprobar el código fuente
de la clase de comprobaciones intrínsecas.
Un último detalle importante: además
de solo cambiar el nombre de todo,
también pueden optar por usar esta
regla assumenosideeffects de ProGuard
y permitir a ProGuard eliminar por ustedes
las comprobaciones intrínsecas.

Korean: 
변수 이름은
내부 점검에서도 사용됩니다
변수가 제대로
초기화되었는지 확인하죠
따라서 잠재적으로
기능이 누출될
가능성도 있습니다
또 다른 예는
확장 함수 이름입니다
이전 슬라이드에서
니콜이 보여줬듯이
확장 함수는
수신자 유형이
매개변수로 전달되는
정적 메서드로 확인됩니다
매개변수의 이름은
달러 기호로 생성될 겁니다
이 달러 기호가 함수 이름이죠
따라서 여러분은
확장 함수 이름에
비밀 정보가 전혀 없도록
이름을 지정할 때
주의를 기울여야 해요
사실 다른 내부 점검이
많이 있습니다
여기에 대해 알아보려면
내부 클래스의
소스 코드를 확인하는 것이 좋습니다
마지막으로 덧붙이자면
전체의 이름을 다시 지정하는 것 외에
assumenosideeffects
ProGuard 규칙을 이용해서
ProGuard에서 내부 점검을
제거하도록 할 수 있어요

Indonesian: 
Nama juga digunakan
oleh pemeriksaan intrinsik
untuk memastikan bahwa nama dimuat
dengan benar dan juga dapat berpotensi
membocorkan fitur Anda.
Contoh lain adalah
nama fungsi ekstensi.
Seperti yang ditunjukkan
Nicole di slide sebelumnya,
fungsi ekstensi
ditetapkan untuk metode statis,
sedangkan jenis penerima
ditampilkan sebagai parameter.
Dan nama parameter akan
dibuat sebagai tanda dolar,
nama fungsi tanda dolar ini.
Jadi juga Anda harus memeriksa
nama fungsi ekstensi
untuk memastikan bahwa
tidak ada rahasia apa pun.
Sebenarnya ada banyak
pemeriksaan intrinsik lainnya.
Cara tepat untuk mempelajarinya adalah
dengan melihat
kode sumber class intrinsik.
Satu hal lagi, selain
mengganti semua nama,
Anda juga dapat memilih
untuk menggunakan aturan
ProGuard assumenosideeffects
agar ProGuard
menghapus pemeriksaan intrinsik.

Chinese: 
它们也被固有检查所使用
确保它们已被正确初始化
所以 它也有可能泄露你的功能
另一个例子是扩展方法名
正如 Nicole 在之前的幻灯片中展示出来的那样
扩展功能被解析到静态方法
接收方类型将在那里作为参数传入
参数名则写作 "$this$功能名"
所以 你还需要关注扩展方法名
确保其中不含任何机密信息
固有检查还有很多种
想要掌握它们 不妨了解一下固有类的源代码
最后一个要点
你可以重命名所有东西
也可以使用这个 assumenosideeffects ProGuard 规则
来让 ProGuard 帮你移除固有检查

English: 
They are also used
by intrinsic checks
to make sure they
are initialized
properly and, therefore,
can potentially
leak your feature as well.
Another example is the
extension function name.
So as Nicole has shown
in previous slides,
extension functions are
resolved to static methods,
where a receiver type is
passed as a parameter.
And the name of
the parameter will
be generated as dollar sign--
this dollar sign function name.
And therefore, you
also need to watch out
for the extension
function name to make
sure there's no secret in it.
There are actually a lot
of other intrinsic checks.
And I think a good way
to learn about them
is to check out the source
code of the intrinsics class.
One last note-- other than
just renaming everything,
you can also choose to use this
assumenosideeffects ProGuard
rule to let ProGuard remove
the intrinsics checks for you.

Chinese: 
不过我推荐至少要保留这些检查
以确保检测环境
如果真的出了问题 也可以很快发现
谢谢
我们讲了很多很棒的东西 
Kotlin 很棒 Java 也很好
我们支持大家使用二者之一来调用另一个 
我认为这很好 谢谢大家

Korean: 
하지만 저는
적어도 이 점검은
이중 시험 환경을 위해
남겨둘 것을 권장합니다
그래야 큰 문제가 생겼을 때
빠르게 실패할 수 있거든요
네, 고마워요
오늘 아주 훌륭한
여러 기능들에 대해 이야기했는데요
Kotlin은 정말 유용하고
Java도 정말 좋죠
서로를 호출하는 것도
양방향으로 지원됩니다
정말 좋다고 생각해요
[웃음]
감사합니다
[박수]
[디지털 음악]

English: 
But I recommend, at
least leave these checks
in for double
testing environment
so that, if something really
goes wrong, it can fail fast.
NICOLE BORELLI: Cool-- thanks.
Yeah, so we talked about a
lot of really awesome things.
And Kotlin is awesome.
Java is great.
And calling them from each
other is supported both ways.
So yeah-- I think, great.
[LAUGHTER]
WENBO ZHU: Thank you.
[APPLAUSE]
[DIGITAL MUSIC]

Portuguese: 
Mas eu recomendo manter essas verificações
ao menos para o ambiente de teste duplo.
Assim, caso algo dê errado,
a falha aparecerá rapidamente.
Obrigada!
Falamos sobre muitas coisas incríveis.
O Kotlin é excelente.
Assim como o Java.
Ter compatibilidade
entre ambos é sensacional.
Agradecemos a presença!

Spanish: 
Pero les recomiendo que, al menos
dejen estas comprobaciones
para un entorno de prueba doble
para que, si algo realmente sale mal,
que pueda salir mal rápidamente.
Perfecto, gracias.
Sí, hablamos
sobre varias cosas maravillosas.
Y Kotlin es maravilloso.
Java es excelente.
E invocarlos uno desde el otro
es compatible an ambos sentidos.
Entonces, sí; creo que es excelente.
Gracias.

Indonesian: 
Tetapi, sebaiknya Anda
setidaknya membiarkan pemeriksaan tersebut
untuk lingkungan pengujian ganda
sehingga jika ada masalah,
pengujian akan langsung gagal.
-Baik. Terima kasih.
Jadi kita bicara tentang
banyak hal yang luar biasa.
Kotlin luar biasa.
Java juga keren.
Keduanya saling mendukung satu sama lain.
Dan menurut saya, ini mengagumkan.
Terima kasih.

Japanese: 
ただし 二重テスト環境では
何かトラブルがあっても
すぐ対処できるよう
少なくともこれらのチェックを
残すことをお勧めします
ありがとう
本当に素晴らしいことについて
お話しができました
Kotlinは素晴らしいです
Javaもすごい
両方とも相互の呼び出しを
サポートしています
ですから…
すごいな と
[笑い]
ありがとう
[拍手]
[音楽]
