Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.21 Safari/532.0 Build Identifier: R3.4.0 tested under dsdp-mtj-runtime-1.0.1RC4 Reproducible: Always Steps to Reproduce: 1. preprocessing marks the correect java classes error in some cases. 2. some statements seem allowed by preprocessing mode, but not supported by java editor 3. debugging could be enabled on the unstoppable locations
Created attachment 148380 [details] bug1
Created attachment 148381 [details] bug2
Created attachment 148382 [details] bug3
Created attachment 148383 [details] bug4
add some snapshots. basic conclusion is: pay attention to use the preprocessing feature.
thanks for your comments. the preprocessor support is one of the main features of mtj and i'm glad that you are trying it. since this is more a user experience improvement it is hard to have time to implement that. if you can provide some fixes we would review and apply the patch if they are able to solve the issues you raised :) gep (In reply to comment #5) > add some snapshots. > > basic conclusion is: pay attention to use the preprocessing feature.
We are using the Java Editor form JDT project. I can not see how we can improve the situation without further help from the JDT UI team. Passing on to JDT to get their input.
>Passing on to JDT to get their input. This is not a JDT bug. Moving back. We can try to answer if you have concrete questions.
(In reply to comment #2) > Created an attachment (id=148381) [details] [diff] > bug2 This looks like you want to edit a file in the Java editor that does not have valid Java syntax (or in some cases, syntax may be valid but you don't expect Java semantics because the comments have a private meaning). To support this non-Java language, you would have to hook into every aspect of the JDT toolchain (compiler, search, AST, refactoring, editor, ...) and add support for the non-Java features. JDT currently doesn't have a story for this. As a workaround, you might want to try this Simple Java PreProcessor: http://web.archive.org/web/20060427153325/http://www.vortoj.com/sjpp/readme.html But be aware that this makes JDT only see the non-commented parts of the code, so search, refactorings, etc. will not take the commented parts into account.
We use the antenna preprocessor http://antenna.sourceforge.net/wtkpreprocess.php. It runs as a builder when enabled. This request is mostly about enhancing the experiences with editing java files that use the preprocessor. Search and refactoring is things I can only dream at the moment I am well aware that JDT does not have a story for preprocessing. I could not really see many hooks we can use for this case as well. please do forward me to the right direction if I am missing those hooks completely. I have added JDT team to this discussion to get any ideas if there are any future possibilities. At this stage I can not see how we can improve the experience without having to create at least our own Java Editor.
Patching the JavaEditor alone is not going to help you much, since the JavaEditor heavily relies on the JDT/Core infrastructure to interpret the meaning of a .java file. Using internals, you could probably fix the syntax highlighting, but anything a bit more involved (e.g Open Declaration, content assist, semantic highlightings, search) quickly requires changes everywhere. To solve this problem without a huge investment, you could try something like the sjpp (comment 9). They basically went the other way and didn't try to adapt the tooling to the new language, but they translate the Java+PreProcessing files on-the-fly to real Java files (with special comments for the preProcessing directives and the disabled code parts). That way, the existing Java tooling works fine for the active parts of the code. If your files have an extension other than .java, then you could probably contribute a new org.eclipse.core.contenttype.contentTypes, give it a special encoding (default-charset), and implement the mapping in a new CharsetProvider (along the lines of sjpp). This is the lowest level where you could inject preprocessing, and it should work everywhere (since people should using encodings to interpret the bits stored in files). We could maybe add a similar hook to the org.eclipse.core.filebuffers plug-in, but that would only work as long as everybody uses file buffers and would cause inconsistencies with the IResource APIs.
