Eclipse: The type ... cannot be resolved. It is indirectly referenced from required .class files

[elusivellama]

Environment

• LWJGL version: 3.1.5
• LWJGL build #: 1
• Java version: 9.0.1
• Java build: 9.0.1+11
• Platform: Windows 7 x64
• Module: glfw & vulkan
• Eclipse version: Oxygen.2 Release (4.7.2)
• Eclipse build id: 20171218-0600

Description

I'm not sure if this is a bug in Eclipse or with some of the machine-generated code in LWJGL3. On their own, either of org.lwjgl.glfw.GLFWVulkan and org.lwjgl.vulkan.VkInstance can be imported and used without issue. However, when I import both of these types into the same source file, Eclipse issues the error The type org.lwjgl.vulkan.VkInstance cannot be resolved. It is indirectly referenced from required .class files. Sometime I can also trigger the (additional) error The import org.lwjgl.vulkan.VkInstance cannot be resolved, but it's not clear to me what precise source code conditions are required for the second one. Strangely, the source file still compiles and runs just fine - only the Eclipse autocomplete functionality is broken by these errors. Also, even when the errors are present Eclipse is happy to link me into the respective source files using the 'Open Declaration' command.

I have already tried:

• restarting Eclipse
• cleaning the project
• deleting Eclipse index data to force its regeneration

Of note, my copy of LWJGL3 was extracted from the zip archive and the modules core, glfw, and vulkan were manually configured as an Eclipse 'User Library' for the workspace. Both sources & javadocs are correctly attached, the jars for natives are included, the User Library is added to the project's build path as a library on the classpath, and everything builds and runs without issue (excluding this mysterious error).

I would be grateful if anyone here could attempt to reproduce this for me.

[TheMrMilchmann]

This is a bug in the module declaration of the GLFW binding. More precisely: GLFWVulkan uses parts of the Vulkan binding without this being specified in the module-info.java file of the GLFW binding.

The latter looks like this:

/*
 * Copyright LWJGL. All rights reserved.
 * License terms: https://www.lwjgl.org/license
 */
module org.lwjgl.glfw {
    requires transitive org.lwjgl;

    exports org.lwjgl.glfw;
}

I'm however not sure how this could be solved without making the GLFW binding depend on the Vulkan binding or splitting GLFWVulkan into a separate artifact.

[elusivellama]

Regarding the dependency, I'm brand new to LWJGL and these APIs in general so hopefully this isn't a silly idea. But from the docs for public static long glfwCreateWindow(..., we see that it Creates a window and its associated OpenGL or OpenGL ES context. and yet glfw somehow isn't dependent on opengl? It seems to me this is because all OpenGL related things are internal to native GLFW and only exposed as pointers (if at all)? So could this approach be used for GLFWVulkan, replacing occurrences of the Java object org.lwjgl.vulkan.VkInstance with the long typed native handle that it wraps?

Edit: Upon investigation, VkInstance extends DispatchableHandleInstance extends Pointer.Default which is part of org.lwjgl.system so shouldn't GLFWVulkan simply use Pointer.Default instead of VkInstance (and similar for the other vulkan dependent types)?

Regarding the Eclipse error, does module-info.java affect libraries configured on the classpath (not modulepath)? My Eclipse 'User Library' also has each listed jar file identified as Is not modular - non modifiable. Not sure if this is relevant though.

[elusivellama]

Somewhat unrelated, but I'm noticing that there's also a number of @NativeType annotations missing throughout the GLFWVulkan source, is this sort of thing considered a bug?

[TheMrMilchmann]

Hey @cwb123,

Regarding the dependency, I'm brand new to LWJGL and these APIs in general so hopefully this isn't a silly idea. But from the docs for public static long glfwCreateWindow(..., we see that it Creates a window and its associated OpenGL or OpenGL ES context. and yet glfw somehow isn't dependent on opengl?

It seems to me this is because all OpenGL related things are internal to native GLFW and only exposed as pointers (if at all)?

Your assumption is correct. OpenGL types are not exposed by GLFW and since LWJGL's bindings are basically bridges to native APIs, the binding does not require types of OpenGL (or the respective binding) either.

Edit: Upon investigation, VkInstance extends DispatchableHandleInstance extends Pointer.Default which is part of org.lwjgl.system so shouldn't GLFWVulkan simply use Pointer.Default instead of VkInstance (and similar for the other vulkan dependent types)?

While this is possible (and already available in the "unsafe" version of GLFWVulkan::glfwGetInstanceProcAddress) I would argue that this would defy LWJGL's purpose of being as type-safe as possible without hurting performance. However, unless we want to split GLFWVulkan into a separate artifact, I suppose an exception would be necessary.

Regarding the Eclipse error, does module-info.java affect libraries configured on the classpath (not modulepath)? My Eclipse 'User Library' also has each listed jar file identified as Is not modular - non modifiable.

I'm not sure about how Eclipse handles dependencies internally but a module declaration should generally be ignored on the classpath. There is nothing else that could prevent the GLFW binding to access code from the Vulkan binding though.

Somewhat unrelated, but I'm noticing that there's also a number of @NativeType annotations missing throughout the GLFWVulkan source, is this sort of thing considered a bug?

This is something I didn't dig into too much yet. I'll refer this one to @Spasi.

Additional notes:
This bug has technically (although in another way) been present in LWJGL since the project has been modularized or the GLFWVulkan functionality has been added (whatever came last). The org.lwjgl:lwjgl-glfw artifact does not depend on the org.lwjgl:lwjgl-vulkan artifact, yet the fromer uses and exposes types from the latter.

[Spasi]

I'm working on fixing this asap. It's trivially resolved by adding:

requires static org.lwjgl.vulkan;

to the GLFW module.

Somewhat unrelated, but I'm noticing that there's also a number of @NativeType annotations missing throughout the GLFWVulkan source, is this sort of thing considered a bug?

@NativeType is in lwjgl.jar. I think you mean the @Nullable annotations from jsr305 (see #344). Annotation classes are not resolved unless you introspect them, so it's not a real dependency. Users have the option to add it to their project if they wish, we didn't want to enforce it to everyone.

[elusivellama]

requires static looks awesome, I had no idea that feature existed until just now.

@TheMrMilchmann I'll go ahead and put in an Eclipse bug report then.

@Spasi Regarding @NativeType, I didn't mean anything about it being a dependency. Its presence just seems to be inconsistent, for example the first argument of the functions at lines 156 and 193; not sure if this happens anywhere else in the code. Sorry for going off topic, I can open a separate issue if you'd like.

L156
@NativeType("GLFWvkproc *") public static long glfwGetInstanceProcAddress(@Nullable VkInstance instance, @NativeType("const char *") ByteBuffer procname) { ...

L193
@NativeType("GLFWvkproc *") public static long glfwGetInstanceProcAddress(@Nullable @NativeType("VkInstance") VkInstance instance, @NativeType("const char *") CharSequence procname) { ...

[Spasi]

The next snapshot (3.1.6 build 13) will have the missing requires static declarations and the unnecessary annotations have been removed (there should be no annotation when the native type matches the Java type exactly).

Thanks @cwb123!

[JaiveerN1692]

The type org.springframework.data.repository.query.QueryByExampleExecutor cannot be resolved. It is indirectly referenced from required .class files.
how to fix it this error in project extends JPARepository i have face this error
'