Сам не сталкивался, но видел упоминание на 4pda о подобной проблеме. Видимо калибровка сенсора слетела. В принципе похоже на брак. И возможно даже подлежит ремонту/замене (если эта услуга оплачивалась при покупке). Но в тоже время поддается лечению через сервисное меню. Если руки из нужного места растут. К сожалению сам подробности рассказать не могу, т.к. просто прочитал про это и забыл. Но думаю, что на 4pda вполне можно найти всю необходимую информацию.
Можно написать пару маленьких программок и декомпилировать.
геттеры и сеттеры будут реализованы как методы getVarName() и setVarName(...)
Даже это делать не надо. В IDEA есть отдельное окно, показывающее, во что превратиться написанный на Kotlin'е исходник. Очень удобно и наглядно демонстрирует качество компилятора...
Null-safety: интересная штука, но на практике во все публичные методы добавляются проверки для каждого аргумента на null. Мне кажется несколько избыточным — и есть подозрение, что это негативно влияет на производительность. (Там не просто проверка, а вызов статического метода с передачей объекта-параметра и его имени как строки, чтобы можно было кинуть понятное исключение)
Это может и выглядит несколько нагружено, если смотреть в байткоде. Но на деле JVM отлично знает как это оптимизировать. И в рантайме никаких издержек выявить не удалось. Более того, если вы попробуете посмотреть, что получется уже на уровне машинного кода после JIT, то навряд ли найдёте эти проверки в явном виде. Где-то про это даже доклад был на одной из конференций.
И первый вопрос для затравки: какие планы по улучшению быстродействия работы плагина Kotlin в Idea?
Дело в том, что если в большом проекте добавить .kt файл, то IDE начинает просто очень медленно работать. Реакция code intelligence может достигать 10-ти секунд и более. Подсветка то слетает, то опять появляется ну и т.п.
Спасибо. К счастью ViewState'а у нас нету. Но вот то, что в Wildfly все коммуникации повесили на один порт (и http и EJB) — неприятно. Пытаюсь сообразить какие могут быть вектора атаки с учётом нашей инфраструктуры. Но для этого надо иметь на руках рабочий экспоид.
Странно. Хотел попробовать прогнать этот эксплоид на нашем приложении, но что-то пошло не так.
Даже если я просто создаю объект, как написано в статье, сериализую его, а потом тут же десериализую, то получаю ошибку десериализации:
Stacktrace
Exception in thread "main" java.lang.ClassCastException: java.lang.Integer cannot be cast to java.util.Set
at com.sun.proxy.$Proxy0.entrySet(Unknown Source)
at sun.reflect.annotation.AnnotationInvocationHandler.readObject(AnnotationInvocationHandler.java:443)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1017)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1893)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
at ru.krista.exploid.Exploid1.deserialize(Exploid1.java:113)
at ru.krista.exploid.Exploid1.send(Exploid1.java:75)
at ru.krista.exploid.Exploid1.main(Exploid1.java:30)
Есть подозрение, что код специально подпорчен. Но вот где ошибка — понять не могу.
Возможно величина ускорения зависит от того, что именно (и как) используется при сборке. Так, например, maven-assembly-plugin не меняет своего времени исполнения, при этом может оказывать существенное влияние на время сборки.
Мы из-за этого выделили проекты, использующие такие плагины в сторону. Благо их немного и для целей разработки каждый раз их собирать вовсе не обязательно.
Ещё Takari не получается использовать со всякими нестандартными сборками а-ля kie-maven-plugin от drools.
Так что это вполне может быть связано с особенностями проекта. Если в проекте преимущественно простые jar артефакты, то ускорение получается очень вкусным.
С ошибками на чистом локальном репозитарии не сталкивались, хотя так делается ночная сборка. Возможно тут у Вас тоже какая-то специфика проекта. Или что-то упущено при настройке.
В целом сейчас никто у нас уже даже думать не хочет о возвращении обратно. Хоть местами это и вызывает некоторые неудобства.
Да с AST там не сильно понятно. Создаётся впечатление, что это должно быть где-то на поверхности, но когда попытался разобраться, то быстро заблудился. Возможно опыт личных навыков в этой области не хватило. Так-то у них даже есть модуль под названием kotlin-compiler-embeddable. Но никакой информации по поводу него найти не удалось.
Скорее всего где-то там AST искать надо. Если будет время вечером — попробую сделать ещё один заход в ту сторону. По крайней мере теперь есть конкретная мотивация.
Ну, например, бегло пробежавшись по исходникам, даже не понял толком, как это работает. Хотя толком не вникал. Было бы интересно получить некоторую развёрнутую информация как реализован функционал. Какие и как использовались технологии. Чтобы другим было легче разобраться и, возможно, попробовать что-либо добавить.
Ну как-то так. Извиняюсь, если слишком сумбурно. Просто тема очень взбудоражила, а работа тоже не ждёт…
ВАУ! Вы прям мои мысли прочитали. Сам давно думаю над подобным, но всё никак не соберусь с духом. А тут уже такой задел хороший.
Правда все мои эксперименты крутятся вокруг геометрических шейдеров. Так что их точно хотелось бы увидеть (или доделать :).
По поводу Kotlin — тоже интересно. Нужно будет на досуге глянуть что да как у Вас сделано. Сейчас как раз развлекаюсь с переписыванием некоторых хитрых алгоритмов на котлин. Очень результат нравится.
И ещё вопрос: а у вас шейдеры какой версии генерируются? Лично меня интересуют возможности 4.2 и выше. Но в тоже время я понимаю, что это только мой интерес. Большинство сейчас на Android затачивается и в результате ограничивает себя исключительно версиями около 3.3. Возможно имеет смысл предусмотреть какой-то способ указания версии шейдеров.
Так же подозреваю, что за уадром осталась довольно интересная история по разработке этой красоты с техническими подробностями :-). Думаю многим было бы интересно :-).
P.S. Огромное спасибо за статью. Буду напосмотреть.
Про длинные перерывы — в онлайне наверное удобнее короткие, а на площадке народ просто выдыхается ко второму дню. Поэтому это осознанное решение.
Полностью согласен. До сих пор пытаюсь отоспаться и при этом стойкое ощущение, что ничего не успел. Времени катастрофически не хватало.
Возможно, что это результат слишком активной позиции к конференции. К примеру одному из моих коллег было местами даже скучно.
При этом к концу первого дня просто сдох и ушёл с доклада Джона. Просто случился перегруз.
между докладами уменьшить перерыв с получаса минут до 15
Раньше так и было, если я не ошибаюсь. Но этого реально мало, т.к. всегда хочется по горячим следам обсудить с докладчиком дополнительные вопросы. Из-за этого на JPoint нас постоянно гоняли организаторы, а тут, на Joker, я катастрофически опоздал на оба обеда.
Беспокоит принципиальная возможность этого. Когда разработчики объявляли об отказе от NPAPI у меня уж очень нехорошие подозрения закрались, что они вообще любую возможность добраться до нативного кода хотят заблокировать. А раз так, то не факто что КриптоПро хоть что-то сможет выкатить.
Плюсую вопрос. У нас подпись с использованием CryptoPro — одно из основных требований. Сейчас до него можно достукиваться через плагин от самих CryptoPro, или через самописный Java Applet. А вот что будет без NPAPI?
С другой стороны можно некоторые вещи делать наоборот, например админ собирает контейнер с системой, содержащей нужные настройки и передает разрабам, а они свой проект запускают уже внутри. при таком раскладе они будут тестировать ПО в окружении идентичному боевому.
Во-о-от! А если ещё вспомнить про то, что докер может наследовать одни образы от других. То и получается следующая картина:
Админы делают правильный базовый образ ОС
Разрабы поверх этого добавляют приложение с минимально необходимыми настройками (В нашем случае: WildFly8 + каталоги с шаблонами + JMS очереди + Infinispan кэши + и т.д.). Можно даже многое параметризировать, по договорённости с админами
Поверх минимального приложения амины делают итоговую настройку. Как правило уже под конкретное клиентское внедрение
Даже это делать не надо. В IDEA есть отдельное окно, показывающее, во что превратиться написанный на Kotlin'е исходник. Очень удобно и наглядно демонстрирует качество компилятора...
Это может и выглядит несколько нагружено, если смотреть в байткоде. Но на деле JVM отлично знает как это оптимизировать. И в рантайме никаких издержек выявить не удалось. Более того, если вы попробуете посмотреть, что получется уже на уровне машинного кода после JIT, то навряд ли найдёте эти проверки в явном виде. Где-то про это даже доклад был на одной из конференций.
И первый вопрос для затравки: какие планы по улучшению быстродействия работы плагина Kotlin в Idea?
Дело в том, что если в большом проекте добавить .kt файл, то IDE начинает просто очень медленно работать. Реакция code intelligence может достигать 10-ти секунд и более. Подсветка то слетает, то опять появляется ну и т.п.
Оказывается ошибка и должна быть. Но она происходит уже после срабатывания уязвимости. Просто я неудачную команду для выполнения выбрал.
Не работает. А вот
уже отрабатывает.
Даже если я просто создаю объект, как написано в статье, сериализую его, а потом тут же десериализую, то получаю ошибку десериализации:
Есть подозрение, что код специально подпорчен. Но вот где ошибка — понять не могу.
Возможно величина ускорения зависит от того, что именно (и как) используется при сборке. Так, например, maven-assembly-plugin не меняет своего времени исполнения, при этом может оказывать существенное влияние на время сборки.
Мы из-за этого выделили проекты, использующие такие плагины в сторону. Благо их немного и для целей разработки каждый раз их собирать вовсе не обязательно.
Ещё Takari не получается использовать со всякими нестандартными сборками а-ля kie-maven-plugin от drools.
Так что это вполне может быть связано с особенностями проекта. Если в проекте преимущественно простые jar артефакты, то ускорение получается очень вкусным.
С ошибками на чистом локальном репозитарии не сталкивались, хотя так делается ночная сборка. Возможно тут у Вас тоже какая-то специфика проекта. Или что-то упущено при настройке.
В целом сейчас никто у нас уже даже думать не хочет о возвращении обратно. Хоть местами это и вызывает некоторые неудобства.
Просто изначально не догадался начать с kotlin-maven-plugin. Который простой как палка.
Скорее всего где-то там AST искать надо. Если будет время вечером — попробую сделать ещё один заход в ту сторону. По крайней мере теперь есть конкретная мотивация.
Ну как-то так. Извиняюсь, если слишком сумбурно. Просто тема очень взбудоражила, а работа тоже не ждёт…
Правда все мои эксперименты крутятся вокруг геометрических шейдеров. Так что их точно хотелось бы увидеть (или доделать :).
По поводу Kotlin — тоже интересно. Нужно будет на досуге глянуть что да как у Вас сделано. Сейчас как раз развлекаюсь с переписыванием некоторых хитрых алгоритмов на котлин. Очень результат нравится.
И ещё вопрос: а у вас шейдеры какой версии генерируются? Лично меня интересуют возможности 4.2 и выше. Но в тоже время я понимаю, что это только мой интерес. Большинство сейчас на Android затачивается и в результате ограничивает себя исключительно версиями около 3.3. Возможно имеет смысл предусмотреть какой-то способ указания версии шейдеров.
Так же подозреваю, что за уадром осталась довольно интересная история по разработке этой красоты с техническими подробностями :-). Думаю многим было бы интересно :-).
P.S. Огромное спасибо за статью. Буду напосмотреть.
Полностью согласен. До сих пор пытаюсь отоспаться и при этом стойкое ощущение, что ничего не успел. Времени катастрофически не хватало.
Возможно, что это результат слишком активной позиции к конференции. К примеру одному из моих коллег было местами даже скучно.
При этом к концу первого дня просто сдох и ушёл с доклада Джона. Просто случился перегруз.
Раньше так и было, если я не ошибаюсь. Но этого реально мало, т.к. всегда хочется по горячим следам обсудить с докладчиком дополнительные вопросы. Из-за этого на JPoint нас постоянно гоняли организаторы, а тут, на Joker, я катастрофически опоздал на оба обеда.
Буду рад ошибиться.
Во-о-от! А если ещё вспомнить про то, что докер может наследовать одни образы от других. То и получается следующая картина:
Каждый делает свою работу. И всем хорошо.