Не надо использовать job, возвращенный из launch внутри этого самого launch — это ошибка. Вам никто не гарантирует, что он уже будет заполнен. Безотносительно исходной задачи надо делать coroutineContext[Job]!!. А если я саму задачу правильно понял, то лучше вообще вместо GlobalScope и ручной отмены использовать просто coroutineScope {}.
antonkeks, в 13 объяснение какое-то совсем неверное. Какой еще компилятор? Какое еще «почему-то»? Какое еще «постарался, но не получилось»? Здесь нет вообще никакой неопределенности и работают исключительно стандартный джавовый механизм загрузки классов.
Котлиновский object — это статический INSTANCE филд в одноименном классе. Инициализация статических филдов происходит в момент инициализации класса, а инициализация классов в джаве отложенная и происходит при первом использовании. Соответственно, в момент первого «println(B.x)» начинает инициализироваться класс B. Ему, для того, чтобы создать этот INSTANCE, нужен класс C. Но в процессе инициализации C при попытке доступа к B.INSTANCE инициализация B не начинается повторно (сама jvm так работает). Соответственно, идет просто чтение еще не инициализированного поля B.INSTANCE (==null) и создание и запись нового объекта в C.INSTANCE. После чего мы выходим из инициализации класса C и спокойно уже обращаемся к его филду (INSTANCE) и создаем красивый, заполненный, B.INSTANCE.
А если заменить Any? на просто Any, то там тоже компилятор ничего дополнительно «пытаться» не начинает. Он просто в конструктор A вставляет проверку на аргумент т.к. он может прийти из джавы и не быть проверенным на стороне вызова. И именно эта проверка и падает. Банальное добавление -Xno-param-assertions в опции компилятора приводит к результату «C null» и с Any тоже.
p.s. По поводу инициализации классов. Вот простой пример, демонстрирующий, что ни бесконечной рекурсии, ни каких-либо ошибок не происходит.
Спасибо за пост, было приятно прочитать и вспомнить. Но ведь это все уже было на джокере в 2014, даже слайды из того доклада! И гораздо интереснее было бы не просто прочитать еще раз что и как у вас сделано, а узнать что изменилось за эти 4 года. Где получилось даже лучше, чем вы рассчитывали, а где, напротив, что-то пошло совсем не так.
Спасибо! Вот неудобный вопрос вы задали. Можно сказать, что в val card = cardDAO.paritalGet<MsisdnAndBalance>(cardId), но это больше как шутка. На самом деле, довольно долго думал пихать ли в котлин, но по итогу решил, что раз такая реализация partialGet для использования из котлина так же хороша, как и из джавы, то пусть там тоже будет. Был бы хаб JVM, сунул бы только туда.
наложено требование на отсутствие проксей и единственный запрос
С lazyload/кэшом сущностей такое невозможно.
ORM уже написаны
В первой версии этого поста был еще большой кусок про то, зачем нам вообще нужен свой ORM и чем плох тот же Hibernate. Тем не менее, пост и так получился слишком большим, так что кусок был выпилен, т.к. это уже совсем отдельный вопрос. И к рассматриваемой проблеме отношения не имеет.
Я просто буду отмечать звёздочками места где, по моему мнению, в нормальной жизни магазин бы закрылся.
Ох, надо было это предложение первым ставить. Я после «поставок*» минуты три потратил в попытках найти сноску где-нибудь в статье или в комментариях. И только когда, уже изрядно огорченный, решил просто забить и продолжить чтение, наткнулся на данное предложение.
А про какое вообще поле речь и где оно заполнится автоматически? Я знаю только один способ сделать такое, но тут нужно и методы писать, и их реализацию. Неужели я упустил что-то очень крутое?!..
class HttpConnector(var port: Int? = null, var host: String? = null)
class JettyBuilder {
fun httpConnector(f: HttpConnector.() -> Unit): Unit = TODO()
}
class ConfigBuilder {
fun jetty(f: JettyBuilder.() -> Unit): Unit = TODO()
}
fun config(f: ConfigBuilder.() -> Unit): Unit = TODO()
тогда котлин ещё не поддерживал DSL (появилось в 1.1.1)
А поясните пожалуйста. kotlin dsl — это экстеншн лямбды и возможность писать лямбду-последний аргумент «за пределами вызова функции» как блок кода. Обе эти штуки были с релиза.
Придрались к формулировке? Ок, сам виноват. Но если по сути. Вы сделали предположение, что, во-первых, «что ни одна цифра, использованная в фальшивом пине, не используется в реальном», а, во-вторых, злоумышленник считает так же. Я же предположил, что первое неверно. А второе, в таком случае, уже не имеет смысла.
Почему вы считаете что ваше предположение верно, а мое нет?
Сразу вопрос по первому примеру. А зачем все эти вызовы worker.setService*? Мы же только что создали воркера уже передав ему все сервисы в конструктор.
Откуда такое дикое предположение? Это, очевидно, неверно. Более того, даже нет гарантии что ни одна из цифр не стоит уже правильная на правильном месте.
Так как раз в этом суть. В джаве тип определяется декларацией, а не использованием. И это глобальное поведение. И var иначе работать не имеет права. Соответственно, данная строчка должна определять тип однозначно и независимо от того, финальный это вызов или же дальше будет еще strings.size() или strings.trimToSize().
Более того, если тип определяется дальнейшим использованием то эта ситуация полностью идентична как раз typeOf(strings) ≡ ArrayList<String>.
Не надо использовать
job, возвращенный изlaunchвнутри этого самогоlaunch— это ошибка. Вам никто не гарантирует, что он уже будет заполнен. Безотносительно исходной задачи надо делатьcoroutineContext[Job]!!. А если я саму задачу правильно понял, то лучше вообще вместоGlobalScopeи ручной отмены использовать простоcoroutineScope {}.Котлиновский object — это статический INSTANCE филд в одноименном классе. Инициализация статических филдов происходит в момент инициализации класса, а инициализация классов в джаве отложенная и происходит при первом использовании. Соответственно, в момент первого «println(B.x)» начинает инициализироваться класс B. Ему, для того, чтобы создать этот INSTANCE, нужен класс C. Но в процессе инициализации C при попытке доступа к B.INSTANCE инициализация B не начинается повторно (сама jvm так работает). Соответственно, идет просто чтение еще не инициализированного поля B.INSTANCE (==null) и создание и запись нового объекта в C.INSTANCE. После чего мы выходим из инициализации класса C и спокойно уже обращаемся к его филду (INSTANCE) и создаем красивый, заполненный, B.INSTANCE.
А если заменить Any? на просто Any, то там тоже компилятор ничего дополнительно «пытаться» не начинает. Он просто в конструктор A вставляет проверку на аргумент т.к. он может прийти из джавы и не быть проверенным на стороне вызова. И именно эта проверка и падает. Банальное добавление -Xno-param-assertions в опции компилятора приводит к результату «C null» и с Any тоже.
p.s. По поводу инициализации классов. Вот простой пример, демонстрирующий, что ни бесконечной рекурсии, ни каких-либо ошибок не происходит.
Спасибо! Вот неудобный вопрос вы задали. Можно сказать, что в
val card = cardDAO.paritalGet<MsisdnAndBalance>(cardId), но это больше как шутка. На самом деле, довольно долго думал пихать ли в котлин, но по итогу решил, что раз такая реализация partialGet для использования из котлина так же хороша, как и из джавы, то пусть там тоже будет. Был бы хаб JVM, сунул бы только туда.Серьёзно? Это всё, что вас заинтересовало?
С lazyload/кэшом сущностей такое невозможно.
В первой версии этого поста был еще большой кусок про то, зачем нам вообще нужен свой ORM и чем плох тот же Hibernate. Тем не менее, пост и так получился слишком большим, так что кусок был выпилен, т.к. это уже совсем отдельный вопрос. И к рассматриваемой проблеме отношения не имеет.
Ох, надо было это предложение первым ставить. Я после «поставок*» минуты три потратил в попытках найти сноску где-нибудь в статье или в комментариях. И только когда, уже изрядно огорченный, решил просто забить и продолжить чтение, наткнулся на данное предложение.
А поясните пожалуйста. kotlin dsl — это экстеншн лямбды и возможность писать лямбду-последний аргумент «за пределами вызова функции» как блок кода. Обе эти штуки были с релиза.
Почему вы считаете что ваше предположение верно, а мое нет?
Более того, если тип определяется дальнейшим использованием то эта ситуация полностью идентична как раз typeOf(strings) ≡ ArrayList<String>.
Какой здесь должен быть тип у переменной strings?
Если в двух словах, то jit в векторизацию умеет, но нестабильно и непредсказуемо.