Re: Trouble with Java completion

Hi David,

1-4, all roughly the same as me.
5. I don't know whether it's necessary, but it doesn't seem to work on
   my machine w/o a project.
7. Did ede pick up the project after you defined it?  You can run
   `ede-customize-project' to verify.

I think that there might be a bug in the db because it isn't finding any
tags for the include.  I get the following output for that import:

    Include Tag: java.util.Map

    This header tag has been marked "Fileless".
    This means that Semantic cannot find a file associated with this tag
    on disk, but a database table of tags has been associated with it.

    This means that the include will still be used to find tags for
    searches, but you cannot visit this include.

    This Header is now represented by the following database table:

      #<semanticdb-table-jar-file java/util/Map.class (1 tags)>

I found a function to detect your java environment:
`cedet-java-describe'.  You could use that to determine whether your
java is being picked up correctly.  I get the following (on a Mac):

    CEDET Java Operational Environment:

    Current Java Version: 1.8.0_11

    Minimum Desired version: 1.4
    Java Command: java
    Jar Command: jar
    Javap Command: javap

    User Specified Global Classpath Extension:

    Project Specified Classpath Extension (EDE):

    Java JDK Core Jar File:
      /Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home/jre/lib/rt.jar


I used the profiler to find the most likely functions involved in
finding tags.  This *might* not be a real call stack, but I find that it
sometimes helps me to orient myself in a project.  If you're going to
debug the issue then I'd say that theses functions are probably a good
place to start:

    - semanticdb-javap-classpath-objects
     - semanticdb-find-table-for-include-java-mode
      - semanticdb-find-table-for-include
       - semanticdb-find-translate-path-includes--internal
        - semanticdb-find-translate-path-includes-default
         - semanticdb-find-translate-path-java-mode
          - semanticdb-find-translate-path
           - semanticdb-table
            - apply
             - eieio-generic-call-primary-only
              - semanticdb-typecache-include-tags
               - #<compiled 0x411b26ed>
                - apply
                 - semanticdb-typecache-find-method
                  - semanticdb-typecache-find-default
                   - semanticdb-typecache-find-java-mode

If I could replicate your problem then I would be much better equipped
to help.  As it stands this is the best I can do to point you in a
direction (I'm sure I'll be corrected if anything I've said is off point
:-) ).

Kind regards,

Edward Steere

