×

Java vs. Kotlin для Android. День 1: спрыгиваем с Java

В очередной раз набирая на клавиатуре в Android Studio строчки кода с циклом for, поймал себя на мысли, что делал это множество раз и уже знаешь каждый следующий оператор, который идет дальше. Задача простая: выбрать из списка множество элементов, удовлетворяющее поставленному условию. Вроде бы ничего сложного, все просто: цикл по списку, внутри условие и добавление нового элемента в результирующий список. Еще один стандартный статический метод в классе с утилитами. Какой он там по счету уже...- 5ый или 10ый? Буквально 3-4 строки кода, которые сделают свое дело, НО почему-то удовлетворения от выполненной задачи нет. Где-то там глубоко есть ощущение, что можно делать это проще. Там же рядышком лежат классы-утилиты для работы со строками и датами. Сколько их уже было за все время?

А тут еще на днях Петя/Ваня/Дэвид сказал, что они начинают новый проект под Android и будут писать его исключительно на Kotlin. Kotlin, а не Java. Чем этот язык лучше Java? Сколько уже было этих пустых никому не нужных попыток писать код под Android на PHP/C/C++/С#/Python, и где все это сейчас? Возможно, в этот раз все по-другому, и стоит обратить на него внимание? Ну что же, посмотрим, хотя я очень слабо верю во что-то путнее.

Разрабатывает его JetBrains и уже давненько, т.е. за это время их желание создать свой язык не иссякло. Это похвально и заслуживает уважения. Мне нравится их IDEA & AS. Более того, главной целью для себя они ставят полностью перевести разработку внутри компании с Java на Kotlin, и хотят, чтобы он, как и Java, использовался в industry. А вот некоторые называют его прямо «Swift под Android», вот же ж юмористы! И не просто люди с улицы, а сами разработчики Kotlin! Утверждают, что про NPE в рантайме можно забыть, что можно расширять стандартные классы из SDK, что можно лямбды и анонимные функции писать и даже передавать функции как параметры в методы! И даже точку с запятой убрали из синтаксиса (кстати, вот с этим я согласен на все 100%). А это прямо-таки из моего PHP-ного прошлого — String Templates — по таким вещам иногда скучаешь. Забавно, конечно, но вряд ли это все как-то может пригодиться в Android-разработке. Хм, у них есть плагин под IDEA/AS и даже специальный плагин под Андроид проекты. Вот это сейчас надо посмотреть.

Интересно выходит — Kotlin на 100% совместим с Java, и плагин позволяет java-код в один клик трансформировать в kotlin-код, и это как раз можно проверить достаточно быстро. Создадим-ка пустой Android-проект с одной Activity и Fragment внутри, и еще один простой дата-класс тоже не помешает.

Берем шаблонную Activity:

package com.testkotlin;

import ...

public class TestActivity extends AppCompatActivity {

   @Override
   protected void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);
       setContentView(R.layout.activity_test);
       Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);
       setSupportActionBar(toolbar);

       FloatingActionButton fab = (FloatingActionButton) findViewById(R.id.fab);
       fab.setOnClickListener(new View.OnClickListener() {
           @Override
           public void onClick(View view) {
               Snackbar.make(view, "Replace with your own action", Snackbar.LENGTH_LONG)
                       .setAction("Action", null).show();
           }
       });
   }
}

и с помощью действия «Convert Java File to Kotlin File»:

на выходе получаем такой вот код:

package com.testkotlin;

import ...

class TestActivity : AppCompatActivity() {

   override fun onCreate(savedInstanceState: Bundle?) {
       super.onCreate(savedInstanceState)
       setContentView(R.layout.activity_test)
       val toolbar = findViewById(R.id.toolbar) as Toolbar
       setSupportActionBar(toolbar)

       val fab = findViewById(R.id.fab) as FloatingActionButton
       fab.setOnClickListener { view ->
           Snackbar.make(view, "Replace with your own action", Snackbar.LENGTH_LONG)
                   .setAction("Action", null).show()
       }
   }
}

Выглядит неплохо, и вроде как все понятно. Получается, что из-за 100%-ой совместимости с Java новая TestActivity на Kotlin спокойно наследуется от AppCompatActivity, которая лежит в Support Library, а не в SDK. Ну что же, это довольно-таки серьезно облегчает переезд на рельсы Kotlin и делает использование Java-библиотек безболезненным. Безусловно это плюс, пожалуй, стоит записать очко в пользу Kotlin.

Теперь проверим, как это сработает на обычном дата-классе:

