Thread: [cedet-semantic] More difficult Java import problems...may be impossible to solve...
Brought to you by:
zappo
From: David V. <dve...@gm...> - 2011-10-24 02:53:21
|
Hi! I noticed a couple of other problems with the Java support in CEDET. First, there are some packages that are automatically available in Java (actually, there may only be one...I don't remember): java.lang. So Java programs typically won't import anything from here. However, Semantic seems to need for there to be in import statement (or include) for every type it encounters and if there isn't, it doesn't know what the type is. For this reason, certain common types, like String, won't have any Semantic support in Java, unless you explicitly import them, as in import java.lang.String. Except, that's something no Java programmer would ever do. Also, it sometimes happens that Java programs will import every public type in a package, using the * globbing character. As in, import java.util.*; In this case Semantic has no idea what types are in the package, so again, it has no idea what the types when it encounters them in the program. Both problems might be solved by changes to semanticdb-javap.el. For instance, perhaps that code--which knows how to poke through Java JAR files--parsed and cached all of the public types in the java.lang package. Then, whenever it encounters a type (like String) which has not been imported, it could assume that it's one of the java.lang types (though it should check). Further, perhaps semanticdb-javap.el also could do the same thing--parse and cache all the types in--any package ending in .*; Then again, if it encounters a type that hasn't been imported, it first could see if it's in that cache, and the subsequently see if it's in the java.lang cache. Thoughts? Cheers, David |
From: Eric M. L. <eri...@gm...> - 2011-11-16 00:34:51
|
On 10/23/2011 10:53 PM, David Ventimiglia wrote: > Hi! > > I noticed a couple of other problems with the Java support in CEDET. > First, there are some packages that are automatically available in > Java (actually, there may only be one...I don't remember): java.lang. > So Java programs typically won't import anything from here. However, > Semantic seems to need for there to be in import statement (or > include) for every type it encounters and if there isn't, it doesn't > know what the type is. For this reason, certain common types, like > String, won't have any Semantic support in Java, unless you explicitly > import them, as in import java.lang.String. Except, that's something > no Java programmer would ever do. > > Also, it sometimes happens that Java programs will import every public > type in a package, using the * globbing character. As in, import > java.util.*; In this case Semantic has no idea what types are in the > package, so again, it has no idea what the types when it encounters > them in the program. > > Both problems might be solved by changes to semanticdb-javap.el. For > instance, perhaps that code--which knows how to poke through Java JAR > files--parsed and cached all of the public types in the java.lang > package. Then, whenever it encounters a type (like String) which has > not been imported, it could assume that it's one of the java.lang > types (though it should check). Further, perhaps semanticdb-javap.el > also could do the same thing--parse and cache all the types in--any > package ending in .*; Then again, if it encounters a type that hasn't > been imported, it first could see if it's in that cache, and the > subsequently see if it's in the java.lang cache. Hi, I've been going backward through my mail, and partially answered some of this. When I tried to do what you suggest, I got stuck, because for android, I need to ask javap to not look in system libraries. For system libraries, you need different command line args. One of the questions CEDET asks is, "is there such an import?". I have no idea how to ask the system what the list of .class files there are in the default classpath libraries to know that. The idea of just asking for some random data type of the unspecified core library did occur to me, but I don't remember why I gave up on that. I think it was related to know knowing what types there were. There might be some happy medium that didn't occur to me here though. Anyone who is more familiar with javap or related java tools who know how to derive that missing info could enable the features you're looking for. Eric |