[jbosstools-issues] [JBoss JIRA] Commented: (JBIDE-6185) NPE o.j.t.common.model.filesystems.impl.FolderImpl.update()

[Darryl Miles (JIRA)]

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

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.isv/reference/api/org/eclipse/core/resources/IResource.html
> 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