public class Message {
   private String text;
   private boolean isRead;

   public Message(String text, boolean isRead) {
       this.text = text;
       this.isRead = isRead;
   }

   public String getText() {
       return text;
   }

   public boolean isRead() {
       return isRead;
   }
}

и конвертнем его в kotlin-файл:

class Message(val text: String, val isRead: Boolean)

Одна строка кода по сравнению с 14-ю в Java-варианте! А если еще перед описанием класса добавить data, то автоматом получаем возможность делать копии объектов с помощью метода copy(). В качестве параметров он может принимать новые значения полей объекта. Запишите еще очко в пользу Kotlin.

Это ж на сколько время-то экономится?!?! Вот такого твиста я не ожидал, и, бегло (ну, как бегло...часика 2) пробежавшись по разделу «Classes and Objects» в документации, я узнал, что:

  • для создания экземпляра класса нам не нужно ключевое слово new;
  • никаких тебе extends или implements, для этого теперь используется «:»;
  • класс может иметь один primary constructor и один/несколько secondary constructors;
  • у primary constructor нет тела, но внутри него можно описать блок инициализации init;
  • используются ключевые слова var (mutable property)/val (read-only property) для декларации и инициализации properties прямо в объявлении конструктора. Ключевые слова val\var используются и при объявлении обычных локальных переменных;
  • OMG!, здесь есть named arguments и дефолтные значения для них;
  • можно описывать кастомные accessors — круть! очень полезная штука;
  • теперь не нужно явно вызывать getter/setter для получения/присвоения значения проперти — обращение происходит просто по имени — тоже здОрово!
  • по умолчанию область видимости для классов/методов/пропертей — public;
  • по умолчанию все классы в Kotlin final и нужно использовать open-аннотацию для класса, если необходимо иное поведение — к этому придется немного привыкать;
  • интерфейсы теперь могу реализовывать методы!!! Т.е. класс может имплементить два интерфейса, которые имеют различную реализацию метода с одинаковой сигнатурой, и я смогу выбрать, где какой из методов использовать. Вот это реально круто! Очень давно об этом мечтал;
  • вариативность женериков (generics) реализована с помощью in/out-кейвордов;
  • реализовать anonymous inner classes можно через object expressionsobject declarations;
  • всеми любимый Singleton легко и просто реализуется с помощью object declaration;
  • Java static methods == object declaration + companion object;
  • делегирование реализовано на уровне декларации класса с помощью by-clause, компилятор сам сгенерирует необходимые дублирующие методы — любители делегирования возрадуйтесь, теперь не нужно дублировать вручную методы!

Отдельно стоит отметить, что фичи, затрагивающие сигнатуры методов, также распространяются и на обычные функции.

А еще можно взять java-код и скопипастить его в kotlin-файл и IDE сама предложит его конвертнуть. Кстати, на Java можно и в kotlin-файлах спокойно писать код, и все будет работать — это как еще один бонус 100%-й совместимости. Там же с помощью IDE полученный код можно упростить и привести его к kotlin-style. Это здорово поможет ускорить обучение и сдвинуть мышление в сторону Functional Programming(FP).

Все это выглядит здорово, местами для закоренелого object-oriented developer непривычно, но ведь красиво же! И, главное, что на выходе я получаю максимально оптимизированный java-код. Да уж, пессимизма по отношению к этому языку во мне поубавилось.

И я уже было собирался ложиться спать (на часах около 3-х ночи), но по глупости взял и посмотрел вот этот небольшой доклад по теме от Jake Wharton и понял, что слишком я перестарался с игнорированием функционального программирования. Но этот пробел я буду восполнять уже завтра, пардон, сегодня. Еще и выспаться нужно успеть, и на проекте ждет меня куча бизнес-логики — опять циклы/условия и статические методы — а дедлайны никто не отменял. К тому же, будет что рассказать хлопцам за чашечкой кофе по Kotlin-у и непрозрачно намекнуть моему РМ-у, что было бы неплохо для Waverley (компания, где я работаю) начинать подыскивать Android-проект, где заказчику будет все равно на Kotlin-е мы его напишем или на Java. И разработчикам профит, и компания может себе в копилку еще одну технологию записать.


Следующие выпуски:
Java vs. Kotlin для Android. День 2: А может ну его, этот Kotlin?
Java vs. Kotlin для Android. День 3: Android высшего порядка

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному4
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Хоч сам обожнюю Котлін, але стаття справила враження, наче єдина причина причина крутості котліна, що можна «;» не писати. Так що трохи прокоментую і поділюсь своїми міслями.

