date:20180410


 [ 
https://issues.apache.org/jira/browse/NETBEANS-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

will mason updated NETBEANS-639:

Labels: Regression accessibility keymap options shortcuts  (was: Regression 
keymap options shortcuts)

> Right-hand ALT key ignored
> --
>
> Key: NETBEANS-639
> URL: https://issues.apache.org/jira/browse/NETBEANS-639
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Refactoring
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-release-205-on-20180202)
> Java: 10; Java HotSpot(TM) 64-Bit Server VM 10+46
> Runtime: Java(TM) SE Runtime Environment 10+46
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_AU (nb)
> User directory: Z:\tmp\.other\user\netbeans\v09.00-beta\FourAbs
> Cache directory: Z:\tmp\.other\cache\netbeans\FourAbs-09
> Can not be directly tested on Linux because Alt/F7 is used by X-Windows for 
> "Move Window"
>Reporter: will mason
>Priority: Major
>  Labels: Regression, accessibility, keymap, options, shortcuts
> Attachments: image-2018-04-11-11-39-20-834.png, 
> image-2018-04-11-11-41-59-642.png
>
>
> h2. expected
> scenario 01
>  * I used *{{Right-Alt/F7}}* to invoke the "*{{Find Usages}}*" pop-up
>  * Expected to see the "*{{Find Usages}}*" pop-up
> scenario 02
>  * Opened the *Options* panel / *KeyMap* tab
>  * Put cursor in "*Search in Shortcuts*" field
>  * Pressed *{{Right-Alt}}*
>  * Expected to see All the actions matching the ALT key
>  * Pressed *{{Right-Alt/Shift}}*
>  * Expected to see All the actions matching the ALT-Shift key combinations
>  * Pressed *{{Right-Alt/Control}}*
>  * Expected to see All the actions matching the ALT-Control key combinations
>  * Pressed *{{Right-Alt/Control/Shift}}*
>  * Expected to see All the actions matching the ALT-Control-Shift key 
> combinations
>  * Pressed *{{Right-Alt/F7}}*
>  * Expected to see "Find Usages" Action
>  * Pressed *{{Left-Alt/F7}}*
>  * Expected to see "Find Usages" Action
> This screen shot shows the Netbeans 8.2 KeyMap
> {panel:title=Right-Alt/F7 in Search in Shortcuts (Netbeans 8.2)}
> !image-2018-04-11-11-41-59-642.png!
> {panel}
> h2. actual
> scenario 01
>  * Pressed *{{Right-Alt/F7 ...}}* "*{{Find Usages}}*" pop-up NOT shown
>  * Pressed *{{Left-Alt/F7}}* --> "*{{Find Usages}}*" pop-up displayed 
> _correctly_
> scenario 02
> Key-presses in the order shown, left-to-right.
>  * Pressed *{{Right-Alt}}* --> _nothing_
>  * Pressed *{{Right-Alt/Shift}}* --> _nothing_
>  * Pressed *{{Right-Alt/Control}}* --> _nothing_
>  * Pressed *{{Right-Alt/Control/Shift}}* --> _nothing_
>  * Pressed *{{Right-Alt/F7}}* --> _nothing_
>  ** Expected to see "Find Usages" Action --> _nothing_
> {panel:title=Right-Alt in Search in Shortcuts (Netbeans 9)}
> !image-2018-04-11-11-39-20-834.png!
> {panel}
>  * Pressed *{{Left-Alt/F7}}* - "Find Usages" Action dialogue popped-up
> Curiously, these key-combinations are each different to the others. Key-press 
> in the sequence as shown, left-to-right.:
>  * "{{CTRL+Alt+Shift+}}" <--
>  ** *{{Left-Control/Left-Alt/Left-Shift}}*
>  ** *{{Left-Control/Left-Alt/Right-Shift}}*
>  * "{{CTRL+}}" <--
>  ** *{{Left-Control/Right-Alt/Left-Shift}}*
>  ** *{{Left-Control/Right-Alt/Right-Shift}}*
>  * "{{CTRL+Shift+}}" <--
>  ** *{{Left-Control/Left-Shift/Right-Alt}}*
>  * "{{CTRL+AltShift+}}" <--
>  ** *{{Left-Control/Left-Shift/Right-Alt}}*
> h2. Impact
>  * This becomes an accessibility issue.
>  * I have an injury at the moment that makes being forced to just use the 
> left-ALT key uncomfortable
>  * Long-term there may also be degenerative physical effects.  Especial for 
> people with conditions affected by this limitation.
>  * It looks like EVERY Right-Alt key combination will NOT work.
>  



--
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-639) Right-hand ALT key ignored


 [ 
https://issues.apache.org/jira/browse/NETBEANS-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

will mason updated NETBEANS-639:

Description: 
h2. expected

scenario 01
 * I used *{{Right-Alt/F7}}* to invoke the "*{{Find Usages}}*" pop-up
 * Expected to see the "*{{Find Usages}}*" pop-up

scenario 02
 * Opened the *Options* panel / *KeyMap* tab
 * Put cursor in "*Search in Shortcuts*" field
 * Pressed *{{Right-Alt}}*
 * Expected to see All the actions matching the ALT key
 * Pressed *{{Right-Alt/Shift}}*
 * Expected to see All the actions matching the ALT-Shift key combinations
 * Pressed *{{Right-Alt/Control}}*
 * Expected to see All the actions matching the ALT-Control key combinations
 * Pressed *{{Right-Alt/Control/Shift}}*
 * Expected to see All the actions matching the ALT-Control-Shift key 
combinations
 * Pressed *{{Right-Alt/F7}}*
 * Expected to see "Find Usages" Action
 * Pressed *{{Left-Alt/F7}}*
 * Expected to see "Find Usages" Action

This screen shot shows the Netbeans 8.2 KeyMap
{panel:title=Right-Alt/F7 in Search in Shortcuts (Netbeans 8.2)}
!image-2018-04-11-11-41-59-642.png!
{panel}
h2. actual

scenario 01
 * Pressed *{{Right-Alt/F7 ...}}* "*{{Find Usages}}*" pop-up NOT shown
 * Pressed *{{Left-Alt/F7}}* --> "*{{Find Usages}}*" pop-up displayed 
_correctly_

scenario 02

Key-presses in the order shown, left-to-right.
 * Pressed *{{Right-Alt}}* --> _nothing_
 * Pressed *{{Right-Alt/Shift}}* --> _nothing_
 * Pressed *{{Right-Alt/Control}}* --> _nothing_
 * Pressed *{{Right-Alt/Control/Shift}}* --> _nothing_
 * Pressed *{{Right-Alt/F7}}* --> _nothing_
 ** Expected to see "Find Usages" Action --> _nothing_

{panel:title=Right-Alt in Search in Shortcuts (Netbeans 9)}
!image-2018-04-11-11-39-20-834.png!
{panel}
 * Pressed *{{Left-Alt/F7}}* - "Find Usages" Action dialogue popped-up

Curiously, these key-combinations are each different to the others. Key-press 
in the sequence as shown, left-to-right.:
 * "{{CTRL+Alt+Shift+}}" <--
 ** *{{Left-Control/Left-Alt/Left-Shift}}*
 ** *{{Left-Control/Left-Alt/Right-Shift}}*
 * "{{CTRL+}}" <--
 ** *{{Left-Control/Right-Alt/Left-Shift}}*
 ** *{{Left-Control/Right-Alt/Right-Shift}}*
 * "{{CTRL+Shift+}}" <--
 ** *{{Left-Control/Left-Shift/Right-Alt}}*
 * "{{CTRL+AltShift+}}" <--
 ** *{{Left-Control/Left-Shift/Right-Alt}}*

h2. Impact
 * This becomes an accessibility issue.
 * I have an injury at the moment that makes being forced to just use the 
left-ALT key uncomfortable
 * Long-term there may also be degenerative physical effects.  Especial for 
people with conditions affected by this limitation.
 * It looks like EVERY Right-Alt key combination will NOT work.

 

  was:
h2. expected

scenario 01
 * I used *{{Right-Alt/F7}}* to invoke the "*{{Find Usages}}*" pop-up
 * Expected to see the "*{{Find Usages}}*" pop-up

scenario 02
 * Opened the *Options* panel / *KeyMap* tab
 * Put cursor in "*Search in Shortcuts*" field
 * Pressed *{{Right-Alt}}*
 * Expected to see All the actions matching the ALT key
 * Pressed *{{Right-Alt/Shift}}*
 * Expected to see All the actions matching the ALT-Shift key combinations
 * Pressed *{{Right-Alt/Control}}*
 * Expected to see All the actions matching the ALT-Control key combinations
 * Pressed *{{Right-Alt/Control/Shift}}*
 * Expected to see All the actions matching the ALT-Control-Shift key 
combinations
 * Pressed *{{Right-Alt/F7}}*
 * Expected to see "Find Usages" Action
 * Pressed *{{Left-Alt/F7}}*
 * Expected to see "Find Usages" Action

This screen shot shows the Netbeans 8.2 KeyMap
{panel:title=Right-Alt/F7 in Search in Shortcuts (Netbeans 8.2)}
!image-2018-04-11-11-41-59-642.png!
{panel}
h2. actual

scenario 01
 * Pressed *{{Right-Alt/F7 ...}}* "*{{Find Usages}}*" pop-up NOT shown
 * Pressed *{{Left-Alt/F7}}* --> "*{{Find Usages}}*" pop-up displayed 
_correctly_

scenario 02

Key-presses in the order shown, left-to-right.
 * Pressed *{{Right-Alt}}* --> _nothing_
 * Pressed *{{Right-Alt/Shift}}* --> _nothing_
 * Pressed *{{Right-Alt/Control}}* --> _nothing_
 * Pressed *{{Right-Alt/Control/Shift}}* --> _nothing_
 * Pressed *{{Right-Alt/F7}}* --> _nothing_
 ** Expected to see "Find Usages" Action --> _nothing_

{panel:title=Right-Alt in Search in Shortcuts (Netbeans 9)}
!image-2018-04-11-11-39-20-834.png!
{panel}
 * Pressed *{{Left-Alt/F7}}* - "Find Usages" Action dialogue popped-up

Curiously, these key-combinations are each different to the others. Key-press 
in the sequence as shown, left-to-right.:
 * "{{CTRL+Alt+Shift+}}" <--
 ** *{{Left-Control/Left-Alt/Left-Shift}}*
 ** *{{Left-Control/Left-Alt/Right-Shift}}*
 * "{{CTRL+}}" <--
 ** *{{Left-Control/Right-Alt/Left-Shift}}*
 ** *{{Left-Control/Right-Alt/Right-Shift}}*
 * "{{CTRL+Shift+}}" <--
 ** *{{Left-Control/Left-Shift/Right-Alt}}*
 * "{{CTRL+AltShift+}}" <--
 ** *{{Left-Control/Left-Shift/Right-Alt}}*

h2. Impact


> Right-hand ALT key ignored
> --
>
>

[jira] [Created] (NETBEANS-639) Right-hand ALT key ignored

will mason created NETBEANS-639:
---

 Summary: Right-hand ALT key ignored
 Key: NETBEANS-639
 URL: https://issues.apache.org/jira/browse/NETBEANS-639
 Project: NetBeans
  Issue Type: Bug
  Components: editor - Refactoring
Affects Versions: 9.0
 Environment: Product Version: Apache NetBeans IDE Dev (Build 
incubator-netbeans-release-205-on-20180202)
Java: 10; Java HotSpot(TM) 64-Bit Server VM 10+46
Runtime: Java(TM) SE Runtime Environment 10+46
System: Windows 10 version 10.0 running on amd64; Cp1252; en_AU (nb)
User directory: Z:\tmp\.other\user\netbeans\v09.00-beta\FourAbs
Cache directory: Z:\tmp\.other\cache\netbeans\FourAbs-09

Can not be directly tested on Linux because Alt/F7 is used by X-Windows for 
"Move Window"
Reporter: will mason
 Attachments: image-2018-04-11-11-39-20-834.png, 
image-2018-04-11-11-41-59-642.png

h2. expected

scenario 01
 * I used *{{Right-Alt/F7}}* to invoke the "*{{Find Usages}}*" pop-up
 * Expected to see the "*{{Find Usages}}*" pop-up

scenario 02
 * Opened the *Options* panel / *KeyMap* tab
 * Put cursor in "*Search in Shortcuts*" field
 * Pressed *{{Right-Alt}}*
 * Expected to see All the actions matching the ALT key
 * Pressed *{{Right-Alt/Shift}}*
 * Expected to see All the actions matching the ALT-Shift key combinations
 * Pressed *{{Right-Alt/Control}}*
 * Expected to see All the actions matching the ALT-Control key combinations
 * Pressed *{{Right-Alt/Control/Shift}}*
 * Expected to see All the actions matching the ALT-Control-Shift key 
combinations
 * Pressed *{{Right-Alt/F7}}*
 * Expected to see "Find Usages" Action
 * Pressed *{{Left-Alt/F7}}*
 * Expected to see "Find Usages" Action

This screen shot shows the Netbeans 8.2 KeyMap
{panel:title=Right-Alt/F7 in Search in Shortcuts (Netbeans 8.2)}
!image-2018-04-11-11-41-59-642.png!
{panel}
h2. actual

scenario 01
 * Pressed *{{Right-Alt/F7 ...}}* "*{{Find Usages}}*" pop-up NOT shown
 * Pressed *{{Left-Alt/F7}}* --> "*{{Find Usages}}*" pop-up displayed 
_correctly_

scenario 02

Key-presses in the order shown, left-to-right.
 * Pressed *{{Right-Alt}}* --> _nothing_
 * Pressed *{{Right-Alt/Shift}}* --> _nothing_
 * Pressed *{{Right-Alt/Control}}* --> _nothing_
 * Pressed *{{Right-Alt/Control/Shift}}* --> _nothing_
 * Pressed *{{Right-Alt/F7}}* --> _nothing_
 ** Expected to see "Find Usages" Action --> _nothing_

{panel:title=Right-Alt in Search in Shortcuts (Netbeans 9)}
!image-2018-04-11-11-39-20-834.png!
{panel}
 * Pressed *{{Left-Alt/F7}}* - "Find Usages" Action dialogue popped-up

Curiously, these key-combinations are each different to the others. Key-press 
in the sequence as shown, left-to-right.:
 * "{{CTRL+Alt+Shift+}}" <--
 ** *{{Left-Control/Left-Alt/Left-Shift}}*
 ** *{{Left-Control/Left-Alt/Right-Shift}}*
 * "{{CTRL+}}" <--
 ** *{{Left-Control/Right-Alt/Left-Shift}}*
 ** *{{Left-Control/Right-Alt/Right-Shift}}*
 * "{{CTRL+Shift+}}" <--
 ** *{{Left-Control/Left-Shift/Right-Alt}}*
 * "{{CTRL+AltShift+}}" <--
 ** *{{Left-Control/Left-Shift/Right-Alt}}*

h2. Impact



--
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-638) Second editor window spontaneously changes current line context

