- 1,109
- 47
- 425
Иконка ресурса
Вырезалка 2
- Автор темы JustAGod
- Дата начала
- 7,164
- 329
- 1,543
Только если эта фича предназначена для килла самой вырезалки
Ведь это костыль, который к тому же заставляет писать бойлерплейт-код.
Почему нельзя сделать вырезание полей вместе с вырезанием usage, которые не вырезались обработкой других аннотаций?
- 1,109
- 47
- 425
Представь кейс
вот с точки зрения байт кода обе ти инициализации будут выглядеть одинаково
если просто вырезать PUTFIELD для всех таких случаев у вас сломается обфускации и иногда стэк мапы
+ внезапные приколы когда вызывается метод который как бы не виден
можно подумать над анализом стэка но тогда мне нужно будет уметь парсить абсолютно все опкоды жавы.
Java:
class SomeClass {
String a = "";
String b;
SomeClass() {
b = "";
}
}если просто вырезать PUTFIELD для всех таких случаев у вас сломается обфускации и иногда стэк мапы
+ внезапные приколы когда вызывается метод который как бы не виден
можно подумать над анализом стэка но тогда мне нужно будет уметь парсить абсолютно все опкоды жавы.
- 7,164
- 329
- 1,543
Может, стоит попробовать работать через парсинг исходников в синтаксическое дерево, вырезать поля и их usage на этом уровне, генерировать из этого дерева новый код и после отправлять его на обычную компиляцию?
- 7,164
- 329
- 1,543
PUTFIELD ведь берет значение из стэка, может тогда заменять PUTFIELD вырезаемых полей на POP? Тогда стэк не поменяет своей структуры.
Это кст ты же мне советовал для одного кейса хуклибы
- 1,109
- 47
- 425
с точки зрения жавы это действительно будет валидным байт-кодом, но:
1) В хук либе действительно это нормальное решение потому что дальше рантайма оно не уходит, но в данном случае от этого сломаются как минимум 3 обфускатора. Так как я хочу потом вырезалку использовать в своих целях, это критично
2) в кейсе типа
1) В хук либе действительно это нормальное решение потому что дальше рантайма оно не уходит, но в данном случае от этого сломаются как минимум 3 обфускатора. Так как я хочу потом вырезалку использовать в своих целях, это критично
2) в кейсе типа
String a = function() функция будет вызываться. Что, я считаю, не инткутивно и не правильно.
- 7,164
- 329
- 1,543
В конфигурации сборки требуется указывать имя аннотации, влияющие на сторону поля и варианты сборки. Можно приведенный вариант настройки сделать дефолтным, а также сделать готовые дефолтные аннотации и интерфейсы инвокеров? Тогда сетап верезалки будет сводиться к минимуму: добавление репы и включение плагина.
Для большинства простых проектов этого будет хватить по идее
~~~
Или там проблема в том, что плагин не добавляет своего кода в проект? Можно аннотации и интерфейсы скомпилить в отдельную либу, а плагин будет подключать эту либу к проекту?
Для большинства простых проектов этого будет хватить по идее
~~~
Или там проблема в том, что плагин не добавляет своего кода в проект? Можно аннотации и интерфейсы скомпилить в отдельную либу, а плагин будет подключать эту либу к проекту?
- 1,109
- 47
- 425
проблема в том что мне не нравится если плагин будет насильно чота пихать, особенно по дефолту
мне нравится идея настройки без конфига, но я скорее соглашусь на настройку одной строкой
типа
cutter.initializeDefault()кста звучит классно
- 7,164
- 329
- 1,543
Насколько я понял, аннотацию anno.SideOnly нужно создать самому. Но ведь случай разделения на клиент и сервер юзается в большинстве проектов, поэтому приведенную в примере аннотацию стоит добавить в сам плагин, чтобы для юза вырезалки нужно было только включить плагин и юзать аннотацию из плагина.
Интерфейсы инвокеров тоже по идее в большинстве случаев будут одинаковыми
Интерфейсы инвокеров тоже по идее в большинстве случаев будут одинаковыми
- 1,109
- 47
- 425
ну да собственно если возражений нет, я наверно вот так сделаю
- 1,109
- 47
- 425
теперь эта штука обрабатывает собранный жарник а не классы
- 1,109
- 47
- 425
У меня были автотесты для градла чистого, для градла 1.7.10, для градла 1.8, но вот для 1.12.2 не было... Щас будет, да.
Но вапще попрошу полный лог пожалуйста