Kotlin на 100% совместим с Java

Про подібне каже будь-яка JVM-мова. Але котлін на цьому полі їх всіх б’є, хоча б тому, що повністю використовє JVM екосистему і бібліотеку. Білдимся в градлі, пишем в ідеї, MutableList<t> — це той же джавовський List<t> (привіт, скала!), можна дуже зручно використовувати джавовські методи й класи і навпаки.

Это ж на сколько время-то экономится?!?!

Імхо, на те, щоб написати дата-клас котліна чи тицьнути на Alt+Ins і згенерувати геттери/сеттери потрібно одинаково часу. І взагалі, для мови швидкість набору — один з останніх критеріїв, на які варти дивитись.

двинуть мышление в сторону Functional Programming(FP)

Kotlin — це в першу чергу better java. Значно better, за що я його й люблю. Але функціональщиной там і не пахне. Так, є лямбди, є map/filter/reduce колекцій, є деяка іммутабельність, як і в інших імеративних мовах, типу джави чи C#. Ніяких монад-трансформерів чи аплікативів х)

И, главное, что на выходе я получаю максимально оптимизированный java-код

На виході такий же байткод, як і після джави, +/-. Так що переїзд на Котлін в n раз код не оптимізує (хіба що він вміє інлайнити лямбди, тобто може бути профіт за рахунок того, що позбудемось від створення анонімних класів).

Основний профіт в тому, що котлін лагодить дуже багато дуже дрібних недоліків джави і в той же час не спонукає програміста писати нечитаємий функціональний бреінфак, писати spaceship operator <|*|> і залишається зрозумілим для Java-розробника. І null-safety, хоч і не рятує, але дуже допомогає.

kapt досить сирий, так що якщо у вас Dagger + Databinding + чуток дженериків — астанавітісь.

для spring-boot проектів заходить навіть краще, ніж для android.

112 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Кому интересно здесь есть большая серия бесплатных видео-уроков по Android Kotlin www.youtube.com/...​eOlyhw?view_as=subscriber

Ради прикола оставлю это здесь vschart.com/compare/java/vs/kotlin

ухххх, какое-то левое сравнение:)) эт точно, по приколу)

Это ж на сколько время-то экономится?!?!

Всё сэкономленное время будет заполнено вашим менеджером, не переживайте

ниже уже постили эту ссылку

Попри всі переваги котліна, ситуації, як із obj-c і swift для IOS, не відбулося. Не спішать люди переходити на Kotlin, і однією з причин, імхо, є те, що в котліні під капотом не так все класно як зовні.
кому цікаво, ось відео — youtu.be/yYG12qaxWO4

Ушел смотреть, спасибо за ссылку)

У гугла просто не хватает смелости Kotling попиарить)

а вдруг у них в разработке есть свой язык, а тут Котлин начал набирать популярность)

ха-ха, были у меня и такие мыслишки)) как выкатят нам LangGo-плагин под андроид и скажут: «фсе, ребята, лафа закончилась» )

спасибо, тоже глянул. + еще вот это — www.youtube.com/watch?v=CABN2r4GPpQ — не увидел ничего такого ради чего хотелось бы переходить на Котлин. из опыта, проблемы проектов обычно упираются в совсем другие вещи. Java — хорошо сбалансированный язык, который помогает бороться с энтропией на проектах.

Собственно есть уже ряд проектов которые полностью перешли на Kotlin, например pinterest.
Cтоило ещё упомянуть о Anko и RxJava2 для Android проектов.

мне тоже нравится Kotlin. Язык новый, но скорость с которой он развивается, радует.
Для тех кто хочет оценить прелести языка, гляньте — fabiomsr.github.io/...java-to-kotlin/index.html

Дякуб! Дуже корисне посилання, шукав саме такий референс

«интерфейсы теперь могу реализовывать методы!!! Т.е. класс может имплементить два интерфейса, которые имеют различную реализацию метода с одинаковой сигнатурой, и я смогу выбрать, где какой из методов использовать.»

А как это выглядит в коде? У меня, конечно, есть предположения, но хотелось бы убедиться в них.

Так и в джаве есть дефилтные методы

Вони в Java 8 з’явилися. Андроїд сидить на Java 6 і Kotlin цей геп заповнює.
тред не читай @ зразу відповідай

І взагалі я мав на увазі, що в котліні зробили як в джаві до цього. А не те, що можна її використати на андроїді.

