SlickEdit Product Discussion > SlickEdit®
Java Live Errors refuses to recognize some classes
rygaard:
I'm having difficulty with Java Live Errors incorrectly flagging references to certain classes as "not found".
In particular, I cannot coax Live Errors to recognize the classes in Log4J 2, and in the org.json.* package. I suspect I have some misconfiguration, but I can't find it. I don't have much visibility into how Live Errors works, so I'm not sure where to look.
I ran several experiments while trying to diagnose the problem with Log4J 2 on Windows using SlickEdit 27, including:
* I included log4j-api-1.19.0.jar and log4j-core-2.19.0.jar in my CLASSPATH system environment variable, and included %(CLASSPATH) in my SlickEdit class path. When I do this, I'm able to compile classes that reference Log4J 2 in SlickEdit using project-compile command (invoked via a keyboard shortcut) just fine. However, all references to any class in the Log4J2 library are flagged by Live Errors.
* I removed log4j-api-1.19.0.jar and log4j-core-2.19.0.jar from my CLASSPATH system environment variable, but I left %(CLASSPATH) in my SlickEdit class path. I added log4j-api-1.19.0.jar and log4j-core-2.19.0.jar to the SlickEdit class path. When I do this, I'm able to compile classes that reference Log4J 2 in SlickEdit using project-compile command (invoked via a keyboard shortcut) just fine. However, all references to any class in the Log4J2 library are flagged by Live Errors.
* I extracted the Log4J2 source code to a temporary directory, I removed log4j-api-1.19.0.jar and log4j-core-2.19.0.jar from my CLASSPATH system environment variable, I added the temporary directory to my CLASSPATH system environment variable, and I included %(CLASSPATH) in my SlickEdit class path. When I do this, I'm able to compile classes that reference Log4J 2 in SlickEdit using project-compile command (invoked via a keyboard shortcut) just fine. However, all references to any class in the Log4J2 library are flagged by Live Errors.
* I extracted the Log4J2 source code to a temporary directory, I removed log4j-api-1.19.0.jar and log4j-core-2.19.0.jar from my CLASSPATH system environment variable, I removed the temporary directory from my CLASSPATH system environment variable, but I still included %(CLASSPATH) in my SlickEdit class path. I added the temporary directory to my SlickEdit project. When I do this, I'm able to compile classes that reference Log4J 2 in SlickEdit using project-compile command (invoked via a keyboard shortcut) just fine. However, all references to any class in the Log4J2 library are flagged by Live Errors.
* I extracted the Log4J2 source code to a temporary directory, I added log4j-api-1.19.0.jar and log4j-core-2.19.0.jar to my CLASSPATH system environment variable, I added the temporary directory to my CLASSPATH system environment variable, I included %(CLASSPATH) in my SlickEdit class path, and I added the temporary directory to my SlickEdit project. When I do this, I'm able to compile classes that reference Log4J 2 in SlickEdit using project-compile command (invoked via a keyboard shortcut) just fine. However, all references to any class in the Log4J2 library are flagged by Live Errors.
Any ideas? In particular, I would like to get some visibility into what Live Errors is doing so I can better understand what is happening. Perhaps there is some setting or feature of which I am not aware.
(edit) I extracted the source code for Log4J 2, and created a SlickEdit tag file from it. When I did that, SlickEdit was not able to automatically add imports for classes in the Log4J 2 library, and I was not able to navigate ( alt + . ) to the Log4J 2 source code.
patrick:
You're probably not missing anything. Barring bugs, Live Errors should use the exact same classpath that is used for compiling. There is one difference in that it's not passing the classpath on the command line to the compiler, so it doesn't have to use the jar mechanism used for regular compiling to avoid command line length limits for very long classpaths.
Since you compile fine, the only setting I can think of for you to check is the compiler being used by Live Errors, and make sure it's the same compiler being used when you compile. An old one like 1.7 wouldn't work for log4j2 > 2.12.4. And would probably give you other problems if it could get past that. Look under Build -> Java Options, go to the Live Errors tab, and check the "Path to JDK 6 or later" field and make sure it's the right compiler.
If that's not it, we'll probably have to get an idea of what options are actually making it to the compiler and see if something is not right there.
rygaard:
I checked Build -> Java Options -> Live Errors -> Path to JDK 6 or later and confirmed that it is configured correctly. I alse checked (in multiple ways) to ensure that the only Java I am using is JDK 17.
Is there some option in SlickEdit to give me more visibility into what Live Errors is doing? I suspect I could get a good idea of what is going wrong if I knew what Live Errors is doing.
patrick:
Live Errors keeps a JVM running (to avoid startup costs), and invokes methods on a class SlickEdit provides to kick off compilation when a syntax check needs to be done. It gets the classpath from the same source the build tool does, so barring bugs in our environment handling, it should be the same in both cases. It does take a separate path, so perhaps something in the Live Errors path is mangling something.
So we need to compare the classpath used for compilation with the classpath sent to the compiler for Live Errors. The first we can see with the "verbose" setting in the project properties for the Build tool, but the latter I don't see a way to enable with a setting.
I've made an updated RTECompiler.class which logs all of the options sent to the Live Errors compiler to a file, including the classpath option. I'm testing it now, and chasing down one strange thing I've seen with a -d option on one of my projects. Once I understand why that looks different than what I expected, I'll send you the debug class with instructions on how to use it.
patrick:
After tracing the weird paths on my windows system, I think I'm going to put in a fix for what I've found before I send you the debug class. Seems like an odd bug that probably could only happen on windows. I'll have to send you an updated DLL for the fix, as it's not hot-fixable. I'll update when the DLL is ready.
Navigation
[0] Message Index
[#] Next page
Go to full version