[
https://issues.apache.org/jira/browse/NETBEANS-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

will mason updated NETBEANS-638:

Description:
h2. context

* Editing a file in Netbens (e.g. Java file)
* Split the screen Vertically or Horizontally
* Split the screen Horizontally
* Clone the edit tab

*_rationale_*

* The predominate reason to do any of these three actions is to facilitate the
viewing of different parts of the same (code) file together, at the same time.
* To permit easier code copy, swap, or move of existing code from one area to
the other.
* To permit referring to two different parts of the same file that can't fit on
the screen together with some other file or display, etc.
* Contemporaneous editing of two different sections of code together; say
editing the declaration section along with some implementation code (for
example).

In summary keeping two (or more) areas of the same file *+In View at the Same
Time+*.

h2. expected

* When the editor window is split or when secondary (clone) windows are open
each display context must remain with, or in the locality of, the lines chosen
for display by the user.

# Use-case scenario #1
#* Split window horizontally -- top and bottom
#* On the top window the cursor is at line 200.
#* On the bottom window use {{CTRL/G}} and jump to line 1,500
#* Those positions are _known_ internally by the editor
#* The cursor must remain _in situ_.
#* Should insert lines say 10 in the top panel, the the cursor location in the
bottom panel must adjust to be at the subjective position of line1,510.
# Use-case scenario #2
#* Split window horizontally -- top and bottom
#* On the top window the cursor is at line 200.
#* On the bottom window use {{CTRL/G}} and jump to line 1,500
#* Scroll bottom window to line 2,000
#** These are the visible lines, the current line remains #1,500
#* If I subsequently edit at line #200 in the top window the lines visible in
the bottom window must remain around the #2,000 line mark if nothing else has
changed!
#** Admittedly the valid behaviour IF I move the cursor (say up-arrow) should
be to reset the visible lines to the area around #1,499

h2. actual

Use-case scenario #1

* After an edit in the top window the bottom window often loses context
(around 80% of cases)
* Sometimes the lines showing in bottom, don't relate to either line 100 or
line 1,500 but some other location
* Using a key in the bottom window can have consequences such as inserting text
in the wrong place dire problems happen if an open brace({) is inadvertently
inserted!
* sometimes edits in the bottom frame cause the top window to move the
displayed location.
** Once more the cursor position is not clearly known

Use-case scenario #2

* Sometimes the view in the second bottom window can move to line #1,500
* Sometimes the view in the second bottom window can move to line #200
* It never seems to stay at line #2,000 where the user (_me_) wants to read
the text/code!

Both situations

* Sometimes the cursor seems to remain on the appropriate line in the other
window (sticking with bottom frame for discussion purposes).
* And the lines in view move (say to line #1,000) -- Leaving the user with an
unknown or unexpected view of lines that he/she expected to be around line
#1,500
* Often boilerplate code in one are can resemble code in a different place
* In this example it would be easy to begin editing line #1,000 believing that
the changes are going into the method on line #1,500 (say).

h2. Impact

* Frustration and wasted time having move cursor or display back to where it
Should Have Remained (Be).
* Code errors, recall the misplaced opening-brace({) -- this kind of typo can
take hours to unravel
* Missed opportunities because the code you need to view is not visible or not
what you are looking at (despite having displayed the code you want *_See_*)

A further problem here is the context changes in the Editor windows your are
Not viewing may not be immediately seen. I may split file-01 and make some
change to top, then edit File-03 altar coming back to file-10 believing the top
and bottom display the Expected code that I had positioned In that frame --
when it no longer represents the chosen line / display locations.

was:
h2. context

* Editing a file in Netbens (e.g. Java file)
* Split the screen Vertically or Horizontally
* Split the screen Horizontally
* Clone the edit tab

*_rationale_*

[jira] [Updated] (NETBEANS-638) Second editor window spontaneously changes current line context

[
https://issues.apache.org/jira/browse/NETBEANS-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

will mason updated NETBEANS-638:

Description:
h2. context

* Editing a file in Netbens (e.g. Java file)
* Split the screen Vertically or Horizontally
* Split the screen Horizontally
* Clone the edit tab

*_rationale_*

In summary keeping two (or more) areas of the same file *+In View at the Same
Time+*.

h2. expected

* When the editor window is split or when secondary (clone) windows are open
each display context must remain with, or in the locality of, the lines chosen
for display by the user.

# Use-case scenario #2
#* Split window horizontally -- top and bottom
#* On the top window the cursor is at line 200.
#* On the bottom window use {{CTRL/G}} and jump to line 1,500
#* Scroll bottom window to line 2,000
#** These are the visible lines, the current line remains #1,500
#* If I subsequently edit at line #200 in the top window the lines visible in
the bottom window must remain around the #2,000 line mark if nothing else has
changed!
#** Admittedly the valid behaviour IF I move the cursor (say up-arrow) should
be to reset the visible lines to the area around #1,499

h2. actual

Use-case scenario #1

Use-case scenario #2

Both situations

h2. Impact

was:
h2. context

* Editing a file in Netbens (e.g. Java file)
* Split the screen Vertically or Horizontally
* Split the screen Horizontally
* Clone the edit tab

*_rationale_*

[jira] [Created] (NETBEANS-638) Second editor window spontaneously changes current line context

will mason created NETBEANS-638:
---

 Summary: Second editor window spontaneously changes current line 
context
 Key: NETBEANS-638
 URL: https://issues.apache.org/jira/browse/NETBEANS-638
 Project: NetBeans
  Issue Type: Bug
  Components: cnd - Editor
Affects Versions: 9.0
 Environment: Product Version: Apache NetBeans IDE Dev (Build 
incubator-netbeans-release-205-on-20180202)
Java: 10; Java HotSpot(TM) 64-Bit Server VM 10+46
Runtime: Java(TM) SE Runtime Environment 10+46
System: Windows 10 version 10.0 running on amd64; Cp1252; en_AU (nb)
User directory: Z:\tmp\.other\user\netbeans\v09.00-beta\FourAbs
Cache directory: Z:\tmp\.other\cache\netbeans\FourAbs-09
Reporter: will mason


h2. context

* Editing a file in Netbens (e.g. Java file)
* Split the screen Vertically or Horizontally
* Split the screen Horizontally
* Clone the edit tab

*_rationale_*

* The predominate reason to do any of these three actions is to facilitate the 
viewing of different parts of the same (code) file together, at the same time.
* To permit easier code copy, swap, or move of existing code from one area to 
the other.
* To permit referring to two different parts of the same file that can't fit on 
the screen together with some other file or display, etc.
* Contemporaneous editing of two different sections of code together; say 
editing the declaration section along with some implementation code (for 
example).

In summary keeping two (or more) areas of the same file *+In View at the Same 
Time+*.

h2. expected

*  When the editor window is split or when secondary (clone) windows are open 
each display context must remain with, or in the locality of, the lines chosen 
for display by the user.

# Use-case scenario #1
#*   Split window horizontally -- top and bottom
#*  On the top window the cursor is at line 200.
#*  On the bottom window use {{CTRL/G}} and jump to line 1,500
#* Those positions are _known_ internally by the editor
#* The cursor must remain _in situ_.
#* Should insert lines say 10 in the top panel, the the cursor location in the 
bottom panel must adjust to be at the subjective position of line1,510.

# Use-case scenario #2
#*   Split window horizontally -- top and bottom
#*  On the top window the cursor is at line 200.
#*  On the bottom window use {{CTRL/G}} and jump to line 1,500
#*  Scroll bottom window to line 2,000 
#**  These are the visible lines, the current line remains #1,500
#*  If I subsequently edit at line #200 in the top window the lines visible in 
the bottom window must remain around the #2,000 line mark if nothing else has 
changed!
#**  Admittedly the valid behaviour IF I move the cursor (say up-arrow) should 
be to reset the visible lines to the area around #1,499

h2. actual

Use-case scenario #1

* After an edit in the top window the bottom window  often loses context 
(around 80% of cases)
* Sometimes the lines showing in bottom, don't relate to either line 100 or 
line 1,500 but some other location
* Using a key in the bottom window can have consequences such as inserting text 
in the wrong place dire problems happen if an open brace({) is inadvertently 
inserted!
* sometimes edits in the bottom frame cause the top window to move the 
displayed location.
**  Once more the cursor position is not clearly known 

Use-case scenario #2

*   Sometimes the view in the second  bottom window can move to line #1,500
*   Sometimes the view in the second  bottom window can move to line #200
*  It never seems to stay at line #2,000 where the user (_me_) wants to read 
the text/code!

Both situations

*  Sometimes the cursor seems to remain on the appropriate line in the other 
window (sticking with bottom frame for discussion purposes).
* And the lines in view move  (say to line #1,000) -- Leaving the user with an 
unknown or unexpected view of lines that he/she expected to be around line 
#1,500
* Often boilerplate code in one are can resemble code in a different place
* In this example it would be easy to begin editing line #1,000 believing that 
the changes are going into the method on line #1,500 (say).

.h2.  Impact

*  Frustration and wasted time having move cursor or display back to where it 
Should Have Remained (Be).
* Code errors, recall the misplaced opening-brace({) -- this kind of typo can 
take hours to unravel
* Missed opportunities because the code you need to view is not visible or not 
what you are looking at (despite having displayed the code you want *_See_*)

A further problem here is the context changes in the Editor windows your are 
Not viewing may not be immediately seen.  I may split file-01 and make some 
change to top, then edit File-03 altar coming back to file-10 believing the top 
and bottom display the Expected code that I had positioned In that frame -- 
when it no longer represents the chosen line / display locations.





--
This message was

[jira] [Created] (NETBEANS-637) git remote/local difference arrows do not show

2018-04-10 Thread Matt Heitker (JIRA)

Matt Heitker created NETBEANS-637:
-

 Summary: git remote/local difference arrows do not show
 Key: NETBEANS-637
 URL: https://issues.apache.org/jira/browse/NETBEANS-637
 Project: NetBeans
  Issue Type: Bug
Affects Versions: 9.0
 Environment: Windows and Mac; netbeans 9 beta and daily builds; java 8 
and 9.
Reporter: Matt Heitker


I have a Netbeans maven project, using git from bitbucket.  In version 8.2, 
when I make a local commit, an "up" arrow shows next to the branch, showing me 
that I need to push the branch back to bitbucket.  When I do a remote fetch, 
and the remote is newer, version 8.2 shows me a "down" arrow next to the branch 
name, to show me I need to do a pull/merge.

Neither the version 9 beta nor any of the daily builds so far display these 
"up" and "down" arrows.  Is this an intended change, or is it a bug?  I'd argue 
that this is a bug.  The feature is very valuable (to me, anyway).



--
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-457) maven build exception

2018-04-10 Thread gary emiddio bello (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432851#comment-16432851
 ] 

gary emiddio bello commented on NETBEANS-457:
-

correction - where above I said -DT=1 -bsinglethreaded,

should be -T=1 -bsinglethreaded.

 

Either alone will also work.

> maven build exception
> -
>
> Key: NETBEANS-457
> URL: https://issues.apache.org/jira/browse/NETBEANS-457
> Project: NetBeans
>  Issue Type: Bug
>  Components: apisupport - Maven
>Affects Versions: 8.2, 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> 20180309-unknown-revn)
> Java: 9.0.4; Java HotSpot(TM) 64-Bit Server VM 9.0.4+11
> Runtime: Java(TM) SE Runtime Environment 9.0.4+11
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb)
> User directory: C:\Users\gary\AppData\Roaming\NetBeans\dev
> Cache directory: C:\Users\gary\AppData\Local\NetBeans\Cache\dev
>Reporter: gary emiddio bello
>Priority: Major
>
>  
> error while building jgit from
> [https://github.com/eclipse/jgit.git]
> java.lang.AssertionError
>  at 
> org.netbeans.modules.maven.execute.cmd.ExecutionEventObject$Tree.startFold(ExecutionEventObject.java:174)
>  at 
> org.netbeans.modules.maven.execute.CommandLineOutputHandler$Output.run(CommandLineOutputHandler.java:350)
>  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)
>  at 
> org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
> Caused: org.openide.util.RequestProcessor$SlowItem: task failed due to
>  at org.openide.util.RequestProcessor.post(RequestProcessor.java:395)
>  at 
> org.netbeans.modules.maven.execute.CommandLineOutputHandler.setStdOut(CommandLineOutputHandler.java:146)
>  at 
> org.netbeans.modules.maven.execute.MavenCommandLineExecutor.run(MavenCommandLineExecutor.java:280)
> [catch] at 
> org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:128)



--
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-373) Netbeans sometimes freezes when showing any refactor dialog when running with jdk 1.8.0_152-b16 or later

2018-04-10 Thread Jan Lahoda (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432706#comment-16432706
 ] 

Jan Lahoda commented on NETBEANS-373:
-

Regarding the old CVS, some have it, but it is fairly difficult to work with 
that (as it was never converted to hg/git; and also the layout of some things 
changed several times).

 

I think Austin's question is valid: why is showDialog synchronized? Looking at 
the CVS, there's no real help with that (the method appears to be synchronized 
from the beginning, but there may be some much bigger context I am missing.). 
And it does not appear to be very meaningful (the lock is locked for the whole 
duration the dialog is showing - why do that? That feels like asking for 
trouble (the dialog may be showing for a long time). My suggestion would be to 
delete the synchronized flag from the showDialog method; and also delete the 
"synchronized (this)" from cancelActionPerformed.

> Netbeans sometimes freezes when showing any refactor dialog when running with 
> jdk 1.8.0_152-b16 or later
> 
>
> Key: NETBEANS-373
> URL: https://issues.apache.org/jira/browse/NETBEANS-373
> Project: NetBeans
>  Issue Type: Bug
>  Components: java - Refactoring
>Affects Versions: 8.2, 9.0
> Environment: Mac
>Reporter: Austin Stephens
>Priority: Blocker
> Attachments: Screen Shot 2018-04-02 at 11.22.11 AM.png, Screen Shot 
> 2018-04-02 at 11.23.15 AM.png, nbpresenter.diff
>
>
> Sometimes (or almost always), when you try to do some refactor action, 
> NetBeans freezes. It appears that a lock is obtained on a panel when the 
> dialog is shown, and the AppKit Thread tries to get the lock while trying to 
> add an accessible listener to it.
> AppKit Thread:
> {code:java}
> Container.addContainerListener:2142    
> Container$AccessibleAWTContainer.addPropertyChangeListener:3885    
> JComponent$AccessibleJComponent.addPropertyChangeListener:3765    
> Hidden Source Calls    
> CAccessible.addNotificationListeners:102    
> CAccessible.:84    
> CAccessible.getCAccessible:60
> {code}
> EDT Thread:
> {code:java}
> Hidden Source Calls    
> Unsafe.park    
> LockSupport.park:194    
> AbstractQueuedSynchronizer$ConditionObject.await:2062    
> EventQueue.getNextEvent:557    
> EventDispatchThread.pumpOneEventForFilters:173    
> EventDispatchThread.pumpEventsForFilter:124    
> EventDispatchThread.pumpEventsForFilter:117    
> WaitDispatchSupport$2.run:190    
> WaitDispatchSupport$4.run:235    
> WaitDispatchSupport$4.run:233    
> AccessController.doPrivileged    
> WaitDispatchSupport.enter:233    
> Dialog.show:1070    
> NbPresenter.superShow:1060    
> NbPresenter.doShow:1110    
> NbPresenter.run:1082    
> NbPresenter.run:105    
> NbMutexEventProvider$Event.doEventAccess:115    
> NbMutexEventProvider$Event.readAccess:75    
> LazyMutexImplementation.readAccess:71    
> Mutex.readAccess:193    
> NbPresenter.show:1067    
> Component.show:1669    
> Component.setVisible:1616    
> Window.setVisible:1017    
> Dialog.setVisible:1005    
> ParametersPanel.showDialog:674    
> RefactoringPanel.refresh:660    
> RefactoringPanel.:144    
> UI.openRefactoringUI:61    
> ContextAnalyzer$4.show:648    
> ContextAnalyzer$TextComponentTask.run:369    
> RefactoringActionsProvider.doFindUsages:232    
> ActionsImplementationFactory.doFindUsages:91    
> WhereUsedAction.performAction:52    
> RefactoringGlobalAction$ContextAction.actionPerformed:172    
> TopComponent.processKeyBinding:1151    
> JComponent.processKeyBindings:2963    
> JComponent.processKeyEvent:2863    
> Component.processEvent:6355    
> Container.processEvent:2259    
> Component.dispatchEventImpl:4961    
> Container.dispatchEventImpl:2317    
> Component.dispatchEvent:4793    
> KeyboardFocusManager.redispatchEvent:1955    
> DefaultKeyboardFocusManager.dispatchKeyEvent:827    
> DefaultKeyboardFocusManager.preDispatchKeyEvent:1096    
> DefaultKeyboardFocusManager.typeAheadAssertions:966    
> DefaultKeyboardFocusManager.dispatchEvent:792    
> Component.dispatchEventImpl:4842    
> Container.dispatchEventImpl:2317    
> Window.dispatchEventImpl:2758    
> Component.dispatchEvent:4793    
> EventQueue.dispatchEventImpl:766    
> EventQueue.access$500:97    
> EventQueue$3.run:717    
> EventQueue$3.run:711    
> AccessController.doPrivileged    
> ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege:89    
> ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege:99    
> EventQueue$4.run:739    
> EventQueue$4.run:737    
> AccessController.doPrivileged    
> ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege:89    
> EventQueue.dispatchEvent:736    
> TimableEventQueue.dispatchEvent:136    
>

[jira] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)


[ 
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432425#comment-16432425
 ] 

Geertjan Wielenga commented on NETBEANS-58:
---

 Can you reproduce with earlier/later JDKs, with JDK 9, 10?

> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt, 
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact 
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users 
> will typically experience this on startup. It was reported in old bug tracker 
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of 
> the reported [JDK-8032832 
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very 
> clever IMO: it puts a lock on the classloader, thus introducing a range of 
> other problems, one of them being that NetNeans IDE or NetBeans Platform will 
> likely freeze on startup when it attempts a network operation. The fact that 
> their fix made things worse (while no doubt fixing the original issue) has 
> been reported as 
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course 
> only happens if there's a network proxy on the path which uses this type of 
> authentication. Also known as SPNEGO. This form of authentication is in my 
> experience very common in corporate networks, in particular those that base 
> themselves on the Microsoft stack. But a person on Oracle's own internal 
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to 
> provide 'credentials' (a Kerberos token) to the network proxy on its own. 
> SPNEGO is really designed to be seamless and promptless. Support for it was 
> added in Java 6. But later on Microsoft tightened the desktop security around 
> obtaining the so-called 'session token' and the JDK folks were never able to 
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in 
> real-life, SPNEGO in the JRE on Windows is no longer promptless:  it will be 
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It 
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is 
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be 
> able to find the following in your thread dump:
> {noformat}
>at 
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked  (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break 
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
>  of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered 
>  Authenticator is invoked. If the Authenticator does work on another thread, 
> that other thread has a need for some classloading and the current thread 
> needs to wait for the result of that thread, then bum!, there's a deadlock 
> between the two threads. This means the lock on the classloader will never be 
> released and it will ultimately affect other threads, such as the AWT 
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what 
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I 
> described and will thus be triggering the deadlock. More precisely it will 
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator 
> does something wrong?  No, of course it doesn't. The real problem is the lock 
> on the classloader. It is actually virtually impossible to design an 
> Authenticator which doesn't trigger this problem. You cannot predict when 
> classloading is needed. In fact it is very likely to be needed when 
> application is still not "warm", i.e. during startup.
> h3. WORKAROUNDS
> *#1*
> If on Windows: Setting the following registry key:
>

[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)


[ 
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432425#comment-16432425
 ] 

Geertjan Wielenga edited comment on NETBEANS-58 at 4/10/18 3:08 PM:


 Can you reproduce with earlier/later JDKs, with JDK 9, 10? Can you reproduce 
it with Apache NetBeans (i.e., instead of 8.2)?


was (Author: geertjanwielenga):
 Can you reproduce with earlier/later JDKs, with JDK 9, 10?

> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt, 
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact 
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users 
> will typically experience this on startup. It was reported in old bug tracker 
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of 
> the reported [JDK-8032832 
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very 
> clever IMO: it puts a lock on the classloader, thus introducing a range of 
> other problems, one of them being that NetNeans IDE or NetBeans Platform will 
> likely freeze on startup when it attempts a network operation. The fact that 
> their fix made things worse (while no doubt fixing the original issue) has 
> been reported as 
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course 
> only happens if there's a network proxy on the path which uses this type of 
> authentication. Also known as SPNEGO. This form of authentication is in my 
> experience very common in corporate networks, in particular those that base 
> themselves on the Microsoft stack. But a person on Oracle's own internal 
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to 
> provide 'credentials' (a Kerberos token) to the network proxy on its own. 
> SPNEGO is really designed to be seamless and promptless. Support for it was 
> added in Java 6. But later on Microsoft tightened the desktop security around 
> obtaining the so-called 'session token' and the JDK folks were never able to 
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in 
> real-life, SPNEGO in the JRE on Windows is no longer promptless:  it will be 
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It 
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is 
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be 
> able to find the following in your thread dump:
> {noformat}
>at 
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked  (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break 
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
>  of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered 
>  Authenticator is invoked. If the Authenticator does work on another thread, 
> that other thread has a need for some classloading and the current thread 
> needs to wait for the result of that thread, then bum!, there's a deadlock 
> between the two threads. This means the lock on the classloader will never be 
> released and it will ultimately affect other threads, such as the AWT 
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what 
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I 
> described and will thus be triggering the deadlock. More precisely it will 
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator 
> does something wrong?  No, of course it doesn't. The real problem is the lock 
> on the classloader. It is actually virtually impossible to design an 
> Authenticator which doesn't trigger this problem. You cannot predict when 
> classloading is needed. In fact it is very likely to be

[jira] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)


[ 
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432388#comment-16432388
 ] 

Jean-Marc Borer commented on NETBEANS-58:
-

It is absolutely related to this topic: proxy authentication leads to HMI 
deadlock at start up. I am 100% sure about it, I just reproduced it now with 
JDK 1.8 162 and Netbeans 8.2. None of the workarounds mentioned here and at 
https://netbeans.org/bugzilla/show_bug.cgi?id=262883 work. Neither the 
ProxySelector V2 plugin 
(http://plugins.netbeans.org/plugin/55258/proxyselector-v2) nor the Network 
authenticator plugin 
(http://plugins.netbeans.org/plugin/72976/network-authenticator) are fixing the 
issue. 

I am exactly in the same situation as all the people here waiting for a JDK (?) 
fix.

> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt, 
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact 
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users 
> will typically experience this on startup. It was reported in old bug tracker 
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of 
> the reported [JDK-8032832 
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very 
> clever IMO: it puts a lock on the classloader, thus introducing a range of 
> other problems, one of them being that NetNeans IDE or NetBeans Platform will 
> likely freeze on startup when it attempts a network operation. The fact that 
> their fix made things worse (while no doubt fixing the original issue) has 
> been reported as 
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course 
> only happens if there's a network proxy on the path which uses this type of 
> authentication. Also known as SPNEGO. This form of authentication is in my 
> experience very common in corporate networks, in particular those that base 
> themselves on the Microsoft stack. But a person on Oracle's own internal 
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to 
> provide 'credentials' (a Kerberos token) to the network proxy on its own. 
> SPNEGO is really designed to be seamless and promptless. Support for it was 
> added in Java 6. But later on Microsoft tightened the desktop security around 
> obtaining the so-called 'session token' and the JDK folks were never able to 
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in 
> real-life, SPNEGO in the JRE on Windows is no longer promptless:  it will be 
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It 
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is 
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be 
> able to find the following in your thread dump:
> {noformat}
>at 
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked  (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break 
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
>  of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered 
>  Authenticator is invoked. If the Authenticator does work on another thread, 
> that other thread has a need for some classloading and the current thread 
> needs to wait for the result of that thread, then bum!, there's a deadlock 
> between the two threads. This means the lock on the classloader will never be 
> released and it will ultimately affect other threads, such as the AWT 
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what 
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I 
> described and will thus be triggering the deadlock. More precisely it will 
> happen when NbAuthenticator calls

[jira] [Created] (NETBEANS-636) Apache Podling Website Checks

2018-04-10 Thread Antonio Vieiro (JIRA)

Antonio Vieiro created NETBEANS-636:
---

 Summary: Apache Podling Website Checks
 Key: NETBEANS-636
 URL: https://issues.apache.org/jira/browse/NETBEANS-636
 Project: NetBeans
  Issue Type: Task
  Components: website
Reporter: Antonio Vieiro
Assignee: Antonio Vieiro


The Apache Podling Website Checks are failing for NetBeans

See https://whimsy.apache.org/pods/project/netbeans

These tests are in beta stage, but it would be good to pass as many tests as 
possible.

The podling disclaimer, for instance, is currently split in different 
paragraphs for better readability, but these automatic tests do not handle this 
properly.



--
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-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)


[ 
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432203#comment-16432203
 ] 

Geertjan Wielenga commented on NETBEANS-58:
---

Not sure if this is the same problem as what this issue is about. Make sure 
you're using the solution described here to check for sure that this doesn't 
solve the problem. I'd advise creating a new issue and providing step by step 
instructions for reproducing this.

> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt, 
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact 
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users 
> will typically experience this on startup. It was reported in old bug tracker 
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of 
> the reported [JDK-8032832 
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very 
> clever IMO: it puts a lock on the classloader, thus introducing a range of 
> other problems, one of them being that NetNeans IDE or NetBeans Platform will 
> likely freeze on startup when it attempts a network operation. The fact that 
> their fix made things worse (while no doubt fixing the original issue) has 
> been reported as 
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course 
> only happens if there's a network proxy on the path which uses this type of 
> authentication. Also known as SPNEGO. This form of authentication is in my 
> experience very common in corporate networks, in particular those that base 
> themselves on the Microsoft stack. But a person on Oracle's own internal 
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to 
> provide 'credentials' (a Kerberos token) to the network proxy on its own. 
> SPNEGO is really designed to be seamless and promptless. Support for it was 
> added in Java 6. But later on Microsoft tightened the desktop security around 
> obtaining the so-called 'session token' and the JDK folks were never able to 
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in 
> real-life, SPNEGO in the JRE on Windows is no longer promptless:  it will be 
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It 
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is 
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be 
> able to find the following in your thread dump:
> {noformat}
>at 
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked  (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break 
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
>  of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered 
>  Authenticator is invoked. If the Authenticator does work on another thread, 
> that other thread has a need for some classloading and the current thread 
> needs to wait for the result of that thread, then bum!, there's a deadlock 
> between the two threads. This means the lock on the classloader will never be 
> released and it will ultimately affect other threads, such as the AWT 
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what 
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I 
> described and will thus be triggering the deadlock. More precisely it will 
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator 
> does something wrong?  No, of course it doesn't. The real problem is the lock 
> on the classloader. It is actually virtually impossible to design an 
> Authenticator which doesn't trigger this problem. You cannot predict when 
> classloading is needed. In fact it is very likely to be

[jira] [Assigned] (NETBEANS-491) Turn off exception reporter


 [ 
https://issues.apache.org/jira/browse/NETBEANS-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiří Kovalský reassigned NETBEANS-491:
--

Assignee: Jiří Kovalský  (was: Reema Taneja)

> Turn off exception reporter
> ---
>
> Key: NETBEANS-491
> URL: https://issues.apache.org/jira/browse/NETBEANS-491
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - Code
>Affects Versions: 9.0
>Reporter: Jiří Kovalský
>Assignee: Jiří Kovalský
>Priority: Critical
>  Labels: pull-request-available
> Attachments: report_error.png
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Apache NetBeans 9.0 tries to send exception reports even though the backend 
> infrastructure is no longer available. In case of an exception NetBeans IDE 
> should no longer display the *Review and Report Problem* button and report 
> URL in the error message should instead read: 
> [https://issues.apache.org/jira/secure/CreateIssue!default.jspa]
> *Steps to reproduce:*
>  # Launch development build #20180320 of Apache NetBeans 9.0.
>  # Type e.g. _properties_ into the *Search* field in the upper right corner 
> of the IDE.
>  # Press Enter.
> *Expected:*
> Due to another bug NetBeans opens an exception dialog which contains old link 
> to _issues.html_ page and *Review and Report Problem* button.
> *Actual:*
> NetBeans opens an exception dialog only instructing user to report the 
> exception to Apache Jira and no *Review and Report Problem* button is shown.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

[jira] [Resolved] (NETBEANS-462) Java Help class cannot be found


 [ 
https://issues.apache.org/jira/browse/NETBEANS-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Geertjan Wielenga resolved NETBEANS-462.

Resolution: Won't Fix

> Java Help class cannot be found
> ---
>
> Key: NETBEANS-462
> URL: https://issues.apache.org/jira/browse/NETBEANS-462
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Help System
>Reporter: Zoran Sevarac
>Priority: Critical
>
> While building NetBeans Platform application that has module with Java Help 
> I'm getting the following exception:
> An annotation processor threw an uncaught exception.
> Consult the following stack trace for details.
> java.lang.NoClassDefFoundError: com/sun/java/help/search/Indexer
>     at 
> org.netbeans.modules.javahelp.HelpSetRegistrationProcessor.handleProcess(HelpSetRegistrationProcessor.java:145)
>     at 
> org.openide.filesystems.annotations.LayerGeneratingProcessor.process(LayerGeneratingProcessor.java:99)
>     at com.sun.tools.javac
> 
> There is no this problem with NetBeans 8.2
>  



--
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-633) GUI Builder fails to load sub-panel with NLS / Respource bundle


[ 
https://issues.apache.org/jira/browse/NETBEANS-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432191#comment-16432191
 ] 

Geertjan Wielenga commented on NETBEANS-633:


Best to include a small application or point to a GitHub repo with a small 
application that reproduces this.

> GUI Builder fails to load sub-panel with NLS / Respource bundle
> ---
>
> Key: NETBEANS-633
> URL: https://issues.apache.org/jira/browse/NETBEANS-633
> Project: NetBeans
>  Issue Type: Bug
>  Components: guibuilder - Binding, guibuilder - Natural Layout
>Affects Versions: 8.2, 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-release-205-on-20180202)
> Java: 10; Java HotSpot(TM) 64-Bit Server VM 10+46
> Runtime: Java(TM) SE Runtime Environment 10+46
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_AU (nb)
> User directory: Z:\tmp\.other\user\netbeans\v09.00-beta\FourAbs
> Cache directory: Z:\tmp\.other\cache\netbeans\FourAbs-09
>Reporter: will mason
>Priority: Critical
>  Labels: GUI, MissingResourceException, Swing, 
> internationalization
> Attachments: image-2018-04-10-10-32-31-818.png
>
>
> h2. expected
>  * To be able to view and edit parent JPanel screen in Netbeans GUI Builder.
>  * This should be possible no matter what the sub-panels do
>  * If/when a resource is missing or unresolved some kind of place holder can 
> be used
> h2. actual
>  * We have several GUI JPanel-s which act as containers for a "details" 
> screen, sub-panel layouts.
>  * In one of the sub-panels we introduced a resource bundle to display 
> options for check-boxes.. 
>  * This details screen works as a sub-panel at run-time.
>  * This details screen works as in the GUI designer/builder fine.
>  * However whenever we load the parent panel, the container it fails with a 
> *{{MissingResourceException}}*.
> !image-2018-04-10-10-32-31-818.png!
>  
>  * This is somewhat of a SHOW STOPPER as far as internationalisation goes for 
> reusable GUI components I'm afraid.
>  * The situation is quite mysterious as well since the Resource file is 
> found, loaded and displayed by the detail JPanel screen which is IN THE SAME 
> java Package at runtime and design time.
>  * The resource bundle itself is in the {{resources/bundles}} folder of 
> common library (Gradle directory layout) and is "fixed" so to speak at design 
> time.
>  * I believe there is some fundamental flaw here because you must have 
> parents able to load sub-components with or without any resource strings.
>  
> h2. supporting information
> {noformat}
> --[ *stacktrace* ]--
> java.util.MissingResourceException: Can't find bundle for base name 
> bundles/SpaAssurancesText, locale en_AU
>     at 
> java.base/java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:2055)
>     at 
> java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1689)
>     at 
> java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1593)
>     at 
> java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1556)
>     at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:857)
>     at 
> au.com.fourtel.fourabs.client.spas.JPanelSpaDetails.initComponents(JPanelSpaDetails.java:1608)
>     at 
> au.com.fourtel.fourabs.client.spas.JPanelSpaDetails.(JPanelSpaDetails.java:148)
>     at 
> au.com.fourtel.fourabs.client.spas.JPanelSpaDetails.(JPanelSpaDetails.java:141)
>     at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>  Method)
>     at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>     at 
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>     at 
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:488)
>     at java.base/java.lang.Class.newInstance(Class.java:560)
>     at 
> org.netbeans.modules.form.CreationFactory.createDefaultInstance(CreationFactory.java:155)
>     at 
> org.netbeans.modules.form.RADComponent.createBeanInstance(RADComponent.java:227)
>     at 
> org.netbeans.modules.form.RADComponent.initInstance(RADComponent.java:166)
>     at 
> org.netbeans.modules.form.GandalfPersistenceManager.restoreComponent(GandalfPersistenceManager.java:755)
>     at 
> org.netbeans.modules.form.GandalfPersistenceManager.loadComponent(GandalfPersistenceManager.java:943)
>     at 
> org.netbeans.modules.form.GandalfPersistenceManager.restoreComponent(GandalfPersistenceManager.java:799)
>     at 
> org.netbeans.modules.form.GandalfPersistenceManager.loadComponent(GandalfPersistenceManager.java:943)
>     at 
>

[incubator-netbeans] branch master updated: #517: Prevent a project to be a subproject of itself (#490)

This is an automated email from the ASF dual-hosted git repository.

geertjan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-netbeans.git


The following commit(s) were added to refs/heads/master by this push:
 new 1bbc9ef  #517: Prevent a project to be a subproject of itself (#490)
1bbc9ef is described below

commit 1bbc9ef6fda1bcdbede134ff2982f31b4b8c77b2
Author: Jaroslav Tulach 
AuthorDate: Tue Apr 10 14:31:54 2018 +0200

#517: Prevent a project to be a subproject of itself (#490)
---
 .../modules/apisupport/project/queries/SubprojectProviderImpl.java   | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/apisupport.ant/src/org/netbeans/modules/apisupport/project/queries/SubprojectProviderImpl.java
 
b/apisupport.ant/src/org/netbeans/modules/apisupport/project/queries/SubprojectProviderImpl.java
index 5ae73d0..f2a363d 100644
--- 
a/apisupport.ant/src/org/netbeans/modules/apisupport/project/queries/SubprojectProviderImpl.java
+++ 
b/apisupport.ant/src/org/netbeans/modules/apisupport/project/queries/SubprojectProviderImpl.java
@@ -153,6 +153,7 @@ public final class SubprojectProviderImpl implements 
SubprojectProvider {
 }
 }
 }
+s.remove(project);
 return s;
 }
 

-- 
To stop receiving notification emails like this one, please contact
geert...@apache.org.

-
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

[incubator-netbeans] branch master updated: Adjusting should-stop parameter to javac to recent changes. (#489)

This is an automated email from the ASF dual-hosted git repository.

geertjan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-netbeans.git


The following commit(s) were added to refs/heads/master by this push:
 new 0561334  Adjusting should-stop parameter to javac to recent changes. 
(#489)
0561334 is described below

commit 056133456ef0326c031fede2080325d3da8395fd
Author: Jan Lahoda 
AuthorDate: Tue Apr 10 14:31:24 2018 +0200

Adjusting should-stop parameter to javac to recent changes. (#489)
---
 .../src/org/netbeans/modules/java/source/parsing/JavacParser.java   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/java.source.base/src/org/netbeans/modules/java/source/parsing/JavacParser.java
 
b/java.source.base/src/org/netbeans/modules/java/source/parsing/JavacParser.java
index 8d5e178..78dc9c1 100644
--- 
a/java.source.base/src/org/netbeans/modules/java/source/parsing/JavacParser.java
+++ 
b/java.source.base/src/org/netbeans/modules/java/source/parsing/JavacParser.java
@@ -820,7 +820,7 @@ public class JavacParser extends Parser {
 options.add("-XDsave-parameter-names");   // NOI18N, javac runs inside 
the IDE
 options.add("-parameters");   // NOI18N, save and read parameter names
 options.add("-XDsuppressAbortOnBadClassFile");   // NOI18N, when a 
class file cannot be read, produce an error type instead of failing with an 
exception
-options.add("--should-stop:at=GENERATE");   // NOI18N, parsing should 
not stop in phase where an error is found
+options.add("-XDshould-stop.at=GENERATE");   // NOI18N, parsing should 
not stop in phase where an error is found
 options.add("-g:source"); // NOI18N, Make the compiler to maintian 
source file info
 options.add("-g:lines"); // NOI18N, Make the compiler to maintain line 
table
 options.add("-g:vars");  // NOI18N, Make the compiler to maintain 
local variables table

-- 
To stop receiving notification emails like this one, please contact
geert...@apache.org.

-
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-554) NetBeans hangs when restarting profiler after disabling profiling points


 [ 
https://issues.apache.org/jira/browse/NETBEANS-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiří Kovalský updated NETBEANS-554:
---
Priority: Major  (was: Minor)

> NetBeans hangs when restarting profiler after disabling profiling points
> 
>
> Key: NETBEANS-554
> URL: https://issues.apache.org/jira/browse/NETBEANS-554
> Project: NetBeans
>  Issue Type: Bug
>  Components: profiler - IDE
>Affects Versions: 9.0
>Reporter: Glenn Holmer
>Priority: Major
>
> Create a profiling point and verify that it works.
> Stop profiler.
> In profiler dropdown, deselect "Use Defined Profiling Points" checkbox.
> Restart profiler; NetBeans hangs and must be restarted.



--
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] [Comment Edited] (NETBEANS-554) NetBeans hangs when restarting profiler after disabling profiling points


[ 
https://issues.apache.org/jira/browse/NETBEANS-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432156#comment-16432156
 ] 

Jiří Kovalský edited comment on NETBEANS-554 at 4/10/18 12:25 PM:
--

Can somebody reliably reproduce this issue? If yes, can you please provide your 
setup and steps to reproduce? Also, please include full thread dump when the 
hang occurs. Thanks!


was (Author: jkovalsky):
Can somebody reliably reproduce this issue? If yes, can you please provide your 
setup and steps to reproduce? Thanks!

> NetBeans hangs when restarting profiler after disabling profiling points
> 
>
> Key: NETBEANS-554
> URL: https://issues.apache.org/jira/browse/NETBEANS-554
> Project: NetBeans
>  Issue Type: Bug
>  Components: profiler - IDE
>Affects Versions: 9.0
>Reporter: Glenn Holmer
>Priority: Minor
>
> Create a profiling point and verify that it works.
> Stop profiler.
> In profiler dropdown, deselect "Use Defined Profiling Points" checkbox.
> Restart profiler; NetBeans hangs and must be restarted.



--
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-491) Turn off exception reporter

2018-04-10 Thread Reema Taneja (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432173#comment-16432173
 ] 

Reema Taneja commented on NETBEANS-491:
---

Jirka, Please let me know the new location for ERROR_URL. As discussed above 
please remove the submit button and reword the message on the new page. Thanks,

> Turn off exception reporter
> ---
>
> Key: NETBEANS-491
> URL: https://issues.apache.org/jira/browse/NETBEANS-491
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - Code
>Affects Versions: 9.0
>Reporter: Jiří Kovalský
>Assignee: Reema Taneja
>Priority: Critical
>  Labels: pull-request-available
> Attachments: report_error.png
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Apache NetBeans 9.0 tries to send exception reports even though the backend 
> infrastructure is no longer available. In case of an exception NetBeans IDE 
> should no longer display the *Review and Report Problem* button and report 
> URL in the error message should instead read: 
> [https://issues.apache.org/jira/secure/CreateIssue!default.jspa]
> *Steps to reproduce:*
>  # Launch development build #20180320 of Apache NetBeans 9.0.
>  # Type e.g. _properties_ into the *Search* field in the upper right corner 
> of the IDE.
>  # Press Enter.
> *Expected:*
> Due to another bug NetBeans opens an exception dialog which contains old link 
> to _issues.html_ page and *Review and Report Problem* button.
> *Actual:*
> NetBeans opens an exception dialog only instructing user to report the 
> exception to Apache Jira and no *Review and Report Problem* button is shown.



--
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-554) NetBeans hangs when restarting profiler after disabling profiling points


[ 
https://issues.apache.org/jira/browse/NETBEANS-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432156#comment-16432156
 ] 

Jiří Kovalský commented on NETBEANS-554:


Can somebody reliably reproduce this issue? If yes, can you please provide your 
setup and steps to reproduce? Thanks!

> NetBeans hangs when restarting profiler after disabling profiling points
> 
>
> Key: NETBEANS-554
> URL: https://issues.apache.org/jira/browse/NETBEANS-554
> Project: NetBeans
>  Issue Type: Bug
>  Components: profiler - IDE
>Affects Versions: 9.0
>Reporter: Glenn Holmer
>Priority: Minor
>
> Create a profiling point and verify that it works.
> Stop profiler.
> In profiler dropdown, deselect "Use Defined Profiling Points" checkbox.
> Restart profiler; NetBeans hangs and must be restarted.



--
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-617) Cyclic dependency dialog box appears while it shouldn't


 [ 
https://issues.apache.org/jira/browse/NETBEANS-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jaroslav Tulach closed NETBEANS-617.

Resolution: Fixed

I was expecting the problem I am trying to fix in 
https://github.com/apache/incubator-netbeans/pull/490 is general and can appear 
anywhere. Thanks for pointing this out.

> Cyclic dependency dialog box appears while it shouldn't
> ---
>
> Key: NETBEANS-617
> URL: https://issues.apache.org/jira/browse/NETBEANS-617
> Project: NetBeans
>  Issue Type: Bug
>  Components: apisupport - Project
>Affects Versions: 9.0
> Environment: MacOSX
>Reporter: John Kostaras
>Assignee: Jaroslav Tulach
>Priority: Major
> Fix For: 9.0
>
> Attachments: Screen Shot 2018-04-06 at 17.08.53.png
>
>
> Following [[API Support] Window 
> Wizard|http://netbeans-vm.apache.org/synergy/client/app/#/specification/207] 
> Test specification, Create Top Component Window Test Case, the created 
> TopComponent contains errors.
> Trying to resolve the errors by adding the missing modules, the attached 
> error is displayed.
> It is very weird how this error appears. I started with a clean NB 9 beta 
> (incubator) (i.e. clean cache, plugins, settings etc.). After having run the 
> Ant-based NB Suite test specification, step 5 "Creating a New Window" was 
> executed without any issues.
> After finishing the Ant-based NB Suite test specification and started the 
> [[API Support] Window 
> Wizard|http://netbeans-vm.apache.org/synergy/client/app/#/specification/207] 
> Test specification, this issue appeared. 
> It could be that it works OK only the first time that a TopComponent is 
> created, and after that the cyclic dependency issue appears. It could be that 
> the issue appears after a module suite is created. 
> In any case, the error should not be displayed as there are no cyclic 
> dependencies with the remaining modules (that need to be added) with the 
> three modules that were added to the project (Lookup API, Base Utilities API 
> and Utilities API).
>  



--
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-617) Cyclic dependency dialog box appears while it shouldn't


 [ 
https://issues.apache.org/jira/browse/NETBEANS-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jaroslav Tulach reassigned NETBEANS-617:


Assignee: Jaroslav Tulach

> Cyclic dependency dialog box appears while it shouldn't
> ---
>
> Key: NETBEANS-617
> URL: https://issues.apache.org/jira/browse/NETBEANS-617
> Project: NetBeans
>  Issue Type: Bug
>  Components: apisupport - Project
>Affects Versions: 9.0
> Environment: MacOSX
>Reporter: John Kostaras
>Assignee: Jaroslav Tulach
>Priority: Major
> Fix For: 9.0
>
> Attachments: Screen Shot 2018-04-06 at 17.08.53.png
>
>
> Following [[API Support] Window 
> Wizard|http://netbeans-vm.apache.org/synergy/client/app/#/specification/207] 
> Test specification, Create Top Component Window Test Case, the created 
> TopComponent contains errors.
> Trying to resolve the errors by adding the missing modules, the attached 
> error is displayed.
> It is very weird how this error appears. I started with a clean NB 9 beta 
> (incubator) (i.e. clean cache, plugins, settings etc.). After having run the 
> Ant-based NB Suite test specification, step 5 "Creating a New Window" was 
> executed without any issues.
> After finishing the Ant-based NB Suite test specification and started the 
> [[API Support] Window 
> Wizard|http://netbeans-vm.apache.org/synergy/client/app/#/specification/207] 
> Test specification, this issue appeared. 
> It could be that it works OK only the first time that a TopComponent is 
> created, and after that the cyclic dependency issue appears. It could be that 
> the issue appears after a module suite is created. 
> In any case, the error should not be displayed as there are no cyclic 
> dependencies with the remaining modules (that need to be added) with the 
> three modules that were added to the project (Lookup API, Base Utilities API 
> and Utilities API).
>  



--
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-568) New Archetype wizard Test Case fails to create project


 [ 
https://issues.apache.org/jira/browse/NETBEANS-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Geertjan Wielenga reassigned NETBEANS-568:
--

Assignee: Geertjan Wielenga

> New Archetype wizard Test Case fails to create project
> --
>
> Key: NETBEANS-568
> URL: https://issues.apache.org/jira/browse/NETBEANS-568
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Maven
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-linux-386-on-20180402)
> Java: 10; Java HotSpot(TM) 64-Bit Server VM 10+46
> Runtime: Java(TM) SE Runtime Environment 10+46
> System: Linux version 4.15.14 running on amd64; UTF-8; en_US (nb)
> User directory: /home/alied/.netbeans/beta
> Cache directory: /home/alied/.cache/netbeans/beta
>Reporter: Alied Pérez Martínez
>Assignee: Geertjan Wielenga
>Priority: Blocker
>  Labels: maven
>
> The test case "New Archetype wizard" fails to create the requested project
> build log:
> {noformat}
> cd /home/alied/NetBeansProjects/netcat90; 
> JAVA_HOME=/home/alied/Downloads/jdk-10 
> /home/alied/Downloads/netbeans/java/maven/bin/mvn 
> -DarchetypeGroupId=org.jvnet.hudson.tools 
> -DarchetypeArtifactId=maven-hpi-plugin -DarchetypeVersion=3.0.1 
> -DarchetypeRepository=https://repo.maven.apache.org/maven2/ 
> -DgroupId=com.mycompany -DartifactId=MvnSampleProject -Dversion=1.0-SNAPSHOT 
> -Dpackage=com.mycompany.mvnsampleproject 
> -Dbasedir=/home/alied/NetBeansProjects/netcat90 -Darchetype.interactive=false 
> --batch-mode archetype:generate
> Scanning for projects...
> 
> 
> Building Maven Stub Project (No POM) 1
> 
> >>> maven-archetype-plugin:2.3:generate (default-cli) > generate-sources @ 
> >>> standalone-pom >>>
> <<< maven-archetype-plugin:2.3:generate (default-cli) < generate-sources @ 
> standalone-pom <<<
> --- maven-archetype-plugin:2.3:generate (default-cli) @ standalone-pom ---
> Generating project in Batch mode
> Archetype defined by properties
> 
> Using following parameters for creating project from Old (1.x) Archetype: 
> maven-hpi-plugin:3.0.1
> 
> Parameter: basedir, Value: /home/alied/NetBeansProjects/netcat90
> Parameter: package, Value: com.mycompany.mvnsampleproject
> Parameter: groupId, Value: com.mycompany
> Parameter: artifactId, Value: MvnSampleProject
> Parameter: packageName, Value: com.mycompany.mvnsampleproject
> Parameter: version, Value: 1.0-SNAPSHOT
> 
> BUILD FAILURE
> 
> Total time: 1.011 s
> Finished at: 2018-04-02T15:34:28-03:00
> Final Memory: 12M/54M
> 
> Failed to execute goal 
> org.apache.maven.plugins:maven-archetype-plugin:2.3:generate (default-cli) on 
> project standalone-pom: Directory MvnSampleProject already exists - please 
> run from a clean directory -> [Help 1]
> To see the full stack trace of the errors, re-run Maven with the -e switch.
> Re-run Maven using the -X switch to enable full debug logging.
> For more information about the errors and possible solutions, please read the 
> following articles:
> [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> {noformat}
> No files are created inside the project directory:
> {noformat}
> alied@development:~/NetBeansProjects/netcat90/MvnSampleProject$ ls -la
> total 8
> drwxr-xr-x 2 alied alied 4096 Apr  2 15:34 .
> drwxr-xr-x 3 alied alied 4096 Apr  2 15:34 ..
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

[jira] [Resolved] (NETBEANS-492) Quick Search for help throws java.lang.ClassNotFoundException


 [ 
https://issues.apache.org/jira/browse/NETBEANS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Geertjan Wielenga resolved NETBEANS-492.

Resolution: Fixed

> Quick Search for help throws java.lang.ClassNotFoundException
> -
>
> Key: NETBEANS-492
> URL: https://issues.apache.org/jira/browse/NETBEANS-492
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Help System
>Affects Versions: 9.0
>Reporter: Jiří Kovalský
>Assignee: Geertjan Wielenga
>Priority: Critical
>  Labels: pull-request-available
> Attachments: exception.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> It is not possible to search for any help in the latest development builds of 
> Apache NetBeans. IDE just throws exception [1] instead of opening a window 
> with relevant help information.
> *Steps to reproduce:*
>  # Launch development build #20180320 of Apache NetBeans 9.0.
>  # Type e.g. _properties_ into the *Search* field in the upper right corner 
> of the IDE.
>  # Press Enter.
> *Expected:*
> Standard help window is opened with relevant information.
> *Actual:*
> NetBeans opens an exception dialog.
> 
> [1] java.lang.ClassNotFoundException: javax.help.search.SearchEngine
>     at java.net.URLClassLoader.findClass(URLClassLoader.java:381) ...
> Caused: java.lang.ClassNotFoundException: javax.help.search.SearchEngine 
> starting from ModuleCL@74a3b713[org.netbeans.modules.javahelp] with possible 
> defining loaders null and declared parents 
> [org.netbeans.MainImpl$BootClassLoader@87aac27, 
> ModuleCL@73eccb6d[org.openide.nodes] ...
> [snip]



--
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] [Comment Edited] (NETBEANS-517) Portable HTML UI wizard is broken


[ 
https://issues.apache.org/jira/browse/NETBEANS-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432106#comment-16432106
 ] 

Jaroslav Tulach edited comment on NETBEANS-517 at 4/10/18 11:43 AM:


Cyclic dependency fixed by 
https://github.com/apache/incubator-netbeans/pull/490 - John can you please 
approve the pull request?


was (Author: jtulach):
Cyclic dependency fixed by https://github.com/apache/incubator-netbeans/pull/490

> Portable HTML UI wizard is broken
> -
>
> Key: NETBEANS-517
> URL: https://issues.apache.org/jira/browse/NETBEANS-517
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - HTML4J
>Reporter: Jaroslav Tulach
>Assignee: Jaroslav Tulach
>Priority: Major
>
> In NB 9 beta (the one used for NetCAT), I created a new module and followed 
> the wizard as you advised New -> Module Development -> Portable HTML UI. I 
> 've got my java and html file and the following dependencies: "Base Utilities 
> API", "HTML Context" and "JSON Model in Java". Of course there are errors, 
> and when I try to add missing dependencies, e.g. "HTML UI API" I get the 
> error that this would create a cyclic dependency.



--
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-491) Turn off exception reporter


[ 
https://issues.apache.org/jira/browse/NETBEANS-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432110#comment-16432110
 ] 

Geertjan Wielenga commented on NETBEANS-491:


Looks good to me, maybe 'Apache NetBeans' rather than 'the NetBeans project'.

> Turn off exception reporter
> ---
>
> Key: NETBEANS-491
> URL: https://issues.apache.org/jira/browse/NETBEANS-491
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - Code
>Affects Versions: 9.0
>Reporter: Jiří Kovalský
>Assignee: Reema Taneja
>Priority: Critical
>  Labels: pull-request-available
> Attachments: report_error.png
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Apache NetBeans 9.0 tries to send exception reports even though the backend 
> infrastructure is no longer available. In case of an exception NetBeans IDE 
> should no longer display the *Review and Report Problem* button and report 
> URL in the error message should instead read: 
> [https://issues.apache.org/jira/secure/CreateIssue!default.jspa]
> *Steps to reproduce:*
>  # Launch development build #20180320 of Apache NetBeans 9.0.
>  # Type e.g. _properties_ into the *Search* field in the upper right corner 
> of the IDE.
>  # Press Enter.
> *Expected:*
> Due to another bug NetBeans opens an exception dialog which contains old link 
> to _issues.html_ page and *Review and Report Problem* button.
> *Actual:*
> NetBeans opens an exception dialog only instructing user to report the 
> exception to Apache Jira and no *Review and Report Problem* button is shown.



--
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-517) Portable HTML UI wizard is broken


[ 
https://issues.apache.org/jira/browse/NETBEANS-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432106#comment-16432106
 ] 

Jaroslav Tulach commented on NETBEANS-517:
--

Cyclic dependency fixed by https://github.com/apache/incubator-netbeans/pull/490

> Portable HTML UI wizard is broken
> -
>
> Key: NETBEANS-517
> URL: https://issues.apache.org/jira/browse/NETBEANS-517
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - HTML4J
>Reporter: Jaroslav Tulach
>Assignee: Jaroslav Tulach
>Priority: Major
>
> In NB 9 beta (the one used for NetCAT), I created a new module and followed 
> the wizard as you advised New -> Module Development -> Portable HTML UI. I 
> 've got my java and html file and the following dependencies: "Base Utilities 
> API", "HTML Context" and "JSON Model in Java". Of course there are errors, 
> and when I try to add missing dependencies, e.g. "HTML UI API" I get the 
> error that this would create a cyclic dependency.



--
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

[incubator-netbeans] branch master updated: Fixing 'downgrading to 1.8' log messages by producing module bootpath in Maven even when module-info is not present; and propagating the module bootpath as

This is an automated email from the ASF dual-hosted git repository.

geertjan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-netbeans.git


The following commit(s) were added to refs/heads/master by this push:
 new 9c49dc1  Fixing 'downgrading to 1.8' log messages by producing module 
bootpath in Maven even when module-info is not present; and propagating the 
module bootpath as needed in Maven persistence. (#486)
9c49dc1 is described below

commit 9c49dc1f62493c66dad5971911de3386e0705e3f
Author: Jan Lahoda 
AuthorDate: Tue Apr 10 13:33:19 2018 +0200

Fixing 'downgrading to 1.8' log messages by producing module bootpath in 
Maven even when module-info is not present; and propagating the module bootpath 
as needed in Maven persistence. (#486)
---
 maven.persistence/nbproject/project.xml|  2 +-
 .../persistence/EntityClassScopeProviderImpl.java  | 13 +++
 .../maven/persistence/PersistenceScopeImpl.java| 13 +++
 .../maven/classpath/ClassPathProviderImpl.java |  2 +-
 .../maven/classpath/ClassPathProviderImplTest.java | 26 ++
 5 files changed, 46 insertions(+), 10 deletions(-)

diff --git a/maven.persistence/nbproject/project.xml 
b/maven.persistence/nbproject/project.xml
index 5b75867..b9d667f 100644
--- a/maven.persistence/nbproject/project.xml
+++ b/maven.persistence/nbproject/project.xml
@@ -58,7 +58,7 @@
 
 
 1
-1.5
+1.36
 
 
 
diff --git 
a/maven.persistence/src/org/netbeans/modules/maven/persistence/EntityClassScopeProviderImpl.java
 
b/maven.persistence/src/org/netbeans/modules/maven/persistence/EntityClassScopeProviderImpl.java
index c747c25..edeab2f 100644
--- 
a/maven.persistence/src/org/netbeans/modules/maven/persistence/EntityClassScopeProviderImpl.java
+++ 
b/maven.persistence/src/org/netbeans/modules/maven/persistence/EntityClassScopeProviderImpl.java
@@ -20,6 +20,7 @@
 package org.netbeans.modules.maven.persistence;
 
 import org.netbeans.api.java.classpath.ClassPath;
+import org.netbeans.api.java.classpath.JavaClassPathConstants;
 import org.netbeans.api.project.Project;
 import org.netbeans.modules.j2ee.metadata.model.api.MetadataModel;
 import org.netbeans.modules.j2ee.persistence.api.EntityClassScope;
@@ -50,10 +51,14 @@ public class EntityClassScopeProviderImpl implements 
EntityClassScopeProvider {
 private synchronized EntityMappingsMetadataModelHelper getHelper() {
 if (helper == null) {
 ProjectSourcesClassPathProvider cp = 
project.getLookup().lookup(ProjectSourcesClassPathProvider.class);
-helper = EntityMappingsMetadataModelHelper.create(
-cp.getProjectSourcesClassPath(ClassPath.BOOT),
-cp.getProjectSourcesClassPath(ClassPath.COMPILE),
-cp.getProjectSourcesClassPath(ClassPath.SOURCE));
+helper = new 
EntityMappingsMetadataModelHelper.Builder(cp.getProjectSourcesClassPath(ClassPath.BOOT))
+
.setModuleBootPath(cp.getProjectSourcesClassPath(JavaClassPathConstants.MODULE_BOOT_PATH))
+.setClassPath(cp.getProjectSourcesClassPath(ClassPath.COMPILE))
+
.setModuleCompilePath(cp.getProjectSourcesClassPath(JavaClassPathConstants.MODULE_COMPILE_PATH))
+
.setModuleClassPath(cp.getProjectSourcesClassPath(JavaClassPathConstants.MODULE_CLASS_PATH))
+.setSourcePath(cp.getProjectSourcesClassPath(ClassPath.SOURCE))
+//The CP provider does not support: 
JavaClassPathConstants.MODULE_SOURCE_PATH
+.build();
 }
 return helper;
 }
diff --git 
a/maven.persistence/src/org/netbeans/modules/maven/persistence/PersistenceScopeImpl.java
 
b/maven.persistence/src/org/netbeans/modules/maven/persistence/PersistenceScopeImpl.java
index 8b0d830..e44a2ad 100644
--- 
a/maven.persistence/src/org/netbeans/modules/maven/persistence/PersistenceScopeImpl.java
+++ 
b/maven.persistence/src/org/netbeans/modules/maven/persistence/PersistenceScopeImpl.java
@@ -23,6 +23,7 @@ package org.netbeans.modules.maven.persistence;
 
 import 
org.netbeans.modules.maven.api.classpath.ProjectSourcesClassPathProvider;
 import org.netbeans.api.java.classpath.ClassPath;
+import org.netbeans.api.java.classpath.JavaClassPathConstants;
 import org.netbeans.modules.j2ee.metadata.model.api.MetadataModel;
 import 
org.netbeans.modules.j2ee.persistence.api.metadata.orm.EntityMappingsMetadata;
 import org.netbeans.modules.j2ee.persistence.spi.PersistenceLocationProvider;
@@ -111,10 +112,14 @@ public class PersistenceScopeImpl implements 
PersistenceScopeImplementation
 }
 
 private EntityMappingsMetadataModelHelper createEntityMappingsHelper() {
-return EntityMappingsMetadataModelHelper.create(
-

[incubator-netbeans] branch master updated: netbeans-480: ConvertToDiamondBulkHint disabled for var type variable initialization (#487)

This is an automated email from the ASF dual-hosted git repository.

geertjan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-netbeans.git


The following commit(s) were added to refs/heads/master by this push:
 new 125510a  netbeans-480: ConvertToDiamondBulkHint disabled for var type 
variable initialization (#487)
125510a is described below

commit 125510a0b4acd6c92aeab6a1d91b3394e17cc19a
Author: Arunava Sinha 
AuthorDate: Tue Apr 10 17:00:11 2018 +0530

netbeans-480: ConvertToDiamondBulkHint disabled for var type variable 
initialization (#487)
---
 .../modules/java/hints/jdk/ConvertToDiamondBulkHint.java   |  9 +
 .../java/hints/jdk/ConvertToDiamondBulkHintTest.java   | 14 ++
 2 files changed, 23 insertions(+)

diff --git 
a/java.hints/src/org/netbeans/modules/java/hints/jdk/ConvertToDiamondBulkHint.java
 
b/java.hints/src/org/netbeans/modules/java/hints/jdk/ConvertToDiamondBulkHint.java
index 57049ee..1991e5f 100644
--- 
a/java.hints/src/org/netbeans/modules/java/hints/jdk/ConvertToDiamondBulkHint.java
+++ 
b/java.hints/src/org/netbeans/modules/java/hints/jdk/ConvertToDiamondBulkHint.java
@@ -95,6 +95,15 @@ public class ConvertToDiamondBulkHint {
 @TriggerPattern("new $clazz<$tparams$>($params$)")
 })
 public static ErrorDescription compute(HintContext ctx) {
+// hint disabled for var type variable initialization.
+TreePath parentPath = ctx.getPath().getParentPath();
+boolean isVarInit = MatcherUtilities.matches(ctx, parentPath, "$mods$ 
$type $name = $init;");   //NOI18N
+if (isVarInit) {
+if (ctx.getInfo().getTreeUtilities().isVarType(parentPath)) {
+return null;
+}
+}
+
 if (ctx.getMultiVariables().get("$tparams$").isEmpty()) return null;
 
 TreePath clazz = ctx.getVariables().get("$clazz");
diff --git 
a/java.hints/test/unit/src/org/netbeans/modules/java/hints/jdk/ConvertToDiamondBulkHintTest.java
 
b/java.hints/test/unit/src/org/netbeans/modules/java/hints/jdk/ConvertToDiamondBulkHintTest.java
index dbf7a66..3305cc7 100644
--- 
a/java.hints/test/unit/src/org/netbeans/modules/java/hints/jdk/ConvertToDiamondBulkHintTest.java
+++ 
b/java.hints/test/unit/src/org/netbeans/modules/java/hints/jdk/ConvertToDiamondBulkHintTest.java
@@ -290,6 +290,20 @@ public class ConvertToDiamondBulkHintTest extends 
NbTestCase {
 .assertWarnings();
 }
 
+public void testConfiguration9() throws Exception {
+HintTest
+.create()
+.input("package test;\n" +
+   "public class Test {\n" +
+   "{\n" +
+   "var list = new 
java.util.LinkedList();\n" +
+   "}\n" +
+   "}\n")
+.sourceLevel("1.10")
+.run(ConvertToDiamondBulkHint.class)
+.assertWarnings();
+}
+
 static {
 TestCompilerSettings.commandLine = "-XDfind=diamond";
 }

-- 
To stop receiving notification emails like this one, please contact
geert...@apache.org.

-
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

[incubator-netbeans] branch master updated: Change category (#466)

This is an automated email from the ASF dual-hosted git repository.

geertjan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-netbeans.git


The following commit(s) were added to refs/heads/master by this push:
 new 33b2f2f  Change category (#466)
33b2f2f is described below

commit 33b2f2f8d09ee4ba858bdca627d77dc36b935723
Author: Duke Script 
AuthorDate: Tue Apr 10 13:28:41 2018 +0200

Change category (#466)

* Change category of html/java wizard

* Change category of html/java wizard

* Update description.html
---
 .../src/org/netbeans/modules/maven/htmlui/DukeScriptWizard.java   | 4 ++--
 maven.htmlui/src/org/netbeans/modules/maven/htmlui/description.html   | 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git 
a/maven.htmlui/src/org/netbeans/modules/maven/htmlui/DukeScriptWizard.java 
b/maven.htmlui/src/org/netbeans/modules/maven/htmlui/DukeScriptWizard.java
index 2308424..809188f 100644
--- a/maven.htmlui/src/org/netbeans/modules/maven/htmlui/DukeScriptWizard.java
+++ b/maven.htmlui/src/org/netbeans/modules/maven/htmlui/DukeScriptWizard.java
@@ -60,12 +60,12 @@ public class DukeScriptWizard {
 position = 133,
 page = "dukeScriptWizard.html",
 content = "dukescript.archetype",
-folder = "Project/JavaFX",
+folder = "Project/Standard",
 displayName = "#DukeScriptWizard_displayName",
 iconBase = "org/netbeans/modules/maven/htmlui/DukeHTML.png",
 description = "description.html"
 )
-@Messages("DukeScriptWizard_displayName=Java HTML5 Application")
+@Messages("DukeScriptWizard_displayName=Java Frontend Application")
 public static WizardData javafxWebViewAppWizard() {
 WizardData data = new WizardData();
 data.init(Boolean.TRUE, Boolean.TRUE, Boolean.TRUE, Boolean.TRUE);
diff --git 
a/maven.htmlui/src/org/netbeans/modules/maven/htmlui/description.html 
b/maven.htmlui/src/org/netbeans/modules/maven/htmlui/description.html
index 0873048..d9ec285 100644
--- a/maven.htmlui/src/org/netbeans/modules/maven/htmlui/description.html
+++ b/maven.htmlui/src/org/netbeans/modules/maven/htmlui/description.html
@@ -21,6 +21,7 @@
 -->
 
 
-Generates a WebView based DukeScript application
+Generates a Java application with a graphical user interface 
following the Model View View Model (MVVM) pattern. 
+Model and ViewModel are written in Java, the View is defined in HTML, 
CSS and JavaScript.
 
 

-- 
To stop receiving notification emails like this one, please contact
geert...@apache.org.

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)


[ 
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16431984#comment-16431984
 ] 

Jean-Marc Borer edited comment on NETBEANS-58 at 4/10/18 11:24 AM:
---

My comment is a backport of this bugzilla entry which is still true and 
extremely annoying for me: https://netbeans.org/bugzilla/show_bug.cgi?id=262883
If I remember well, it appeared after upgrading to JDK 1.8 121, but not 
absolutely sure, since we often had trouble with the corporate proxy and I 
first thought it was my IT team that messed it up again and I had the network 
proxy disabled. My trouble started when I wanted to check for IDE updates and 
turned the proxy settings on again. 


was (Author: jmborer):
My comment is a backport of this bugzilla entry which is still true and 
extremely annoying for me: https://netbeans.org/bugzilla/show_bug.cgi?id=262883
If I remember well, it appeared after upgrading to JDK 1.8 121, but not 
absolutely sure, since I we often had trouble with the corporate proxy and I 
first thought it was my IT team that messed it up again and I had the network 
proxy disabled. My trouble started when I wanted to check for IDE updates and 
turned the proxy settings on again. 

> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt, 
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact 
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users 
> will typically experience this on startup. It was reported in old bug tracker 
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of 
> the reported [JDK-8032832 
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very 
> clever IMO: it puts a lock on the classloader, thus introducing a range of 
> other problems, one of them being that NetNeans IDE or NetBeans Platform will 
> likely freeze on startup when it attempts a network operation. The fact that 
> their fix made things worse (while no doubt fixing the original issue) has 
> been reported as 
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course 
> only happens if there's a network proxy on the path which uses this type of 
> authentication. Also known as SPNEGO. This form of authentication is in my 
> experience very common in corporate networks, in particular those that base 
> themselves on the Microsoft stack. But a person on Oracle's own internal 
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to 
> provide 'credentials' (a Kerberos token) to the network proxy on its own. 
> SPNEGO is really designed to be seamless and promptless. Support for it was 
> added in Java 6. But later on Microsoft tightened the desktop security around 
> obtaining the so-called 'session token' and the JDK folks were never able to 
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in 
> real-life, SPNEGO in the JRE on Windows is no longer promptless:  it will be 
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It 
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is 
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be 
> able to find the following in your thread dump:
> {noformat}
>at 
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked  (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break 
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
>  of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered 
>  Authenticator is invoked. If the Authenticator does work on another thread, 
> that other thread has a need for some classloading and the current thread 
> needs to wait for the result of that thread, then bum!, there's a deadlock

[jira] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)


[ 
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16431984#comment-16431984
 ] 

Jean-Marc Borer commented on NETBEANS-58:
-

My comment is a backport of this bugzilla entry which is still true and 
extremely annoying for me: https://netbeans.org/bugzilla/show_bug.cgi?id=262883
If I remember well, it appeared after upgrading to JDK 1.8 121, but not 
absolutely sure, since I we often had trouble with the corporate proxy and I 
first thought it was my IT team that messed it up again and I had the network 
proxy disabled. My trouble started when I wanted to check for IDE updates and 
turned the proxy settings on again. 

> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt, 
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact 
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users 
> will typically experience this on startup. It was reported in old bug tracker 
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of 
> the reported [JDK-8032832 
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very 
> clever IMO: it puts a lock on the classloader, thus introducing a range of 
> other problems, one of them being that NetNeans IDE or NetBeans Platform will 
> likely freeze on startup when it attempts a network operation. The fact that 
> their fix made things worse (while no doubt fixing the original issue) has 
> been reported as 
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course 
> only happens if there's a network proxy on the path which uses this type of 
> authentication. Also known as SPNEGO. This form of authentication is in my 
> experience very common in corporate networks, in particular those that base 
> themselves on the Microsoft stack. But a person on Oracle's own internal 
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to 
> provide 'credentials' (a Kerberos token) to the network proxy on its own. 
> SPNEGO is really designed to be seamless and promptless. Support for it was 
> added in Java 6. But later on Microsoft tightened the desktop security around 
> obtaining the so-called 'session token' and the JDK folks were never able to 
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in 
> real-life, SPNEGO in the JRE on Windows is no longer promptless:  it will be 
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It 
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is 
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be 
> able to find the following in your thread dump:
> {noformat}
>at 
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked  (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break 
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
>  of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered 
>  Authenticator is invoked. If the Authenticator does work on another thread, 
> that other thread has a need for some classloading and the current thread 
> needs to wait for the result of that thread, then bum!, there's a deadlock 
> between the two threads. This means the lock on the classloader will never be 
> released and it will ultimately affect other threads, such as the AWT 
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what 
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I 
> described and will thus be triggering the deadlock. More precisely it will 
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator 
> does something wrong?  No, of course it doesn't. The real

[jira] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)


[ 
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16431972#comment-16431972
 ] 

Geertjan Wielenga commented on NETBEANS-58:
---

"We started running into this issue (Frozen stack trace with Java x64 8_162 and 
Netbeans 8.2 Win7x64) . No idea, why we never saw it before."

Can you be more specific? When did you start running into this and what does 
"before" mean? "Before" what, before what date or what?

> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt, 
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact 
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users 
> will typically experience this on startup. It was reported in old bug tracker 
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of 
> the reported [JDK-8032832 
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very 
> clever IMO: it puts a lock on the classloader, thus introducing a range of 
> other problems, one of them being that NetNeans IDE or NetBeans Platform will 
> likely freeze on startup when it attempts a network operation. The fact that 
> their fix made things worse (while no doubt fixing the original issue) has 
> been reported as 
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course 
> only happens if there's a network proxy on the path which uses this type of 
> authentication. Also known as SPNEGO. This form of authentication is in my 
> experience very common in corporate networks, in particular those that base 
> themselves on the Microsoft stack. But a person on Oracle's own internal 
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to 
> provide 'credentials' (a Kerberos token) to the network proxy on its own. 
> SPNEGO is really designed to be seamless and promptless. Support for it was 
> added in Java 6. But later on Microsoft tightened the desktop security around 
> obtaining the so-called 'session token' and the JDK folks were never able to 
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in 
> real-life, SPNEGO in the JRE on Windows is no longer promptless:  it will be 
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It 
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is 
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be 
> able to find the following in your thread dump:
> {noformat}
>at 
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked  (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break 
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
>  of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered 
>  Authenticator is invoked. If the Authenticator does work on another thread, 
> that other thread has a need for some classloading and the current thread 
> needs to wait for the result of that thread, then bum!, there's a deadlock 
> between the two threads. This means the lock on the classloader will never be 
> released and it will ultimately affect other threads, such as the AWT 
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what 
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I 
> described and will thus be triggering the deadlock. More precisely it will 
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator 
> does something wrong?  No, of course it doesn't. The real problem is the lock 
> on the classloader. It is actually virtually impossible to design an 
> Authenticator which doesn't trigger this problem. You cannot predict when 
> classloading is needed. In fact it is very

[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)


[ 
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16431958#comment-16431958
 ] 

Jean-Marc Borer edited comment on NETBEANS-58 at 4/10/18 9:14 AM:
--

We started running into this issue (Frozen stack trace with Java x64 8_162 and 
Netbeans 8.2 Win7x64) . No idea, why we never saw it before. Maybe someone 
changed something in the corporate proxy, but this is completely out of our 
reach.

Once Netbeans is frozen, VisualVM can no longer properly interact with it.

I managed to monitor NB with VisualVM before the freeze: thread view update. 
When NB freezes, thread view is also blocked, but I can still do a thread 
dump...

VisualVM also suffers from this freezing bug as well as any NB platform 
application. No really astonishing since it based on NB platform.

When we use "Manual Proxy Settings" from "No Proxy" it first works. Then we 
close the IDE and reopen it. It starts, but as soon as I try an action using 
the classloader such as opening a menu, it freezes completely.
 
I managed to get a thread dump and the conclusion is similar to the ones here 
(I will attach it too).

Unfortunately, https://bitbucket.org/phansson/netbeansproxy2 does not solve the 
issue at all. Same behaviour. 

After further analysis of my second thread [^nb-freeze-dump.txt] one can see 
that the issue lies in:

1) "Thread-8" takes the lock 0xc0d64370 in 
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
 Then further down the call stack, it creates a task that will wait forever 
reading the a value from Keyring at 
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thred "org.netbeans.api.keyring.Keyring" where it 
tries to get the lock on 0xc0d64370. Boom deadlock...

This blocks the lock on 0xc0d64370 for every other thread including the 
AWT Event one.

Workaround #1 doesn't work. The only solution currently is to work offline with 
"No proxy" or use a local proxy such as CNTLM, which then allows corporate 
proxy authentication and doesn't lead to this Keyring/Authenticator deadlock. 

[1] https://netbeans.org/bugzilla/show_bug.cgi?id=262883
[2] http://cntlm.sourceforge.net/


was (Author: jmborer):
We started running into this issue (Frozen stack trace with Java x64 8_162 and 
Netbeans 8.2 Win7x64) . No idea, why we never saw it before. Maybe someone 
changed something in the corporate proxy, but this is completely out of our 
reach.

Once Netbeans is frozen, VisualVM can no longer properly interact with it.

I managed to monitor NB with VisualVM before the freeze: thread view update. 
When NB freezes, thread view is also blocked, but I can still do a thread 
dump...

VisualVM also suffers from this freezing bug as well as any NB platform 
application. No really astonishing since it based on NB platform.

When we use "Manual Proxy Settings" from "No Proxy" it first works. Then we 
close the IDE and reopen it. It starts, but as soon as I try an action using 
the classloader such as opening a menu, it freezes completely.
 
I managed to get a thread dump and the conclusion is similar to the ones here 
(I will attach it too).

Unfortunately, https://bitbucket.org/phansson/netbeansproxy2 does not solve the 
issue at all. Same behaviour. The only solution currently is to work offline 
with "No proxy" or use a local proxy such as CNTLM, which then allows corporate 
proxy authentication and doesn't lead to this Keyring/Authenticator deadlock.

After further analysis of my second thread [^nb-freeze-dump.txt] one can see 
that the issue lies in:

1) "Thread-8" takes the lock 0xc0d64370 in 
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
 Then further down the call stack, it creates a task that will wait forever 
reading the a value from Keyring at 
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thred "org.netbeans.api.keyring.Keyring" where it 
tries to get the lock on 0xc0d64370. Boom deadlock...

This blocks the lock on 0xc0d64370 for every other thread including the 
AWT Event one.

[1] https://netbeans.org/bugzilla/show_bug.cgi?id=262883
[2] http://cntlm.sourceforge.net/

> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt, 
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to

[jira] [Updated] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Marc Borer updated NETBEANS-58:

Priority: Critical  (was: Major)

> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt, 
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact 
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users 
> will typically experience this on startup. It was reported in old bug tracker 
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of 
> the reported [JDK-8032832 
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very 
> clever IMO: it puts a lock on the classloader, thus introducing a range of 
> other problems, one of them being that NetNeans IDE or NetBeans Platform will 
> likely freeze on startup when it attempts a network operation. The fact that 
> their fix made things worse (while no doubt fixing the original issue) has 
> been reported as 
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course 
> only happens if there's a network proxy on the path which uses this type of 
> authentication. Also known as SPNEGO. This form of authentication is in my 
> experience very common in corporate networks, in particular those that base 
> themselves on the Microsoft stack. But a person on Oracle's own internal 
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to 
> provide 'credentials' (a Kerberos token) to the network proxy on its own. 
> SPNEGO is really designed to be seamless and promptless. Support for it was 
> added in Java 6. But later on Microsoft tightened the desktop security around 
> obtaining the so-called 'session token' and the JDK folks were never able to 
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in 
> real-life, SPNEGO in the JRE on Windows is no longer promptless:  it will be 
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It 
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is 
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be 
> able to find the following in your thread dump:
> {noformat}
>at 
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked  (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break 
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
>  of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered 
>  Authenticator is invoked. If the Authenticator does work on another thread, 
> that other thread has a need for some classloading and the current thread 
> needs to wait for the result of that thread, then bum!, there's a deadlock 
> between the two threads. This means the lock on the classloader will never be 
> released and it will ultimately affect other threads, such as the AWT 
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what 
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I 
> described and will thus be triggering the deadlock. More precisely it will 
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator 
> does something wrong?  No, of course it doesn't. The real problem is the lock 
> on the classloader. It is actually virtually impossible to design an 
> Authenticator which doesn't trigger this problem. You cannot predict when 
> classloading is needed. In fact it is very likely to be needed when 
> application is still not "warm", i.e. during startup.
> h3. WORKAROUNDS
> *#1*
> If on Windows: Setting the following registry key:
> {{HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters\allowtgtsessionkey}}
> to {{true}} will allow the JRE to obtain

[jira] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)


[ 
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16431958#comment-16431958
 ] 

Jean-Marc Borer commented on NETBEANS-58:
-

We started running into this issue (Frozen stack trace with Java x64 8_162 and 
Netbeans 8.2 Win7x64) . No idea, why we never saw it before. Maybe someone 
changed something in the corporate proxy, but this is completely out of our 
reach.

Once Netbeans is frozen, VisualVM can no longer properly interact with it.

I managed to monitor NB with VisualVM before the freeze: thread view update. 
When NB freezes, thread view is also blocked, but I can still do a thread 
dump...

VisualVM also suffers from this freezing bug as well as any NB platform 
application. No really astonishing since it based on NB platform.

When we use "Manual Proxy Settings" from "No Proxy" it first works. Then we 
close the IDE and reopen it. It starts, but as soon as I try an action using 
the classloader such as opening a menu, it freezes completely.
 
I managed to get a thread dump and the conclusion is similar to the ones here 
(I will attach it too).

Unfortunately, https://bitbucket.org/phansson/netbeansproxy2 does not solve the 
issue at all. Same behaviour. The only solution currently is to work offline 
with "No proxy" or use a local proxy such as CNTLM, which then allows corporate 
proxy authentication and doesn't lead to this Keyring/Authenticator deadlock.

After further analysis of my second thread [^nb-freeze-dump.txt] one can see 
that the issue lies in:

1) "Thread-8" takes the lock 0xc0d64370 in 
sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
 Then further down the call stack, it creates a task that will wait forever 
reading the a value from Keyring at 
org.netbeans.api.keyring.Keyring.read(Keyring.java:144)
2) This task is posted on thred "org.netbeans.api.keyring.Keyring" where it 
tries to get the lock on 0xc0d64370. Boom deadlock...

This blocks the lock on 0xc0d64370 for every other thread including the 
AWT Event one.

[1] https://netbeans.org/bugzilla/show_bug.cgi?id=262883
[2] http://cntlm.sourceforge.net/

> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Proxy
>Affects Versions: 8.2, 9.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Major
> Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt, 
> netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact 
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users 
> will typically experience this on startup. It was reported in old bug tracker 
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of 
> the reported [JDK-8032832 
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very 
> clever IMO: it puts a lock on the classloader, thus introducing a range of 
> other problems, one of them being that NetNeans IDE or NetBeans Platform will 
> likely freeze on startup when it attempts a network operation. The fact that 
> their fix made things worse (while no doubt fixing the original issue) has 
> been reported as 
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course 
> only happens if there's a network proxy on the path which uses this type of 
> authentication. Also known as SPNEGO. This form of authentication is in my 
> experience very common in corporate networks, in particular those that base 
> themselves on the Microsoft stack. But a person on Oracle's own internal 
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to 
> provide 'credentials' (a Kerberos token) to the network proxy on its own. 
> SPNEGO is really designed to be seamless and promptless. Support for it was 
> added in Java 6. But later on Microsoft tightened the desktop security around 
> obtaining the so-called 'session token' and the JDK folks were never able to 
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in 
> real-life, SPNEGO in the JRE on Windows is no longer promptless:  it will be 
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It 
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is 
> most likely working just fine and the bug will never be experienced.

[jira] [Updated] (NETBEANS-635) Surefire 2.19.1 stacktrace hyperlinks don't work with Maven


 [ 
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Marc Borer updated NETBEANS-635:
-
Description: 
When running tests with surefire 2.19.1, to see the stacktrace, make sure the 
plugin is configured as following:
{code:java}

    org.apache.maven.plugins
    maven-surefire-plugin
     2.19.1
     
         false
     
 {code}
Then you will see the stacktraces in the output. Even though they are 
recognized as being hyperlinks, when you click on them, nothing happens and in 
the status bar of Netbeans it says that the source file cannot be found.

This works perfectly with surefire 2.18.1. Something changed between these 
versions.

Related topics:

[1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]

[2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]

[3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]

 

 

> Surefire 2.19.1 stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Maven
>Affects Versions: 8.2
>Reporter: Jean-Marc Borer
>Priority: Major
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the 
> plugin is configured as following:
> {code:java}
> 
>     org.apache.maven.plugins
>     maven-surefire-plugin
>      2.19.1
>      
>          false
>      
>  {code}
> Then you will see the stacktraces in the output. Even though they are 
> recognized as being hyperlinks, when you click on them, nothing happens and 
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these 
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>  
>  



--
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-635) Surefire 2.19.1 stacktrace hyperlinks don't work with Maven