[jira] [Created] (NETBEANS-997) Unable to download and create GlassFish server
Rick Hegarty created NETBEANS-997:
-
Summary: Unable to download and create GlassFish server
Key: NETBEANS-997
URL: https://issues.apache.org/jira/browse/NETBEANS-997
Project: NetBeans
Issue Type: Bug
Components: serverplugins - GlassFish
Affects Versions: 8.2, 9.0
Environment: Product Version: Apache NetBeans IDE Dev (Build
incubator-netbeans-release-302-on-20180517)
Updates: Updates available
Java: 1.8.0_172-ea; Java HotSpot(TM) 64-Bit Server VM 25.172-b03
Runtime: Java(TM) SE Runtime Environment 1.8.0_172-ea-b03
System: Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb)
User directory: C:\Users\johndoe\AppData\Roaming\NetBeans\dev
Cache directory: C:\Users\johndoe\AppData\Local\NetBeans\Cache\dev
Reporter: Rick Hegarty
Attachments: installGlassfish1.png, installGlassfish2.png
[1] Add a Glassfish server: *Services Panel > Servers >* right-click *> Add
Server... > GlassFish Server > Next >*
[2] On the *Add Server* screen:
* In *Installation Location* enter a valid directory name that does not exist.
* Check the _I have read_ checkbox.
* Click *Download Now...* and then select _Glassfish Server 4.1.1_ as the
server to be downloaded.
* See attached screenshot *installGlassfish1.png*
[3] The download appears to be successful but there is an error at the bottom
of the *Add Server Instance* window: *! Does not exist.* See attached
screenshot *installGlassfish2.png*
[4] The target folder does not get created. Also, if an empty target folder is
pre-created the same error occurs, and the target folder remains empty.
[5] This error occurs with both NB 8.2 and NB 9.0 RC1.
[6] Priority is minor since the simple workaround is to download Glassfish
first outside of NetBeans, and then select that downloaded folder within the
*Add Server* wizard.
[7] Possible duplicate of NETBEANS-965 ("does not load GlassFish"), but there
is no description for that bug and the screenshot information is in Russian.
--
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-996) java.util.regex.PatternSyntaxException: Unexpected internal error near index 7
chopin xiao created NETBEANS-996: Summary: java.util.regex.PatternSyntaxException: Unexpected internal error near index 7 Key: NETBEANS-996 URL: https://issues.apache.org/jira/browse/NETBEANS-996 Project: NetBeans Issue Type: Bug Reporter: chopin xiao \.idea\ ^ at java.base/java.util.regex.Pattern.error(Pattern.java:2010) at java.base/java.util.regex.Pattern.compile(Pattern.java:1779) at java.base/java.util.regex.Pattern.(Pattern.java:1422) at java.base/java.util.regex.Pattern.compile(Pattern.java:1082) at org.eclipse.jgit.ignore.internal.Strings.convertGlob(Strings.java:352) at org.eclipse.jgit.ignore.internal.WildCardMatcher.(WildCardMatcher.java:66) at org.eclipse.jgit.ignore.internal.PathMatcher.createNameMatcher0(PathMatcher.java:145) at org.eclipse.jgit.ignore.internal.PathMatcher.createPathMatcher(PathMatcher.java:127) at org.eclipse.jgit.ignore.FastIgnoreRule.(FastIgnoreRule.java:114) at org.eclipse.jgit.ignore.IgnoreNode.parse(IgnoreNode.java:114) at org.eclipse.jgit.treewalk.WorkingTreeIterator$PerDirectoryIgnoreNode.load(WorkingTreeIterator.java:1166) at org.eclipse.jgit.treewalk.WorkingTreeIterator.getIgnoreNode(WorkingTreeIterator.java:625) at org.eclipse.jgit.treewalk.WorkingTreeIterator.isEntryIgnored(WorkingTreeIterator.java:593) at org.eclipse.jgit.treewalk.WorkingTreeIterator.isEntryIgnored(WorkingTreeIterator.java:576) at org.eclipse.jgit.treewalk.WorkingTreeIterator.isEntryIgnored(WorkingTreeIterator.java:563) at org.netbeans.libs.git.jgit.commands.StatusCommand.run(StatusCommand.java:182) at org.netbeans.libs.git.jgit.commands.GitCommand$1.run(GitCommand.java:57) at org.netbeans.libs.git.jgit.commands.GitCommand$1.run(GitCommand.java:54) at java.base/java.security.AccessController.doPrivileged(Native Method) at org.netbeans.libs.git.jgit.commands.GitCommand.execute(GitCommand.java:54) at org.netbeans.libs.git.GitClient.getStatus(GitClient.java:737) at org.netbeans.modules.git.client.GitClient$26.call(GitClient.java:477) at org.netbeans.modules.git.client.GitClient$26.call(GitClient.java:473) at org.netbeans.modules.git.client.GitClient$CommandInvoker$1$1.call(GitClient.java:933) at org.netbeans.modules.git.client.GitClient$CommandInvoker$1.call(GitClient.java:956) at org.netbeans.modules.git.client.GitClient$CommandInvoker.runMethodIntern(GitClient.java:968) at org.netbeans.modules.git.client.GitClient$CommandInvoker.runMethod(GitClient.java:897) at org.netbeans.modules.git.client.GitClient$CommandInvoker.access$300(GitClient.java:869) at org.netbeans.modules.git.client.GitClient.getStatus(GitClient.java:473) at org.netbeans.modules.git.client.GitClient.getStatus(GitClient.java:469) at org.netbeans.modules.git.FileStatusCache.refreshAllRoots(FileStatusCache.java:210) at org.netbeans.modules.git.FileStatusCache.refreshAllRoots(FileStatusCache.java:170) at org.netbeans.modules.git.FilesystemInterceptor$RefreshTask.run(FilesystemInterceptor.java:669) Caused: org.openide.util.RequestProcessor$SlowItem: task failed due to at org.openide.util.RequestProcessor$Task.schedule(RequestProcessor.java:1459) at org.netbeans.modules.git.FilesystemInterceptor.reScheduleRefresh(FilesystemInterceptor.java:755) at org.netbeans.modules.git.FilesystemInterceptor.access$3300(FilesystemInterceptor.java:73) at org.netbeans.modules.git.FilesystemInterceptor$GitFolderEventsHandler.initializeFiles(FilesystemInterceptor.java:1023) at org.netbeans.modules.git.FilesystemInterceptor$GitFolderEventsHandler.access$2500(FilesystemInterceptor.java:842) at org.netbeans.modules.git.FilesystemInterceptor$GitFolderEventsHandler$1.run(FilesystemInterceptor.java:854) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418) at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45) at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278) [catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033) -- 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-867) Refactoring popup does not close
[ https://issues.apache.org/jira/browse/NETBEANS-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chopin xiao reassigned NETBEANS-867: Assignee: (was: chopin xiao) > Refactoring popup does not close > > > Key: NETBEANS-867 > URL: https://issues.apache.org/jira/browse/NETBEANS-867 > Project: NetBeans > Issue Type: Bug > Components: php - Refactoring >Affects Versions: 8.2 > Environment: Product Version: NetBeans IDE 8.2 (Build 201609300101) > Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2 > Java: 1.8.0_171; OpenJDK 64-Bit Server VM 25.171-b10 > Runtime: OpenJDK Runtime Environment 1.8.0_171-b10 > System: Linux version 4.16.11-200.fc27.x86_64 running on amd64; UTF-8; en_US > (nb) > User directory: /home/chopin/.netbeans/8.2 > Cache directory: /home/chopin/.cache/netbeans/8.2 >Reporter: chopin xiao >Priority: Major > Attachments: 2018-05-27 11-30-21屏幕截图.png > > > when refactor-rename php code many times, the refactoring popup box will does > not close > This issue reproduce only while refactor after many times, may be after > refactor three times reproduce > like below unsolve bug: > [https://netbeans.org/bugzilla/show_bug.cgi?id=252972] > [https://netbeans.org/bugzilla/show_bug.cgi?id=258261] > [https://netbeans.org/bugzilla/show_bug.cgi?id=268493] -- 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-867) Refactoring popup does not close
[ https://issues.apache.org/jira/browse/NETBEANS-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chopin xiao reassigned NETBEANS-867: Assignee: chopin xiao > Refactoring popup does not close > > > Key: NETBEANS-867 > URL: https://issues.apache.org/jira/browse/NETBEANS-867 > Project: NetBeans > Issue Type: Bug > Components: php - Refactoring >Affects Versions: 8.2 > Environment: Product Version: NetBeans IDE 8.2 (Build 201609300101) > Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2 > Java: 1.8.0_171; OpenJDK 64-Bit Server VM 25.171-b10 > Runtime: OpenJDK Runtime Environment 1.8.0_171-b10 > System: Linux version 4.16.11-200.fc27.x86_64 running on amd64; UTF-8; en_US > (nb) > User directory: /home/chopin/.netbeans/8.2 > Cache directory: /home/chopin/.cache/netbeans/8.2 >Reporter: chopin xiao >Assignee: chopin xiao >Priority: Major > Attachments: 2018-05-27 11-30-21屏幕截图.png > > > when refactor-rename php code many times, the refactoring popup box will does > not close > This issue reproduce only while refactor after many times, may be after > refactor three times reproduce > like below unsolve bug: > [https://netbeans.org/bugzilla/show_bug.cgi?id=252972] > [https://netbeans.org/bugzilla/show_bug.cgi?id=258261] > [https://netbeans.org/bugzilla/show_bug.cgi?id=268493] -- 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-994) NetBeans deletes remote files, when local project-file-location gets offline
Heli Ammann created NETBEANS-994: Summary: NetBeans deletes remote files, when local project-file-location gets offline Key: NETBEANS-994 URL: https://issues.apache.org/jira/browse/NETBEANS-994 Project: NetBeans Issue Type: Bug Components: apisupport - Project, projects - Generic Infrastructure Affects Versions: 8.2 Reporter: Heli Ammann Product Version = NetBeans IDE 8.2 (Build 201705191307) Operating System = Windows 7 version 6.1 running on amd64 Java; VM; Vendor = 1.8.0_101 Runtime = Java HotSpot(TM) 64-Bit Server VM 25.101-b13 STEPS: * Open project-files from a local fileserver * Configure Remote Connection with "Upload Files = On Save" * Disconnect connection to local fileserver ACTUAL: NetBeans begins to delete all files on the remote connection -> website is destroyed EXPECTED: NetBeans checks if project-file-location is available, bevore deleting remote files -- 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-980) Home/end/up/down do not work properly when word wrapping is enabled
[ https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated NETBEANS-980: Labels: pull-request-available (was: ) > Home/end/up/down do not work properly when word wrapping is enabled > --- > > Key: NETBEANS-980 > URL: https://issues.apache.org/jira/browse/NETBEANS-980 > Project: NetBeans > Issue Type: Bug > Components: editor - Other, editor - Painting & Printing >Affects Versions: 9.0 >Reporter: Eirik Bakke >Priority: Major > Labels: pull-request-available > > Caret movements via Home/End and arrow Up/Down keys do not work properly when > text wrap (especially in "after words" mode) is enabled in the NetBeans > editor. > Specific bugs: > 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the > beginning of the paragraph rather than to the beginning of the current wrap > line (physical line). > 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the > beginning of the next wrap line instead of to the end of the current wrap > line. > 3) Pressing Up has no effect if the preceding wrap line ended before the > caret's current X position. > 4) Pressing Down will move the caret down _two_ lines if the following wrap > line ended before the caret's current X position (and assuming the wrap line > two lines down is long enough). > 5) Left-clicking the mouse to the right of the end of a wrap line puts the > caret on the beginning of the next wrap line rather than at the end of the > current (clicked) wrap line. > The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit > (UpAction/DownAction/BeginLineAction/EndLineAction). > Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and > is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to > move the caret before lineStartPos.) > Bugs 2-5 above all relate to what caret position is mapped to the "infinite" > horizontal space that follows each wrap line. With NetBeans' current > behavior, this space corresponds to a caret position directly following the > last character of a wrap line. This caret position, however, is physically > mapped (and painted) on the beginning of the following wrap line, which > confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 > is fixed, then bugs 2-4 might "fix themselves" as well. > For bug 5, I think the best solution when clicking the space beyond the end > of a wrap line would be to move the caret to right _before_ the last > character on the wrap line. This character is usually a space (in word wrap > mode), though it could also be a hyphen or such if a more advanced word > wrapping algorithm is used (proposed in the pull request for NETBEANS-977). > The resulting behavior would be similar to that of a default JTextArea, or > jEdit (though these never break words on anything else than a space). Another > solution would be to do like the TextEdit app on MacOS, where the cursor is > placed _after_ the last character on the wrap line, like NetBeans currently > does, but with a backwards bias such that the cursor is painted on the end of > the current wrap line instead of on the beginning of the next wrap line. The > latter is probably harder to implement, and is not really necessary. > To test the above bugs: > 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and > set "Line Wrap" to "After words". Click OK. > 2) Create a new plain text file and paste in the paragraph "SHORTWORD > LONGWORD SHORTWORD LUUUNGWORD". > 3) Resize the editor window so that the paragraph gets split into four wrap > lines (one word on each wrap line--i.e. make the editor a little wider than > the long word). > 4) For each bugs 1-4 listed above, position the caret right after > "...ONG", then press the relevant key to test. > 5) To test bug 5 above, click the mouse to the right of the first, second, or > third wrap line. > Tested in NetBeans 9.0 rc1. -- 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-956) Position / Color of SplashScreen ProgressBar/Text is broken with new branding
[ https://issues.apache.org/jira/browse/NETBEANS-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522807#comment-16522807 ] Sven Reimers commented on NETBEANS-956: --- PR for master https://github.com/apache/incubator-netbeans/pull/602 > Position / Color of SplashScreen ProgressBar/Text is broken with new branding > - > > Key: NETBEANS-956 > URL: https://issues.apache.org/jira/browse/NETBEANS-956 > Project: NetBeans > Issue Type: Bug > Components: ide - UI >Affects Versions: 9.0 >Reporter: Sven Reimers >Assignee: Sven Reimers >Priority: Major > Labels: branding, pull-request-available > Attachments: NewProgressBarAndTextBranding.png, > fix-progress-bar-and-text.diff > > Time Spent: 50m > Remaining Estimate: 0h > > With change of the splash screen the other bits and pieces do not fit that > well anymore. > Attached is a diff and a screenshot of a probable solution. -- 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-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522770#comment-16522770 ] Thierry Danard commented on NETBEANS-798: - I am not the original poster, others might have a different use case. For my particular example, it's all lighweight/swing components. I agree this is not a critical issue from a NetBeans release point of view. > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug > Components: platform - JDK Problems >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Labels: Windows10 > Attachments: Snipping tool issue.mov, b0.PNG, hs_err_pid10608.log, > hs_err_pid7492.log, hs_err_pid7920.log > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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-931) OutOfMemory after a night of stand-by
[ https://issues.apache.org/jira/browse/NETBEANS-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522753#comment-16522753 ] Laszlo Kishalmi commented on NETBEANS-931: -- Could we get a Heapdump before you stop using the IDE and another one next morning (or when the crash happens.)? > OutOfMemory after a night of stand-by > - > > Key: NETBEANS-931 > URL: https://issues.apache.org/jira/browse/NETBEANS-931 > Project: NetBeans > Issue Type: Bug >Affects Versions: 9.0 >Reporter: Luca Mambretti >Priority: Critical > Attachments: messages.log, uigestures.xml > > > After a full day of work I left the system running (it had manifested the > errors described in NETBEANS-901). > > The day after it was out of commission with OOM. > > attached IDE logs and gestures, I also have the heap dump but it's 1.5 gigs > so I doubt I'll be able to attach it (sent it thru a WeTransfer link for now) -- 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-931) OutOfMemory after a night of stand-by
[ https://issues.apache.org/jira/browse/NETBEANS-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522739#comment-16522739 ] Laszlo Kishalmi commented on NETBEANS-931: -- Got it. It seems somewhere we have a serious leak on WeakListener. The heapdump says we have more than 10 million of org.openide.util.WeakListenerImpl$ListenerReference eating up 640 Mb of heap. Could you provide the IDE build and git commit number as well? It's in the Help -> About dialog. > OutOfMemory after a night of stand-by > - > > Key: NETBEANS-931 > URL: https://issues.apache.org/jira/browse/NETBEANS-931 > Project: NetBeans > Issue Type: Bug >Affects Versions: 9.0 >Reporter: Luca Mambretti >Priority: Critical > Attachments: messages.log, uigestures.xml > > > After a full day of work I left the system running (it had manifested the > errors described in NETBEANS-901). > > The day after it was out of commission with OOM. > > attached IDE logs and gestures, I also have the heap dump but it's 1.5 gigs > so I doubt I'll be able to attach it (sent it thru a WeTransfer link for now) -- 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-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522735#comment-16522735 ] Laszlo Kishalmi commented on NETBEANS-798: -- As I see it is a desktop application built on NetBeans Platform. Could it happen that you might use heavyweight (java.awt) or custom components in your application? I'm going to close this issue, as if the message log is empty regarding the crash then it is outside of our reach. Try to check it under Linux or Mac if windows fails. I only could wish you guys the bests, but we are sorry this is really out of our reach. > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug > Components: platform - JDK Problems >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Labels: Windows10 > Attachments: Snipping tool issue.mov, b0.PNG, hs_err_pid10608.log, > hs_err_pid7492.log, hs_err_pid7920.log > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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] [Closed] (NETBEANS-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laszlo Kishalmi closed NETBEANS-798. Resolution: Information Provided > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug > Components: platform - JDK Problems >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Labels: Windows10 > Attachments: Snipping tool issue.mov, b0.PNG, hs_err_pid10608.log, > hs_err_pid7492.log, hs_err_pid7920.log > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laszlo Kishalmi updated NETBEANS-798: - Component/s: platform - JDK Problems > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug > Components: platform - JDK Problems >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Labels: Windows10 > Attachments: Snipping tool issue.mov, b0.PNG, hs_err_pid10608.log, > hs_err_pid7492.log, hs_err_pid7920.log > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522710#comment-16522710 ] Thierry Danard commented on NETBEANS-798: - There are no messages.log created when the JVM crashes, just the JVM logs. I have attached a video of the crash to explain how it is reproduced. I doesn't happen each time. > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Labels: Windows10 > Attachments: Snipping tool issue.mov, b0.PNG, hs_err_pid10608.log, > hs_err_pid7492.log, hs_err_pid7920.log > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thierry Danard updated NETBEANS-798: Attachment: Snipping tool issue.mov > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Labels: Windows10 > Attachments: Snipping tool issue.mov, b0.PNG, hs_err_pid10608.log, > hs_err_pid7492.log, hs_err_pid7920.log > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522687#comment-16522687 ] Laszlo Kishalmi commented on NETBEANS-798: -- The messages.log would be useful. Though I fear this issue happens due to some JavaVM and Windows disagreement. As it happens with all 8,9 and 10 Java VMs you either hit a long standing bug in the windows Java runtime or your windows is somehow not in the "right state", whatever could that mean. Still the messages.log could tell more. > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Labels: Windows10 > Attachments: b0.PNG, hs_err_pid10608.log, hs_err_pid7492.log, > hs_err_pid7920.log > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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-781) java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 in build-impl.xml
[
https://issues.apache.org/jira/browse/NETBEANS-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522576#comment-16522576
]
Emilian Bold commented on NETBEANS-781:
---
Created review for patch https://reviews.apache.org/r/67721/
> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 in
> build-impl.xml
> --
>
> Key: NETBEANS-781
> URL: https://issues.apache.org/jira/browse/NETBEANS-781
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Ant Project
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-285-on-20180502)
> Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
> Runtime: Java(TM) SE Runtime Environment 10.0.1+10
> System: Linux version 4.15.0-20-generic running on amd64; UTF-8; en_US (nb)
>Reporter: Simon IJskes
>Assignee: Emilian Bold
>Priority: Major
> Labels: pull-request-available
> Attachments: JavaApplication10.zip
>
> Time Spent: 4h 2m
> Remaining Estimate: 0h
>
> When i build a project (target jar) with do.depend=true (in
> project.properties or private.properties) for a second time after clean, the
> following is thrown:
> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19
> at
> org.apache.tools.ant.taskdefs.optional.depend.constantpool.ConstantPoolEntry.readEntry(ConstantPoolEntry.java:180)
> This is in the depend macro:
> excludes="${excludes}" includes="${includes}" srcdir="@\{srcdir}">
>
>
>
>
>
> project properties:
> javac.source=10
> javac.target=10
> platform.active=JDK_10
> The exception is thrown direct after opening build/classes/module-info.class
--
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-781) java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 in build-impl.xml
[
https://issues.apache.org/jira/browse/NETBEANS-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522522#comment-16522522
]
Emilian Bold commented on NETBEANS-781:
---
OK, I have
https://hg.netbeans.org/binaries/D6330851B59C33A3A8D98C86FF438F23DD3B4267-ant-misc-1.10.4.zip
let me make a PR.
> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 in
> build-impl.xml
> --
>
> Key: NETBEANS-781
> URL: https://issues.apache.org/jira/browse/NETBEANS-781
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Ant Project
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-285-on-20180502)
> Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
> Runtime: Java(TM) SE Runtime Environment 10.0.1+10
> System: Linux version 4.15.0-20-generic running on amd64; UTF-8; en_US (nb)
>Reporter: Simon IJskes
>Assignee: Emilian Bold
>Priority: Major
> Labels: pull-request-available
> Attachments: JavaApplication10.zip
>
> Time Spent: 4h 2m
> Remaining Estimate: 0h
>
> When i build a project (target jar) with do.depend=true (in
> project.properties or private.properties) for a second time after clean, the
> following is thrown:
> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19
> at
> org.apache.tools.ant.taskdefs.optional.depend.constantpool.ConstantPoolEntry.readEntry(ConstantPoolEntry.java:180)
> This is in the depend macro:
> excludes="${excludes}" includes="${includes}" srcdir="@\{srcdir}">
>
>
>
>
>
> project properties:
> javac.source=10
> javac.target=10
> platform.active=JDK_10
> The exception is thrown direct after opening build/classes/module-info.class
--
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-990) Creating a new NetBeans Project from template has the old branding.
[ https://issues.apache.org/jira/browse/NETBEANS-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated NETBEANS-990: Labels: branding pull-request-available (was: branding) > Creating a new NetBeans Project from template has the old branding. > --- > > Key: NETBEANS-990 > URL: https://issues.apache.org/jira/browse/NETBEANS-990 > Project: NetBeans > Issue Type: Bug > Components: apisupport - Project >Affects Versions: 9.0 >Reporter: Laszlo Kishalmi >Priority: Major > Labels: branding, pull-request-available > -- 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-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522456#comment-16522456 ] Eduardo Quintanilla commented on NETBEANS-798: -- Could you share the contents of IDE Log (View => IDE Log)? %APPDATA%\Roaming\NetBeans\8.2\var\log\messages.log > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Labels: Windows10 > Attachments: b0.PNG, hs_err_pid10608.log, hs_err_pid7492.log, > hs_err_pid7920.log > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522452#comment-16522452 ] Thierry Danard commented on NETBEANS-798: - hs_err_pid7920.log is the log with Java 10. So far, we could only reproduce this issue with the snipping tool, but we'll try with other tools. > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Labels: Windows10 > Attachments: b0.PNG, hs_err_pid10608.log, hs_err_pid7492.log, > hs_err_pid7920.log > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thierry Danard updated NETBEANS-798: Attachment: hs_err_pid7920.log > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Labels: Windows10 > Attachments: b0.PNG, hs_err_pid10608.log, hs_err_pid7492.log, > hs_err_pid7920.log > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thierry Danard updated NETBEANS-798: Attachment: hs_err_pid10608.log > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Labels: Windows10 > Attachments: b0.PNG, hs_err_pid10608.log, hs_err_pid7492.log > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522409#comment-16522409 ] Geertjan Wielenga commented on NETBEANS-798: The question is also whether the snipping tools are the only tools you can use for what it is you're doing and whether using some other tool that does the same thing causes the same problem. > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Labels: Windows10 > Attachments: b0.PNG, hs_err_pid7492.log > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522405#comment-16522405 ] Thierry Danard commented on NETBEANS-798: - I have attached the crash logs on Java 8. I am working on getting the same error logs on Java 9 and 10 > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Labels: Windows10 > Attachments: b0.PNG, hs_err_pid7492.log > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thierry Danard updated NETBEANS-798: Attachment: hs_err_pid7492.log > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Labels: Windows10 > Attachments: b0.PNG, hs_err_pid7492.log > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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-993) Template Wizard ignores folder selection sometimes
Svatopluk Dedic created NETBEANS-993: Summary: Template Wizard ignores folder selection sometimes Key: NETBEANS-993 URL: https://issues.apache.org/jira/browse/NETBEANS-993 Project: NetBeans Issue Type: Bug Components: platform - Data Systems Reporter: Svatopluk Dedic Assignee: Svatopluk Dedic The template wizard allows to select a folder where the template is instantiated. If the user selects the target folder using the file list (i.e. doubleclicks the folder name), everything seems to be OK - the custom PropertyEditor calls setValue --> setTargetFolder on the wizard panel. But I don't see such a call if the user selects a (parent) folder using the combobox above the file list. Note that if the user first selects a parent from the dropdown, then picks some child (i.e. sibling of the original), the template wizard will use the appropriate value. To reproduce: invoke new from template from some folder. Select some of the parents from the drop down. check that "Look in" edit box indeed changed the folder's name. Press Finish. The file will be created in the folder originally selected, not the current one. -- 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-992) Exception when singlestep debugging
Jacco van Weert created NETBEANS-992: Summary: Exception when singlestep debugging Key: NETBEANS-992 URL: https://issues.apache.org/jira/browse/NETBEANS-992 Project: NetBeans Issue Type: Bug Reporter: Jacco van Weert java.lang.AssertionError: Debugger lock taken in AWT Event Queue! at org.netbeans.modules.debugger.jpda.JPDADebuggerImpl$DebuggerReentrantReadWriteLock$DebuggerReadLock.lock(JPDADebuggerImpl.java:2675) at org.netbeans.modules.debugger.jpda.models.JPDAThreadImpl$ThreadReentrantReadWriteLock$ThreadWriteLock.lock(JPDAThreadImpl.java:2555) at org.netbeans.modules.debugger.jpda.JPDADebuggerImpl.invokeMethod(JPDADebuggerImpl.java:1066) at org.netbeans.modules.debugger.jpda.JPDADebuggerImpl.invokeMethod(JPDADebuggerImpl.java:1008) at org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.getToStringValue(AbstractObjectVariable.java:496) at org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.getToStringValue(AbstractObjectVariable.java:460) at org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.getToStringValue(AbstractObjectVariable.java:424) at org.netbeans.modules.debugger.jpda.ui.models.VariablesTableModel.getValueAt(VariablesTableModel.java:108) at org.netbeans.spi.viewmodel.Models$DelegatingTableModel.getValueAt(Models.java:2249) at org.netbeans.modules.debugger.jpda.ui.models.NumericDisplayFilter.getValueAt(NumericDisplayFilter.java:112) at org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1439) at org.netbeans.modules.debugger.jpda.ui.models.VariablesTreeModelFilter.getValueAt(VariablesTreeModelFilter.java:530) at org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1439) at org.netbeans.modules.debugger.jpda.ui.models.PendingActionsFilter.getValueAt(PendingActionsFilter.java:108) at org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1439) at org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1441) at org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1441) at org.netbeans.spi.viewmodel.Models$CompoundModel.getValueAt(Models.java:4566) at org.netbeans.modules.viewmodel.TreeModelNode$MyProperty.updateShortDescription(TreeModelNode.java:2102) at org.netbeans.modules.viewmodel.TreeModelNode$MyProperty.getShortDescription(TreeModelNode.java:2084) at org.openide.explorer.view.SheetCell.getTableCellRendererComponent(SheetCell.java:276) at org.openide.explorer.view.SheetCell$OutlineSheetCell.getTableCellRendererComponent(SheetCell.java:737) at org.netbeans.modules.viewmodel.DelegatingCellRenderer.getTableCellRendererComponent(DelegatingCellRenderer.java:66) at javax.swing.JTable.prepareRenderer(JTable.java:5723) at org.netbeans.swing.outline.Outline.getToolTipText(Outline.java:393) at javax.swing.ToolTipManager$insideTimerAction.actionPerformed(ToolTipManager.java:663) at javax.swing.Timer.fireActionPerformed(Timer.java:313) at javax.swing.Timer$DoPostEvent.run(Timer.java:245) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:709) at java.awt.EventQueue$3.run(EventQueue.java:703) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) at java.awt.EventQueue.dispatchEvent(EventQueue.java:728) at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:136) [catch] at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) -- 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] [Issue Comment Deleted] (NETBEANS-781) java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 in build-impl.xml
[
https://issues.apache.org/jira/browse/NETBEANS-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon IJskes updated NETBEANS-781:
--
Comment: was deleted
(was: i think it was already maven based.)
> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 in
> build-impl.xml
> --
>
> Key: NETBEANS-781
> URL: https://issues.apache.org/jira/browse/NETBEANS-781
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Ant Project
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-285-on-20180502)
> Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
> Runtime: Java(TM) SE Runtime Environment 10.0.1+10
> System: Linux version 4.15.0-20-generic running on amd64; UTF-8; en_US (nb)
>Reporter: Simon IJskes
>Assignee: Emilian Bold
>Priority: Major
> Labels: pull-request-available
> Attachments: JavaApplication10.zip
>
> Time Spent: 4h 2m
> Remaining Estimate: 0h
>
> When i build a project (target jar) with do.depend=true (in
> project.properties or private.properties) for a second time after clean, the
> following is thrown:
> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19
> at
> org.apache.tools.ant.taskdefs.optional.depend.constantpool.ConstantPoolEntry.readEntry(ConstantPoolEntry.java:180)
> This is in the depend macro:
> excludes="${excludes}" includes="${includes}" srcdir="@\{srcdir}">
>
>
>
>
>
> project properties:
> javac.source=10
> javac.target=10
> platform.active=JDK_10
> The exception is thrown direct after opening build/classes/module-info.class
--
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-781) java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 in build-impl.xml
[
https://issues.apache.org/jira/browse/NETBEANS-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522187#comment-16522187
]
Simon IJskes commented on NETBEANS-781:
---
i think it was already maven based.
> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 in
> build-impl.xml
> --
>
> Key: NETBEANS-781
> URL: https://issues.apache.org/jira/browse/NETBEANS-781
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Ant Project
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-285-on-20180502)
> Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
> Runtime: Java(TM) SE Runtime Environment 10.0.1+10
> System: Linux version 4.15.0-20-generic running on amd64; UTF-8; en_US (nb)
>Reporter: Simon IJskes
>Assignee: Emilian Bold
>Priority: Major
> Labels: pull-request-available
> Attachments: JavaApplication10.zip
>
> Time Spent: 4h 2m
> Remaining Estimate: 0h
>
> When i build a project (target jar) with do.depend=true (in
> project.properties or private.properties) for a second time after clean, the
> following is thrown:
> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19
> at
> org.apache.tools.ant.taskdefs.optional.depend.constantpool.ConstantPoolEntry.readEntry(ConstantPoolEntry.java:180)
> This is in the depend macro:
> excludes="${excludes}" includes="${includes}" srcdir="@\{srcdir}">
>
>
>
>
>
> project properties:
> javac.source=10
> javac.target=10
> platform.active=JDK_10
> The exception is thrown direct after opening build/classes/module-info.class
--
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-991) requestAttention() not working on macOS Sierra
[ https://issues.apache.org/jira/browse/NETBEANS-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ionut Enescu updated NETBEANS-991: -- Description: Calling requestAttention() on a TopComponent works as expected on Win7 x64 and Ubuntu 16.04, but not on macOS Sierra (10.12.6). There's no error message or any indication that something went wrong in the execution. was: Calling requestAttention() on a TopComponent works as expected on Win7 x64 and Ubuntu 16.04, but not on macOS Sierra (10.12.6). > requestAttention() not working on macOS Sierra > -- > > Key: NETBEANS-991 > URL: https://issues.apache.org/jira/browse/NETBEANS-991 > Project: NetBeans > Issue Type: Bug > Components: ide - UI >Affects Versions: 8.2 > Environment: macOS Sierra (10.12.6). > JDK 1.8u121 > Netbeans 8.2 >Reporter: Ionut Enescu >Priority: Major > > Calling requestAttention() on a TopComponent works as expected on Win7 x64 > and Ubuntu 16.04, but not on macOS Sierra (10.12.6). There's no error message > or any indication that something went wrong in the execution. > -- 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-991) requestAttention() not working on macOS Sierra
Ionut Enescu created NETBEANS-991: - Summary: requestAttention() not working on macOS Sierra Key: NETBEANS-991 URL: https://issues.apache.org/jira/browse/NETBEANS-991 Project: NetBeans Issue Type: Bug Components: ide - UI Affects Versions: 8.2 Environment: macOS Sierra (10.12.6). JDK 1.8u121 Netbeans 8.2 Reporter: Ionut Enescu Calling requestAttention() on a TopComponent works as expected on Win7 x64 and Ubuntu 16.04, but not on macOS Sierra (10.12.6). -- 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-781) java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 in build-impl.xml
[
https://issues.apache.org/jira/browse/NETBEANS-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522179#comment-16522179
]
Emilian Bold commented on NETBEANS-781:
---
OK, let me see how to do this step: "updating the ant-misc zip and uploading it
to hg.netbeans.org/binaries".
I see the Ant guys were busy reformatting shell scripts so the files in
ant-misc need updating. I suspect the existing ant-misc might be sufficient but
I want to keep these in sync.
> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 in
> build-impl.xml
> --
>
> Key: NETBEANS-781
> URL: https://issues.apache.org/jira/browse/NETBEANS-781
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Ant Project
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-285-on-20180502)
> Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
> Runtime: Java(TM) SE Runtime Environment 10.0.1+10
> System: Linux version 4.15.0-20-generic running on amd64; UTF-8; en_US (nb)
>Reporter: Simon IJskes
>Assignee: Emilian Bold
>Priority: Major
> Labels: pull-request-available
> Attachments: JavaApplication10.zip
>
> Time Spent: 4h 2m
> Remaining Estimate: 0h
>
> When i build a project (target jar) with do.depend=true (in
> project.properties or private.properties) for a second time after clean, the
> following is thrown:
> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19
> at
> org.apache.tools.ant.taskdefs.optional.depend.constantpool.ConstantPoolEntry.readEntry(ConstantPoolEntry.java:180)
> This is in the depend macro:
> excludes="${excludes}" includes="${includes}" srcdir="@\{srcdir}">
>
>
>
>
>
> project properties:
> javac.source=10
> javac.target=10
> platform.active=JDK_10
> The exception is thrown direct after opening build/classes/module-info.class
--
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-862) Autocomplete for var keyword not supported in Lambda parameter
[ https://issues.apache.org/jira/browse/NETBEANS-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated NETBEANS-862: Labels: JDK11-VarInLambda pull-request-available (was: JDK11-VarInLambda) > Autocomplete for var keyword not supported in Lambda parameter > -- > > Key: NETBEANS-862 > URL: https://issues.apache.org/jira/browse/NETBEANS-862 > Project: NetBeans > Issue Type: Bug >Reporter: ARUNAVA SINHA >Assignee: ARUNAVA SINHA >Priority: Minor > Labels: JDK11-VarInLambda, pull-request-available > > Auto-complete(CTL+ space) for var keyword in not happening in Lambda > parameter (JDK-11). Cursor is at caret position. > IntBinaryOperator calc2 = (var x, ^ y ) -> x+y; > -- 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-862) Autocomplete for var keyword not supported in Lambda parameter
[ https://issues.apache.org/jira/browse/NETBEANS-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ARUNAVA SINHA updated NETBEANS-862: --- Description: Auto-complete(CTL+ space) for var keyword in not happening in Lambda parameter (JDK-11). Cursor is at caret position. IntBinaryOperator calc2 = (var x, ^ y ) -> x+y; was: Auto-complete for var keyword in not happening in Lambda parameter (JDK-11). Cursor is at caret position. IntBinaryOperator calc2 = (var x, ^ y ) -> x+y; > Autocomplete for var keyword not supported in Lambda parameter > -- > > Key: NETBEANS-862 > URL: https://issues.apache.org/jira/browse/NETBEANS-862 > Project: NetBeans > Issue Type: Bug >Reporter: ARUNAVA SINHA >Assignee: ARUNAVA SINHA >Priority: Minor > Labels: JDK11-VarInLambda > > Auto-complete(CTL+ space) for var keyword in not happening in Lambda > parameter (JDK-11). Cursor is at caret position. > IntBinaryOperator calc2 = (var x, ^ y ) -> x+y; > -- 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-862) Autocomplete for var keyword not supported in Lambda parameter
[ https://issues.apache.org/jira/browse/NETBEANS-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ARUNAVA SINHA updated NETBEANS-862: --- Description: Auto-complete for var keyword in not happening in Lambda parameter (JDK-11). Cursor is at caret position. IntBinaryOperator calc2 = (var x, ^ y ) -> x+y; was: Auto-complete for var keyword in not happening in Lambda parameter (JDK-11). Cursor is at caret position. IntBinaryOperator calc2 = (int x, va^ y ) -> x+y; > Autocomplete for var keyword not supported in Lambda parameter > -- > > Key: NETBEANS-862 > URL: https://issues.apache.org/jira/browse/NETBEANS-862 > Project: NetBeans > Issue Type: Bug >Reporter: ARUNAVA SINHA >Assignee: ARUNAVA SINHA >Priority: Minor > Labels: JDK11-VarInLambda > > Auto-complete for var keyword in not happening in Lambda parameter (JDK-11). > Cursor is at caret position. > IntBinaryOperator calc2 = (var x, ^ y ) -> x+y; > -- 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-980) Home/end/up/down do not work properly when word wrapping is enabled
[ https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-980: - Description: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is long enough). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to move the caret before lineStartPos.) Bugs 2-5 above all relate to what caret position is mapped to the "infinite" horizontal space that follows each wrap line. With NetBeans' current behavior, this space corresponds to a caret position directly following the last character of a wrap line. This caret position, however, is physically mapped (and painted) on the beginning of the following wrap line, which confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 is fixed, then bugs 2-4 might "fix themselves" as well. For bug 5, I think the best solution when clicking the space beyond the end of a wrap line would be to move the caret to right _before_ the last character on the wrap line. This character is usually a space (in word wrap mode), though it could also be a hyphen or such if a more advanced word wrapping algorithm is used (proposed in the pull request for NETBEANS-977). The resulting behavior would be similar to that of a default JTextArea, or jEdit (though these never break words on anything else than a space). Another solution would be to do like the TextEdit app on MacOS, where the cursor is placed _after_ the last character on the wrap line, like NetBeans currently does, but with a backwards bias such that the cursor is painted on the end of the current wrap line instead of on the beginning of the next wrap line. The latter is probably harder to implement, and is not really necessary. To test the above bugs: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and paste in the paragraph "SHORTWORD LONGWORD SHORTWORD LUUUNGWORD". 3) Resize the editor window so that the paragraph gets split into four wrap lines (one word on each wrap line--i.e. make the editor a little wider than the long word). 4) For each bugs 1-4 listed above, position the caret right after "...ONG", then press the relevant key to test. 5) To test bug 5 above, click the mouse to the right of the first, second, or third wrap line. Tested in NetBeans 9.0 rc1. was: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is long enough). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to move the caret before lineStartPos.) Bugs 2-5 above all relate to what caret position is mapped to the "inf
[jira] [Updated] (NETBEANS-980) Home/end/up/down do not work properly when word wrapping is enabled
[ https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-980: - Description: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is long enough). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to move the caret before lineStartPos.) Bugs 2-5 above all relate to what caret position is mapped to the "infinite" horizontal space that follows each wrap line. With NetBeans' current behavior, this space corresponds to a caret position directly following the last character of a wrap line. This caret position, however, is physically mapped (and painted) on the beginning of the following wrap line, which confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 is fixed, then bugs 2-4 might "fix themselves" as well. For bug 5, I think the best solution when clicking the space beyond the end of a wrap line would be to move the caret to right _before_ the last character on the wrap line. This character is usually a space (in word wrap mode), though it could also be a hyphen or such if a more advanced word wrapping algorithm is used (proposed in the pull request for NETBEANS-977). The resulting behavior would be similar to that of a default JTextArea, or jEdit (though these never break words on anything else than a space). Another solution would be to do like the TextEdit app on MacOS, where the cursor is placed _after_ the last character on the wrap line, but with a backwards bias such that the cursor is painted on the end of the current wrap line instead of on the beginning of the next wrap line. The latter is probably harder to implement, and is not really necessary. To test the above bugs: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and paste in the paragraph "SHORTWORD LONGWORD SHORTWORD LUUUNGWORD". 3) Resize the editor window so that the paragraph gets split into four wrap lines (one word on each wrap line--i.e. make the editor a little wider than the long word). 4) For each bugs 1-4 listed above, position the caret right after "...ONG", then press the relevant key to test. 5) To test bug 5 above, click the mouse to the right of the first, second, or third wrap line. Tested in NetBeans 9.0 rc1. was: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is long enough). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to move the caret before lineStartPos.) Bugs 2-5 above all relate to what caret position is mapped to the "infinite" horizontal space that
[jira] [Updated] (NETBEANS-980) Home/end/up/down do not work properly when word wrapping is enabled
[ https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-980: - Description: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is long enough). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to move the caret before lineStartPos.) Bugs 2-5 above all relate to what caret position is mapped to the "infinite" horizontal space that follows each wrap line. With NetBeans' current behavior, this space corresponds to a caret position directly following the last character of a wrap line. This caret position, however, is physically mapped (and painted) on the beginning of the following wrap line, which confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 is fixed, then bugs 2-4 might "fix themselves" as well. For bug 5, I think the best solution when clicking the space beyond the end of a wrap line would be to move the caret to right _before_ the last character on the wrap line. This character is usually a space (in word wrap mode), though it could also be a hyphen or such if a more advanced word wrapping algorithm is used (proposed in the pull request for NETBEANS-977). This behavior would be similar to that of a default JTextArea, or jEdit (neither which break words on anything else than a space). Another solution would be to do like the TextEdit app on MacOS, where the cursor is placed _after_ the last character on the wrap line, but with a backwards bias such that the cursor is painted on the end of the current wrap line instead of on the beginning of the next wrap line. The latter is probably harder to implement, and is not really necessary. To test the above bugs: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and paste in the paragraph "SHORTWORD LONGWORD SHORTWORD LUUUNGWORD". 3) Resize the editor window so that the paragraph gets split into four wrap lines (one word on each wrap line--i.e. make the editor a little wider than the long word). 4) For each bugs 1-4 listed above, position the caret right after "...ONG", then press the relevant key to test. 5) To test bug 5 above, click the mouse to the right of the first, second, or third wrap line. Tested in NetBeans 9.0 rc1. was: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is long enough). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix (don't allow Utilities.getRowFirstNonWhite to move cursor before lineStartPos) and is unrelated to the others. Bugs 2-5 above all relate to what caret position is mapped to the "infinite" horizontal space that follows each wrap l
[jira] [Updated] (NETBEANS-980) Home/end/up/down do not work properly when word wrapping is enabled
[ https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-980: - Description: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is long enough). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix (don't allow Utilities.getRowFirstNonWhite to move cursor before lineStartPos) and is unrelated to the others. Bugs 2-5 above all relate to what caret position is mapped to the "infinite" horizontal space that follows each wrap line. With NetBeans' current behavior, this space corresponds to a caret position directly following the last character of a wrap line. This caret position, however, is physically mapped (and painted) on the beginning of the following wrap line, which confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 is fixed, then bugs 2-4 might "fix themselves" as well. For bug 5, I think the best solution when clicking the space beyond the end of a wrap line would be to move the caret to right _before_ the last character on the wrap line. This character is usually a space (in word wrap mode), though it could also be a hyphen or such if a more advanced word wrapping algorithm is used (proposed in the pull request for NETBEANS-977). This behavior would be similar to that of a default JTextArea, or jEdit (neither which break words on anything else than a space). Another solution would be to do like the TextEdit app on MacOS, where the cursor is placed _after_ the last character on the wrap line, but with a backwards bias such that the cursor is painted on the end of the current wrap line instead of on the beginning of the next wrap line. The latter is probably harder to implement, and is not really necessary. To test the above bugs: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and paste in the paragraph "SHORTWORD LONGWORD SHORTWORD LUUUNGWORD". 3) Resize the editor window so that the paragraph gets split into four wrap lines (one word on each wrap line--i.e. make the editor a little wider than the long word). 4) For each bugs 1-4 listed above, position the caret right after "...ONG", then press the relevant key to test. 5) To test bug 5 above, click the mouse to the right of the first, second, or third wrap line. Tested in NetBeans 9.0 rc1. was: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is longer). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix (don't allow Utilities.getRowFirstNonWhite to move cursor before lineStartPos) and is unrelated to the others. Bugs 2-5 above all relate to what caret position is mapped to the "infinite" horizontal space that follows each wrap line. With
[jira] [Updated] (NETBEANS-980) Home/end/up/down do not work properly when word wrapping is enabled
[ https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-980: - Summary: Home/end/up/down do not work properly when word wrapping is enabled (was: Home/end/up/down does not work properly when word wrapping is enabled) > Home/end/up/down do not work properly when word wrapping is enabled > --- > > Key: NETBEANS-980 > URL: https://issues.apache.org/jira/browse/NETBEANS-980 > Project: NetBeans > Issue Type: Bug > Components: editor - Other, editor - Painting & Printing >Affects Versions: 9.0 >Reporter: Eirik Bakke >Priority: Major > > Caret movements via Home/End and arrow Up/Down keys do not work properly when > text wrap (especially in "after words" mode) is enabled in the NetBeans > editor. > Specific bugs: > 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the > beginning of the paragraph rather than to the beginning of the current wrap > line (physical line). > 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the > beginning of the next wrap line instead of to the end of the current wrap > line. > 3) Pressing Up has no effect if the preceding wrap line ended before the > caret's current X position. > 4) Pressing Down will move the caret down _two_ lines if the following wrap > line ended before the caret's current X position (and assuming the wrap line > two lines down is longer). > 5) Left-clicking the mouse to the right of the end of a wrap line puts the > caret on the beginning of the next wrap line rather than at the end of the > current (clicked) wrap line. > The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit > (UpAction/DownAction/BeginLineAction/EndLineAction). > Bug number 1 above, for the Home action (BeginLineAction), is easy to fix > (don't allow Utilities.getRowFirstNonWhite to move cursor before > lineStartPos) and is unrelated to the others. > Bugs 2-5 above all relate to what caret position is mapped to the "infinite" > horizontal space that follows each wrap line. With NetBeans' current > behavior, this space corresponds to a caret position directly following the > last character of a wrap line. This caret position, however, is physically > mapped (and painted) on the beginning of the following wrap line, which > confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 > is fixed, then bugs 2-4 might "fix themselves" as well. > For bug 5, I think the best solution when clicking the space beyond the end > of a wrap line would be to move the caret to right _before_ the last > character on the wrap line. This character is usually a space (in word wrap > mode), though it could also be a hyphen or such if a more advanced word > wrapping algorithm is used (proposed in the pull request for NETBEANS-977). > This behavior would be similar to that of a default JTextArea, or jEdit > (neither which break words on anything else than a space). Another solution > would be to do like the TextEdit app on MacOS, where the cursor is placed > _after_ the last character on the wrap line, but with a backwards bias such > that the cursor is painted on the end of the current wrap line instead of on > the beginning of the next wrap line. The latter is probably harder to > implement, and is not really necessary. > To test the above bugs: > 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and > set "Line Wrap" to "After words". Click OK. > 2) Create a new plain text file and paste in the paragraph "SHORTWORD > LONGWORD SHORTWORD LUUUNGWORD". > 3) Resize the editor window so that the paragraph gets split into four wrap > lines (one word on each wrap line--i.e. make the editor a little wider than > the long word). > 4) For each bugs 1-4 listed above, position the caret right after > "...ONG", then press the relevant key to test. > 5) To test bug 5 above, click the mouse to the right of the first, second, or > third wrap line. > Tested in NetBeans 9.0 rc1. -- 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-980) Home/end/up/down does not work properly when word wrapping is enabled
[ https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-980: - Description: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is longer). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix (don't allow Utilities.getRowFirstNonWhite to move cursor before lineStartPos) and is unrelated to the others. Bugs 2-5 above all relate to what caret position is mapped to the "infinite" horizontal space that follows each wrap line. With NetBeans' current behavior, this space corresponds to a caret position directly following the last character of a wrap line. This caret position, however, is physically mapped (and painted) on the beginning of the following wrap line, which confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 is fixed, then bugs 2-4 might "fix themselves" as well. For bug 5, I think the best solution when clicking the space beyond the end of a wrap line would be to move the caret to right _before_ the last character on the wrap line. This character is usually a space (in word wrap mode), though it could also be a hyphen or such if a more advanced word wrapping algorithm is used (proposed in the pull request for NETBEANS-977). This behavior would be similar to that of a default JTextArea, or jEdit (neither which break words on anything else than a space). Another solution would be to do like the TextEdit app on MacOS, where the cursor is placed _after_ the last character on the wrap line, but with a backwards bias such that the cursor is painted on the end of the current wrap line instead of on the beginning of the next wrap line. The latter is probably harder to implement, and is not really necessary. To test the above bugs: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and paste in the paragraph "SHORTWORD LONGWORD SHORTWORD LUUUNGWORD". 3) Resize the editor window so that the paragraph gets split into four wrap lines (one word on each wrap line--i.e. make the editor a little wider than the long word). 4) For each bugs 1-4 listed above, position the caret right after "...ONG", then press the relevant key to test. 5) To test bug 5 above, click the mouse to the right of the first, second, or third wrap line. Tested in NetBeans 9.0 rc1. was: If line wrap is enabled, and the text caret is located in a wrapped paragraph, the up/down arrow keys cannot be used to move the caret up/down to another wrap line if the target wrap line is shorter than the current caret position. Either nothing happens, or the caret may skip the shorter wrap lines and step multiple wrap lines up/down. To reproduce: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and paste in the paragraph "SHORTWORD LONGWORD SHORTWORD LUUUNGWORD". 3) Resize the editor window so that the paragraph gets split into three wrap lines (one word on each wrap line--i.e. make the editor a little wider than the long word). 4) Position the cursor right after "...ONG" 5) Press the "Up" arrow. Nothing happens (expected would be to the caret to move up to the end of the previous wrap line). 6) Press the "Down" arrow. This moves the caret _two_ wrap lines down instead of to the end of the next wrap line. Tested in NetBeans 9.0 rc1. > Home/end/up/down does not work properly when word wrapping is enabled > - > > Key: NETBEANS-980 > URL: https://issues.apache.org/jira/browse/NETBEANS-980 > Project: NetBeans > Issue Type: Bug > Compon
[jira] [Updated] (NETBEANS-980) Home/end/up/down does not work properly when word wrapping is enabled
[ https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-980: - Summary: Home/end/up/down does not work properly when word wrapping is enabled (was: Cannot arrow up/down to shorter word-wrapped line in editor) > Home/end/up/down does not work properly when word wrapping is enabled > - > > Key: NETBEANS-980 > URL: https://issues.apache.org/jira/browse/NETBEANS-980 > Project: NetBeans > Issue Type: Bug > Components: editor - Other, editor - Painting & Printing >Affects Versions: 9.0 >Reporter: Eirik Bakke >Priority: Major > > If line wrap is enabled, and the text caret is located in a wrapped > paragraph, the up/down arrow keys cannot be used to move the caret up/down to > another wrap line if the target wrap line is shorter than the current caret > position. Either nothing happens, or the caret may skip the shorter wrap > lines and step multiple wrap lines up/down. > To reproduce: > 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and > set "Line Wrap" to "After words". Click OK. > 2) Create a new plain text file and paste in the paragraph "SHORTWORD > LONGWORD SHORTWORD LUUUNGWORD". > 3) Resize the editor window so that the paragraph gets split into three wrap > lines (one word on each wrap line--i.e. make the editor a little wider than > the long word). > 4) Position the cursor right after "...ONG" > 5) Press the "Up" arrow. Nothing happens (expected would be to the caret to > move up to the end of the previous wrap line). > 6) Press the "Down" arrow. This moves the caret _two_ wrap lines down instead > of to the end of the next wrap line. > Tested in NetBeans 9.0 rc1. -- 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] [Closed] (NETBEANS-979) With line wrap enabled, cursor at end of line is painted at beginning of next line instead
[ https://issues.apache.org/jira/browse/NETBEANS-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke closed NETBEANS-979. Resolution: Duplicate Fix Version/s: (was: 9.0) Having done a little work on this, the underlying issue is the same as for NETBEANS-980, so I'm closing this one and making all new comments on that one. > With line wrap enabled, cursor at end of line is painted at beginning of next > line instead > -- > > Key: NETBEANS-979 > URL: https://issues.apache.org/jira/browse/NETBEANS-979 > Project: NetBeans > Issue Type: Bug > Components: editor - Painting & Printing >Reporter: Eirik Bakke >Priority: Major > > In an editor with line wrap enabled, the cursor is shown at the wrong > physical location whenever it is supposed to be located at the end of a wrap > line. Instead of being painted at the end of the wrap line, it is painted at > the beginning of the following line. This causes the behavior of keyboard > shortcuts like "End" and "Up" to seem nonsensical to the user, although they > might well be behaving correctly wrt. the physical location of the cursor > (the character offset). > To reproduce: > 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and > set "Line Wrap" to "After words". Click OK. > 2) Create a new plain text file and open it in the editor. > 3) Type some gibberish into the editor on a single line that is long enough > to be broken into several break lines. > 4) With the cursor before the first character of the first wrap line in the > paragraph, press the "End" key (Command+Right on MacBook keyboards). The > cursor appears to move one line down, which is unexpected. From looking at > this situation, the user would now assume that they could press the "Up" key > to move the cursor back to the previous break line, but this will not change > the cursor position (because the cursor is logically on the previous line). > 5) Another unexpected example: Pressing Home anywhere in a paragraph will > move the cursor to the first character on the paragraph rather than at the > first character of the wrap line. (This might indicate that the problem is > more than just a paint bug, though.) > Originally reported in BugZilla at > https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on > NetBeans 9.0 rc1. > See also https://issues.apache.org/jira/browse/NETBEANS-980 . -- 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-168) Background scanning process needs a rethink
[ https://issues.apache.org/jira/browse/NETBEANS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16521974#comment-16521974 ] Christian Lenz commented on NETBEANS-168: - Will try to find a big OSS project to test it with this. > Background scanning process needs a rethink > --- > > Key: NETBEANS-168 > URL: https://issues.apache.org/jira/browse/NETBEANS-168 > Project: NetBeans > Issue Type: Bug > Components: ide - Performance, java - Platform, platform - Execution >Affects Versions: 8.2, Next > Environment: NetBeans 8.2, Windows 10 x64 >Reporter: Christian Lenz >Priority: Critical > > Often, while cloning, switching branch, merging, opening etc. etc. NetBeans > starts Background scanning for changes, but it is not real background, > because everything what you want to do then, like changing the branch, > commit, push, pull, open project, delete or whatever, is blocking by this > task and you can't cancel it, because it is essential. > Either we need to rethink about this process like to make everything or most > of the stuff doing things in parallel or the task should really be > cancelable. It is a pain in the ass for big projects when they start to scan > for changes. > It is a real world case because you acan see it when you work on NetBeans > modules. > Cheers > Chris -- 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-168) Background scanning process needs a rethink
[ https://issues.apache.org/jira/browse/NETBEANS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16521975#comment-16521975 ] Christian Lenz commented on NETBEANS-168: - Could be PHP related or smth else. Only guessing. > Background scanning process needs a rethink > --- > > Key: NETBEANS-168 > URL: https://issues.apache.org/jira/browse/NETBEANS-168 > Project: NetBeans > Issue Type: Bug > Components: ide - Performance, java - Platform, platform - Execution >Affects Versions: 8.2, Next > Environment: NetBeans 8.2, Windows 10 x64 >Reporter: Christian Lenz >Priority: Critical > > Often, while cloning, switching branch, merging, opening etc. etc. NetBeans > starts Background scanning for changes, but it is not real background, > because everything what you want to do then, like changing the branch, > commit, push, pull, open project, delete or whatever, is blocking by this > task and you can't cancel it, because it is essential. > Either we need to rethink about this process like to make everything or most > of the stuff doing things in parallel or the task should really be > cancelable. It is a pain in the ass for big projects when they start to scan > for changes. > It is a real world case because you acan see it when you work on NetBeans > modules. > Cheers > Chris -- 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-967) java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location
[ https://issues.apache.org/jira/browse/NETBEANS-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16521976#comment-16521976 ] Jacco van Weert commented on NETBEANS-967: -- Same for me... I have multiple monitors, but it doesn't matter on which screen NB is running, the same issue. > java.awt.IllegalComponentStateException: component must be showing on the > screen to determine its location > -- > > Key: NETBEANS-967 > URL: https://issues.apache.org/jira/browse/NETBEANS-967 > Project: NetBeans > Issue Type: Bug > Components: java - Editor >Affects Versions: 9.0 > Environment: Windows10 >Reporter: Jacco van Weert >Priority: Major > > A lot of times I get this exception when CTRL+click to a method or browsing > through the sourcecode. > It's terrible! > > > java.awt.IllegalComponentStateException: component must be showing on the > screen to determine its location > at java.awt.Component.getLocationOnScreen_NoTreeLock(Component.java:2062) > at java.awt.Component.getLocationOnScreen(Component.java:2036) > at > javax.swing.text.JTextComponent$InputMethodRequestsHandler.getTextLocation(JTextComponent.java:4643) > at sun.awt.im.InputMethodContext.getTextLocation(InputMethodContext.java:278) > at sun.awt.windows.WInputMethod$1.run(WInputMethod.java:588) > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758) > at java.awt.EventQueue.access$500(EventQueue.java:97) > at java.awt.EventQueue$3.run(EventQueue.java:709) > at java.awt.EventQueue$3.run(EventQueue.java:703) > at java.security.AccessController.doPrivileged(Native Method) > at > java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) > at > java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:90) > at java.awt.EventQueue$4.run(EventQueue.java:733) > at java.awt.EventQueue$4.run(EventQueue.java:731) > at java.security.AccessController.doPrivileged(Native Method) > at > java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:730) > at > org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:136) > [catch] at > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205) > at > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) -- 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-931) OutOfMemory after a night of stand-by
[ https://issues.apache.org/jira/browse/NETBEANS-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16521931#comment-16521931 ] Luca Mambretti commented on NETBEANS-931: - The file I sent originally was already compressed and comes down to roughly 156 MB. I do not regularly use Telegram, so can I ask for any other means of transfer, I'll add another we-trasfer link [https://we.tl/uNs1zJBntx] just in case you manage to download that > OutOfMemory after a night of stand-by > - > > Key: NETBEANS-931 > URL: https://issues.apache.org/jira/browse/NETBEANS-931 > Project: NetBeans > Issue Type: Bug >Affects Versions: 9.0 >Reporter: Luca Mambretti >Priority: Critical > Attachments: messages.log, uigestures.xml > > > After a full day of work I left the system running (it had manifested the > errors described in NETBEANS-901). > > The day after it was out of commission with OOM. > > attached IDE logs and gestures, I also have the heap dump but it's 1.5 gigs > so I doubt I'll be able to attach it (sent it thru a WeTransfer link for now) -- 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
