Re: Trouble with Java package imports
Edward John Steere <[email protected]> Tue, 04 Oct 2016 20:09:02 +0200
| Newsgroups | gmane.emacs.semantic |
|---|---|
| Message-ID | <[email protected]> |
> I've a few clues about the error with Java package includes. > > First, with a package include (i.e., "include java.util.*") the tag at point has a proxy (:proxy keyword)--whatever that is--that sends us down a branch starting with semanticdb-javap-resolve-proxy. Without a package include (i.e., "include java.util.Map") the proxy > is nil, there's no proxy-function, and we steam on ahead. See semantic-tag-resolve-proxy in tag.el: > > (defun semantic-tag-resolve-proxy (tag) > "Resolve the proxy in TAG. > The return value is whatever format the proxy was setup as. > It should be a list of complete tags. > If TAG has no proxy, then just return tag." > (let* ((proxy (semantic--tag-get-property tag :proxy)) > (function (get proxy 'proxy-function)) > (data (get proxy 'proxy-data))) > (if proxy > (funcall function data tag) > tag))) > > In that branch, we eventually end up in semanticdb-normalize-tags in db-javap.el where a let* binds realtable to the value of (semanticdb-jar-extract-and-save-tags obj tfn), which is determined to set it to nil. The problem is that the next let* expression binds > foundtags to (semanticdb-find-tags-by-name-method realtable (semantic-tag-name T)), and realtable has just been set to nil. See semanticdb-normalize-tags in db-javap.el: > > (defmethod semanticdb-normalize-tags ((obj semanticdb-table-jar-directory) tags) > "Convert tags found by our java directory table into a complete tag. > The default tag just has a name, type, and the filename. Normalize by > loading in the file it belongs to, and looking up that symbol in the file > and returning that tag instead." > (let ((tagret nil) > (parentdb (oref obj parent-db))) > (dolist (T tags) > (let* ((tfn (semantic-tag-file-name T)) > (realtable (semanticdb-jar-extract-and-save-tags obj tfn)) > (foundtags (semanticdb-find-tags-by-name-method > realtable (semantic-tag-name T)))) > (dolist (FT foundtags) > (semantic--tag-put-property FT :filename tfn) > (setq tagret (cons FT tagret))))) > tagret)) > > Some questions leap to mind. > > 1 What is a tag proxy and is it correct for the tag to have one with a package import (i.e., "import java.util.*") and not have one otherwise? > 2 Is it correct for semanticdb-jar-extract-and-save-tags to return nil in this case? > 3 Should semanticdb-find-tags-by-name-method be able to cope with a nil argument to the realtable parameter, without throwing an error? > 4 If it were able to cope such that execution would continue, would the analyzer do the right thing for a package import, or would it break somewhere else down the line? > > I'll try to answer these questions in the coming days. Stay tuned! > > Cheers, > David > > On Sun, Sep 18, 2016 at 11:57 AM, David Ventimiglia <[email protected]> wrote: > > Hi! > > I'm having trouble with the Semantic Analyzer and "package imports" for Java programs. I've an example Java program that looks like this: > > import java.util.*; > import java.util.HashMap; > public class HelloWorld2 { > public static void main (String[] args) { > System.out.println("Hello, World!"); > Map m = new HashMap(); > m. > } > } > > When I put point after the "m." and try semantic-ia-complete-symbol-menu (for example) it fails with this message: > > Cannot find types for `"m"' > > If I try semantic-analyze-current-context, the output indicates that it encountered this error (full message below): > > Method semanticdb-find-tags-by-name-method called on nil > > These problems don't occur if I replace the "import java.util.*;" in the Java file with "import java.utl.Map" and so I'd never encounter them if I didn't used wildcards in the import statements. > > Any idea what's going on here? > > I have a Docker image that reproduces this behavior, if anyone's game for trying it out. It uses Ubuntu, Emacs 24.5.1, the latest CEDET (as of 2016/09/18), and OpenJDK 8. If you have Docker installed, you should be ale to get the image with this > command: > > docker pull dventimi/docker-emacs > > You can then launch a container that opens Emacs on a version of the Java file with package imports, with this command: > > docker run -t -i dventimi/docker-emacs emacs /root/Scratch/HelloWorld2.java > > Likewise, you can launch a container that opens Emacs on a version of the Java file without package imports, with this command: > > docker run -t -i dventimi/docker-emacs emacs /root/Scratch/HelloWorld.java > > The Semantic Analyzer works in the second case, but not in the first case. I've been groping my way through this with the debugger, and will continue to do so, but I thought I'd throw this out there to see if anyone else has a clue as to what the problem > might be. Thanks! > > Best, > David > > ====== Output of semantic-analyze-current-context ======= > > Context Type: #<semantic-analyze-context context> > Bounds: (186 . 186) > Prefix: "m" > "" > Prefix Classes: 'function > 'variable > 'type > Prefix Types: <none> > Encountered Errors: '(error "Method semanticdb-find-tags-by-name-method called on nil") > -------- > -> ScopeTypes: class HelloWorld2 > -> Parents: class HelloWorld2 > -> Scope: void main(String[]) > -> Local Args: String[] args > -> Local Vars: String[] args > this > Map m > > > ------------------------------------------------------------------------------ > > _______________________________________________ > cedet-semantic mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/cedet-semantic Hi David, Without debugging this myself I really can't say. Before you start debugging though I would recommend that you try to replicate it with the smallest possible example of the problem. i.e. jar up a package with a few classes you wrote and see whether it finds definitions from a star import of the package in that jar. I think that you might be running into other issues which could be clouding the actual problem. There are, for example, some features of modern Java which the current grammar doesn't support (e.g. annotations.) I've done some work on getting the parser to recognise annotations (I don't think that it's ready yet.) In my experience problems with the grammar can sometimes cause entire files to not be parsed correctly and although I'm not sure what impact that would have on db-javap it does seem like something worth eliminating first. If I get some time over the weekend then I'll see what I can find. Kind regards, Edward Steere ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot