Missing constructor while parsing FileInputStream in JDK 1.7

[jecisc]

I am parsing the JDK 1.7 of Java and in the resulting model I have this list of methods in the class FileInputStream:

But in the file I'm attaching bellow from this JDK we can see this piece of code:

    /**
     * Creates a <code>FileInputStream</code> by
     * opening a connection to an actual file,
     * the file named by the path name <code>name</code>
     * in the file system.  A new <code>FileDescriptor</code>
     * object is created to represent this file
     * connection.
     * <p>
     * First, if there is a security
     * manager, its <code>checkRead</code> method
     * is called with the <code>name</code> argument
     * as its argument.
     * <p>
     * If the named file does not exist, is a directory rather than a regular
     * file, or for some other reason cannot be opened for reading then a
     * <code>FileNotFoundException</code> is thrown.
     *
     * @param      name   the system-dependent file name.
     * @exception  FileNotFoundException  if the file does not exist,
     *                   is a directory rather than a regular file,
     *                   or for some other reason cannot be opened for
     *                   reading.
     * @exception  SecurityException      if a security manager exists and its
     *               <code>checkRead</code> method denies read access
     *               to the file.
     * @see        java.lang.SecurityManager#checkRead(java.lang.String)
     */
    public FileInputStream(String name) throws FileNotFoundException {
        this(name != null ? new File(name) : null);
    }

We see that this constructor is not present in the list of methods generated.

Code of the class:

FileInputStream.java

PS: With romain we tried to parse only java.io package and in that case we have the constructor. But parsing the whole JDK does not work

[jecisc]

Note:

• Full JDK 1.7 => No constructor
• Java package => No constructor
• Java.io => The constructor is present

[jecisc]

Here is a zip of the problematic folder

java.zip

[jecisc]

New info:

The constructor seems to exists but it misses a parameter in the signature.
The constructor with the String as parameter is the "FileInputStream()" instead of "FileInputStream(String)"

[RomainDeg]

We did some testing with Guille to have a minimal artefact which can be used to replicate the bug.

The bug seems to be related to the java.lang implicit imports of Java (in the example of this issue, java.lang.String).
If you have a model that:

• includes java.lang classes (in our case, we import a version of the JDK with its own String class)
• has some implicit (that is, without importing it) usage of String

Then the symbol resolution freaks out and creates several stubs when they shouldn't.
For example, the invocation of the constructor gets bound to an inner class ?

This explains why the bug described here is not present when only parsing java.io (the implicitly imported classes are not in the final model as model classes) but is present when parsing the java package or the entire JDK.

We prepared a little java project to reproduce it:

src.zip