Интересно было бы посмотреть на хайперов прошлого, которым когда-то сказали: «Гемороя с множественным наследованием больше не будет». Думаю, они вели себя так же, как те, кто сегодня радуется функиональным интерфейсам, котлину.

Хоч сам обожнюю Котлін, але стаття справила враження, наче єдина причина причина крутості котліна, що можна «;» не писати. Так що трохи прокоментую і поділюсь своїми міслями.

Kotlin на 100% совместим с Java

Про подібне каже будь-яка JVM-мова. Але котлін на цьому полі їх всіх б’є, хоча б тому, що повністю використовє JVM екосистему і бібліотеку. Білдимся в градлі, пишем в ідеї, MutableList<t> — це той же джавовський List<t> (привіт, скала!), можна дуже зручно використовувати джавовські методи й класи і навпаки.

Это ж на сколько время-то экономится?!?!

Імхо, на те, щоб написати дата-клас котліна чи тицьнути на Alt+Ins і згенерувати геттери/сеттери потрібно одинаково часу. І взагалі, для мови швидкість набору — один з останніх критеріїв, на які варти дивитись.

двинуть мышление в сторону Functional Programming(FP)

Kotlin — це в першу чергу better java. Значно better, за що я його й люблю. Але функціональщиной там і не пахне. Так, є лямбди, є map/filter/reduce колекцій, є деяка іммутабельність, як і в інших імеративних мовах, типу джави чи C#. Ніяких монад-трансформерів чи аплікативів х)

И, главное, что на выходе я получаю максимально оптимизированный java-код

На виході такий же байткод, як і після джави, +/-. Так що переїзд на Котлін в n раз код не оптимізує (хіба що він вміє інлайнити лямбди, тобто може бути профіт за рахунок того, що позбудемось від створення анонімних класів).

Основний профіт в тому, що котлін лагодить дуже багато дуже дрібних недоліків джави і в той же час не спонукає програміста писати нечитаємий функціональний бреінфак, писати spaceship operator <|*|> і залишається зрозумілим для Java-розробника. І null-safety, хоч і не рятує, але дуже допомогає.

kapt досить сирий, так що якщо у вас Dagger + Databinding + чуток дженериків — астанавітісь.

для spring-boot проектів заходить навіть краще, ніж для android.

але стаття справила враження, наче єдина причина причина крутості котліна, що можна «;» не писати.
Та ні, не тільки за це;) це було б дуже сумно якби тільки за це

По оптимізації я мав на увазі, що на виході після Котліна ми отримуємо ефективний байт-код, а не якогось товстенького незграбного монстра. Тут річ не в швидкості, а в якості

Про подібне каже будь-яка JVM-мова
хоть одну мову которая поддерживает еще и обратную совместимость назовите)
і згенерувати геттери/сеттери потрібно одинаково часу
можно взять еще AutoValue/Lambok. но по факту нужно еще equals, hashCode, copy писать самому. а это все занимает дофига места и читать не очень удобно
Але функціональщиной там і не пахне
если нужны монады, компоузы, каррирование и тд — для этого есть специальные библиотеки типа funktionale

Lombok @Data генерит equals, hashCode и toString, остаётся только copy написать, а его можно и не писать, ведь есть @Builder(toBuilder = true).

ну может на ведроиде и есть какие-то преимущества
что же касается простейшей вычислительной задачи по фильтрации сигналов, то соотношение производительности kotlin/java составляет 5 к 1...
что говорит об очень сыром компиляторе

они вообще-то содержат куски кода реального проекта, который совсем не open-source
но смысл теста очень простой:
есть массив сигналов, у каждого набор переменных фиксированной длины
есть популяция особей-фильтров (задача генетической оптимизации) с наборами верхних и нижних допустимых значений переменных для сигналов.
для каждой особи вычисляется значение фитнесс-функции — для теста специально была заменена на простое суммирование еще одного поля в сигнале, при условии что все переменные сигнала попадают между верхними и нижними значениями особи-фильтра. в противном случае сигнал не учитывается.
результаты для java/c#/c практически одинаковые:
на тестовом наборе данных примерно 170 секунд.
scala и f# чуть больше чем в два раза медленнее — 390 и 405 секунд,
go посередине — 280 секунд,
а kotlin — 870 секунд.

А какой порядок данных? и было бы интересно узнать КАК именно реализовывалось это для сравнения на джаве и котлине. Задача не выглядит сложной на первый взгляд, и я не вижу, где именно компилятор котлина мог накосячить. Я бы с удовольствием поигрался с написанием такого бенчмарка. Я не хочу сказать, что котлин не виноват — может просто его в данном случае не сумели приготовить)). Ведь даже на супер-эффективном инструменте можно написать супер-неэффективное решение)

