我有一個簡單的注釋處理器，其應用如下：@DiffElement(diffReceiver = Renderer.class)class ViewState {? String getHello();? int getWorld();}class Renderer {? void renderHello(String hello);? void renderWorld(int world);}為了使該處理器工作，get-functions 和Renderer-interface 函數參數的名稱必須匹配。它檢查這一點并使用注釋的參數來查看提供的類并基于該類進行一些代碼生成。它生成一個文件。我已閱讀有關增量注釋處理的文檔，但我無法決定應用于該處理器的類別。以下是我的考慮：它不可能isolating，因為它不會從帶注釋的元素的 AST 派生所有內容，因為它還從注釋參數檢查類不可能aggregating，因為它在類上沒有任何注釋Renderer，所以根據上面的文檔，每當類發生變化時，處理器都不會被調用Renderer，因為處理器還沒有注冊來處理這個文件，所以這會導致生成結果中的錯誤。問題：我正確理解文檔嗎？或者某些類別是否仍適用于該處理器如果它不屬于任一類別，我如何告訴 Gradle 它不是增量的，因此像“kotlin kapt”這樣的工具不會向用戶抱怨我的處理器不是增量的
2 回答
慕容森
TA貢獻1853條經驗 獲得超18個贊
我正確理解文檔嗎？或者某些類別是否仍適用于該處理器
關于處理器類別的文檔非常簡短，而且在我看來，缺乏示例。我花了很多時間來弄清楚這些文檔，構建一些簡單的實驗項目。所以，據我所知，如果我最終正確地弄清楚了它們，就可以應用一個類別:)
你這么說
它不能隔離，因為它不會從帶注釋元素的 AST 派生所有內容，因為它還從注釋參數檢查類
這并不完全正確，我將解釋原因。正如文檔中提到的，隔離處理器
必須根據可從其 AST 獲取的信息為帶注釋的類型做出所有決策（代碼生成、驗證消息）。這意味著您可以分析類型的超類、方法返回類型、注釋等，甚至是傳遞性的。
“甚至傳遞”短語在這里非常重要 - 它意味著，您不僅可以分析帶注釋類型的 AST，還可以分析其中某些方法的返回類型的 AST，然后，比方說，分析該類型的超類。 ..
據我了解，您可以通過 AST 從帶注釋的元素中遍歷發現的每種類型，都是帶注釋的類型（或一般元素）的依賴項。如果依賴項發生更改，則依賴類型需要重新編譯。因此，當Renderer類更改時，ViewState?將重新編譯并因此重新處理，因為它引用?Renderer?作為其注釋參數。超類型、超接口、方法的返回類型、方法參數的類型、注釋類參數……所有這些都被視為依賴類型。
因此，您的注釋處理器實際上可以隔離.
PS如果隔離不起作用，請確保注釋保留為CLASS或更高，無論出于何種原因。
PPS我發現注釋處理中的增量是一個非常陰暗的話題，充滿了驚喜和水下巖石。我自己發現的經驗法則是，幾乎每個經過一些調整的處理器都可以隔離，除非它確實需要基于許多輸入生成一個實體。而且，重要的是，只有這些輸入在引用方面彼此完全無關，甚至位于不同的庫中。
DIEA
TA貢獻1820條經驗 獲得超2個贊
它不能聚合，因為它在 Renderer 類上沒有任何注釋，所以根據上面的文檔，每當 Renderer 類發生變化時，處理器都不會被調用，因為處理器還沒有注冊來處理這個文件，所以這個將導致生成的結果出現錯誤。
這不會是一個直接的答案，但我認為它仍然可以回答您的問題：據我所知，這個陳述是您問題的實際根源。任何溫和的增量系統都會讓你失敗，而不僅僅是 Gradle 的“聚合”模式（例如，嘗試在一個簡單的 Eclipse 項目中使用你的處理器，甚至可能是 IntelliJ，盡管我在那里得到了好壞參半的結果）。
如果您實際上想要強制對未注釋類型的更改將導致注釋處理器再次運行，則不得將注釋處理器限制為該注釋，但必須返回來自 的魔術值，指示任何更改的類都"*"必須getSupportedAnnotationTypes()觸發處理器重新運行。來自此方法的 Javadoc：
最后，“*”本身代表所有注釋類型的集合，包括空集。請注意，處理器不應聲明“*”，除非它實際上正在處理所有文件；聲明不必要的注釋可能會導致某些環境中的性能下降。
理想情況下，您只需創建第二個（或第三個等）注釋來提供此提示，但這并不總是可行，這就是為什么您可以使用此通配符選項
添加回答
舉報
0/150
提交
取消