Comments (11)
Dear @bcorso,
I am also facing this issue. In my case, the issue happens when I modify an Activity file that hosts fragments. I created a sample project where I can reproduce it on my end.
https://github.com/alpaca0984/DaggerKspIssueRepro
I hope it helps the investigation.
from dagger.
I tried patching the repro, and can consistently reproduce the issue with dagger 2.50. But the issue seems to be gone with dagger at head. So next release should fix this problem.
from dagger.
I'm also having this issue with an app using Circuit and its associated codegen artifacts; I'll try to create a simple project to reproduce the issue.
from dagger.
That might be tricky because to me it is happening with pretty large commercial app but I will try to reproduce this with a sample project over the weekend by isolating a module where the stack trace points to and deleting everything that's irrelevant (no promises though 😄). I also have a smaller project but that does not uses @ContributesAndroidInjector and there KSP works as expected so that's definitely needed to reproduce this bug.
from dagger.
I'm also experiencing this. In addition to the author's description, despite second build being successful, it takes way longer to build and run than it was before. It feels like there is no incremental build and full clean rebuild is happening. Changing even one line of kotlin code makes it 5 minutes to run in the emulator. Before it would take me less than 10 sec to get latest code into the running app. XML code changes work fine - runs on 1st attempt and fast compilation times as before.
I also tried with AGP 8.2.1 and kotlin 1.9.22 with ksp 1.9.22-1.0.16 and the problem is still there.
from dagger.
Hi, I was able to repro the problem at head, not sure why couldn't repro earlier. It seems to be a ksp bug where the cached generated source file wasn't discoverable by the processor. I'm working with ksp team on this issue now, will follow up once made progress. Thanks for the patience!
from dagger.
@wanyingd1996 Thank you for the fix on this issue. I just upgraded my project to the latest dagger version and for me the issue still persist however I am getting a different exception than before saying that a generated file already exists. I saw that there is a similar issue #4161 but in my project I do not use hilt and I still get this exception. After building again the issue disappears just like before. Here is my stack trace, I would appreciate if you would take a look and let me know if I should open a new issue for this one.
Thanks in advance.
java.nio.file.FileAlreadyExistsException: ~\build\generated\ksp\*******Debug\java\com\***\***\***\***\***\*******_Factory.java
at java.base/sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:124)
at java.base/sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:284)
at java.base/java.nio.file.Files.copy(Files.java:1305)
at com.google.devtools.ksp.common.IncrementalUtilKt.copyWithTimestamp(IncrementalUtil.kt:80)
at com.google.devtools.ksp.AbstractKotlinSymbolProcessingExtension.updateFromShadow(KotlinSymbolProcessingExtension.kt:477)
at com.google.devtools.ksp.AbstractKotlinSymbolProcessingExtension.doAnalysis(KotlinSymbolProcessingExtension.kt:375)
at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration(TopDownAnalyzerFacadeForJVM.kt:112)
at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration$default(TopDownAnalyzerFacadeForJVM.kt:77)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler$analyze$1.invoke(KotlinToJVMBytecodeCompiler.kt:256)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler$analyze$1.invoke(KotlinToJVMBytecodeCompiler.kt:247)
at org.jetbrains.kotlin.cli.common.messages.AnalyzerWithCompilerReport.analyzeAndReport(AnalyzerWithCompilerReport.kt:115)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.analyze(KotlinToJVMBytecodeCompiler.kt:247)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.repeatAnalysisIfNeeded(KotlinToJVMBytecodeCompiler.kt:181)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.repeatAnalysisIfNeeded(KotlinToJVMBytecodeCompiler.kt:181)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileModules$cli(KotlinToJVMBytecodeCompiler.kt:87)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileModules$cli$default(KotlinToJVMBytecodeCompiler.kt:43)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:165)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:50)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:104)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:48)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:101)
at org.jetbrains.kotlin.daemon.CompileServiceImpl.compile(CompileServiceImpl.kt:1523)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:360)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:840)
from dagger.
Hi, @palpapp04, from the stack trace you provided, nothing points to dagger or hilt, it seems a bug from ksp side during incremental processing that fails to handle generated file. It is different from #4161, as that bug happens when hilt is trying to write file. So I think you may want to try bump your ksp version first, if it still fails, file a bug to the ksp issue.
from dagger.
I am also experiencing this problem (just commenting to raise awareness of this one)
from dagger.
Thanks, if you can provide a project reproducing this that would help a lot.
from dagger.
@wanyingd1996 I just tried it out after the release of Dagger 2.51 and I am still seeing this problem unfortunately
from dagger.
Related Issues (20)
- Update Dagger guava dependency to address CVE-2023-2976 HOT 2
- Add KMP support for @HiltViewModel annotation HOT 2
- Dagger resolution and dynamic feature module HOT 1
- Feature request: Manually regenerate application component HOT 1
- Using TestContainer.com HOT 2
- Detect dependency cycles containing Lazy or Provider during the compilation time HOT 6
- error when ksp.useKSP2=true HOT 2
- Suppress annotation on @Inject is not honored on the Factory HOT 1
- [KSP2] Dagger and Hilt incompatibility with KSP2 HOT 2
- [KSP2] NullPointerException: null cannot be cast to non-null type androidx.room.compiler.processing.XType HOT 1
- App crashing with NPE for some classes when Lazy Class Key is used HOT 6
- OutOfMemoryError with Maven HOT 1
- DaggerAppComponent not creating in the version 2.51.1 HOT 3
- java.lang.ClassNotFoundException: dagger.spi.shaded.androidx.room.compiler.processing.javac.JavacBasicAnnotationProcessor. Hilt 2.49+ HOT 1
- how to manually generate module HOT 1
- Explain how to add dagger jar files manually to the android project HOT 2
- Annotate interface with default Bind implementation HOT 2
- Transitive vulnerability from symbol-processing-api HOT 1
- java.lang.IllegalArgumentException: CreationExtras must have a value by `SAVED_STATE_REGISTRY_OWNER_KEY` HOT 2
- Update of different dependency: Error "package javax.annotation.processing is not visible" HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dagger.