Размерности тестовых данных не такие уж и большие: сигналов 100к, переменных у сигналов и особей 30. Особей — 50. Число итераций расчета 1000. Реализацию сходу не дам, надо выпилить оттуда проприетарные куски и упоминания о предметной области. Если реально интересно, то чуть позже (скажем на выходных) могу сделать.

а в цифрах резалты можете еще добавить?

результаты для java/c#/c практически одинаковые:
на тестовом наборе данных примерно 170 секунд.
scala и f# чуть больше чем в два раза медленнее — 390 и 405 секунд,
go посередине — 280 секунд,
а kotlin — 870 секунд.
на котлине 1.1 результат лучше стал — 690 секунд

-12500 249 — котлин
-12500 78 — джава
i7

у меня соотношение было 1 к 4, а тут получается 1 к 3
возможно из-за того что у меня старый i3 5-ти летней давности
но все равно, согласитесь — так не должно быть))

в бенчмарке ошибка, щас реквест пришлю. если убрать оверхед боксинга, выходит
-12500 76 — kotlin
-12500 78 — java

ждю
потому как интересно посмотреть что у меня получится

ха, что ж в доках не пишут что Array это не java array?))

пишут же kotlinlang.org/…​e/basic-types.html#arrays

Kotlin also has specialized classes to represent arrays of primitive types without boxing overhead: ByteArray, ShortArray, IntArray and so on. These classes have no inheritance relation to the Array class, but they have the same set of methods and properties. Each of them also has a corresponding factory function

ну вот до этого места не добрался, думал что прочитал про массивы достаточно...

имхо подобное в доках должно быть очень жирно выделено

ну так какие результаты бенчмарка теперь?

kotlin — 186
java — 172
но это уже в пределах погрешности
интересно, со скалой та же история?
правда в рабочем проекте все равно шарп останется,
там через unsafe и fixed работает быстрее чем на java

из-за JIT возникают погрешности, это с JMH надо бенчмаркать. на выходе у котлина и джавы ± одинаковый байткод должен быть по конкретно этому примеру

в общем, Котлин, тест сдал...фьюх)

Гоферы, они, такие))) От них и не спрятаться и не скрыться)
Спасибо за тесты, пошел смотреть

к примеру для больших коллекций могли не взять секвенцию, а обычные методы, которые создают новые коллекции все из вызова в вызов

В том то и интерес, что данные не меняются. Тестовый набор заполняется один раз, а затем делается тысяча прогонов.

если сможете предоставить бенчмарк на котором это видно, то можете помочь развитию котлина)

Мені теж цікаво. Бо весь мій досвід каже, що в kotlinа швидкість має бути така ж, що і у джави.

местами быстрее, если брать стримы джавы против коллекций котлина

Kotlin — крутейший язык! Но к сожалению без нативной поддержки в платформе это увеличивает размер apk и количество методов

Это, да, но та же типа «нативная гугловская» поддержка Java 8 лямбды переводит в анонимные классы))) так что, через боль и страдания, и мультидекс нам в помощь)

там рантайм небольшой же

github.com/mix-it/mixit пример бекенда на kotlin, spring 5, reactor, gradle kotlin

Кому интересен Котлин с использованием популярных Андроид либ (Glide, Dagger 2, Retrofit 2, Realm, RxJava ) -
github.com/...tting-started-with-Kotlin

Коллекции в Котлине —
github.com/...kiwi/collection_in_kotlin

За шаринг и лайки буду благодарен)

Сам в последнее время погружаюсь в язык и прямо не могу нарадоваться. Больше про Kotlin на DOU!

в GlobalLogic юзают котлин уже?

Сколько уже было этих пустых никому не нужных попыток писать код под Android на PHP/C/C++/С#/Python,
smeshalis’ v kuchu koni, lyudi...pro NDK slyshali?

ну были такие безумные и храбрые, которые ратовали за то, чтобы на NDK писать UI-код: activity, fragment, etc...и книжки даже были по этой теме. Но давненько это было)

Qt na Android rabotaet prekrasno. Native vsegda budet bystree pesochnitsy

Android Chrome полностью написан на Сипипи, на Джаве только Юай.

Я бы на самом деле удивился, если бы хром полностью был написан на джаве)
Для ЮаЯ как-раз джаву и можно использовать, а вот всякий realtime-processing можно и нужно выносить на уровень ниже.

