I've been contemplating your information for a while. The
CEDET/Semantic framework is supposed to be as language independent as
it can, but clearly there is no match here.
I suspect that perhaps in Java a classic "semanticdb" search is not
relevant. Instead, of wasting time there then, perhaps the
"typecache" part of semantic should be used instead. For C, all the
header files are scanned, and the namespaces and classes available in
them are merged into one massive hierarchical lookup table.
I suspect that for Java, we'd want to turn the list of importable
items into a typecache for the entire project. The imports then act
as using statements for determining which classes can be used.
This goes off into getting CEDET/Semantic smart completion working
in Java more completely. I'm not sure that was one of your goals.
Of course, I don't think that solves the original problem, which is
how imports are marked yellow and red. In this case the solution is
more simple. We can override the function
`semantic-decoration-on-includes-highlight' for java mode. It would
then make decisions based on Java for how to color the imports, and
what kinds of options are in the menu. If it makes sense to jump to
an associated .java file, or list tags in a class file, then it can do
that. If there are commonalities we should exploit them and add a
different layer for overrides for Java.
I've lost track of the original question/answer about an EDE project
wrapping prj.el. That part may still be important for whatever goes
into the above.
>>> Bo Lin <lbsmtp@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>> I think you misunderstand what this function needs to do. For C, if
>> it sees:
>> #include "moose.h"
>> then the function returns the lisp string:
>> which then refers to EDE's include path to see where moose.h might be.
>> Thus, I would assume that the Java statement:
>> import org.slf4j.Logger;
>> would need to return the lisp string
>> It doesn't need to find it, only report out a string that represents
>> fragments of a filename. The file is then found in various paths
>> later in the system. For example, the EDE project might specify one
>> path at "/home/myself/myproj/src" under which the Logger.java file
>> exists, and then it could be found.
>I think it's a bit more complicated than that (or actually simpler, if
>you do it the Java way instead of "molding" the C way to work for Java
>;-). Java imports are more like C++ "using" statements rather than
>#includes. So the statement
>does not necessarily mean there's a "org/slf4j/Logger.java" file to be
>found somewhere, but rather just tells the parser that any "Logger"
>class appearing in this source file is the "Logger" class in package
>(namespace in C++) "org.slf4j". The programmer could omit the import
>statement and just typed "org.slf4j.Logger" instead of "Logger"
>everywhere in the source file and achieve the same effect.
>Now in order to find "org.slf4j.Logger", one could try the following, in
>1. The source file "org/slf4j/Logger.java" in the list of "project
>source directories". These are the directories that contain the source
>files to be compiled for this project.
>2. The source file "org/slf4j/Logger.java" in a list of "library source
>directories". These are the directories that contain reference source
>code for various libraries and not compiled when building project.
>3. The Java byte code class file "org/slf4j/Logger.class" in the "class
>path". This is analogous to semantic-dependency-include-path +
>semantic-c-dependency-system-include-path. Of course we'll need a elisp
>Java byte code parser to understand these files. I don't think it'll be
>very difficult to implement, if it hasn't been done already -- we don't
>need to do a full parse, just enough to extract the tag data for the
>class. But this is important if semanticdb is to be of any use to Java
>modes, as the majority of tag information for the Java environment is
>contained in these byte code class files.
>Major differences compared to C #include:
>1. #includes are recursive, in that files included from includes are
>also included. imports are not.
>2. When doing steps 2 and 3, the search list could contain zip files
>(usually with '.jar' suffix) in addition to directories. These should be
>treated like ordinary directories (as though they were expanded).
>Also, there's the package import statement, like
>which means "pull in every class in the `org.slf4j' namespace". This
>might complicate dependency searching somewhat.
>> [ ... ]
>>> There has to be code to implement semantic-tag-include-filename for java-mode and call jde-find-class-source-file there. But I don't know what package should do it:
>>>- Maybe JDEE can always do it; it depends on CEDET anyway
>>>- CEDET should probably not do it by default, since CEDET does not depend on JDEE and this is very Java-specific. (Mmm... although more Java functionality from JDEE could also be integrated into CEDET instead of replicated).
>>>- or CEDET could use these JDEE functions just inside that new wrapper you spoke about; something like ede-jde-proj.el. I think this is the best.
>I haven't used JDE for a long time. As you mentioned, there are a lot of
>duplicated efforts between JDE and Cedet, and this is not good. For
>example, JDE does not use semanticdb, but instead fires up a Java
>process (beanshell) to retrieve dependency tag data for completions.
>This is *slow* (not just at startup, which takes a century btw, but also
>because of the inter-process communications), and also can't find tags
>from uncompiled source files. This could be a legacy from times when
>semantic was less capable of doing the job, but IMHO now everything the
>beanshell does can be (with some effort) done in semantic better,
>cleaner, and faster.
>The ideal thing to happen for JDE and Cedet integration, and IMHO the
>best path for the long term, is to take the plunge and clean up the mess
>once and for all. It'll take quite some effort, but less duplicated work
>in the future. The things that needs to be done for this to happen, that
>I can think of right now, includes:
>- Merge from JDE to semantic, everything related to the "backend", e.g.
> parsing, tag finding, etc. This will require in Cedet:
> 1. semantic-java-bytecode parser, as mentioned above.
> 2. Java-specific tag searching strategy, handling of zip (jar) files.
> 3. Merge the JDE project stuff into EDE
>- The JDE mode itself should contain just the goodie "frontend" stuff,
> e.g. completion, highlighting, automatic code generation, etc..
>If these were to happen then there might truly come the day that Emacs
>becomes a formidable Java IDE, one not, Eclipsed, by some other IDE...
>I would like to hear your thoughts on this, whether this is a desirable
>goal or not, and whether some of this has already been done (I haven't
>followed JDE development for some time. AFAIK no new version has been
>released since I last used it). I can volunteer to do some of the work,
>if this is considered a good path.
> - Bo