[jbosstools-issues] [JBoss JIRA] (JBIDE-19720) NPE in org.jboss.tools.common.model.util.EclipseResourceUtil.getJREClassPath

Sat May 16 02:20:19 EDT 2015

    [ https://issues.jboss.org/browse/JBIDE-19720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13068615#comment-13068615 ] 

Viacheslav Kabanovich edited comment on JBIDE-19720 at 5/16/15 2:19 AM:
------------------------------------------------------------------------

Yes, you are right, in the case of JRE only external libraries are allowed (even if they physically may reside inside the workspace, paths to them should be absolute), so that the check should be just removed from the code.

Still, the confusion remains for referenced libraries that can be selected both from the workspace and from the disk. 

After consideration I add this: 
Suppose, you create in your 'System' project in Eclipse resource /System/Library/Java/Extensions/MRJToolkit.jar. Make that MRJToolkit.jar not a valid copy, but just a fake. Suppose, EclipseResourceUtil is fixed and finds the external jar without exceptions. But what will Eclipse itself resolve for JRE? I have my doubts. Docs to JavaCore.getResolvedClasspathEntry(IClasspathEntry) describe the algorithm, in which the priority is given to 'a project, JAR or binary folder in the workspace at the resolved path location', and only if this fails, 'an external JAR file or folder outside the workspace at the resolved path location' is tried. Docs say nothing about treating JRE entries in any different way than other entries. So, even though Eclipse prompts user to select for JRE libraries external paths, when resolving them it may get stuck with a fake workspace resource whose workspace path by accident is the same as the external path of a real JRE library.

After 'a field experiment':
Eclipse indeed resolved JRE to the fake resource inside its workspace, though I added to JRE in Preferences an external path to the valid library. Oh, boy! Eclipse users should beware to give same favourite names to both Linux aliases and Eclipse projects.

was (Author: scabanovich):
Yes, you are right, in the case of JRE only external libraries are allowed (even if they physically may reside inside the workspace, paths to them should be absolute), so that the check should be just removed from the code.

Still, the confusion remains for referenced libraries that can be selected both from the workspace and from the disk. 

After consideration I add this: 
Suppose, you create in your 'System' project in Eclipse resource /System/Library/Java/Extensions/MRJToolkit.jar. Make that MRJToolkit.jar not a valid copy, but just a fake. Suppose, EclipseResourceUtil is fixed and finds the external jar without exceptions. But what will Eclipse itself resolve for JRE? I have my doubts. Docs to JavaCore.getResolvedClasspathEntry(IClasspathEntry) describe the algorithm, in which the priority is given to 'a project, JAR or binary folder in the workspace at the resolved path location', and only if this fails, 'an external JAR file or folder outside the workspace at the resolved path location' is tried. Docs say nothing about treating JRE entries in any different way than other entries. So, even though Eclipse prompts user to select for JRE libraries external paths, when resolving them it may get stuck with a fake workspace resource whose workspace path by accident is the same as the external path of a real JRE library.

> NPE in org.jboss.tools.common.model.util.EclipseResourceUtil.getJREClassPath
> ----------------------------------------------------------------------------
>
>                 Key: JBIDE-19720
>                 URL: https://issues.jboss.org/browse/JBIDE-19720
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: common/jst/core
>    Affects Versions: 4.2.3.Final
>         Environment: Mac OS X 10.10.3, java full version "1.8.0_25-b17"
>            Reporter: Valentin Baciu
>            Assignee: Viacheslav Kabanovich
>            Priority: Minor
>             Fix For: 4.3.0.Beta1
>
>
> java.lang.NullPointerException
> 	at org.jboss.tools.common.model.util.EclipseResourceUtil.getJREClassPath(EclipseResourceUtil.java:711)
> 	at org.jboss.tools.common.model.filesystems.impl.Libs.getNewPaths(Libs.java:141)
> 	at org.jboss.tools.common.model.filesystems.impl.Libs.update(Libs.java:108)
> 	at org.jboss.tools.common.model.util.EclipseResourceUtil.updateLibs(EclipseResourceUtil.java:535)
> 	at org.jboss.tools.common.model.util.EclipseResourceUtil.createObjectForResource(EclipseResourceUtil.java:417)
> 	at org.jboss.tools.jst.web.model.helpers.InnerModelHelper.createXModel(InnerModelHelper.java:40)
> 	at org.jboss.tools.jst.web.kb.internal.scanner.ClassPathMonitor.init(ClassPathMonitor.java:60)
> 	at org.jboss.tools.jst.web.kb.internal.KbProject.setProject(KbProject.java:202)
> 	at org.eclipse.core.internal.resources.NatureManager.createNature(NatureManager.java:234)
> 	at org.eclipse.core.internal.resources.Project.getNature(Project.java:448)
> 	at org.jboss.tools.jst.web.kb.KbProjectFactory.getKbProject(KbProjectFactory.java:71)
> 	at org.jboss.tools.jst.web.kb.KbProjectFactory.getKbProject(KbProjectFactory.java:38)
> 	at org.jboss.tools.jst.web.kb.internal.scanner.ClassPathMonitor.getKbProjects(ClassPathMonitor.java:193)
> 	at org.jboss.tools.jst.web.kb.internal.scanner.ClassPathMonitor.validateProjectDependencies(ClassPathMonitor.java:143)
> 	at org.jboss.tools.jst.web.kb.internal.KbProject.load(KbProject.java:347)
> 	at org.jboss.tools.jst.web.kb.internal.KbProject.resolveStorage(KbProject.java:315)
> 	at org.jboss.tools.jst.web.kb.internal.KbProject.resolve(KbProject.java:330)
> 	at org.jboss.tools.jst.web.kb.internal.KbProject.addKbProject(KbProject.java:216)
> 	at org.jboss.tools.jst.web.kb.internal.scanner.ClassPathMonitor.validateProjectDependencies(ClassPathMonitor.java:154)
> 	at org.jboss.tools.jst.web.kb.internal.KbProject.load(KbProject.java:347)
> 	at org.jboss.tools.jst.web.kb.internal.KbProject.resolveStorage(KbProject.java:315)
> 	at org.jboss.tools.jst.web.kb.internal.KbBuilder.build(KbBuilder.java:100)
> 	at org.jboss.tools.jst.web.kb.KbProjectFactory$1KbBuilderEx.build(KbProjectFactory.java:107)
> 	at org.jboss.tools.jst.web.kb.KbProjectFactory$1.run(KbProjectFactory.java:122)
> 	at org.jboss.tools.common.model.XJob.runInWorkspace(XJob.java:192)
> 	at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
> 	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> Another code path:
> java.lang.NullPointerException
> 	at org.jboss.tools.common.model.util.EclipseResourceUtil.getJREClassPath(EclipseResourceUtil.java:711)
> 	at org.jboss.tools.common.model.filesystems.impl.Libs.getNewPaths(Libs.java:141)
> 	at org.jboss.tools.common.model.filesystems.impl.Libs.update(Libs.java:108)
> 	at org.jboss.tools.common.model.project.ext.AbstractClassPathMonitor.update(AbstractClassPathMonitor.java:73)
> 	at org.jboss.tools.jsf.jsf2.bean.build.JSF2ProjectBuilder.build(JSF2ProjectBuilder.java:116)
> 	at org.jboss.tools.jsf.jsf2.bean.build.JSF2ProjectBuilder.<init>(JSF2ProjectBuilder.java:71)
> 	at org.jboss.tools.jsf.jsf2.bean.model.impl.JSF2Project.load(JSF2Project.java:261)
> 	at org.jboss.tools.jsf.jsf2.bean.model.impl.JSF2Project.resolveStorage(JSF2Project.java:247)
> 	at org.jboss.tools.jsf.jsf2.bean.model.impl.JSF2Project.resolve(JSF2Project.java:254)
> 	at org.jboss.tools.jsf.jsf2.bean.model.impl.JSF2Project$1.run(JSF2Project.java:172)
> 	at org.jboss.tools.common.model.XJob.runInWorkspace(XJob.java:192)
> 	at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
> 	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

--
This message was sent by Atlassian JIRA
(v6.3.15#6346)