Сколько уже было этих пустых никому не нужных попыток писать код под Android на PHP/C/C++/С#/Python, и где все это сейчас?
А чьи же это тогда слова?;)

ну так есть приложения, где скорость роляет — тот же браузер. Там есть реальный смысл использовать С/С++ при обработке данныйх, построении лейаута. Но юзер-интерфейс нет смысла выносить на уровень ниже, имхо.

Ну т.е это не пустая и никому не нужная попытка?

Уточню свою мысль, если она все еще не ясна: в местах, где роляет скорость, можно/нужно юзать NDK. Переносить на NDK полностью все приложение, имхо, не имеет смысла — просто неэффективно по энергозатратам.

Может это как то связано с Chromium? И почему UI на Java?
И почему то Google не рекомендует вызывать JNI методы без необходимости.

Связано или не связано, какая разница(да, код хромиума кроссплатформенный и для андроида почти ничем не отличается от остальных платформ)? Смысл в том что на С++ под андроид есть мощные прилажухи, которые трудно назвать «бессмысленными и никому не нужными попытками»

Очень многие используют NDK для бекэнда С/С++ библиотек, но это не делает их С++ приложениями, В том же Chrome код под андроид пишется на Java.
Dmitry Oleynichenko имел ввиду попытки полностью писать приложение под
другие языки.

lyudi...pro NDK slyshali?

видел пару исходников серьёзных проектов, у которых большая часть на с/с++. Но вот я, например, зелёный совсем в работе с NDK и вообще не секу пока-что, с чего начинать, чтоб писать обычные проекты на плюсах (не говорю за игры), хотя безумно был бы не против научиться. Подскажите зелёному чуваку, вот я там выучил к примеру слегка плюсы), что почитать дальше, что посмотреть, где увидеть эту тонкую грань, какие классы писать на C++ а какие на Java/Kotlin? :D

Надеюсь, я не один интересуюсь данным вопросом.

В нативную часть(NDK) как правило выносят кроссплатформенную логику или тяжелые вычисления, или работу с С/С++ библиотекой.
Если хотите попробывать NDK в деле — есть примеры в ndk/samples.
Потом попробуйте создать свой проект с OpenCV библитекой, которая например на привью камеры вместо глаз рисует монетки. =)

благодарочка))) буду гуглить)

Как вариант обработку превью камеры тоже запросто можно вынести в NDK и, допустим, делать цветовую коррекцию изображения. Я такое делал.

В очередной раз набирая на клавиатуре в Android Studio строчки кода с циклом for, поймал себя на мысли, что делал это множество раз и уже знаешь каждый следующий оператор, который идет дальше.

Так-так, значит стримы и всю мощь Java 8 вы не используете, но все равно Java осуждаете? :)

Ни в коем случае!!!:) Джаву люблю и уважаю, но вот только нет всей мощи Java 8 в андроиде. Да, они вроде как добавили поддержку тех же лямбд начиная с версии N, что уже что-то хоть и с бубном. Но не лямбдами ж едиными, согласитесь...

Згоден з вами повністю. Так, можна використовувати сторонні бібліотеки, і я знаю багатьох, хто це робить. Але особисто для мене це якісь «милиці». Одна річ — взяти лібку з якимось UI-компонентом, на розробку якого прийдеться витратити, скажімо, неділю, і зовсім інша — це взяти лібку, яка виправляє косяки мови программування. Це якось дуже дивно як на мене, але це особисто моє ставлення до цієї проблеми)
До того ж, неможна взяти і з середини проекту почати використовувати, наприклад, тіж лямбди(retrolambda) і почати переписувати код з їх використанням. Тільки якщо багато вільного часу, і тім-мейти не проти, і QA-інженери не повісять десь на гачку) — їм-то регресію треба буде проводити. А у випадку з Котлін все отримуєш out-of-the-box.
Якось так)

Dagger & ButterKnife не фіксають косяки Java, а лише спрощують нам життя. Той же Котлін відкидає необхідність юзати ButterKnife. Так, раніше це було зроблено окремим плагіном, а зараз все в одному місці. Гугл теж хотят допомогти за дата-байндінгом і роблять свої рішення для цього — але як завжди вже занадто піздно). Той же Даггер прийшов зі Spring, а Spring це фреймворк, але ж ніяк не частина Java.

Jack&Jill взагалі
Як я розюмію, дивлячісь на коменти унизу, ще засирі і мають сайд-ефекти. Сам з ними не працював, тому за свій досвід тут не говорю. Але одного разу, коли робити було нічого, я вирішив перекинути проект з Java 7 на Java 8 і в мене нічого не вийшло, хоча я робив усе «по мурзилке» ))

