[jira] [Closed] (NETBEANS-4610) URISyntaxException building with org-netbeans-libs-javafx.jar using Java 11.0.7 or later
[
https://issues.apache.org/jira/browse/NETBEANS-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rangi Keen closed NETBEANS-4610.
> URISyntaxException building with org-netbeans-libs-javafx.jar using Java
> 11.0.7 or later
>
>
> Key: NETBEANS-4610
> URL: https://issues.apache.org/jira/browse/NETBEANS-4610
> Project: NetBeans
> Issue Type: Bug
> Components: javafx - Deployment
>Affects Versions: 12.0
>Reporter: Rangi Keen
>Priority: Major
> Fix For: 12.4
>
>
> To reproduce:
> # Create a new Java project in NetBeans
> # Open the project properties
> # Select the Libraries category
> # Choose JDK 11.0.7 or later for Java Platform
> # On the Compile tab, click the ellipsis button next to Classpath and choose
> Add JAR/Folder
> # Select /platform/modules/org-netbeans-libs-javafx.jar
> # Save the changes and close the project properties
> # Clean and build the project
> You'll see the following error in the build output:
> {noformat}
> error reading /platform/modules/org-netbeans-libs-javafx.jar;
> java.net.URISyntaxException: Illegal character in path at index :
> file://platform/modules/${java.home}/lib/ext/jfxrt.jar
> {noformat}
--
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] [Resolved] (NETBEANS-4610) URISyntaxException building with org-netbeans-libs-javafx.jar using Java 11.0.7 or later
[
https://issues.apache.org/jira/browse/NETBEANS-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rangi Keen resolved NETBEANS-4610.
--
Fix Version/s: 12.4
Resolution: Fixed
This was resolved with [PR
#2761|https://github.com/apache/netbeans/pull/2761/commits/1b96b56ac3bfda8bd9b97f36c25901e84289cb23].
> URISyntaxException building with org-netbeans-libs-javafx.jar using Java
> 11.0.7 or later
>
>
> Key: NETBEANS-4610
> URL: https://issues.apache.org/jira/browse/NETBEANS-4610
> Project: NetBeans
> Issue Type: Bug
> Components: javafx - Deployment
>Affects Versions: 12.0
>Reporter: Rangi Keen
>Priority: Major
> Fix For: 12.4
>
>
> To reproduce:
> # Create a new Java project in NetBeans
> # Open the project properties
> # Select the Libraries category
> # Choose JDK 11.0.7 or later for Java Platform
> # On the Compile tab, click the ellipsis button next to Classpath and choose
> Add JAR/Folder
> # Select /platform/modules/org-netbeans-libs-javafx.jar
> # Save the changes and close the project properties
> # Clean and build the project
> You'll see the following error in the build output:
> {noformat}
> error reading /platform/modules/org-netbeans-libs-javafx.jar;
> java.net.URISyntaxException: Illegal character in path at index :
> file://platform/modules/${java.home}/lib/ext/jfxrt.jar
> {noformat}
--
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] [Commented] (NETBEANS-5500) URLStreamFactory registration violates JDK9+ reflection restrictions
[
https://issues.apache.org/jira/browse/NETBEANS-5500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347791#comment-17347791
]
Rangi Keen commented on NETBEANS-5500:
--
JDK 16 will throw a runtime exception and JDK 17 will no longer allow this
reflective access. See [A peek into Java 17: Continuing the drive to
encapsulate the Java runtime
internals|https://blogs.oracle.com/javamagazine/java-runtime-encapsulation-internals#anchor_7]
for details.
> URLStreamFactory registration violates JDK9+ reflection restrictions
>
>
> Key: NETBEANS-5500
> URL: https://issues.apache.org/jira/browse/NETBEANS-5500
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Module System
>Affects Versions: 9.0
>Reporter: Jaroslav Tulach
>Assignee: Svatopluk Dedic
>Priority: Major
> Labels: VSNetBeans
> Fix For: Next
>
>
> If you run NetBeans on JDK9+ you'll see:
> {code:java}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.netbeans.ProxyURLStreamHandlerFactory
> (file:/netbeans/nbbuild/netbeans/platform/lib/boot.jar) to field
> java.net.URL.handler
> WARNING: Please consider reporting this to the maintainers of
> org.netbeans.ProxyURLStreamHandlerFactory
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {code}
> There is a new API that one can use to register (most of) the factories on
> JDK9+:
> [https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/spi/URLStreamHandlerProvider.html]
>
> We should use it as once the JDK is going to ban the illegal access
> operations and then it is better to be ready.
--
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-5429) Resizing a floated window is difficult when close to the edge of the screen
Rangi Keen created NETBEANS-5429: Summary: Resizing a floated window is difficult when close to the edge of the screen Key: NETBEANS-5429 URL: https://issues.apache.org/jira/browse/NETBEANS-5429 Project: NetBeans Issue Type: Bug Components: platform - Window System Affects Versions: 12.0 Reporter: Rangi Keen Resizing a floated window can cause the mouse to move opposite the expected direction when the opposite side is near the edge of the screen and snapping is enabled. Do the following to reproduce: # Ensure that both the "Snapping floating windows" and "Snap to screen edges" settings are checked in the Appearance tab # Float any window (e.g. the Servers tab) # Move/resize it so that the right edge of the window is closer than that snapping distance from the edge of the screen. This is possible by moving the window until it snaps a few pixels away from the edge of the screen and then resizing the right edge of the window further to the right so it is at or almost at the edge of the screen. # Resize the window from its left edge and dragging to the right (i.e. making the window narrower) Depending on how fast you drag the mouse, you will see some or all of the following: * The mouse cursor and window will resize to the left, opposite the direction you are physically dragging the mouse * The resize will not be smooth * The mouse will snap to the far right edge of the screen, resizing the window to its minimum width -- 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-4610) URISyntaxException building with org-netbeans-libs-javafx.jar using Java 11.0.7 or later
[
https://issues.apache.org/jira/browse/NETBEANS-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161610#comment-17161610
]
Rangi Keen commented on NETBEANS-4610:
--
This is due to [JDK-8218268|https://bugs.openjdk.java.net/browse/JDK-8218268]
which changed the resolution of the classpath in a manifest file to [use
{{URI}}|http://hg.openjdk.java.net/jdk-updates/jdk11u/file/f9fef514b121/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java#l121]
which does not allow "$".
One solution that seems to resolve the issue (but may have other negative side
effects) is to remove the "${java.home}" prefix from the manifest and project
files for platform/libs.javafx:
{code:none}
diff --git a/platform/libs.javafx/manifest.mf b/platform/libs.javafx/manifest.mf
index 192afed0..bda9cde7 100644
--- a/platform/libs.javafx/manifest.mf
+++ b/platform/libs.javafx/manifest.mf
@@ -38,5 +38,5 @@ OpenIDE-Module-Provides: javafx.animation,
javafx.util,
javafx.util.converter,
netscape.javascript
-Class-Path: ${java.home}/lib/ext/jfxrt.jar
+Class-Path: lib/ext/jfxrt.jar
diff --git a/platform/libs.javafx/nbproject/project.xml
b/platform/libs.javafx/nbproject/project.xml
index e2313422..9bff3a11 100644
--- a/platform/libs.javafx/nbproject/project.xml
+++ b/platform/libs.javafx/nbproject/project.xml
@@ -93,7 +93,7 @@
com.sun.javafx.scene.web
-
${java.home}/lib/ext/jfxrt.jar
+
lib/ext/jfxrt.jar
build/openjfx.zip
{code}
> URISyntaxException building with org-netbeans-libs-javafx.jar using Java
> 11.0.7 or later
>
>
> Key: NETBEANS-4610
> URL: https://issues.apache.org/jira/browse/NETBEANS-4610
> Project: NetBeans
> Issue Type: Bug
> Components: javafx - Deployment
>Affects Versions: 12.0
>Reporter: Rangi Keen
>Priority: Major
>
> To reproduce:
> # Create a new Java project in NetBeans
> # Open the project properties
> # Select the Libraries category
> # Choose JDK 11.0.7 or later for Java Platform
> # On the Compile tab, click the ellipsis button next to Classpath and choose
> Add JAR/Folder
> # Select /platform/modules/org-netbeans-libs-javafx.jar
> # Save the changes and close the project properties
> # Clean and build the project
> You'll see the following error in the build output:
> {noformat}
> error reading /platform/modules/org-netbeans-libs-javafx.jar;
> java.net.URISyntaxException: Illegal character in path at index :
> file://platform/modules/${java.home}/lib/ext/jfxrt.jar
> {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-4610) URISyntaxException building with org-netbeans-libs-javafx.jar using Java 11.0.7 or later
Rangi Keen created NETBEANS-4610:
Summary: URISyntaxException building with
org-netbeans-libs-javafx.jar using Java 11.0.7 or later
Key: NETBEANS-4610
URL: https://issues.apache.org/jira/browse/NETBEANS-4610
Project: NetBeans
Issue Type: Bug
Components: javafx - Deployment
Affects Versions: 12.0
Reporter: Rangi Keen
To reproduce:
# Create a new Java project in NetBeans
# Open the project properties
# Select the Libraries category
# Choose JDK 11.0.7 or later for Java Platform
# On the Compile tab, click the ellipsis button next to Classpath and choose
Add JAR/Folder
# Select /platform/modules/org-netbeans-libs-javafx.jar
# Save the changes and close the project properties
# Clean and build the project
You'll see the following error in the build output:
{noformat}
error reading /platform/modules/org-netbeans-libs-javafx.jar;
java.net.URISyntaxException: Illegal character in path at index :
file://platform/modules/${java.home}/lib/ext/jfxrt.jar
{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-3390) Presence of java.lang.Module causes build path errors in Eclipse
[
https://issues.apache.org/jira/browse/NETBEANS-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rangi Keen updated NETBEANS-3390:
-
Component/s: platform - JDK Problems
> Presence of java.lang.Module causes build path errors in Eclipse
>
>
> Key: NETBEANS-3390
> URL: https://issues.apache.org/jira/browse/NETBEANS-3390
> Project: NetBeans
> Issue Type: Bug
> Components: platform - JDK Problems, platform - LaunchersCLI
>Affects Versions: 10.0, 11.0, 11.1, 11.2
>Reporter: Rangi Keen
>Priority: Major
>
> To reproduce:
> * Create a Java project in Eclipse 2019-09 (and probably also 2019-06)
> * Add a dependency on {{org.netbeans.modules:org-netbeans-bootstrap}}
> * Build the project in Eclipse
> You'll see the following in the problems window:
> bq. The project was not built since its build path is incomplete. Cannot find
> the class file for java.lang.Object. Fix the build path then try building
> this project
> In the Eclipse log file, there are many errors similar to the following:
> bq. MESSAGE Compile error during code evaluation: The package java.lang is
> accessible from more than one module: , java.base
> This appears to be due to the addition of {{java.lang.Module}} in
> {{o.n.bootstrap}} as part of [JDK 9 instrumentation
> support|https://github.com/apache/netbeans/commit/4325e6ca3600c7234072df38ce50ff8c69172343].
> Removing this file and building/running with JDK 11 resolves the issue.
--
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-3390) Presence of java.lang.Module causes build path errors in Eclipse
[
https://issues.apache.org/jira/browse/NETBEANS-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975213#comment-16975213
]
Rangi Keen commented on NETBEANS-3390:
--
Building with JDK 11 first requires that you build the
{{nbbuild/external/vanilla-javac-*.jar}} archives. When you have {{$JAVA_HOME}}
set to JDK 11, these will fail to compile with errors similar to
{quote}package sun.reflect.annotation is declared in module java.base, which
does not export it to module java.compiler}}
{quote}
As such, you need to first compile these using JDK 8 before compiling the rest
of the platform with JDK 11:
{code:java}
JAVA_HOME= ant prepare-vanilla-javac
{code}
For reference, it appears the vanilla javac target was added as part of [an
experiment on using javac from JDK for source code
modeling|https://github.com/apache/netbeans/commit/ffc0de5a17b88ced95a0bd5b89175108701f86a0].
> Presence of java.lang.Module causes build path errors in Eclipse
>
>
> Key: NETBEANS-3390
> URL: https://issues.apache.org/jira/browse/NETBEANS-3390
> Project: NetBeans
> Issue Type: Bug
> Components: platform - LaunchersCLI
>Affects Versions: 10.0, 11.0, 11.1, 11.2
>Reporter: Rangi Keen
>Priority: Major
>
> To reproduce:
> * Create a Java project in Eclipse 2019-09 (and probably also 2019-06)
> * Add a dependency on {{org.netbeans.modules:org-netbeans-bootstrap}}
> * Build the project in Eclipse
> You'll see the following in the problems window:
> bq. The project was not built since its build path is incomplete. Cannot find
> the class file for java.lang.Object. Fix the build path then try building
> this project
> In the Eclipse log file, there are many errors similar to the following:
> bq. MESSAGE Compile error during code evaluation: The package java.lang is
> accessible from more than one module: , java.base
> This appears to be due to the addition of {{java.lang.Module}} in
> {{o.n.bootstrap}} as part of [JDK 9 instrumentation
> support|https://github.com/apache/netbeans/commit/4325e6ca3600c7234072df38ce50ff8c69172343].
> Removing this file and building/running with JDK 11 resolves the issue.
--
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-3390) Presence of java.lang.Module causes build path errors in Eclipse
Rangi Keen created NETBEANS-3390:
Summary: Presence of java.lang.Module causes build path errors in
Eclipse
Key: NETBEANS-3390
URL: https://issues.apache.org/jira/browse/NETBEANS-3390
Project: NetBeans
Issue Type: Bug
Components: platform - LaunchersCLI
Affects Versions: 11.1, 11.0, 10.0, 11.2
Reporter: Rangi Keen
To reproduce:
* Create a Java project in Eclipse 2019-09 (and probably also 2019-06)
* Add a dependency on {{org.netbeans.modules:org-netbeans-bootstrap}}
* Build the project in Eclipse
You'll see the following in the problems window:
bq. The project was not built since its build path is incomplete. Cannot find
the class file for java.lang.Object. Fix the build path then try building this
project
In the Eclipse log file, there are many errors similar to the following:
bq. MESSAGE Compile error during code evaluation: The package java.lang is
accessible from more than one module: , java.base
This appears to be due to the addition of {{java.lang.Module}} in
{{o.n.bootstrap}} as part of [JDK 9 instrumentation
support|https://github.com/apache/netbeans/commit/4325e6ca3600c7234072df38ce50ff8c69172343].
Removing this file and building/running with JDK 11 resolves the issue.
--
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-2649) Output tab name truncated
[
https://issues.apache.org/jira/browse/NETBEANS-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rangi Keen updated NETBEANS-2649:
-
Environment: Windows 10, JDK 11 (was: Windows 10)
> Output tab name truncated
> -
>
> Key: NETBEANS-2649
> URL: https://issues.apache.org/jira/browse/NETBEANS-2649
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Window System
>Affects Versions: 8.2, 11.0
> Environment: Windows 10, JDK 11
>Reporter: Rangi Keen
>Priority: Trivial
> Attachments: Truncated Output Tab.png
>
>
> When running NetBeans with JDK 11 (specifically AdoptOpenJDK 11.0.3+7) on
> Windows 10, the Output tab name is truncated and appears as "Outp..." rather
> than "Output".
> The problem appears to be related to text antialiasing not being used in the
> offscreen graphics while it is used when actually rendering the tab contents.
> The widths of some characters, notably the wider capital letters such as "O",
> differ when "LCD HRGB antialiasing" (and perhaps others) is used.
> Adding the following to
> {{BasicScrollingTabDisplayerUI.getOffscreenGraphics()}} appears to resolve
> the issue:
> {code:java}
> public static Graphics2D getOffscreenGraphics() {
> ...
> Graphics2D graphics = (Graphics2D) result.getGraphics();
> graphics.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
> UIManager.getDefaults().get(RenderingHints.KEY_TEXT_ANTIALIASING));
> return graphics;
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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] [Resolved] (NETBEANS-1834) Possible race condition in ExplorerActionsImpl
[
https://issues.apache.org/jira/browse/NETBEANS-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rangi Keen resolved NETBEANS-1834.
--
Resolution: Fixed
Assignee: (was: Rangi Keen)
Fix Version/s: Next
> Possible race condition in ExplorerActionsImpl
> --
>
> Key: NETBEANS-1834
> URL: https://issues.apache.org/jira/browse/NETBEANS-1834
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Explorer
>Affects Versions: 8.2
>Reporter: Rangi Keen
>Priority: Minor
> Labels: pull-request-available
> Fix For: Next
>
> Attachments: ExplorerActionsImpl.Race.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{ExplorerActionsImpl}} uses a background thread to determine the enabled
> state of its actions. The background thread calls
> {{ExplorerActionsImpl.BaseAction.toEnabled(boolean)}} to set the target state
> from the background thread and then queues up a call on the {{EventQueue}} to
> be run on the EDT that calls {{ExplorerActionsImpl.BaseAction.syncEnable()}}
> which calls {{setEnabled}} if {{toEnable}} is non-null.
> However, since the check for {{toEnable != null}}, the use of {{toEnable}} in
> the call to {{setEnabled}}, and the set of {{toEnable = null}} are all on
> separate lines there is the possibility that another call to
> {{toEnabled(boolean)}} will set {{toEnable}} after the call to {{setEnabled}}
> but before it is reset to null. The end result is that if the new value of
> {{toEnable}} was different from the one being acted upon, the action may end
> up in the wrong state.
> One solution (in [^ExplorerActionsImpl.Race.patch]) is to use an
> {{AtomicInteger}} to get the value of {{toEnable}} and set it to null (or
> {{NO_CHANGE}}) atomically, thus avoiding the race condition.
> I don't have a reproducible case in the NetBeans IDE, but we encountered this
> in our custom application using the NetBeans platform. The attached patch
> solved the issue in our case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-1834) Possible race condition in ExplorerActionsImpl
[
https://issues.apache.org/jira/browse/NETBEANS-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729731#comment-16729731
]
Rangi Keen commented on NETBEANS-1834:
--
Created [pull request
#1058|https://github.com/apache/incubator-netbeans/pull/1058].
> Possible race condition in ExplorerActionsImpl
> --
>
> Key: NETBEANS-1834
> URL: https://issues.apache.org/jira/browse/NETBEANS-1834
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Explorer
>Affects Versions: 8.2
>Reporter: Rangi Keen
>Assignee: Rangi Keen
>Priority: Minor
> Attachments: ExplorerActionsImpl.Race.patch
>
>
> {{ExplorerActionsImpl}} uses a background thread to determine the enabled
> state of its actions. The background thread calls
> {{ExplorerActionsImpl.BaseAction.toEnabled(boolean)}} to set the target state
> from the background thread and then queues up a call on the {{EventQueue}} to
> be run on the EDT that calls {{ExplorerActionsImpl.BaseAction.syncEnable()}}
> which calls {{setEnabled}} if {{toEnable}} is non-null.
> However, since the check for {{toEnable != null}}, the use of {{toEnable}} in
> the call to {{setEnabled}}, and the set of {{toEnable = null}} are all on
> separate lines there is the possibility that another call to
> {{toEnabled(boolean)}} will set {{toEnable}} after the call to {{setEnabled}}
> but before it is reset to null. The end result is that if the new value of
> {{toEnable}} was different from the one being acted upon, the action may end
> up in the wrong state.
> One solution (in [^ExplorerActionsImpl.Race.patch]) is to use an
> {{AtomicInteger}} to get the value of {{toEnable}} and set it to null (or
> {{NO_CHANGE}}) atomically, thus avoiding the race condition.
> I don't have a reproducible case in the NetBeans IDE, but we encountered this
> in our custom application using the NetBeans platform. The attached patch
> solved the issue in our case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-1834) Possible race condition in ExplorerActionsImpl
[
https://issues.apache.org/jira/browse/NETBEANS-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rangi Keen reassigned NETBEANS-1834:
Assignee: Rangi Keen
> Possible race condition in ExplorerActionsImpl
> --
>
> Key: NETBEANS-1834
> URL: https://issues.apache.org/jira/browse/NETBEANS-1834
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Explorer
>Affects Versions: 8.2
>Reporter: Rangi Keen
>Assignee: Rangi Keen
>Priority: Minor
> Attachments: ExplorerActionsImpl.Race.patch
>
>
> {{ExplorerActionsImpl}} uses a background thread to determine the enabled
> state of its actions. The background thread calls
> {{ExplorerActionsImpl.BaseAction.toEnabled(boolean)}} to set the target state
> from the background thread and then queues up a call on the {{EventQueue}} to
> be run on the EDT that calls {{ExplorerActionsImpl.BaseAction.syncEnable()}}
> which calls {{setEnabled}} if {{toEnable}} is non-null.
> However, since the check for {{toEnable != null}}, the use of {{toEnable}} in
> the call to {{setEnabled}}, and the set of {{toEnable = null}} are all on
> separate lines there is the possibility that another call to
> {{toEnabled(boolean)}} will set {{toEnable}} after the call to {{setEnabled}}
> but before it is reset to null. The end result is that if the new value of
> {{toEnable}} was different from the one being acted upon, the action may end
> up in the wrong state.
> One solution (in [^ExplorerActionsImpl.Race.patch]) is to use an
> {{AtomicInteger}} to get the value of {{toEnable}} and set it to null (or
> {{NO_CHANGE}}) atomically, thus avoiding the race condition.
> I don't have a reproducible case in the NetBeans IDE, but we encountered this
> in our custom application using the NetBeans platform. The attached patch
> solved the issue in our case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-1836) Out of heap space removing large number of nodes
Rangi Keen created NETBEANS-1836:
Summary: Out of heap space removing large number of nodes
Key: NETBEANS-1836
URL: https://issues.apache.org/jira/browse/NETBEANS-1836
Project: NetBeans
Issue Type: Bug
Components: platform - Explorer
Affects Versions: 8.2
Reporter: Rangi Keen
Attachments: RemoveNodeOutOfHeapSpace.patch
If you remove a large number of selected nodes (e.g. 10,000), you may run out
of heap space. Note that this does not occur when deleting nodes because the
nodes are first deselected, but it will happen if the nodes to be removed are
not first deselected.
This seems to be related to [bug
#193852|https://netbeans.org/bugzilla/show_bug.cgi?id=193852] designed to
attempt to maintain cursor position when removing a node from the tree. Prior
to the change for this bug, the node parent was set to null when the node was
destroyed and therefore was not added to the list of nodes to be deselected in
{{org.openide.explorer.view.TreeView.removedNodes}}.
One fix (in [^RemoveNodeOutOfHeapSpace.patch]) is to change the check in
{{org.openide.explorer.view.TreeView.removedNodes}} when adding to the removed
selection list ({{remSel}}) to avoid adding paths for the nodes that will be
deleted and only add the selected child nodes. This was put in place to avoid
leaking memory for child nodes (see
[JDK-6472844|https://bugs.openjdk.java.net/browse/JDK-6472844]), so I think
this will maintain the intent and not result in further memory leaks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-1835) Difficult to choose from menu button in overflow toolbar
Rangi Keen created NETBEANS-1835: Summary: Difficult to choose from menu button in overflow toolbar Key: NETBEANS-1835 URL: https://issues.apache.org/jira/browse/NETBEANS-1835 Project: NetBeans Issue Type: Bug Components: platform - Window System Affects Versions: 9.0, 8.2 Reporter: Rangi Keen Attachments: ToolbarOverflow.patch Do the following to reproduce the issue: # Make the main window small enough so that some of the toolbars with associated dropdowns are hidden. This could be in the NetBeans IDE (or any platform based application). # Invoke the overflow toolbar and then invoke the dropdown from one of the buttons. For example, in the IDE, invoke the dropdown for the Profile Project action. # Move the mouse to select an item from the menu. If the mouse pointer moves outside the bounds of the overflow toolbar, even if it is inside the bounds of the dropdown, the toolbar will close along with the dropdown. When there is a dropdown open, the overflow toolbar should remain open, at least when the mouse is inside the bounds of the dropdown and probably also even when outside the bounds as is typically the case for menus. I've attached a possible solution (in [^ToolbarOverflow.patch]) that will keep the overflow toolbar open when a context menu invoked from one of the components in the toolbar is open. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-1834) Possible race condition in ExplorerActionsImpl
Rangi Keen created NETBEANS-1834:
Summary: Possible race condition in ExplorerActionsImpl
Key: NETBEANS-1834
URL: https://issues.apache.org/jira/browse/NETBEANS-1834
Project: NetBeans
Issue Type: Bug
Components: platform - Explorer
Affects Versions: 8.2
Reporter: Rangi Keen
Attachments: ExplorerActionsImpl.Race.patch
{{ExplorerActionsImpl}} uses a background thread to determine the enabled state
of its actions. The background thread calls
{{ExplorerActionsImpl.BaseAction.toEnabled(boolean)}} to set the target state
from the background thread and then queues up a call on the {{EventQueue}} to
be run on the EDT that calls {{ExplorerActionsImpl.BaseAction.syncEnable()}}
which calls {{setEnabled}} if {{toEnable}} is non-null.
However, since the check for {{toEnable != null}}, the use of {{toEnable}} in
the call to {{setEnabled}}, and the set of {{toEnable = null}} are all on
separate lines there is the possibility that another call to
{{toEnabled(boolean)}} will set {{toEnable}} after the call to {{setEnabled}}
but before it is reset to null. The end result is that if the new value of
{{toEnable}} was different from the one being acted upon, the action may end up
in the wrong state.
One solution (in [^ExplorerActionsImpl.Race.patch]) is to use an
{{AtomicInteger}} to get the value of {{toEnable}} and set it to null (or
{{NO_CHANGE}}) atomically, thus avoiding the race condition.
I don't have a reproducible case in the NetBeans IDE, but we encountered this
in our custom application using the NetBeans platform. The attached patch
solved the issue in our case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-1833) Typeahead selection in comboboxes only works when using lower case
[
https://issues.apache.org/jira/browse/NETBEANS-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rangi Keen updated NETBEANS-1833:
-
Attachment: (was: Typeahead.patch)
> Typeahead selection in comboboxes only works when using lower case
> --
>
> Key: NETBEANS-1833
> URL: https://issues.apache.org/jira/browse/NETBEANS-1833
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Property Editors
>Affects Versions: 8.2, 9.0
>Reporter: Rangi Keen
>Priority: Minor
> Attachments: Typeahead.patch
>
>
> In any combobox edited property, if any of the items contain upper case
> letters, typing the value in the property sheet will not match them unless
> you use all lowercase letters.
> As a specific example:
> # Create a new JFrame form in NetBeans
> # Select the cursor property. Note that the options all start with an upper
> case letter.
> # Start typing the text of an unselected value using an upper case letter
> (e.g. start typing "Wait Cursor").
> Note that the "Wait Cursor" item will not be selected. However, if you type
> "wait cursor" in lower case, the "Wait Cursor" item will be selected.
> Additionally, when an item is already selected in the middle of the list,
> typing a value should match items after that point. For example, in the
> cursor property example, if "Wait Cursor" is currently selected, typing
> "north" should match "Northwest Resize Cursor" because it follows "Wait
> Cursor" but it instead matches "North Resize Cursor" which comes before "Wait
> Cursor". This behavior would then match that implemented in standard combo
> box type-ahead matching (see
> {{javax.swing.JComboBox.DefaultKeySelectionManager.selectionForKey}}).
> See [^Typeahead.patch] for a possible update.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-1833) Typeahead selection in comboboxes only works when using lower case
[
https://issues.apache.org/jira/browse/NETBEANS-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rangi Keen updated NETBEANS-1833:
-
Attachment: Typeahead.patch
> Typeahead selection in comboboxes only works when using lower case
> --
>
> Key: NETBEANS-1833
> URL: https://issues.apache.org/jira/browse/NETBEANS-1833
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Property Editors
>Affects Versions: 8.2, 9.0
>Reporter: Rangi Keen
>Priority: Minor
> Attachments: Typeahead.patch
>
>
> In any combobox edited property, if any of the items contain upper case
> letters, typing the value in the property sheet will not match them unless
> you use all lowercase letters.
> As a specific example:
> # Create a new JFrame form in NetBeans
> # Select the cursor property. Note that the options all start with an upper
> case letter.
> # Start typing the text of an unselected value using an upper case letter
> (e.g. start typing "Wait Cursor").
> Note that the "Wait Cursor" item will not be selected. However, if you type
> "wait cursor" in lower case, the "Wait Cursor" item will be selected.
> Additionally, when an item is already selected in the middle of the list,
> typing a value should match items after that point. For example, in the
> cursor property example, if "Wait Cursor" is currently selected, typing
> "north" should match "Northwest Resize Cursor" because it follows "Wait
> Cursor" but it instead matches "North Resize Cursor" which comes before "Wait
> Cursor". This behavior would then match that implemented in standard combo
> box type-ahead matching (see
> {{javax.swing.JComboBox.DefaultKeySelectionManager.selectionForKey}}).
> See [^Typeahead.patch] for a possible update.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-1833) Typeahead selection in comboboxes only works when using lower case
Rangi Keen created NETBEANS-1833:
Summary: Typeahead selection in comboboxes only works when using
lower case
Key: NETBEANS-1833
URL: https://issues.apache.org/jira/browse/NETBEANS-1833
Project: NetBeans
Issue Type: Bug
Components: platform - Property Editors
Affects Versions: 9.0, 8.2
Reporter: Rangi Keen
Attachments: Typeahead.patch
In any combobox edited property, if any of the items contain upper case
letters, typing the value in the property sheet will not match them unless you
use all lowercase letters.
As a specific example:
# Create a new JFrame form in NetBeans
# Select the cursor property. Note that the options all start with an upper
case letter.
# Start typing the text of an unselected value using an upper case letter
(e.g. start typing "Wait Cursor").
Note that the "Wait Cursor" item will not be selected. However, if you type
"wait cursor" in lower case, the "Wait Cursor" item will be selected.
Additionally, when an item is already selected in the middle of the list,
typing a value should match items after that point. For example, in the cursor
property example, if "Wait Cursor" is currently selected, typing "north" should
match "Northwest Resize Cursor" because it follows "Wait Cursor" but it instead
matches "North Resize Cursor" which comes before "Wait Cursor". This behavior
would then match that implemented in standard combo box type-ahead matching
(see {{javax.swing.JComboBox.DefaultKeySelectionManager.selectionForKey}}).
See [^Typeahead.patch] for a possible update.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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
