[
https://jira.jboss.org/jira/browse/JBIDE-6185?page=com.atlassian.jira.plu...
]
Darryl Miles commented on JBIDE-6185:
-------------------------------------
I wondered about the getLocationURI() too.
My only comment would be to not call getLocation() twice in a row for the fast-path.
Reasons for this:
* You are guaranteed it will be consistent across the two uses in the new method (maybe
it is possible for another thread to modify the value? I don't know or not, but why
leave yourself open).
* Since it is an interface method the implementation of it may not be simple/trivial it
might consume a small amount of processing power, you are force this computation to be
done twice when you don't need too.
* The performance of the normal case where getLocation()!=null is impacted as little as
possible by the extra logic.
File f = resource.getLocation();
if(f == null) { ... }
return f;
With regards to the 300 calls, I suspect that most of them even if they use "unsafe
handling of getLocation()" aren't affected, because it maybe that only certain
project artifacts such as JAR/libraries/dependencies are affected and not all of those 300
calls ever handle that kind of artifact (just one example I can think of).
NPE o.j.t.common.model.filesystems.impl.FolderImpl.update()
-----------------------------------------------------------
Key: JBIDE-6185
URL:
https://jira.jboss.org/jira/browse/JBIDE-6185
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: common
Affects Versions: 3.1.0.GA
Environment: Linux
Reporter: Darryl Miles
Assignee: Viacheslav Kabanovich
Fix For: 3.1.2
Attachments: FolderImpl_6185.patch
More IResource.getLocation()==null (see my bug
https://jira.jboss.org/jira/browse/JBIDE-4912 )
Check out the following background reading on IResource.getLocation()==null
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc....
https://bugs.eclipse.org/bugs/show_bug.cgi?id=130398
I am a Linux user, therefore I have multiple file systems for different purposes, not all
my data is on the same filesystem.
Please please audit all plugins for the same presumption. Looking at the context this is
a "linked resource" and usually it is linked because it is somewhere else on my
filesystem. I don't understand the comment from
bugs.eclipse.org link above about
getResource()==null when its on a different file system, it seems users need a reliable
way to resolve a java.io.File for a given resource, if that resource is backed by a file,
even if its on a different file system.
!MESSAGE An internal error occurred during: "JBoss Tools Model Update".
!STACK 0
java.lang.NullPointerException
at
org.jboss.tools.common.model.filesystems.impl.FolderImpl.update(FolderImpl.java:306)
at
org.jboss.tools.common.model.filesystems.impl.FileSystemFolderLoader.update(FileSystemFolderLoader.java:28)
at
org.jboss.tools.common.model.filesystems.impl.FileSystemsLoader.update(FileSystemsLoader.java:67)
at
org.jboss.tools.common.model.filesystems.impl.FileSystemsImpl.doUpdate(FileSystemsImpl.java:286)
at
org.jboss.tools.common.model.filesystems.impl.FileSystemsImpl.access$4(FileSystemsImpl.java:280)
at
org.jboss.tools.common.model.filesystems.impl.FileSystemsImpl$UpdateRunnable.run(FileSystemsImpl.java:273)
at org.jboss.tools.common.model.XJob.runInWorkspace(XJob.java:158)
at
org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira