[jira] [Created] (NETBEANS-6490) Plugin Portal: Add GitHub link for the portal itself
Lars Bruun-Hansen created NETBEANS-6490: --- Summary: Plugin Portal: Add GitHub link for the portal itself Key: NETBEANS-6490 URL: https://issues.apache.org/jira/browse/NETBEANS-6490 Project: NetBeans Issue Type: Improvement Components: updatecenters - Pluginportal Reporter: Lars Bruun-Hansen As has nearly become the standard on many websites the [Plugin Portal|https://plugins.netbeans.apache.org/] should have a link to where it sources can be found. I suggest the footer for this. Background: I wanted to contribute but had a hard time figuring out where the code resides. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-6228) NBI: Support JVM bundling with other than Info-Zip
[
https://issues.apache.org/jira/browse/NETBEANS-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Bruun-Hansen updated NETBEANS-6228:
Description:
(This ticket is carried over from [BugZilla
#239238|https://bz.apache.org/netbeans/show_bug.cgi?id=239238].)
The NBI has a feature whereby a JRE can be bundled as a self-executable
compressed archive. This means the Installer can be launched without any JRE
present on the target machine: the JRE is simply bundled inside the Installer
executable.
In order to execute the archive (uncompress it), NBI will add a {{-d}} option
to the command line. Unfortunately this option is very specific to Info-ZIP's
version of self-executables. This excludes use of other archive methods, for
example 7Zip, which does not recognize a {{-d}} option.
For one reason or another 7Zip compresses a JRE far better than Info-ZIP. It is
also better documented. In contrast the Info-ZIP project seems rather abandoned
and it is not trivial to get hold of the 'unzipsfx' stub needed to create the
self-executable.
What to do about it: The {{-d}} option to Info-Zip's unzipsfx specifies a
target directory to unzip into. Instead of using this option the same effect
can be achieved by first changing the working directory into the target
directory (creating it if it doesn't exist) and then executing the
self-executable archive which will then uncompress into the current directory.
Hence the suggestion is to avoid any command line arguments on the
self-executable archive.
This way the user of the NetBeans Platform is free to use his/her own choice of
archiving mechanism as long the archiving mechanism can produce a
self-executable archive.
The problem only exists on Windows. On other platforms the Installer Launcher
does not add the {{-d}} option. The problem is in [JavaUtils.c
file|https://github.com/apache/netbeans/blob/master/nbi/engine/native/launcher/windows/src/JavaUtils.c],
line 626-627. These lines are unnecessary as in line 629 the command is anyway
executed with {{jvmDir}} as the working directory. Therefore a fix is trivial
and will have no side-effects.
was:
(This ticket is carried over from [BugZilla
#239238|https://bz.apache.org/netbeans/show_bug.cgi?id=239238].)
The NBI has a feature whereby a JRE can be bundled as a self-executable
compressed archive. This means the Installer can be launched without any JRE
present on the target machine: the JRE is simply bundled inside the Installer
executable.
In order to execute the archive (uncompress it), NBI will add a {{-d}} option
to the command line. Unfortunately this option is very specific to Info-ZIP's
version of self-executables. This excludes use of other archive methods, for
example 7Zip. which does not recognize a {{-d}} option.
For one reason or another 7Zip compresses a JRE far better than Info-ZIP. It is
also better documented. In contrast the Info-ZIP project seems rather abandoned
and it is not trivial to get hold of the 'unzipsfx' stub needed to create the
self-executable.
What to do about it: The {{-d}} option to Info-Zip's unzipsfx specifies a
target directory to unzip into. Instead of using this option the same effect
can be achieved by first changing the working directory into the target
directory (creating it if it doesn't exist) and then executing the
self-executable archive which will then uncompress into the current directory.
Hence the suggestion is to avoid any command line arguments on the
self-executable archive.
This way the user of the NetBeans Platform is free to use his/her own choice of
archiving mechanism as long the archiving mechanism can produce a
self-executable archive.
The problem only exists on Windows. On other platforms the Installer Launcher
does not add the {{-d}} option. The problem is in [JavaUtils.c
file|https://github.com/apache/netbeans/blob/master/nbi/engine/native/launcher/windows/src/JavaUtils.c],
line 626-627. These lines are unnecessary as in line 629 the command is anyway
executed with {{jvmDir}} as the working directory. Therefore a fix is trivial
and will have no side-effects.
> NBI: Support JVM bundling with other than Info-Zip
> ---
>
> Key: NETBEANS-6228
> URL: https://issues.apache.org/jira/browse/NETBEANS-6228
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - installer
>Reporter: Lars Bruun-Hansen
>Priority: Trivial
>
> (This ticket is carried over from [BugZilla
> #239238|https://bz.apache.org/netbeans/show_bug.cgi?id=239238].)
> The NBI has a feature whereby a JRE can be bundled as a self-executable
> compressed archive. This means the Installer can be launched without any JRE
> present on the target machine: the JRE is simply bundled inside the Installer
> executable.
> In
[jira] [Created] (NETBEANS-6228) NBI: Support JVM bundling with other than Info-Zip
Lars Bruun-Hansen created NETBEANS-6228:
---
Summary: NBI: Support JVM bundling with other than Info-Zip
Key: NETBEANS-6228
URL: https://issues.apache.org/jira/browse/NETBEANS-6228
Project: NetBeans
Issue Type: Improvement
Components: platform - installer
Reporter: Lars Bruun-Hansen
(This ticket is carried over from [BugZilla
#239238|https://bz.apache.org/netbeans/show_bug.cgi?id=239238].)
The NBI has a feature whereby a JRE can be bundled as a self-executable
compressed archive. This means the Installer can be launched without any JRE
present on the target machine: the JRE is simply bundled inside the Installer
executable.
In order to execute the archive (uncompress it), NBI will add a {{-d}} option
to the command line. Unfortunately this option is very specific to Info-ZIP's
version of self-executables. This excludes use of other archive methods, for
example 7Zip. which does not recognize a {{-d}} option.
For one reason or another 7Zip compresses a JRE far better than Info-ZIP. It is
also better documented. In contrast the Info-ZIP project seems rather abandoned
and it is not trivial to get hold of the 'unzipsfx' stub needed to create the
self-executable.
What to do about it: The {{-d}} option to Info-Zip's unzipsfx specifies a
target directory to unzip into. Instead of using this option the same effect
can be achieved by first changing the working directory into the target
directory (creating it if it doesn't exist) and then executing the
self-executable archive which will then uncompress into the current directory.
Hence the suggestion is to avoid any command line arguments on the
self-executable archive.
This way the user of the NetBeans Platform is free to use his/her own choice of
archiving mechanism as long the archiving mechanism can produce a
self-executable archive.
The problem only exists on Windows. On other platforms the Installer Launcher
does not add the {{-d}} option. The problem is in [JavaUtils.c
file|https://github.com/apache/netbeans/blob/master/nbi/engine/native/launcher/windows/src/JavaUtils.c],
line 626-627. These lines are unnecessary as in line 629 the command is anyway
executed with {{jvmDir}} as the working directory. Therefore a fix is trivial
and will have no side-effects.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Comment Edited] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17349634#comment-17349634
]
Lars Bruun-Hansen edited comment on NETBEANS-2523 at 5/22/21, 8:07 AM:
---
The bug still exists in the [Release Candidate for NetBeans IDE 12.4 Installer
for
Windows|https://dist.apache.org/repos/dist/dev/netbeans/netbeans/12.4-installers/windows/Apache-NetBeans-12.4-bin-windows-x64.exe].
For reference here's the Quick-and-Dirty method for how to "release" the fix:
# Build new binary for Windows from the jnilib project (repo path:
{{nbi/engine/native/jnilib}})
# Based on the [current binary package
used|https://netbeans.osuosl.org/binaries/2B892D9E648A792EDB0F705378E06F84C322E208-nbi.engine-external-binaries-11.zip]
you would create a new zip package which includes the updated binary (meaning
newly build version of (ZIP path) {{native/jnilib/dist/windows*.dll}} from step
1).
# Name the new zip package something like
{{nbi.engine-external-binaries-12.zip}} (i.e. bump its version) and upload it
to OSUOSL.
# The binary is used in project (repo path) {{harness/libs.nbi.engine}} which
would need to have its pointers to the binary on OSUOSL changed so that the new
ZIP package is used.
The reason why the method is called "quick-and-dirty" is that the audit trail
is lost. By using such method we cannot be sure from which git ref the binaries
at OSUOSL are build. In fact, we cannot even guarantee that what is at OSUOSL
is based on on source code committed and pushed to the Netbeans Git repo. Lot's
of discussions on this on the NetBeans dev mailing list.
As a parallel example, the build process for native binaries for Profiler Lib
project has been streamlined in
[PR2853|https://github.com/apache/netbeans/pull/2853]. Those binaries are now
build on a CI pipeline whenever the source code changes and a ZIP package with
git ref pointers is build as a result (which can then subsequently be put into
OSUOSL). Ideally something similar would need to be done for jnilib project. Or
use the quick-and-dirty method if in a hurry ... however such method is
unsustainable for the community in the long run.
was (Author: lbruun):
The bug still exists in the [Release Candidate for NetBeans IDE 12.4 Installer
for
Windows|https://dist.apache.org/repos/dist/dev/netbeans/netbeans/12.4-installers/windows/Apache-NetBeans-12.4-bin-windows-x64.exe].
For reference here's the Quick-and-Dirty method for how to "release" the fix:
# Build new binary for Windows from the jnilib project (repo path:
{{nbi/engine/native/jnilib}})
# Based on the [current binary package
used|https://netbeans.osuosl.org/binaries/2B892D9E648A792EDB0F705378E06F84C322E208-nbi.engine-external-binaries-11.zip]
you would create a new zip package which includes the updated binary (meaning
newly build version of (ZIP path) {{native/jnilib/dist/windows*.dll}} from step
1).
# Name the new zip package something like
{{nbi.engine-external-binaries-12.zip}} (i.e. bump its version) and upload it
to OSUOSL.
# The binary is used in project (repo path) {{harness/libs.nbi.engine}} which
would need to have its pointers to the binary on OSUOSL changed.
The reason why the method is called "quick-and-dirty" is that the audit trail
is lost. By using such method we cannot be sure from which git ref the binaries
at OSUOSL are build. In fact, we cannot even guarantee that what is at OSUOSL
is based on on source code committed and pushed to the Netbeans Git repo. Lot's
of discussions on this on the NetBeans dev mailing list.
As a parallel example, the build process for native binaries for Profiler Lib
project has been streamlined in
[PR2853|https://github.com/apache/netbeans/pull/2853]. Those binaries are now
build on a CI pipeline whenever the source code changes and a ZIP package with
git ref pointers is build as a result (which can then subsequently be put into
OSUOSL). Ideally something similar would need to be done for jnilib project. Or
use the quick-and-dirty method if in a hurry ... however such method is
unsustainable for the community in the long run.
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Labels: pull-request-available
> Attachments: 2020-01-04 22_13_24-Registry Editor.png, 2021-01-03
> 08_22_56-Registry Editor.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer
[jira] [Commented] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17349634#comment-17349634
]
Lars Bruun-Hansen commented on NETBEANS-2523:
-
The bug still exists in the [Release Candidate for NetBeans IDE 12.4 Installer
for
Windows|https://dist.apache.org/repos/dist/dev/netbeans/netbeans/12.4-installers/windows/Apache-NetBeans-12.4-bin-windows-x64.exe].
For reference here's the Quick-and-Dirty method for how to "release" the fix:
# Build new binary for Windows from the jnilib project (repo path:
{{nbi/engine/native/jnilib}})
# Based on the [current binary package
used|https://netbeans.osuosl.org/binaries/2B892D9E648A792EDB0F705378E06F84C322E208-nbi.engine-external-binaries-11.zip]
you would create a new zip package which includes the updated binary (meaning
newly build version of (ZIP path) {{native/jnilib/dist/windows*.dll}} from step
1).
# Name the new zip package something like
{{nbi.engine-external-binaries-12.zip}} (i.e. bump its version) and upload it
to OSUOSL.
# The binary is used in project (repo path) {{harness/libs.nbi.engine}} which
would need to have its pointers to the binary on OSUOSL changed.
The reason why the method is called "quick-and-dirty" is that the audit trail
is lost. By using such method we cannot be sure from which git ref the binaries
at OSUOSL are build. In fact, we cannot even guarantee that what is at OSUOSL
is based on on source code committed and pushed to the Netbeans Git repo. Lot's
of discussions on this on the NetBeans dev mailing list.
As a parallel example, the build process for native binaries for Profiler Lib
project has been streamlined in
[PR2853|https://github.com/apache/netbeans/pull/2853]. Those binaries are now
build on a CI pipeline whenever the source code changes and a ZIP package with
git ref pointers is build as a result (which can then subsequently be put into
OSUOSL). Ideally something similar would need to be done for jnilib project. Or
use the quick-and-dirty method if in a hurry ... however such method is
unsustainable for the community in the long run.
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Labels: pull-request-available
> Attachments: 2020-01-04 22_13_24-Registry Editor.png, 2021-01-03
> 08_22_56-Registry Editor.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Closed] (NETBEANS-142) Freeze on search and replace
[ https://issues.apache.org/jira/browse/NETBEANS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Bruun-Hansen closed NETBEANS-142. -- Resolution: Cannot Reproduce I'm closing this myself since I haven't been able to reproduce for a long time, > Freeze on search and replace > > > Key: NETBEANS-142 > URL: https://issues.apache.org/jira/browse/NETBEANS-142 > Project: NetBeans > Issue Type: Bug > Components: editor - Search >Affects Versions: 8.2, 9.0 >Reporter: Lars Bruun-Hansen >Priority: Major > Attachments: 2017-11-14 17_15_04-D__freeze-dump.txt - Notepad++.png, > 2017-11-14 17_16_07-D__freeze-dump.txt - Notepad++2.png, freeze-dump.txt > > > While doing a search and replace operation, NetBeans IDE froze on me. > The search-and-replace operation found 298 occurrences in multiple files, > however all within same project. > I've attached a thread dump. > I see the AWT event thread being blocked: > !2017-11-14 17_15_04-D__freeze-dump.txt - Notepad++.png! > and the culprit is here: > !2017-11-14 17_16_07-D__freeze-dump.txt - Notepad++2.png! > That is how far I got in the analysis of the bug. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-5592) Output Window is extremely slow for Surefire tests (IDEA is 20x faster)
[
https://issues.apache.org/jira/browse/NETBEANS-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Bruun-Hansen updated NETBEANS-5592:
Description:
For show casing the problem I've created a minimal example (attached). It
simply prints 10,000 lines to {{stdout}}.
When the sample application is executed it performs well in both NetBeans IDE
and IntelliJ IDEA: The "Output Window" is able to consume the messages at a
very rapid pace. (in fact, dare I say, NetBeans IDE is perhaps a little bit
faster than IntelliJ IDEA).
However, when the same is executed as a JUnit 5 test using Maven Surefire
Plugin it performs extremely poorly in NetBeans IDE while IntelliJ IDEA
exhibits same behavior as in the non-test case, meaning it is just as fast.
Below are executions of {{mvn clean install}} from within the two IDEs:
*NetBeans IDE:*
{code:java}
BUILD SUCCESS
Total time: 01:21 min
{code}
*IntelliJ IDEA*:
{noformat}
BUILD SUCCESS
Total time: 4.818 s
{noformat}
In fact, in the test scenario, NetBeans IDE is so slow to consume the messages
that one needs to increase the Surefire Plugin's property
{{forkedProcessExitTimeoutInSeconds}} from 30s to a lot more in order to avoid
that Surefire will kill its forked process before all messages have been
forwarded into the IDE. (try removing the setting from the POM and see what
happens)
The reason why I'm logging this in the NetBeans bug tracker is that it seems to
be specific to NetBeans IDE.
I've played around with various Surefire settings, such as {{forkCount = 0}} in
order to disable forking. However, to no avail.
My tests are on Windows - in case it matters.
was:
For show casing the problem I've created a minimal example (attached). It
simply prints 10,000 lines to {{stdout}}.
When the sample application is executed it performs well in both NetBeans IDE
and IntelliJ IDEA: The "Output Window" is able to consume the messages at a
very rapid pace. (in fact, dare I say, NetBeans IDE is perhaps a little bit
faster than IntelliJ IDEA).
However, when the same is executed as a JUnit 5 test using Maven Surefire
Plugin it performs extremely poorly in NetBeans IDE while IntelliJ IDEA
exhibits same behavior as in the non-test case, meaning it is just as fast.
Below are executions of {{mvn clean install}} from within the two IDEs:
*NetBeans IDE:*
{code:java}
BUILD SUCCESS
Total time: 01:21 min
{code}
*IntelliJ IDEA*:
{noformat}
BUILD SUCCESS
Total time: 4.818 s
{noformat}
In fact, in the test scenario, NetBeans IDE is so slow to consume the messages
that one needs to increase the Surefire Plugin's property
{{forkedProcessExitTimeoutInSeconds}} from 30s to a lot more in order to avoid
that Surefire will kill its forked process before all messages has been
forwarded into the IDE. (try removing the setting from the POM and see what
happens)
The reason why I'm logging this in the NetBeans bug tracker is that it seems to
be specific to NetBeans IDE.
I've played around with various Surefire settings, such as {{forkCount = 0}} in
order to disable forking. However, to no avail.
My tests are on Windows - in case it matters.
> Output Window is extremely slow for Surefire tests (IDEA is 20x faster)
> ---
>
> Key: NETBEANS-5592
> URL: https://issues.apache.org/jira/browse/NETBEANS-5592
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Output Window
>Affects Versions: 12.1
>Reporter: Lars Bruun-Hansen
>Priority: Major
> Attachments: surefire-massive-output-test.zip
>
>
> For show casing the problem I've created a minimal example (attached). It
> simply prints 10,000 lines to {{stdout}}.
> When the sample application is executed it performs well in both NetBeans IDE
> and IntelliJ IDEA: The "Output Window" is able to consume the messages at a
> very rapid pace. (in fact, dare I say, NetBeans IDE is perhaps a little bit
> faster than IntelliJ IDEA).
> However, when the same is executed as a JUnit 5 test using Maven Surefire
> Plugin it performs extremely poorly in NetBeans IDE while IntelliJ IDEA
> exhibits same behavior as in the non-test case,
[jira] [Updated] (NETBEANS-5592) Output Window is extremely slow for Surefire tests (IDEA is 20x faster)
[
https://issues.apache.org/jira/browse/NETBEANS-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Bruun-Hansen updated NETBEANS-5592:
Description:
For show casing the problem I've created a minimal example (attached). It
simply prints 10,000 lines to {{stdout}}.
When the sample application is executed it performs well in both NetBeans IDE
and IntelliJ IDEA: The "Output Window" is able to consume the messages at a
very rapid pace. (in fact, dare I say, NetBeans IDE is perhaps a little bit
faster than IntelliJ IDEA).
However, when the same is executed as a JUnit 5 test using Maven Surefire
Plugin it performs extremely poorly in NetBeans IDE while IntelliJ IDEA
exhibits same behavior as in the non-test case, meaning it is just as fast.
Below are executions of {{mvn clean install}} from within the two IDEs:
*NetBeans IDE:*
{code:java}
BUILD SUCCESS
Total time: 01:21 min
{code}
*IntelliJ IDEA*:
{noformat}
BUILD SUCCESS
Total time: 4.818 s
{noformat}
In fact, in the test scenario, NetBeans IDE is so slow to consume the messages
that one needs to increase the Surefire Plugin's property
{{forkedProcessExitTimeoutInSeconds}} from 30s to a lot more in order to avoid
that Surefire will kill its forked process before all messages has been
forwarded into the IDE. (try removing the setting from the POM and see what
happens)
The reason why I'm logging this in the NetBeans bug tracker is that it seems to
be specific to NetBeans IDE.
I've played around with various Surefire settings, such as {{forkCount = 0}} in
order to disable forking. However, to no avail.
My tests are on Windows - in case it matters.
was:
For show casing the problem I've created a minimal example (attached). It
simply prints 10,000 lines to {{stdout}}.
When the sample application is executed it performs well in both NetBeans IDE
and IntelliJ IDEA: The "Output Window" is able to consume the messages at a
very rapid pace. (in fact, dare I say, NetBeans IDE is perhaps a little bit
faster than IntelliJ IDEA).
However, when the same is executed as a JUnit 5 test using Maven Surefire
Plugin it performs extremely poorly in NetBeans IDE while IntelliJ IDEA
exhibits same behavior as in the non-test case, meaning it is just as fast.
Below are executions of {{mvn clean install}} from within the two IDEs:
*NetBeans IDE:*
{code:java}
BUILD SUCCESS
Total time: 01:21 min
{code}
*IntelliJ IDEA*:
{noformat}
BUILD SUCCESS
Total time: 4.818 s
{noformat}
In fact, in the test scenario, NetBeans IDE is so slow to consume the messages
that one needs to increase the Surefire Plugin's property
{{forkedProcessExitTimeoutInSeconds}} from 30s to a lot more in order to avoid
that Surefire will kill its forked process before all messages has been
forwarded into the IDE. (try removing the setting from the POM and see what
happens)
The reason why I'm logging this in the NetBeans bug tracker is that it seems to
be specific to NetBeans IDE.
I've played around with various Surefire settings, such as {{forkCount = 0}} in
order to disable forking. However, to no avail.
My tests are on Windows - in case it matters.
> Output Window is extremely slow for Surefire tests (IDEA is 20x faster)
> ---
>
> Key: NETBEANS-5592
> URL: https://issues.apache.org/jira/browse/NETBEANS-5592
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Output Window
>Affects Versions: 12.1
>Reporter: Lars Bruun-Hansen
>Priority: Major
> Attachments: surefire-massive-output-test.zip
>
>
> For show casing the problem I've created a minimal example (attached). It
> simply prints 10,000 lines to {{stdout}}.
> When the sample application is executed it performs well in both NetBeans IDE
> and IntelliJ IDEA: The "Output Window" is able to consume the messages at a
> very rapid pace. (in fact, dare I say, NetBeans IDE is perhaps a little bit
> faster than IntelliJ IDEA).
> However, when the same is executed as a JUnit 5 test using Maven Surefire
> Plugin it performs extremely poorly in NetBeans IDE while IntelliJ IDEA
> exhibits same behavior as in the non-test case, meaning
[jira] [Created] (NETBEANS-5592) Output Window is extremely slow for Surefire tests (IDEA is 20x faster)
Lars Bruun-Hansen created NETBEANS-5592:
---
Summary: Output Window is extremely slow for Surefire tests (IDEA
is 20x faster)
Key: NETBEANS-5592
URL: https://issues.apache.org/jira/browse/NETBEANS-5592
Project: NetBeans
Issue Type: Bug
Components: platform - Output Window
Affects Versions: 12.1
Reporter: Lars Bruun-Hansen
Attachments: surefire-massive-output-test.zip
For show casing the problem I've created a minimal example (attached). It
simply prints 10,000 lines to {{stdout}}.
When the sample application is executed it performs well in both NetBeans IDE
and IntelliJ IDEA: The "Output Window" is able to consume the messages at a
very rapid pace. (in fact, dare I say, NetBeans IDE is perhaps a little bit
faster than IntelliJ IDEA).
However, when the same is executed as a JUnit 5 test using Maven Surefire
Plugin it performs extremely poorly in NetBeans IDE while IntelliJ IDEA
exhibits same behavior as in the non-test case, meaning it is just as fast.
Below are executions of {{mvn clean install}} from within the two IDEs:
*NetBeans IDE:*
{code:java}
BUILD SUCCESS
Total time: 01:21 min
{code}
*IntelliJ IDEA*:
{noformat}
BUILD SUCCESS
Total time: 4.818 s
{noformat}
In fact, in the test scenario, NetBeans IDE is so slow to consume the messages
that one needs to increase the Surefire Plugin's property
{{forkedProcessExitTimeoutInSeconds}} from 30s to a lot more in order to avoid
that Surefire will kill its forked process before all messages has been
forwarded into the IDE. (try removing the setting from the POM and see what
happens)
The reason why I'm logging this in the NetBeans bug tracker is that it seems to
be specific to NetBeans IDE.
I've played around with various Surefire settings, such as {{forkCount = 0}} in
order to disable forking. However, to no avail.
My tests are on Windows - in case it matters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Created] (NETBEANS-5478) nbbuild : DownloadBinaries task: 5 secs connect time is not enough
Lars Bruun-Hansen created NETBEANS-5478:
---
Summary: nbbuild : DownloadBinaries task: 5 secs connect time is
not enough
Key: NETBEANS-5478
URL: https://issues.apache.org/jira/browse/NETBEANS-5478
Project: NetBeans
Issue Type: Bug
Reporter: Lars Bruun-Hansen
Assignee: Lars Bruun-Hansen
h3. *nbbuild*
When building NetBeans the {{DownloadBinaries}} Ant task is executed. (this
task downloads prerequisite artifacts from either Central Maven or
{{https://netbeans.osuosl.org/binaries}})
However, via the {{ConfigureProxy}} class it implicitly uses a hard-coded
connect timeout of 5 seconds. This would seem enough for the general case, but
simply isn't enough for virtualized environments, such as GitHub Actions
runners. Such environments typically incur a "first touch" penalty on outbound
network connections, meaning that the first outbound connection to internet may
require more connect time than 5 seconds. (after this it is of course fast).
As a result, I see intermittent failures when the build is executed on GitHub
Actions runners. Possibly someone else have seen the problem on other CI
systems?
The failures have been hard to track down because both {{DownloadBinaries}} and
{{ConfigureProxy}} are swallowing exceptions (not cool!).
I'll create a PR. I'll make the connect timeout overridable via a property, but
leave the default as-is for those who have become accustomed to the current
fail-fast behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-5320) Windows Launcher - Support WER (auto restore)
[
https://issues.apache.org/jira/browse/NETBEANS-5320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Bruun-Hansen updated NETBEANS-5320:
Description:
Windows has a (fairly) new function which allows an application to
automatically restart itself if it encounters an error or if the system was
automatically re-booted due to software updates.
I've noticed that on my Windows system applications such as MS Office, Firefox
and Notepad conveniently will automatically restart after a Windows Update
forced re-boot and be restored exactly to where they were. Nice! NetBeans IDE
doesn't do this. (nor does my Mozilla Thunderbird application for that matter).
For this to work the application, in this case the *Windows IDE Launcher* or
the *Windows Platform Launcher*, must [register for
restart|https://docs.microsoft.com/en-us/windows/win32/recovery/registering-for-application-restart]
by calling the [Win32 {{RegisterApplicationRestart}}
function|https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-registerapplicationrestart].
It looks fairly trivial to me.
Note that this Windows feature also has some tricks for _recovery_ (saving and
restoring of state) but we can skip that part as NetBeans does this by itself.
In other words: Registering for recovery is not necessary for NetBeans.
was:
Windows has a (fairly) new function which allows an application to
automatically restart itself if it encounters an error or if the system was
automatically re-booted due to software updates.
I've noticed that on my Windows system applications such as MS Office, Firefox
and Notepad conveniently will automatically restart after a Windows Update
forced re-boot and be restored exactly to where they were. Nice! NetBeans IDE
doesn't do this. (nor does my Mozilla Thunderbird application for that matter).
For this to work the application, in this case the *Windows IDE Launcher* or
the *Windows Platform Launcher*, must [register for
restart|https://docs.microsoft.com/en-us/windows/win32/recovery/registering-for-application-restart]
by calling the [Win32 RegisterApplication Restart
function|https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-registerapplicationrestart].
It looks fairly trivial to me.
Note that this Windows feature also has some tricks for _recovery_ (saving and
restoring of state) but we can skip that part as NetBeans does this by itself.
In other words: Registering for recovery is not necessary for NetBeans.
> Windows Launcher - Support WER (auto restore)
> -
>
> Key: NETBEANS-5320
> URL: https://issues.apache.org/jira/browse/NETBEANS-5320
> Project: NetBeans
> Issue Type: Improvement
>Reporter: Lars Bruun-Hansen
>Priority: Major
>
> Windows has a (fairly) new function which allows an application to
> automatically restart itself if it encounters an error or if the system was
> automatically re-booted due to software updates.
> I've noticed that on my Windows system applications such as MS Office,
> Firefox and Notepad conveniently will automatically restart after a Windows
> Update forced re-boot and be restored exactly to where they were. Nice!
> NetBeans IDE doesn't do this. (nor does my Mozilla Thunderbird application
> for that matter).
> For this to work the application, in this case the *Windows IDE Launcher* or
> the *Windows Platform Launcher*, must [register for
> restart|https://docs.microsoft.com/en-us/windows/win32/recovery/registering-for-application-restart]
> by calling the [Win32 {{RegisterApplicationRestart}}
> function|https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-registerapplicationrestart].
> It looks fairly trivial to me.
> Note that this Windows feature also has some tricks for _recovery_ (saving
> and restoring of state) but we can skip that part as NetBeans does this by
> itself. In other words: Registering for recovery is not necessary for
> NetBeans.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Comment Edited] (NETBEANS-3094) NBI Windows Cleaner.exe doesn't delete read-only files
[
https://issues.apache.org/jira/browse/NETBEANS-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17257680#comment-17257680
]
Lars Bruun-Hansen edited comment on NETBEANS-3094 at 2/26/21, 2:44 PM:
---
I'm re-opening this issue.
This is NBI native binaries so things are little bit different than with the
rest of NetBeans in the sense that a commit to Git doesn't guarantee that the
fix will become part of a release. Native binaries as part of NBI are _not_,
re-build automatically and they will only find their way into an actual release
if a new bundle is uploaded to
[https://netbeans.osuosl.org/binaries/.|https://netbeans.osuosl.org/binaries/]
In this particular case the following needs to happen:
# The new binary, {{cleaner.exe}}, must be build.
# A new ZIP package {{-nbi.engine-external-binaries-.zip}} must
be created. This must be based on the current in-use ZIP and then only updating
{{cleaner.exe}} within the ZIP. Then upload new ZIP to
[https://netbeans.osuosl.org/binaries/]. (as of writing the current version of
that ZIP is "11", we would want to bump that to say "12" - the version string
used on these ZIPs has no affinity with the NB versions).
# New PR: Update file {{harness/libs.nbi.engine/external/binaries-list}} to
point to the new ZIP.
Closing this issue should only happen after it has been verified that the fix
has found its way into a release.
was (Author: lbruun):
I'm re-opening this issue.
This is NBI native binaries so things are little bit than with the rest of
NetBeans in the sense that a commit to Git doesn't guarantee that the fix will
become part of a release. Native binaries as part of NBI are _not_, AFAIK,
re-build automatically, unlike all Java code which goes into the IDE.
Closing this issue should only happen after it has been verified that the fix
has found its way into a release.
> NBI Windows Cleaner.exe doesn't delete read-only files
> --
>
> Key: NETBEANS-3094
> URL: https://issues.apache.org/jira/browse/NETBEANS-3094
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Other
>Affects Versions: 11.1
> Environment: Windows
>Reporter: Lars Bruun-Hansen
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Problem: The Windows Cleaner process isn't able to delete files with
> read-only attribute set.
>
> (Windows Cleaner is a small C application which is part of *NBI* - NetBeans
> Installer)
>
> This is in particular a problem when the uninstaller tries to delete a
> bundled JRE as the JRE has files with read-only attribute set.
> For the record: this has always been a problem. The Unistaller leaves files
> behind and the main reason is this. Note that the equivalent on Linux/Mac,
> the {{cleaner.sh}} script, doesn't suffer from the same problem as it does
> 'rm -f' operation.
> It is rather trivial to fix. I'll file a PR.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Comment Edited] (NETBEANS-3094) NBI Windows Cleaner.exe doesn't delete read-only files
[
https://issues.apache.org/jira/browse/NETBEANS-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17257680#comment-17257680
]
Lars Bruun-Hansen edited comment on NETBEANS-3094 at 2/26/21, 2:44 PM:
---
I'm re-opening this issue.
This is NBI native binaries so things are little bit different than with the
rest of NetBeans in the sense that a commit to Git doesn't guarantee that the
fix will become part of a release. Native binaries as part of NBI are _not_
re-build automatically and they will only find their way into an actual release
if a new bundle is uploaded to
[https://netbeans.osuosl.org/binaries/.|https://netbeans.osuosl.org/binaries/]
In this particular case the following needs to happen:
# The new binary, {{cleaner.exe}}, must be build.
# A new ZIP package {{\-nbi.engine-external-binaries-.zip}}
must be created. This must be based on the current in-use ZIP and then only
updating {{cleaner.exe}} within the ZIP. Then upload new ZIP to
[https://netbeans.osuosl.org/binaries/]. (as of writing the current version of
that ZIP is "11", we would want to bump that to say "12" - the version string
used on these ZIPs has no affinity with the NB versions).
# New PR: Update file {{harness/libs.nbi.engine/external/binaries-list}} to
point to the new ZIP.
Closing this issue should only happen after it has been verified that the fix
has found its way into a release.
was (Author: lbruun):
I'm re-opening this issue.
This is NBI native binaries so things are little bit different than with the
rest of NetBeans in the sense that a commit to Git doesn't guarantee that the
fix will become part of a release. Native binaries as part of NBI are _not_
re-build automatically and they will only find their way into an actual release
if a new bundle is uploaded to
[https://netbeans.osuosl.org/binaries/.|https://netbeans.osuosl.org/binaries/]
In this particular case the following needs to happen:
# The new binary, {{cleaner.exe}}, must be build.
# A new ZIP package {{-nbi.engine-external-binaries-.zip}} must
be created. This must be based on the current in-use ZIP and then only updating
{{cleaner.exe}} within the ZIP. Then upload new ZIP to
[https://netbeans.osuosl.org/binaries/]. (as of writing the current version of
that ZIP is "11", we would want to bump that to say "12" - the version string
used on these ZIPs has no affinity with the NB versions).
# New PR: Update file {{harness/libs.nbi.engine/external/binaries-list}} to
point to the new ZIP.
Closing this issue should only happen after it has been verified that the fix
has found its way into a release.
> NBI Windows Cleaner.exe doesn't delete read-only files
> --
>
> Key: NETBEANS-3094
> URL: https://issues.apache.org/jira/browse/NETBEANS-3094
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Other
>Affects Versions: 11.1
> Environment: Windows
>Reporter: Lars Bruun-Hansen
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Problem: The Windows Cleaner process isn't able to delete files with
> read-only attribute set.
>
> (Windows Cleaner is a small C application which is part of *NBI* - NetBeans
> Installer)
>
> This is in particular a problem when the uninstaller tries to delete a
> bundled JRE as the JRE has files with read-only attribute set.
> For the record: this has always been a problem. The Unistaller leaves files
> behind and the main reason is this. Note that the equivalent on Linux/Mac,
> the {{cleaner.sh}} script, doesn't suffer from the same problem as it does
> 'rm -f' operation.
> It is rather trivial to fix. I'll file a PR.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Comment Edited] (NETBEANS-3094) NBI Windows Cleaner.exe doesn't delete read-only files
[
https://issues.apache.org/jira/browse/NETBEANS-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17257680#comment-17257680
]
Lars Bruun-Hansen edited comment on NETBEANS-3094 at 2/26/21, 2:44 PM:
---
I'm re-opening this issue.
This is NBI native binaries so things are little bit different than with the
rest of NetBeans in the sense that a commit to Git doesn't guarantee that the
fix will become part of a release. Native binaries as part of NBI are _not_
re-build automatically and they will only find their way into an actual release
if a new bundle is uploaded to
[https://netbeans.osuosl.org/binaries/.|https://netbeans.osuosl.org/binaries/]
In this particular case the following needs to happen:
# The new binary, {{cleaner.exe}}, must be build.
# A new ZIP package {{-nbi.engine-external-binaries-.zip}} must
be created. This must be based on the current in-use ZIP and then only updating
{{cleaner.exe}} within the ZIP. Then upload new ZIP to
[https://netbeans.osuosl.org/binaries/]. (as of writing the current version of
that ZIP is "11", we would want to bump that to say "12" - the version string
used on these ZIPs has no affinity with the NB versions).
# New PR: Update file {{harness/libs.nbi.engine/external/binaries-list}} to
point to the new ZIP.
Closing this issue should only happen after it has been verified that the fix
has found its way into a release.
was (Author: lbruun):
I'm re-opening this issue.
This is NBI native binaries so things are little bit different than with the
rest of NetBeans in the sense that a commit to Git doesn't guarantee that the
fix will become part of a release. Native binaries as part of NBI are _not_,
re-build automatically and they will only find their way into an actual release
if a new bundle is uploaded to
[https://netbeans.osuosl.org/binaries/.|https://netbeans.osuosl.org/binaries/]
In this particular case the following needs to happen:
# The new binary, {{cleaner.exe}}, must be build.
# A new ZIP package {{-nbi.engine-external-binaries-.zip}} must
be created. This must be based on the current in-use ZIP and then only updating
{{cleaner.exe}} within the ZIP. Then upload new ZIP to
[https://netbeans.osuosl.org/binaries/]. (as of writing the current version of
that ZIP is "11", we would want to bump that to say "12" - the version string
used on these ZIPs has no affinity with the NB versions).
# New PR: Update file {{harness/libs.nbi.engine/external/binaries-list}} to
point to the new ZIP.
Closing this issue should only happen after it has been verified that the fix
has found its way into a release.
> NBI Windows Cleaner.exe doesn't delete read-only files
> --
>
> Key: NETBEANS-3094
> URL: https://issues.apache.org/jira/browse/NETBEANS-3094
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Other
>Affects Versions: 11.1
> Environment: Windows
>Reporter: Lars Bruun-Hansen
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Problem: The Windows Cleaner process isn't able to delete files with
> read-only attribute set.
>
> (Windows Cleaner is a small C application which is part of *NBI* - NetBeans
> Installer)
>
> This is in particular a problem when the uninstaller tries to delete a
> bundled JRE as the JRE has files with read-only attribute set.
> For the record: this has always been a problem. The Unistaller leaves files
> behind and the main reason is this. Note that the equivalent on Linux/Mac,
> the {{cleaner.sh}} script, doesn't suffer from the same problem as it does
> 'rm -f' operation.
> It is rather trivial to fix. I'll file a PR.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Created] (NETBEANS-5320) Windows Launcher - Support WER (auto restore)
Lars Bruun-Hansen created NETBEANS-5320: --- Summary: Windows Launcher - Support WER (auto restore) Key: NETBEANS-5320 URL: https://issues.apache.org/jira/browse/NETBEANS-5320 Project: NetBeans Issue Type: Improvement Reporter: Lars Bruun-Hansen Windows has a (fairly) new function which allows an application to automatically restart itself if it encounters an error or if the system was automatically re-booted due to software updates. I've noticed that on my Windows system applications such as MS Office, Firefox and Notepad conveniently will automatically restart after a Windows Update forced re-boot and be restored exactly to where they were. Nice! NetBeans IDE doesn't do this. (nor does my Mozilla Thunderbird application for that matter). For this to work the application, in this case the *Windows IDE Launcher* or the *Windows Platform Launcher*, must [register for restart|https://docs.microsoft.com/en-us/windows/win32/recovery/registering-for-application-restart] by calling the [Win32 RegisterApplication Restart function|https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-registerapplicationrestart]. It looks fairly trivial to me. Note that this Windows feature also has some tricks for _recovery_ (saving and restoring of state) but we can skip that part as NetBeans does this by itself. In other words: Registering for recovery is not necessary for NetBeans. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-1428) Fatal error when profiling
[
https://issues.apache.org/jira/browse/NETBEANS-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269662#comment-17269662
]
Lars Bruun-Hansen commented on NETBEANS-1428:
-
As per the [discussion on the mailing
list|http://mail-archives.apache.org/mod_mbox//netbeans-dev/202101.mbox/%3CCADQsCza6%3DVYZNB48zMKp%3DHy-e_kPGrfE_ELC241Uy%2B7T13dwvA%40mail.gmail.com%3E]
I've created [PR-2700|https://github.com/apache/netbeans/pull/2700].
> Fatal error when profiling
> --
>
> Key: NETBEANS-1428
> URL: https://issues.apache.org/jira/browse/NETBEANS-1428
> Project: NetBeans
> Issue Type: Bug
> Components: profiler - Base
>Affects Versions: 9.0, 10.0, 11.0
> Environment: Windows 10, JDK11 (OpenJDK 11.0+28)
>Reporter: Peter Hull
>Priority: Major
> Labels: netcat, pull-request-available
> Attachments: hs_err_pid2496.log, hs_err_pid38528.log
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> Attempting to profile a Java freeform project (Netcat 10, Profiling FreeForm,
> Step 2)
> I get the following error
> {{#}}
> {{# A fatal error has been detected by the Java Runtime Environment:}}
> {{#}}
> {{# EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7ff8e831c775,
> pid=38528, tid=38596}}
> {{#}}
> {{# JRE version: OpenJDK Runtime Environment (11.0+28) (build 11+28)}}
> {{# Java VM: OpenJDK 64-Bit Server VM (11+28, mixed mode, tiered, compressed
> oops, g1 gc, windows-amd64)}}
> {{# Problematic frame:}}
> {{# V [jvm.dll+0x5ec775]}}
> {{#}}
> {{# No core dump will be written. Minidumps are not enabled by default on
> client versions of Windows}}
> {{#}}
> {{# An error report file with more information is saved as:}}
> {{# D:\Libraries\Downloads\TS_Profiler_freeform\freeform\hs_err_pid38528.log}}
> {{#}}
> {{# If you would like to submit a bug report, please visit:}}
> {{# http://bugreport.java.com/bugreport/crash.jsp}}
> {{#}}
> Seems reproducible, I have attached the crash log.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Reopened] (NETBEANS-3094) NBI Windows Cleaner.exe doesn't delete read-only files
[
https://issues.apache.org/jira/browse/NETBEANS-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Bruun-Hansen reopened NETBEANS-3094:
-
I'm re-opening this issue.
This is NBI native binaries so things are little bit than with the rest of
NetBeans in the sense that a commit to Git doesn't guarantee that the fix will
become part of a release. Native binaries as part of NBI are _not_, AFAIK,
re-build automatically, unlike all Java code which goes into the IDE.
Closing this issue should only happen after it has been verified that the fix
has found its way into a release.
> NBI Windows Cleaner.exe doesn't delete read-only files
> --
>
> Key: NETBEANS-3094
> URL: https://issues.apache.org/jira/browse/NETBEANS-3094
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Other
>Affects Versions: 11.1
> Environment: Windows
>Reporter: Lars Bruun-Hansen
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Problem: The Windows Cleaner process isn't able to delete files with
> read-only attribute set.
>
> (Windows Cleaner is a small C application which is part of *NBI* - NetBeans
> Installer)
>
> This is in particular a problem when the uninstaller tries to delete a
> bundled JRE as the JRE has files with read-only attribute set.
> For the record: this has always been a problem. The Unistaller leaves files
> behind and the main reason is this. Note that the equivalent on Linux/Mac,
> the {{cleaner.sh}} script, doesn't suffer from the same problem as it does
> 'rm -f' operation.
> It is rather trivial to fix. I'll file a PR.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-3094) NBI Windows Cleaner.exe doesn't delete read-only files
[
https://issues.apache.org/jira/browse/NETBEANS-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Bruun-Hansen updated NETBEANS-3094:
Fix Version/s: (was: 11.2)
> NBI Windows Cleaner.exe doesn't delete read-only files
> --
>
> Key: NETBEANS-3094
> URL: https://issues.apache.org/jira/browse/NETBEANS-3094
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Other
>Affects Versions: 11.1
> Environment: Windows
>Reporter: Lars Bruun-Hansen
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Problem: The Windows Cleaner process isn't able to delete files with
> read-only attribute set.
>
> (Windows Cleaner is a small C application which is part of *NBI* - NetBeans
> Installer)
>
> This is in particular a problem when the uninstaller tries to delete a
> bundled JRE as the JRE has files with read-only attribute set.
> For the record: this has always been a problem. The Unistaller leaves files
> behind and the main reason is this. Note that the equivalent on Linux/Mac,
> the {{cleaner.sh}} script, doesn't suffer from the same problem as it does
> 'rm -f' operation.
> It is rather trivial to fix. I'll file a PR.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Bruun-Hansen updated NETBEANS-2523:
Attachment: 2021-01-03 08_22_56-Registry Editor.png
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Labels: pull-request-available
> Attachments: 2020-01-04 22_13_24-Registry Editor.png, 2021-01-03
> 08_22_56-Registry Editor.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Comment Edited] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17257679#comment-17257679
]
Lars Bruun-Hansen edited comment on NETBEANS-2523 at 1/3/21, 7:29 AM:
--
Not fixed in release.
Please see the below screenshot from _Registry Editor_ which documents that the
bug still exists when using the 12.2 installer of the IDE.
!2021-01-03 08_22_56-Registry Editor.png!
The problem is - as explained previously in this bug report - that committing
the fix to Git isn't a guarantee that the fix actually finds its way into a
release.
was (Author: lbruun):
Not fixed in release.
Please see the below screenshot from _Registry Editor_ which documents that the
bug still exists when using the 12.2 installer of the IDE.
!2020-01-04 22_13_24-Registry Editor.png!
The problem is - as explained previously in this bug report - that committing
the fix to Git isn't a guarantee that the fix actually finds its way into a
release.
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Labels: pull-request-available
> Attachments: 2020-01-04 22_13_24-Registry Editor.png, 2021-01-03
> 08_22_56-Registry Editor.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Comment Edited] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17257679#comment-17257679
]
Lars Bruun-Hansen edited comment on NETBEANS-2523 at 1/3/21, 7:28 AM:
--
Not fixed in release.
Please see the below screenshot from _Registry Editor_ which documents that the
bug still exists when using the 12.2 installer of the IDE.
!2020-01-04 22_13_24-Registry Editor.png!
The problem is - as explained previously in this bug report - that committing
the fix to Git isn't a guarantee that the fix actually finds its way into a
release.
was (Author: lbruun):
!2020-01-04 22_13_24-Registry Editor.png! Not fixed in release.
Please see the below screenshot from _Registry Editor_ which documents that the
bug still exists when using the 12.2 installer of the IDE.
!image-2021-01-03-08-24-11-316.png!
The problem is - as explained previously in this bug report - that committing
the fix to Git isn't a guarantee that the fix actually finds its way into a
release.
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Labels: pull-request-available
> Attachments: 2020-01-04 22_13_24-Registry Editor.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Comment Edited] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17257679#comment-17257679
]
Lars Bruun-Hansen edited comment on NETBEANS-2523 at 1/3/21, 7:27 AM:
--
!2020-01-04 22_13_24-Registry Editor.png! Not fixed in release.
Please see the below screenshot from _Registry Editor_ which documents that the
bug still exists when using the 12.2 installer of the IDE.
!image-2021-01-03-08-24-11-316.png!
The problem is - as explained previously in this bug report - that committing
the fix to Git isn't a guarantee that the fix actually finds its way into a
release.
was (Author: lbruun):
Not fixed in release.
Please see the below screenshot from _Registry Editor_ which documents that the
bug still exists when using the 12.2 installer of the IDE.
!image-2021-01-03-08-24-11-316.png!
The problem is - as explained previously in this bug report - that committing
the fix to Git isn't a guarantee that the fix actually finds its way into a
release.
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Labels: pull-request-available
> Attachments: 2020-01-04 22_13_24-Registry Editor.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Reopened] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Bruun-Hansen reopened NETBEANS-2523:
-
Not fixed in release.
Please see the below screenshot from _Registry Editor_ which documents that the
bug still exists when using the 12.2 installer of the IDE.
!image-2021-01-03-08-24-11-316.png!
The problem is - as explained previously in this bug report - that committing
the fix to Git isn't a guarantee that the fix actually finds its way into a
release.
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Labels: pull-request-available
> Attachments: 2020-01-04 22_13_24-Registry Editor.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Bruun-Hansen updated NETBEANS-2523:
Fix Version/s: (was: 11.3)
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Labels: pull-request-available
> Attachments: 2020-01-04 22_13_24-Registry Editor.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047794#comment-17047794
]
Lars Bruun-Hansen commented on NETBEANS-2523:
-
Verified that the bug still exists in the Release Candidate for NetBeans IDE
11.3 Installer for Windows. (because of the binary not being re-rebuild
automatically)
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Labels: pull-request-available
> Fix For: 11.3
>
> Attachments: 2020-01-04 22_13_24-Registry Editor.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046962#comment-17046962
]
Lars Bruun-Hansen commented on NETBEANS-2523:
-
Okay, got it. It is Jenkins which builds releases. Still, I've looked through
Jenkins and really cannot see anywhere where it would build the native C / C++
binaries which goes into NBI. But I must admit it is a blur to me, so don't
take my word for it. If Jenkins really builds these bits then we would be
looking for something which would need a C / C++ compiler and it would _have_
to execute on Windows. [Reema Taneja
commented|https://github.com/apache/netbeans/pull/1844#issuecomment-571937304]
on Jan 8th this year that such bits are build manually (which I assume means on
some developer's workstation), so I would assume that is still the case ?
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Labels: pull-request-available
> Fix For: 11.3
>
> Attachments: 2020-01-04 22_13_24-Registry Editor.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046788#comment-17046788
]
Lars Bruun-Hansen commented on NETBEANS-2523:
-
[~skygo]: Well, the current status is that it was merged into NB code base in
[PR-1844|https://github.com/apache/netbeans/pull/1844]. However, this doesn't
mean that it becomes part of the NetBeans distribution as this is one area of
the NetBeans world which is build by hand, i.e. it is not part of Travis build.
Therefore, advertising this bug in 11.3 Release Notes as something which has
been fixed would be premature / incorrect.
We need to figure out who in NetBeans community builds these binaries. There's
a [comment on the
PR|https://github.com/apache/netbeans/pull/1844#issuecomment-571937304] which
at least gives an idea. Personally, I wouldn't know how to get things into that
ZIP.
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Labels: pull-request-available
> Fix For: 11.3
>
> Attachments: 2020-01-04 22_13_24-Registry Editor.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Comment Edited] (NETBEANS-3772) Netbeans hangs on projects background scan
[
https://issues.apache.org/jira/browse/NETBEANS-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028036#comment-17028036
]
Lars Bruun-Hansen edited comment on NETBEANS-3772 at 2/1/20 10:24 AM:
--
[~gary002g]. The dump clearly shows that you are affected by NETBEANS-58. Your
proxy is using SPNEGO authentication.
You may not have been affected on NetBeans 11.1 for a variety of reason, for
example running it on an old version of JDK 8. But that has nothing to do with
NetBeans 11.1 vs 11.2. You may also have had different settings in 11.1, for
example you may have overridden the Proxy Settings in the IDE's option setting.
Just guessing here.
Note: You may think that this has to do with "Project Scan" because that is
where you notice that the IDE freezes. In fact it has nothing to do with
"Project Scan", that is just a coincidence. When the IDE starts up it attempts
to do an outbound HTTP connection to the NetBeans Update Center. To check for
new updates. It does this in a background thread. In order to do this it has to
pass out through your corporate proxy (which uses SPNEGO authentication). This
is where the deadlock happens and it freezes all of the IDE. Making the IDE not
attempt any type of outbound HTTP connections is therefore clearly another type
of workaround.
Java 14 seems to be providing a solution as per the notes in NETBEANS-58. Other
than that there are many other suggestions scattered across NETBEANS-58. If you
have permission to set that darned registry key, {{allowtgtsessionkey}}, then
that is really what I would go for if I was you.
was (Author: lbruun):
[~gary002g]. The dump clearly shows that you are affected by NETBEANS-58. Your
proxy is using SPNEGO authentication.
You may not have been affected on NetBeans 11.1 for a variety of reason, for
example running it on an old version of JDK 8. But that has nothing to do with
NetBeans 11.1 vs 11.2. You may also have had different settings in 11.1, for
example you may have overridden the Proxy Settings in the IDE's option setting.
Just guessing here.
Java 14 seems to be providing a solution as per the notes in NETBEANS-58. Other
than that there are many other suggestions scattered across NETBEANS-58. If you
have permission to set that darned registry key, {{allowtgtsessionkey}}, then
that is really what I would go for if I was you.
> Netbeans hangs on projects background scan
> --
>
> Key: NETBEANS-3772
> URL: https://issues.apache.org/jira/browse/NETBEANS-3772
> Project: NetBeans
> Issue Type: Bug
>Affects Versions: 11.2
> Environment: Dell Precision 5520
> Intel I7-7820; 2.9 GHz
> 32 GB RAM
> Windows 10 Enterprise 64 bit
> Oracle JDK-13.0.2
>Reporter: Gary Greenberg
>Priority: Blocker
> Attachments: nb11-2.JPG, thread_dump.dmp
>
>
> Netbeans hangs right after the start during the projects background scan.
> Progress bar shows different figures ranging from 2% to 94%.
> It did not happened on NB 11.1 with JDK-1.8
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-3772) Netbeans hangs on projects background scan
[
https://issues.apache.org/jira/browse/NETBEANS-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028036#comment-17028036
]
Lars Bruun-Hansen commented on NETBEANS-3772:
-
[~gary002g]. The dump clearly shows that you are affected by NETBEANS-58. Your
proxy is using SPNEGO authentication.
You may not have been affected on NetBeans 11.1 for a variety of reason, for
example running it on an old version of JDK 8. But that has nothing to do with
NetBeans 11.1 vs 11.2. You may also have had different settings in 11.1, for
example you may have overridden the Proxy Settings in the IDE's option setting.
Just guessing here.
Java 14 seems to be providing a solution as per the notes in NETBEANS-58. Other
than that there are many other suggestions scattered across NETBEANS-58. If you
have permission to set that darned registry key, {{allowtgtsessionkey}}, then
that is really what I would go for if I was you.
> Netbeans hangs on projects background scan
> --
>
> Key: NETBEANS-3772
> URL: https://issues.apache.org/jira/browse/NETBEANS-3772
> Project: NetBeans
> Issue Type: Bug
>Affects Versions: 11.2
> Environment: Dell Precision 5520
> Intel I7-7820; 2.9 GHz
> 32 GB RAM
> Windows 10 Enterprise 64 bit
> Oracle JDK-13.0.2
>Reporter: Gary Greenberg
>Priority: Blocker
> Attachments: nb11-2.JPG, thread_dump.dmp
>
>
> Netbeans hangs right after the start during the projects background scan.
> Progress bar shows different figures ranging from 2% to 94%.
> It did not happened on NB 11.1 with JDK-1.8
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Comment Edited] (NETBEANS-106) NB classloaders should use fine grained locking
[ https://issues.apache.org/jira/browse/NETBEANS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023597#comment-17023597 ] Lars Bruun-Hansen edited comment on NETBEANS-106 at 1/25/20 3:59 PM: - Well, currently this is only "fixed" in JDK 14. The fix in JDK-8068184 simply means that the JDK will no longer lock on the classloader. This lock was bad news for the NetBeans Platform because the Platform also puts a lock on the classloader. Hence a deadlock could easily occur as examplified in NETBEANS-58. But it wasn't bad for anyone else i.e. those not using NetBeans Platforms but simply using JDK as-is. This is because the JDK's own class loaders (which aren't used in NetBeans Platform) do _not_ use a global lock on the class loader. This background is probably also the reason why the issue hasn't been addressed by the JDK developers for years, until now. It simply wasn't important. I'll argue that it is only a matter of time before another JDK developer gets the idea to put a lock on the classloader, thinking that this is acceptable ...because it will actually work, except for those who also has the idea to put a lock on the classloader ... and they are not many, probably NB Platform is the only one. Therefore I still believe in this ticket. was (Author: lbruun): Well, currently this is only "fixed" in JDK 14. The fix in JDK-8068184 simply means that the JDK will no longer lock on the classloader. This lock was bad news for the NetBeans Platform because the Platform also puts a lock on the classloader. Hence a deadlock could easily occur as examplified in NETBEANS-58. But it wasn't bad for anyone else i.e. those not using NetBeans Platforms but simply using JDK as-is. This is because the JDK's own class loaders (which aren't used in NetBeans Platform) do _not_ use a global lock on the class loader. This background is probably also the reason why the issue hasn't been addressed by the JDK developers for years, until now. It simply wasn't important. I'll argue that is only a matter of time before another JDK developer gets the idea to put a lock on the classloader, thinking that this is acceptable ...because it will actually work, except for those who also has the idea to put a lock on the classloader ... and they are not many, probably NB Platform is the only one. Therefore I still believe in this ticket. > NB classloaders should use fine grained locking > --- > > Key: NETBEANS-106 > URL: https://issues.apache.org/jira/browse/NETBEANS-106 > Project: NetBeans > Issue Type: Bug >Reporter: Lars Bruun-Hansen >Priority: Major > > In order to avoid issues such as NETBEANS-58 the NB classloaders should use > fine grained locking. (possibly only needed on System Classloader) > Background: At the time when the NB classloaders were created the general > consensus at the time was that a proper classloader used locking at the level > of the classloader itself. This was also how the classloaders in the JDK > worked. However, in Java 7 this > [changed|https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html]. > The JDK classloaders started using more fine grained locking. But the NB > classloaders didn't follow suit. (it is not exactly an inheritable feature) > This means we are now in a situation were deadlocks occur in NB code which > cannot be reproduced with only the JDK. One such case is JDK-8068184 which > causes a severe freeze in NetBeans. We cannot expect the JDK folks to fix > problems that occur only in NB code. > What I propose is that a more fine grained locking mechanism is used. Look to > the JDK for inspiration. This will solve such deadlock issues. I don't think > it is necessary to actually claim that it is now fully multi-thread safe by > calling > [registerAsParallelCapable()|https://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html#registerAsParallelCapable()]. > This can be left for a later exercise. First step is to remove the lock on > the classloader as a whole. > NETBEANS-58 contains a simple [minimal > example|https://issues.apache.org/jira/browse/NETBEANS-58?focusedCommentId=16224149=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16224149] > which can be used as a measure of success. Once an NB application can use > the pattern in the example without freezing then we have accomplished the > goal. > > (I'm personally not confident with fiddling with the NB classloaders. Scares > the sh.. out of me because I know it is the heart of the platform. So won't > come up with a PR. Sorry.) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail:
[jira] [Comment Edited] (NETBEANS-106) NB classloaders should use fine grained locking
[ https://issues.apache.org/jira/browse/NETBEANS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023597#comment-17023597 ] Lars Bruun-Hansen edited comment on NETBEANS-106 at 1/25/20 3:58 PM: - Well, currently this is only "fixed" in JDK 14. The fix in JDK-8068184 simply means that the JDK will no longer lock on the classloader. This lock was bad news for the NetBeans Platform because the Platform also puts a lock on the classloader. Hence a deadlock could easily occur as examplified in NETBEANS-58. But it wasn't bad for anyone else i.e. those not using NetBeans Platforms but simply using JDK as-is. This is because the JDK's own class loaders (which aren't used in NetBeans Platform) do _not_ use a global lock on the class loader. This background is probably also the reason why the issue hasn't been addressed by the JDK developers for years, until now. It simply wasn't important. I'll argue that is only a matter of time before another JDK developer gets the idea to put a lock on the classloader, thinking that this is acceptable ...because it will actually work, except for those who also has the idea to put a lock on the classloader ... and they are not many, probably NB Platform is the only one. Therefore I still believe in this ticket. was (Author: lbruun): Well, currently this is only "fixed" in JDK 14. The fix in JDK-8068184 simply means that the JDK will no longer lock on the classloader. This lock was bad news for the NetBeans Platform because the Platform also puts a lock on the classloader. Hence a deadlock could easily occur as exemplified in NETBEANS-58. But it wasn't bad for anyone else i.e. those not using NetBeans Platforms but simply using JDK as-is. This is because the JDK's own class loaders (which aren't used in NetBeans Platform) do _not_ use a global lock on the class loader. This background is probably also the reason why the issue hasn't been addressed by the JDK developers for years, until now. It simply wasn't important. I'll argue that is only a matter of time before another JDK developer gets the idea to put a lock on the classloader, thinking that this is acceptable ...because it will actually work, except for those who also has the idea to put a lock on the classloader ... and they are not many, probably NB Platform is the only one. Therefore I still believe in this ticket. > NB classloaders should use fine grained locking > --- > > Key: NETBEANS-106 > URL: https://issues.apache.org/jira/browse/NETBEANS-106 > Project: NetBeans > Issue Type: Bug >Reporter: Lars Bruun-Hansen >Priority: Major > > In order to avoid issues such as NETBEANS-58 the NB classloaders should use > fine grained locking. (possibly only needed on System Classloader) > Background: At the time when the NB classloaders were created the general > consensus at the time was that a proper classloader used locking at the level > of the classloader itself. This was also how the classloaders in the JDK > worked. However, in Java 7 this > [changed|https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html]. > The JDK classloaders started using more fine grained locking. But the NB > classloaders didn't follow suit. (it is not exactly an inheritable feature) > This means we are now in a situation were deadlocks occur in NB code which > cannot be reproduced with only the JDK. One such case is JDK-8068184 which > causes a severe freeze in NetBeans. We cannot expect the JDK folks to fix > problems that occur only in NB code. > What I propose is that a more fine grained locking mechanism is used. Look to > the JDK for inspiration. This will solve such deadlock issues. I don't think > it is necessary to actually claim that it is now fully multi-thread safe by > calling > [registerAsParallelCapable()|https://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html#registerAsParallelCapable()]. > This can be left for a later exercise. First step is to remove the lock on > the classloader as a whole. > NETBEANS-58 contains a simple [minimal > example|https://issues.apache.org/jira/browse/NETBEANS-58?focusedCommentId=16224149=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16224149] > which can be used as a measure of success. Once an NB application can use > the pattern in the example without freezing then we have accomplished the > goal. > > (I'm personally not confident with fiddling with the NB classloaders. Scares > the sh.. out of me because I know it is the heart of the platform. So won't > come up with a PR. Sorry.) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail:
[jira] [Commented] (NETBEANS-106) NB classloaders should use fine grained locking
[ https://issues.apache.org/jira/browse/NETBEANS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023597#comment-17023597 ] Lars Bruun-Hansen commented on NETBEANS-106: Well, currently this is only "fixed" in JDK 14. The fix in JDK-8068184 simply means that the JDK will no longer lock on the classloader. This lock was bad news for the NetBeans Platform because the Platform also puts a lock on the classloader. Hence a deadlock could easily occur as exemplified in NETBEANS-58. But it wasn't bad for anyone else i.e. those not using NetBeans Platforms but simply using JDK as-is. This is because the JDK's own class loaders (which aren't used in NetBeans Platform) do _not_ use a global lock on the class loader. This background is probably also the reason why the issue hasn't been addressed by the JDK developers for years, until now. It simply wasn't important. I'll argue that is only a matter of time before another JDK developer gets the idea to put a lock on the classloader, thinking that this is acceptable ...because it will actually work, except for those who also has the idea to put a lock on the classloader ... and they are not many, probably NB Platform is the only one. Therefore I still believe in this ticket. > NB classloaders should use fine grained locking > --- > > Key: NETBEANS-106 > URL: https://issues.apache.org/jira/browse/NETBEANS-106 > Project: NetBeans > Issue Type: Bug >Reporter: Lars Bruun-Hansen >Priority: Major > > In order to avoid issues such as NETBEANS-58 the NB classloaders should use > fine grained locking. (possibly only needed on System Classloader) > Background: At the time when the NB classloaders were created the general > consensus at the time was that a proper classloader used locking at the level > of the classloader itself. This was also how the classloaders in the JDK > worked. However, in Java 7 this > [changed|https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html]. > The JDK classloaders started using more fine grained locking. But the NB > classloaders didn't follow suit. (it is not exactly an inheritable feature) > This means we are now in a situation were deadlocks occur in NB code which > cannot be reproduced with only the JDK. One such case is JDK-8068184 which > causes a severe freeze in NetBeans. We cannot expect the JDK folks to fix > problems that occur only in NB code. > What I propose is that a more fine grained locking mechanism is used. Look to > the JDK for inspiration. This will solve such deadlock issues. I don't think > it is necessary to actually claim that it is now fully multi-thread safe by > calling > [registerAsParallelCapable()|https://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html#registerAsParallelCapable()]. > This can be left for a later exercise. First step is to remove the lock on > the classloader as a whole. > NETBEANS-58 contains a simple [minimal > example|https://issues.apache.org/jira/browse/NETBEANS-58?focusedCommentId=16224149=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16224149] > which can be used as a measure of success. Once an NB application can use > the pattern in the example without freezing then we have accomplished the > goal. > > (I'm personally not confident with fiddling with the NB classloaders. Scares > the sh.. out of me because I know it is the heart of the platform. So won't > come up with a PR. Sorry.) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023459#comment-17023459
]
Lars Bruun-Hansen commented on NETBEANS-58:
---
It is perhaps worth adding that in Java 13 the problem can possibly also be
avoided by setting {{sun.security.jgss.native=true}} on the JVM. See
[this|https://www.oracle.com/technetwork/java/13-relnote-issues-5460548.html#JDK-6722928].
I haven't tested it myself. This will mean that the Kerberos authentication
will now hopefully work on the workstation (seen from Java's perspective) and
there will therefore be no reason for the NetBeans Platform to present the
{{Authenticator}} and therefore the deadlock will not happen. This is the
theory, at least.
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator
[jira] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023082#comment-17023082
]
Lars Bruun-Hansen commented on NETBEANS-58:
---
My 2c:
The real fix, rather than the workarounds I've created in the past, is indeed
NETBEANS-106. The main problem is that NetBeans' classloader is simply too lock
happy. (it uses a global lock rather than a targeted one, something which - in
my opinion - will ultimately lead to deadlocks, not just in this case but in
other cases too).
I don't think NETBEANS-106 is being worked on, AFAIK.
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator
> does something wrong? No, of course it doesn't. The real problem is the lock
> on the classloader. It is
[jira] [Commented] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008169#comment-17008169
]
Lars Bruun-Hansen commented on NETBEANS-2523:
-
It is worth noting why the bug hasn't had more of an impact:
* Windows will ignore such registry entry where there's a mismatch between the
stated type (e.g. DWORD) and the length of the actual value.. For the case of
the 'NoModify' it will - if unset - default to a value of true (1) and this is
what NBI intends anyway (NBI's uninstaller feature doesn't support modifying an
installation).
* NBI has no other use-case for _writing_ registry keys than setting the
Uninstaller information. Of these, only the 'NoModify' entry is of type DWORD.
All the other registry entries are of type string. (see screenshot)
However, I've seen certain Windows system analyzer tools trip over this value
from NBI. The tool flagged the registry value as "suspect". (can't right now
remember which tool it was)
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Attachments: 2020-01-04 22_13_24-Registry Editor.png
>
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Comment Edited] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008162#comment-17008162
]
Lars Bruun-Hansen edited comment on NETBEANS-2523 at 1/4/20 9:15 PM:
-
See below for how the bug manifests itself (yellow highlight):
!2020-01-04 22_13_24-Registry Editor.png!
was (Author: lbruun):
See below for how the bug manifests itself (yellow highlight):
!2020-01-04 22_04_58-Registry Editor.png!
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Attachments: 2020-01-04 22_04_58-Registry Editor.png, 2020-01-04
> 22_13_24-Registry Editor.png
>
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Bruun-Hansen updated NETBEANS-2523:
Attachment: (was: 2020-01-04 22_04_58-Registry Editor.png)
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Attachments: 2020-01-04 22_13_24-Registry Editor.png
>
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Bruun-Hansen updated NETBEANS-2523:
Attachment: 2020-01-04 22_13_24-Registry Editor.png
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Attachments: 2020-01-04 22_04_58-Registry Editor.png, 2020-01-04
> 22_13_24-Registry Editor.png
>
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008162#comment-17008162
]
Lars Bruun-Hansen commented on NETBEANS-2523:
-
See below for how the bug manifests itself (yellow highlight):
!2020-01-04 22_04_58-Registry Editor.png!
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Attachments: 2020-01-04 22_04_58-Registry Editor.png
>
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Assigned] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Bruun-Hansen reassigned NETBEANS-2523:
---
Assignee: Lars Bruun-Hansen
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Assignee: Lars Bruun-Hansen
>Priority: Major
> Attachments: 2020-01-04 22_04_58-Registry Editor.png
>
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Bruun-Hansen updated NETBEANS-2523:
Attachment: 2020-01-04 22_04_58-Registry Editor.png
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Priority: Major
> Attachments: 2020-01-04 22_04_58-Registry Editor.png
>
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-2523) Netbeans 64-bit creates invalid nomodify value in windows registry for years
[
https://issues.apache.org/jira/browse/NETBEANS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Bruun-Hansen updated NETBEANS-2523:
Description:
See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be a
32 bit dword in the registry, which becomes an invalid value.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
"NoModify"=hex(4):01,00,00,00,00,00,00,00
Netbeans prevents powershell from listing registry uninstall keys in windows:
{noformat}
get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
...
get-itemproperty : Specified cast is not valid.
At line:1 char:1
+ get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
+ ~
+ CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
+ FullyQualifiedErrorId :
System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
{noformat}
was:
See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be a
32 bit dword in the registry, which becomes an invalid value.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
"NoModify"=hex(4):01,00,00,00,00,00,00,00
Netbeans prevents powershell from listing registry uninstall keys in windows:
get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall\*
...
get-itemproperty : Specified cast is not valid.
At line:1 char:1
+ get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
+ ~
+ CategoryInfo : NotSpecified: (:) [Get-ItemProperty],
InvalidCastException
+ FullyQualifiedErrorId :
System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> Netbeans 64-bit creates invalid nomodify value in windows registry for years
>
>
> Key: NETBEANS-2523
> URL: https://issues.apache.org/jira/browse/NETBEANS-2523
> Project: NetBeans
> Issue Type: Bug
>Reporter: Joseph Szabo
>Priority: Major
>
> See [https://netbeans.org/bugzilla/show_bug.cgi?id=251538]
> Netbeans 64 bit installer creates a 64 bit integer in what is supposed to be
> a 32 bit dword in the registry, which becomes an invalid value.
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\nbi-nb-base-8.2.0.0.201609300101]
> "NoModify"=hex(4):01,00,00,00,00,00,00,00
>
> Netbeans prevents powershell from listing registry uninstall keys in windows:
> {noformat}
> get-itemproperty hklm:\software\microsoft\windows\currentversion\uninstall*
> ...
> get-itemproperty : Specified cast is not valid.
> At line:1 char:1
> + get-itemproperty hklm:\software\microsoft\windows\currentversion\unin ...
> + ~
> + CategoryInfo : NotSpecified: ( [Get-ItemProperty], InvalidCastException
> + FullyQualifiedErrorId :
> System.InvalidCastException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Created] (NETBEANS-3652) PAC: myIpAddress() returns "127.0.0.1" when executed in Travis env
Lars Bruun-Hansen created NETBEANS-3652:
---
Summary: PAC: myIpAddress() returns "127.0.0.1" when executed in
Travis env
Key: NETBEANS-3652
URL: https://issues.apache.org/jira/browse/NETBEANS-3652
Project: NetBeans
Issue Type: Bug
Components: platform - Proxy
Reporter: Lars Bruun-Hansen
Assignee: Lars Bruun-Hansen
The PAC function {{myIpAddress()}} returns "127.0.0.1" when executed by Travis
environment. Thus test test fail.
This is ultimately due to the
{{LocalAddressUtils.getMostLikelyLocalInetAddresses()}} method not being able
to detect the local host's IP when executed in that type of environment.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
