This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 270069 - NullPointerException at org.netbeans.modules.remote.impl.fs.RemoteFileSystem$RootFileObject.getAttribute
Summary: NullPointerException at org.netbeans.modules.remote.impl.fs.RemoteFileSystem$...
Status: NEW
Alias: None
Product: cnd
Classification: Unclassified
Component: Remote (show other bugs)
Version: 8.2
Hardware: All All
: P4 normal (vote)
Assignee: Vladimir Kvashin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-14 16:09 UTC by Exceptions Reporter
Modified: 2017-03-23 12:10 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter: 228404

Attachments
stacktrace (3.52 KB, text/plain)
2017-03-14 16:09 UTC, Exceptions Reporter 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Exceptions Reporter 2017-03-14 16:09:56 UTC 
Build: NetBeans IDE 8.2 (Build 201609300101)
VM: Java HotSpot(TM) 64-Bit Server VM, 25.121-b13, Java(TM) SE Runtime Environment, 1.8.0_121-b13
OS: Windows 10

User Comments:
GUEST: After a fresh install of NetBeans IDE 8.2 and JDK, I created a project on our Linux server.  I can browse, etc, when creating the project, and it will even build correctly.

However, in the Project pane (at left), under the proj folder, NO files are displayed, only "Loading ...." with an hourglass.  AND in the lower right status bar of the Netbeans IDE Window:  "Analyze source root" with spinning progress bar.

I suspect this Java Exception is causing the File Explorer to hang with no source files displayed - since the error appears to be a Filesystem "Get Attribute" error.  

Please help.  Netbeans is unusable if I can't view source files.

Thanks,
Bruce Rodgers
Gordon.rodgers@dematic.com




Stacktrace: 
java.lang.NullPointerException
   at org.netbeans.modules.remote.impl.fs.RemoteFileSystem$RootFileObject.getAttribute(RemoteFileSystem.java:1295)
   at org.netbeans.modules.remote.impl.fs.RemoteFileObject.getAttribute(RemoteFileObject.java:450)
   at org.netbeans.modules.versioning.core.api.VCSFileProxy.getAttribute(VCSFileProxy.java:510)
   at org.netbeans.modules.versioning.core.api.VCSFileProxy.getFileProxyOperations(VCSFileProxy.java:496)
   at org.netbeans.modules.versioning.core.api.VCSFileProxy.createFileProxy(VCSFileProxy.java:182)
   at org.netbeans.modules.localhistory.LocalHistory$OpenedFilesListener.getFiles(LocalHistory.java:573)
Comment 1 Exceptions Reporter 2017-03-14 16:09:58 UTC 
Created attachment 163832 [details]
stacktrace
Comment 2 Vladimir Kvashin 2017-03-15 10:33:02 UTC 
I see two things here: 

1) The code is NPE prone: FileOperationsProvider.getDefault() return value is never checked for null, but it can return null of for some strange reason remotefs.versioning module is absent. This should be fixed in code. I think FileOperationsProvider.getDefault() should return fake result in such case.

2) But I do not understand how can remotefs.versioning module be absent. It provides key "org.netbeans.modules.remotefs.versioning" and remote.impl, in which the NPE occurs, requires this key. So there is something strange in user dir.

The conclusion:
- we should fix the bug in code
- user can work this around via using a fresh user dir.
Comment 3 Vladimir Kvashin 2017-03-23 12:10:17 UTC 
If a userdir is broken, many things can become messed up. Downgrading to P4.