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 178273 - Pinned taskbar icon is duplicated in 64-bit mode
Summary: Pinned taskbar icon is duplicated in 64-bit mode
Status: REOPENED
Alias: None
Product: platform
Classification: Unclassified
Component: Launchers&CLI (show other bugs)
Version: 8.1
Hardware: PC Windows 10 x64
: P2 normal with 9 votes (vote)
Assignee: Libor Fischmeistr
URL:
Keywords:
: 189577 198262 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-12-07 20:33 UTC by pjulien
Modified: 2016-03-14 10:40 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
NetBeans startup log file as requested. (32.32 KB, text/plain)
2016-01-04 10:44 UTC, BlameFate
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pjulien 2009-12-07 20:33:58 UTC
Using windows 7 64-bit with a 64-bit jvm

1. pin netbeans to the taskbar
2. Start netbeans from said taskbar


We expect the icon to "light up" since the program is active. 

Instead another slot in the task bar is created for netbeans.

This issue cannot be reproduced using windows 7 64-bit with a 32-bit jvm.
Comment 1 pjulien 2009-12-08 06:34:50 UTC
This occurs in 6.8 RC1 and RC2.  This does not occur with 6.7.1
Comment 2 t_h 2009-12-08 06:58:40 UTC
Probably caused by the fact that if 32bit JVM is used NB executable and JVM runs in the same process. If 64bit JVM is used separate process is started for JVM. The behavior should be same in 6.7.
Comment 3 pjulien 2009-12-08 07:00:43 UTC
(In reply to comment #2)
> Probably caused by the fact that if 32bit JVM is used NB executable and JVM
> runs in the same process. If 64bit JVM is used separate process is started for
> JVM. The behavior should be same in 6.7.

And yet it isn't.
Comment 4 TSchorny 2010-02-15 16:50:16 UTC
(In reply to comment #2)
> Probably caused by the fact that if 32bit JVM is used NB executable and JVM
> runs in the same process. If 64bit JVM is used separate process is started for
> JVM. The behavior should be same in 6.7.

Nope.
It is caused by the fact that the netbeans.exe is a 32bit application.
It tries to load the 64bit jvm inside it's own process which of course fails, so it reverts back to starting the jvm as another process.

It is pretty easy to fix: add a 64bit netbeans64.exe file as loader for 64bit jvms.
Comment 5 ithinkihaveacat 2010-07-11 13:33:57 UTC
This is still a problem with 6.9.
Comment 6 Jaroslav Tulach 2010-09-06 07:59:21 UTC
We could generate netbeans64.exe, nbexec64.dll and installer could use them on 64bit windows.
Comment 7 EvilVIr 2010-09-08 20:52:51 UTC
There is quick temporaray solution for that issue - you must specify additional command-line option for the netbeans.exe like this:

"C:\Program Files\NetBeans\bin\netbeans.exe" --jdkhome "C:\Program Files (x86)\Java\jdk"

This will force netbeans launcher to use 32-bit JDK and, in result, it will stay under pinned icon.

So you must:

- pin netbeans.exe to the taskbar

- right-click that pinned icon and in the context menu right-click on "NetBeans IDE 6.x"

- from that 2nd menu select "Properties"

- in the window that will popup find "Target:" field and change it's content to 
"C:\Program Files\NetBeans\bin\netbeans.exe" --jdkhome "C:\Program Files (x86)\Java\jdk"

- click "OK" to close window

- now NetBeans will work under pinned icon but will use 32-bit Java as default (you can still run your projects under 64-bit Java but you must add and select new platform under Java Platform Manager that's found under Tools->Java Platforms menu)
Comment 8 Antonin Nebuzelsky 2011-05-30 13:19:24 UTC
*** Bug 198262 has been marked as a duplicate of this bug. ***
Comment 9 unai 2011-06-19 09:26:33 UTC
This is still a problem in NB 7.

IMHO, best option would be to have a compiled "netbeans64.exe" for windows x64 and have it deployed ini the /bin directory, together with "netbeans.exe" (win x86) and "netbeans[.sh]" (GNU).
Comment 10 Antonin Nebuzelsky 2011-06-22 13:22:55 UTC
Won't be fixed for 7.0.1.
Comment 11 snowjoke 2011-08-04 21:12:10 UTC
"Won't be fixed for 7.0.1." wait, what? Why not? This is a very obvious and annoying bug for people with Windows 7 64-bit and it makes Netbeans look very unprofessional when it is the one application that fails to integrate with the taskbar.

Suggestion in comment #7 does not work for me.
Comment 12 Antonin Nebuzelsky 2011-10-05 20:21:19 UTC
*** Bug 189577 has been marked as a duplicate of this bug. ***
Comment 13 Antonin Nebuzelsky 2011-11-29 14:47:22 UTC
Producing 64-bit launcher is targeted for 7.2.
Comment 14 Jiri Rechtacek 2012-02-16 16:57:22 UTC
Assigned to new owner.
Comment 15 Jiri Rechtacek 2012-03-14 09:53:12 UTC
Integrated in trunk - core-main/rev/34fef02e9b05.
Build for verification will be available in a few days at
http://bits.netbeans.org/download/trunk/nightly/latest/
Comment 16 Antonin Nebuzelsky 2012-03-19 15:41:04 UTC
Works for me on Win 7 x64 with Java 64-bit as expected with a latest 7.2 dev build.

Reporters, can you verify and confirm as well? Thanks.
Comment 17 st3vie 2012-03-19 19:49:39 UTC
After installing Netbeans dev and Java 64bit it works for me now.

OS: Windows 7 64-bit
Version: NetBeans IDE Dev (Build 201203190400)
Java: 1.7.0_03; Java HotSpot(TM) 64-Bit Server VM 22.1-b02
Comment 18 BlameFate 2016-01-02 06:04:39 UTC
This issue was fixed, but seems to be happening again for me on Windows 10 with NetBeans 8.1 (I had previous versions of NetBeans installed, but have un-installed them: the pinned taskbar icon is for the latest version, and works fine in opening the application, which then creates a duplicate taskbar icon). Naturally I want to use the 64-bit version of Java wherever I am required to use Java, though I am developing for PHP.
Comment 19 Libor Fischmeistr 2016-01-04 07:55:32 UTC
(In reply to BlameFate from comment #18)
> This issue was fixed, but seems to be happening again for me on Windows 10
> with NetBeans 8.1 (I had previous versions of NetBeans installed, but have
> un-installed them: the pinned taskbar icon is for the latest version, and
> works fine in opening the application, which then creates a duplicate
> taskbar icon). Naturally I want to use the 64-bit version of Java wherever I
> am required to use Java, though I am developing for PHP.

Could you please attach the launcher log - run the IDE with switch --trace <log file name>
Comment 20 BlameFate 2016-01-04 10:44:26 UTC
Created attachment 157980 [details]
NetBeans startup log file as requested.
Comment 21 BlameFate 2016-01-08 15:20:08 UTC
This bug also affects Nightly Build 2016-Jan-06. I presume it's still affecting the nightly development builds.
Comment 22 Libor Fischmeistr 2016-03-10 09:20:37 UTC
Is your issue still actual? Usually, when such thing occurs it's caused because wrong version of launcher is called. Could you check if you are calling the correct launcher? If the IDE uses 64-bit Java - use netbeans64.exe, if 32-bit Java - netbeans.exe. For me it works...
Comment 23 Libor Fischmeistr 2016-03-10 10:09:41 UTC
If the issue still persist for you, please create the new issue, because the origin of the issue may be quite different.

Thanks
Comment 24 BlameFate 2016-03-11 05:32:06 UTC
@LiborFishmeistr: Thanks for your advice! I have now MANUALLY resolved this issue, on my machine!

Please explain: why is it not possible for NetBeans to detect which version is installed/ running, and install the correct shortcut icons accordingly, in:
"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\NetBeans"?

Why would that be such a hard change to put in place, which would after all, resolve this issue for all of us, without any of us having to edit shortcut properties manually in the future???

And why should I duplicate this issue, instead of someone actually resolving the underlying issue, which now looks very simple indeed to resolve?
Comment 25 BlameFate 2016-03-11 05:33:10 UTC
p.s. My shortcut target now looks like this:
"C:\Program Files\NetBeans Dev 201603070002\bin\netbeans64.exe" -J-Dnb.php7=true
Comment 26 Libor Fischmeistr 2016-03-14 07:05:36 UTC
(In reply to BlameFate from comment #24)
> And why should I duplicate this issue, instead of someone actually resolving
> the underlying issue, which now looks very simple indeed to resolve?

Because the original cause was quite different. Your issue may be caused by nested JRE...

Thanks
Comment 27 BlameFate 2016-03-14 10:40:12 UTC
⇒ ONE issue, MULTIPLE causes.

The original title and description of the issue still apply perfectly well, to the issue I am experiencing!

If you want to handle this another way, please duplicate this issue yourself (leading to confusion over duplicated issue titles, no doubt; but if you insist!) Please copy me in on the new issue number, in this case.