тут скорее имелось ввиду косяки гугла. Скоро 9 джава будет. Как считаете, когда она на андроиде будет, где пока официально 6 + немного 7?

Николай точно сказал, о чем я не успел написать)

Но почему только для Android? Почему бэкенд проекты не писать на Kotlin?

Можно запросто! Просто для сервер-сайда есть куча java-совместимых-решений со всеми плюшками функционального программирования, поэтому людям есть из чего выбирать) Андроидистам особенно выбирать не приходится. Плюс, ситуативно так вышло, что про Kotlin я узнал именно в ключе Android-разработки, да и сами JetBrains довольно сильно его пиарят в этом направлении.

Андройд жеж поддерживает лямбды, Stream API и что-то ещё из Java 8. Разве не?

Нативная поддержка есть, разве что если писать под API 24+. Что в ближайшие несколько лет нереально.

с помощью Jack toolchain можно использовать Lambda expressions, Method References и Type Annotations на API 23 и ниже. Правда есть небольшие side эффекты

небольшие side эффекты
Jack & Jill вообще сыроват пока. Пару месяцев назад он еще не работал с даггером и датабиндингом, серьезно замедлял билд и вообще вел себя по-свински. К тому же, куда же java 8 да без Stream API? Поэтому да, пока есть «небольшие» side эффекты.

>> Пару месяцев назад он еще не работал с даггером и датабиндингом
Ну да, как и Kotlin

Ахаха! «Совпадение? Не думаю.» ©
И, да, фтопку Jack:)

изначальная идея Jack-a была преобразование java файлов напрямую в dex минуя class файлы.
Legacy javac toolchain:
javac (.java → .class) → dx (.class → .dex)
New Jack toolchain:
Jack (.java → .jack → .dex)

По хорошему, он делал действия, которые выполняли различные тулзы и за счёт этого должен был вырулить в скорости. Но, к сожалению, это повлекло за собой такие тяжёлые последствия, что пришлось отказаться. Переводя его в deprecated они перечёркивают кучу усилий, по сути делают шаг назад, к точке с которой всё начиналось

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
т.е. весь функционал Jack toolchain добавят в javac и dx никого не спрашивая. Чудненько

В Spring 5 поддержка котлина на уровне фреймворка, но можно даже не дожидаться и писать сейчас. Все работает отлично из коробки

На это есть несколько причин:
— вот в статье написано, что он совместим с java на 100%, это не так, например версии 1.0.x не совместима с лямбдами java 1.8 (не знаю, как там обстоит с kotlin 1.1).
— вроде бы kotlin и поддерживает функциональщину, но полноценная поддержка появилась только в версии 1.1
— решение проблемы на 1 000 000 (null safety) не всегда работала (может быть и щас такая же проблема?) и невсегда удобна, не говоря уже о вставке notNull везде и вся. Да, есть опция компилятора, которая отключает это, но эта опция не работает.
— в баг трекере более 1000 ишуе. Да, есть ишуе связанные с идеей, есть с javascript, но колличество впечетляепт, это после релиза версии 1.1. По ощущению, что 1.0.x, в которм тоже было, а может быть и есть приличное кол. багов, был бетой, а вот 1.1.x — это релиз кандидаты. Так что ждем версию 1.2 — и тода можно будет подумать о бэкенде

вот в статье написано, что он совместим с java на 100%, это не так, например версии 1.0.x не совместима с лямбдами java 1.8
что значит не совместима? там SAM конвенции работают. или речь о том что компилируются как анонимные классы?
вроде бы kotlin и поддерживает функциональщину, но полноценная поддержка появилась только в версии 1.1
что в вашем понимании «функциональщина» и чего не хватает?
решение проблемы на 1 000 000 (null safety) не всегда работала (может быть и щас такая же проблема?) и невсегда удобна, не говоря уже о вставке notNull везде и вся. Да, есть опция компилятора, которая отключает это, но эта опция не работает.
все отлично работает. а то что если из котлина вызывать джава код и компилятор не потребует проверки на нул так это такой дизайн, об этом уже не мало говорили
в баг трекере более 1000 ишуе
в спринге полторы тысячи открытых ишьюсов, в скале 2 тысячи, за jdk вообще молчу... у вас были конкретные нерешенные проблемы/баги?
компилируются как анонимные классы?

да именно это, что в конечном итоге приводит к неэффективному байткоду (anonymous inner classes vs lambda — www.infoq.com/...das-A-Peek-Under-the-Hood )