> Hi Edward,
>
> Thanks so much for replying. Here's what I can tell you.
>
> 1 I'm using CEDET from the Git repository
>   http://git.code.sf.net/p/cedet/git and it's up-to-date.
> 2 It's the very first thing I load in my init file, so as to avoid
>   using the built-in CEDET.
> 3 CEDET version is 2.0. Full (cedet-version) output is below.
> 4 I've always had global-semantic-decoration-mode enabled and all my
>   imports have always been green "Fileless." Full output is below.
> 5 I didn't originally have an EDE project-root (is that necessary). I
>   only had the HelloWorld.java file in /home/dventimi/Scratch
> 6 I have however always had (require 'semantic/db-javap) at the top of
>   my init file.
> 7 I added a project-root with this line in my init file:
>   (ede-java-root-project "Scratch" :file
>   "/home/dventimi/Scratch/HelloWorld.java"). I know the project root
>   doesn't typically "hang off" the file I'm trying to compile, but
>   there's no choice since I have no other files in the Scratch
>   directory.
> 8 Even with this addition, I get precisely the same behavior. The key
>   is that it seems to identify the import statements as "Fileless." In
>   my experience (I've had completion working in the past, though long
>   ago under different circumstances on a different computer) "green is
>   good" and that's the ideal state for importing tags from JAR files
>   via javap. And yet, the tags table it builds this time has 0 tags. 
>
> I'm happy to start drilling in with the debugger, but at present I
> don't even know where to begin. Anyway, thanks!
>
> Best,
> David
>
> (cedet-version)
> ->
> CEDET Version: 2.0
> Requested File Loaded
> Package Version Version Version
> ----------------------------------------------------------
> cedet: 2.0 ok ok
> eieio: 1.4 nil ok
> semantic: 2.2 ok ok
> srecode: 1.2 ok ok
> ede: 1.2 2.0 2.0
> cogre: 1.2 ok ok
> cedet-contrib: 1.2 nil Not Loaded
>
> "What's this?"
> ->
> Include Tag: java.util.Map
>
> This header tag has been marked "Fileless".
> This means that Semantic cannot find a file associated with this tag
> on disk, but a database table of tags has been associated with it.
>
> This means that the include will still be used to find tags for
> searches, but you cannot visit this include.
>
> This Header is now represented by the following database table:
>
> #<semanticdb-table-jar-file java/util/Map.class (0 tags)>
>
> On Mon, Aug 29, 2016 at 1:26 PM, Edward John Steere
> <[email protected]> wrote:
>
>     Hi David,
>     
>     You're right, db-javap does deal with this :) I could only
>     replicate
>     your problem with db-javap turned off (i.e. not `require'd). Once
>     I
>     `require'd it it complained that generic projects don't have a
>     :classpath slot (which is of course true.) Once I created a
>     `java-root'
>     project, and dumped your code in it, it worked fine and gave me
>     the
>     following options:
>     
>     clear compute
>     computeIfAbsent computeIfPresent
>     containsKey containsValue entrySet
>     equals forEach get
>     getOrDefault hashCode isEmpty
>     keySet merge put
>     putAll putIfAbsent remove
>     replace replaceAll size
>     values
>     
>     Are you using upstream or built in CEDET?
>     
>     You can also turn on `global-semantic-decoration-mode' and your
>     imports
>     will be decorated to indicate whether they have been:
>     
>     - Parsed (no highlighting)
>     - Still need to be parsed (highlighted yellow on my machine)
>     - None-file imports -- such as an import from a jar file
>     (highlighted
>     green on my machine)
>     - Unrecognised imports (highlighted red on my machine)
>     - (Your function tags will also be decorated in the buffer)
>     
>     This ought to give you a good idea of whether cedet has figured
>     out your
>     project setup.
>     
>     To answer 1. and 2. I'm not familiar with the global versus local
>     type
>     cache, but with any luck you wont have to be either :)
>     
>     Kind regards,
>     
>     Edward Steere
>     
>     > Hi!
>     >
>     > I'm having trouble with the Semantic Analyzer and Analyzer
>     Debugging
>     > for Java programs. I've a simple "Hello, World!" Java file that
>     looks
>     > like this:
>     >
>     > import java.util.Map;
>     >
>     > import java.util.HashMap;
>     >
>     >
>     >
>     >
>     > public class HelloWorld {
>     >
>     > public static void main (String[] args) {
>     >
>     > Map m = new HashMap();
>     >
>     > m.
>     >
>     > }
>     >
>     > }
>     >
>     > When I try M-x semantic-ia-complete-symbol after the "m.", I get
>     the
>     > message "Cannot find types for `Map m'," I get the output in the
>     > attached debug.txt file. I'm trying to interpret this output,
>     and a
>     > couple questions come to mind.
>     >
>     > 1 Should I expect the type to be a local type or a global type?
>     > 2 What's the difference between a local type and a global type?
>     > 3 Shouldn't semantic/db-javap just handle this?
>     >
>     > The typecache (also attached) seems to have all the java.lang
>     types,
>     > which semantic/db-javap presumably fished out of my Java
>     > installation's rt.jar file. If that's the case, shouldn't it
>     also have
>     > fished out java.util.Map?
>     >
>     > Thanks!
>     > Best,
>     > David
>     >
>     >
>     >
>     >
>     > -
>     -----------------------------------------------------------------------------
>    
>     > _______________________________________________
>     > cedet-semantic mailing list
>     > [email protected]
>     > https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>     

------------------------------------------------------------------------------