Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE

Resolving Missing Types or Methods in Java Modules

Resolving Missing Types or Methods in Java Modules


 I have added my Java source to my Java project and I get a number of the following errors:

            Error - The import <import> cannot be resolved (at line 4)

           Error - <type> cannot be resolved to a type (at line 6)




A common issue in setting up a Java workspace in Enterprise Analyser or Modernization Workbench is resolving references to missing types or methods.


That is, a given Java method or type will contain a reference to another Java method or type, but there is no definition of the referenced method or type visible in the workspace. 

These verification errors generally occur in two places: in import statements, or in the body of a type.

 Consider the following source code (with line numbers):

  1: package com.company.salesapp;


 3: import com.company.common.*;

 4: import junit.framework.TestCase;


 6: public class CustomerTest extends TestCase {

 7: }


This source file is referencing the junit unit test library.

However, suppose we did not include that jar file on our classpath.

Then, we would get two error messages here:

        Error - The import junit cannot be resolved (at line 4)

        Error - TestCase cannot be resolved to a type (at line 6)


Consider first the error on the import statement at line 4.

During verification, the parser will try to resolve the package or type listed in each import statement, so that the types listed there can be matched up against usages in the body of the code.

It does this by first checking for a package component named "junit" in one of the classpath elements, and then for looking for a package named "framework" under one of the "junit" components, and then finally for a type named "TestCase" under "framework".

If it cannot find a package component named "junit", then the error is reported as this:

Error - The import junit cannot be resolved


Unfortunately, due to the way the Eclipse parser operates, it does not report the full referenced name, but instead only up to the first component of the name that could not be located. 

So rather than getting a message that "junit.framework.TestCase" was not located, we only currently report that "junit" cannot be located.

When you get this message, it means that you need to add to the classpath a jar file which defines types whose full names start with "junit.".

To be more specific, right now you would need to check the referenced line of the error message to see the full text of the import statement (e.g. to get the full name "junit.framework.TestCase").

However, it is often the case with libraries that all types defined under a specific package prefix, such as "junit", will be located in one or a small number of jar files, so often just locating the prefix value is sufficient without needing to look up the full name from the source code.

Missing type references can also occur in the body of the source code.

Consider the error at line 6. The issue here is that there is a reference to a type named "TestCase".

The Java parser attempts to resolve this name according to the Java language specification, which means checking in the local package of the file, and also checking against any packages named in import statements in the file. However, in this case, it could not find any such type (because we did not include the junit library jar file on the classpath).

 The error text given for this error describes the information we know:

 Error - TestCase cannot be resolved to a type


The parser does not know that the type referenced is junit.framework.TestCase, because in theory it could have been resolved by the other import statement, or by the package declaration on the file. So, all that it can report is that there is a reference to a type named "TestCase", but that it could not find any definition of such a type.

When you get this message, it generally means that you need to add to the classpath a jar file that defines a type which ends in ".TestCase", since the type name is the last component of a fully-qualified Java name.

We have a utility program named JarLister, which is used to generate a text file containing the names of the Java types defined in a set of jar files.

JarLister takes two parameters: first, a directory containing jar files to be processed (the directory and all of its sub-directories will be scanned); and second, an output file name.

For example, if we run this program on a directory containing a typical junit jar file, we would see entries like this in the generated output file:






















Each line contains the path of a jar file, a comma, and the fully-qualified name of a Java type defined in that jar file. This output could be used to diagnose the import statement error, by seeing that multiple types beginning with "junit" are defined in the c:\src\jars\junit.jar file.

Note that the prefix may appear in multiple jar files; in this case, it may require checking against the source file to see what specific sub-packages are referenced in the import statement, to narrow down which specific jar file should be included.

It also could be used to diagnose the other missing type reference error, by seeing that a type ending in "TestCase" is also defined in the c:\src\jars\junit.jar file (as seen in the third line from the bottom of the listing).

Note that there could be multiple types named "TestCase" present in a set of jar files - if so, it may require checking against the source code containing the error to see which specific packages are referenced there, in order to determine which of the possibilities is the one being referenced from that source.




Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Version history
Revision #:
1 of 1
Last update:
‎2013-03-14 09:54
Updated by:
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.