что в вашем понимании «функциональщина» и чего не хватает?

как минимум это означает, что в kotlin 1.0.x не поддерживал ссылку на функции класса — youtrack.jetbrains.com/issue/KT-6947

в спринге полторы тысячи открытых ишьюсов, в скале 2 тысячи, за jdk вообще молчу... у вас были конкретные нерешенные проблемы/баги?

Конечно были. И не только у меня (www.youtube.com/watch?v=CABN2r4GPpQ. А вот сравнивать JDK и стандартную либу котлина как бы не совсем уместно.

— Зачем же мне лямбды Java 1.8, если у меня в kotlin они уже есть и отлично работают?)
— а в Java 8 ее до сих пор нет) и как-то, имхо, некорректно сравнивать, что было между версиями. И нам же важен конечный результат, а не то, что было в середине, так ведь? ;)
— не знаю, у меня проблем с этим не возникло аж ни разу

Зачем же мне лямбды Java 1.8, если у меня в kotlin они уже есть и отлично работают?)

на андроиде сейчас пока не зачем, а вот на бэкенде есть зачем

а в Java 8 ее до сих пор нет) и как-то, имхо, некорректно сравнивать, что было между версиями. И нам же важен конечный результат, а не то, что было в середине, так ведь? ;)

Если вам это не надо, это не означает что и остальным это не надо. Хотя может быть я и не прав, так как на их ресурсах я так и не нашел ответ на вопрос — какие парадигмы поддерживает kotlin? Ну разве что если «Statically typed programming language for the JVM, Android and the browser» — и есть описание парадигм, поддерживаемых котлином :)

youtrack.jetbrains.com/issue/KT-6947 вроде ж как в Fixed состоянии, не? и вот описание реализации — github.com/Kotlin/KEEP/issues/5. Только что проверил — все работает)

Про бекенд согласен, но мы тут больше об Андроиде говорим)

Если вам это не надо, это не означает что и остальным это не надо.
Не совсем понял, что вы тут хотели сказать. Что плохого в том, что в одной версии языка не было фичи, а в следующей она появилась? Язык развивается, добавляются новые возможности и то, что просят/ожидают люди. Какой смысл в «минус» записывать недостаток прошлого, но при этом умалчивать, что этого недостатка уже нет?
и есть описание парадигм, поддерживаемых котлином :)
Вот так в одном месте вроде нигде это у них не описано, НО если сесть и перечитать спеки, то, думаю, можно будет выписать себе чуток;)
Про бекенд согласен, но мы тут больше об Андроиде говорим)

так я же отвечал на вопрос про бэкенд

Не совсем понял, что вы тут хотели сказать. Что плохого в том, что в одной версии языка не было фичи, а в следующей она появилась? Язык развивается, добавляются новые возможности и то, что просят/ожидают люди. Какой смысл в «минус» записывать недостаток прошлого, но при этом умалчивать, что этого недостатка уже нет?

Это описывалось для того, что бы понять, куда движется язык? Есть ли понимание разработчиков языка где он окажется через 3 года? Смогут ли разработчики довести все это до «ума»? По ощущению, что фичи в языке появляются как то спонтанно. Это может привести к проблемам. А это отпугивает разработку бэкенда, который надо будет поддерживать развивать много лет.

Вот так в одном месте вроде нигде это у них не описано, НО если сесть и перечитать спеки, то, думаю, можно будет выписать себе чуток;)

Ну может быть это и появится, кода они наконец напишут спеку к языку, а может и раньше. Но вот, например, в таких языках, как D ( dlang.org/comparison.html ) и Scala ( www.scala-lang.org/what-is-scala.html ) это описано. Это наводит на мысли о том, что разработчики не совсем понимают назначение и использоваение языка (вот относительно недавно они заявили, что готовы двигаться в нативную сторону — blog.jetbrains.com/...otlin/2017/03/kotlin-1-1 ).

Пэтому я бы никому не рекомендовал сейча использовать kotlin версии менее 1.2 на бэкенде в серьезных проектах.

Как минимум помогло выбросить lombok, retrofit и всякие конструкции аля поиск определенных элементов в коллекциях.
еще extensions прикольная штука, избавляет от butterknife
Было ранее множество вылетов IDE, каждый раз отправлял баг репорты.

на бэкэнде используем в продакшне.
и в юнит тестах довольно лаконичный код.
в целом полет нормальный

а ретрофит чем заменили?)

сорри, думал о ретролямде, а написал ретрофит )

Підписатись на коментарі