I expect the problems are result of

changeset:   219696:836f5c2762c5
parent:      219569:5b2c1d79a577
user:        S. Aubrecht <saubrecht@netbeans.org>
date:        Fri Apr 20 11:34:55 2012 +0200
summary:     #211403 - upgrading JNA to 3.4.0

Isn't this caused by the fact that previous version of JNA module extracted its OS native binaries to user dir and the new version of JNA module did not overwrite them?
Did you try starting the IDE with a clean user dir?

saubrecht, I believe the below addresses the suggestion and shows there is still an issue.  Feel free to email me directly if there is a specific directory to address that I am missing.

==
removed the only jna like directory under ~
  ./.visualvm/1.3/var/cache/jna  <= which was empty

for nightly builds - I have a general practice of:
- use the zip installer
- rm -rf netbeans <= the unzip file and dir
- rm -rf ~/.netbeans
- unzip the new nightly
- run from bash and accept the license

This process is the result of new nightly releases often resulting in broken modules.

Reporter, please search your system for libjnidispatch.so library, thanks.

*** Bug 211599 has been marked as a duplicate of this bug. ***

saubrecht, found below
  /usr/lib/jni/libjnidispatch.so

(In reply to comment #6)
> saubrecht, found below
>   /usr/lib/jni/libjnidispatch.so

OK, try running NetBeans with -J-Djna.nosys=true

The command line option below results in no JNA related stack traces or exceptions.  What is the operational impact of this option?  Shall this be considered a short term workaround with the JNA issue still to be resolved?
-J-Djna.nosys=true

The question is why the presence of $NB/platform/modules/lib/amd64/Linux/libjnidispatch.so does not suffice; our copy of JNA should not even be considering /usr/lib/jni/libjnidispatch.so.

the below libraries also exist:
Netbeans unzip top level directory:
./netbeans/platform/modules/lib/i386/Linux/libjnidispatch.so
./netbeans/platform/modules/lib/amd64/Linux/libjnidispatch.so

1. not sure which one NB picks up or how it is determined.
2. this is the openjdk7 from Ubuntu "precise" - replacing the current nightly with the unzip from several days ago still functions without the jna issue.
* unfortunately, I do not have access to try with the Oracle java7... This should not have any impact... should it?

FYI:
uname -a
Linux usa 3.2.0-24-generic #37-Ubuntu SMP Wed Apr 25 08:43:22 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

*** Bug 211600 has been marked as a duplicate of this bug. ***

*** Bug 211591 has been marked as a duplicate of this bug. ***

Stopper for Beta

*** Bug 211664 has been marked as a duplicate of this bug. ***

(In reply to comment #7)
> (In reply to comment #6)
> > saubrecht, found below
> >   /usr/lib/jni/libjnidispatch.so
> 
> OK, try running NetBeans with -J-Djna.nosys=true

It works as a workaround for me too.

core-main 6848495bad4f

Stando, backport to release72_beta as well. Thanks.

*** Bug 211818 has been marked as a duplicate of this bug. ***

in release72_beta branch as 17840f7bcdfa

What was the cause?  What was the resolution?

(In reply to comment #20)
> What was the cause?  What was the resolution?

http://hg.netbeans.org/core-main/rev/6848495bad4f

The cause - JNA by default tries System.loadLibrary("jnidispatch"), falling back to unpacking and loading a bundled copy of this library which is a little slower. For speed we do distribute the unpacked library in NB, which is normally fine. But if it is also in /usr/lib, apparently that gets loaded preferentially. JNA 3.4 detects this problem and signals an error for it (seems 3.2.7 would have just proceeded, possibly causing runtime errors later).

The resolution - early during NB startup, set a system property instructing JNA to load "jninbdispatch" instead, renaming the unpacked DLLs included with the NB module accordingly. No library of this name would be expected in /usr/lib or the like, so it is sure to be loaded from the intended location in the NB installation.

Integrated into 'main-golden', will be available in build *201205010400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/6848495bad4f
User: S. Aubrecht <saubrecht@netbeans.org>
Log: #211655 - ensure jnidispatch native lib is loaded from NetBeans folders

(In reply to comment #19)
> in release72_beta branch as 17840f7bcdfa

Standa, I do not see this changeset in repository

Found that finally : 
http://hg.netbeans.org/releases/rev/17840f7bcdfa

Integrated into 'releases', will be available in build *201205021516* or newer. Wait for official and publicly available build.
Changeset: http://hg.netbeans.org/releases/rev/17840f7bcdfa
User: S. Aubrecht <saubrecht@netbeans.org>
Log: #211655 - ensure jnidispatch native lib is loaded from NetBeans folders
(transplanted from 6848495bad4fc64c7f7e2b363cb13b002b041e8f)

Product Version: NetBeans IDE Dev (Build 201205030400)
Java: 1.7.0_04; Java HotSpot(TM) Client VM 23.0-b21
System: Linux version 3.3.4-22-desktop running on i386; UTF-8; en_US (nb)

java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.Native
	at org.netbeans.modules.masterfs.watcher.linux.LinuxNotifier.<init>(LinuxNotifier.java:103)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
	at java.lang.reflect.Constructor.newInstance(Unknown Source)
	at java.lang.Class.newInstance0(Unknown Source)
	at java.lang.Class.newInstance(Unknown Source)
	at org.openide.util.lookup.implspi.SharedClassObjectBridge.newInstance(SharedClassObjectBridge.java:64)
[catch] at org.openide.util.lookup.MetaInfServicesLookup$P.getInstance(MetaInfServicesLookup.java:519)
	at org.netbeans.modules.masterfs.watcher.Watcher.getNotifierForPlatform(Watcher.java:417)
	at org.netbeans.modules.masterfs.watcher.Watcher.<init>(Watcher.java:85)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
	at java.lang.reflect.Constructor.newInstance(Unknown Source)
	at java.lang.Class.newInstance0(Unknown Source)
	at java.lang.Class.newInstance(Unknown Source)
	at org.openide.util.lookup.implspi.SharedClassObjectBridge.newInstance(SharedClassObjectBridge.java:64)
	at org.openide.util.lookup.MetaInfServicesLookup$P.getInstance(MetaInfServicesLookup.java:519)
	at org.openide.util.lookup.AbstractLookup$R.allInstances(AbstractLookup.java:1041)
	at org.openide.util.lookup.AbstractLookup$R.allInstances(AbstractLookup.java:1021)
	at org.openide.util.lookup.ProxyLookup$LazyCollection.computeSingleResult(ProxyLookup.java:1249)
	at org.openide.util.lookup.ProxyLookup$LazyCollection.computeDelegate(ProxyLookup.java:1091)
	at org.openide.util.lookup.ProxyLookup$LazyCollection.access$900(ProxyLookup.java:1021)
	at org.openide.util.lookup.ProxyLookup$LazyCollection$1.hasNext(ProxyLookup.java:1215)
	at org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem$StatusImpl.resultChanged(FileBasedFileSystem.java:305)
	at org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem$StatusImpl.<init>(FileBasedFileSystem.java:271)
	at org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem.<init>(FileBasedFileSystem.java:81)
	at org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem.<clinit>(FileBasedFileSystem.java:79)
	at org.netbeans.modules.masterfs.filebasedfs.FileBasedURLMapper.getFileObjects(FileBasedURLMapper.java:138)
	at org.netbeans.modules.masterfs.MasterURLMapper.getFileObjects(MasterURLMapper.java:65)
	at org.openide.filesystems.URLMapper.findFileObject(URLMapper.java:212)
	at org.netbeans.modules.project.ui.LazyProject.getProjectDirectory(LazyProject.java:92)
	at org.netbeans.modules.project.ui.OpenProjectList$RecentProjectList$4.run(OpenProjectList.java:1537)
	at org.netbeans.modules.project.ui.OpenProjectList$RecentProjectList$4.run(OpenProjectList.java:1505)
	at org.openide.util.Mutex.readAccess(Mutex.java:290)
	at org.netbeans.modules.project.ui.OpenProjectList$RecentProjectList.load(OpenProjectList.java:1505)
	at org.netbeans.modules.project.ui.OpenProjectList$2.run(OpenProjectList.java:215)
	at org.netbeans.modules.project.ui.OpenProjectList$2.run(OpenProjectList.java:208)
	at org.openide.util.Mutex.readAccess(Mutex.java:290)
	at org.netbeans.modules.project.ui.OpenProjectList.getDefault(OpenProjectList.java:208)
	at org.netbeans.modules.project.ui.OpenProjectsTrampolineImpl.addPropertyChangeListenerAPI(OpenProjectsTrampolineImpl.java:95)
	at org.netbeans.api.project.ui.OpenProjects.addPropertyChangeListener(OpenProjects.java:287)
	at org.netbeans.api.project.ui.OpenProjects.<init>(OpenProjects.java:98)
	at org.netbeans.api.project.ui.OpenProjects.<clinit>(OpenProjects.java:90)
	at org.netbeans.modules.editor.bookmarks.BookmarksPersistence.initProjectsListening(BookmarksPersistence.java:105)
	at org.netbeans.modules.editor.bookmarks.EditorBookmarksModule.restored(EditorBookmarksModule.java:77)
	at org.netbeans.core.startup.NbInstaller.loadCode(NbInstaller.java:450)
	at org.netbeans.core.startup.NbInstaller.load(NbInstaller.java:383)
	at org.netbeans.ModuleManager.enable(ModuleManager.java:1177)
	at org.netbeans.ModuleManager.enable(ModuleManager.java:1000)
	at org.netbeans.core.startup.ModuleList.installNew(ModuleList.java:340)
	at org.netbeans.core.startup.ModuleList.trigger(ModuleList.java:276)
	at org.netbeans.core.startup.ModuleSystem.restore(ModuleSystem.java:295)
	at org.netbeans.core.startup.Main.getModuleSystem(Main.java:169)
	at org.netbeans.core.startup.Main.start(Main.java:305)
	at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:123)
	at java.lang.Thread.run(Unknown Source)

For me it is fixed.

Product Version: NetBeans IDE Dev (Build 201205030400)
Java: 1.7.0_04; Java HotSpot(TM) Client VM 23.0-b21
System: Linux version 3.0.0-17-generic-pae running on i386; UTF-8; en_US (nb)

yuriy_lalym - if you encounter problems please file fresh bug reports, as your issue may not even be related. In fact the stack trace you pasted in (BTW please use attachments instead) does not contain the root cause, i.e. the reason why the class could not be initialized. This would be in your messages.log, which gets attached to a bug automatically if you use the IDE's Exception Reporter.

*** Bug 212977 has been marked as a duplicate of this bug. ***

See issue 212977 - it's from NB 7.2 Beta

Let's leave this issue closed for the moment, issue #212977 just reports that JNA initialization failed. But there's no message.log attached to it so I can't evaluate the root cause (which could be different from this issue).

This could happen if there is already a  "/tmp/jna" directory present, and not owned by the user starting the netbeans instance.
The jna library is extracted in directory pointed by 'java.io.tmpdir' system property, which on Unix is /tmp by default.
This is a problem when multiple users are concerned, as only one can own the '/tmp/jna' directory.

To fix it, instead of the recommended '-J-Djna.nosys=true', try '-J-Djava.io.tmpdir=$HOME' , so that the jna directory gets created in the user's home directory.

Using '-J-Djava.io.tmpdir=$HOME' helped me solve the issue on my box.

(In reply to comment #33)
> if there is already a  "/tmp/jna" directory present, and not
> owned by the user starting the netbeans instance.

See bug #212938.

*** Bug 214383 has been marked as a duplicate of this bug. ***

*** Bug 214725 has been marked as a duplicate of this bug. ***

Integrated into 'releases', will be available in build *201210100002* or newer. Wait for official and publicly available build.
Changeset: http://hg.netbeans.org/releases/rev/17840f7bcdfa
User: S. Aubrecht <saubrecht@netbeans.org>
Log: #211655 - ensure jnidispatch native lib is loaded from NetBeans folders
(transplanted from 6848495bad4fc64c7f7e2b363cb13b002b041e8f)