[incubator-netbeans-website] branch master updated (7950d3f -> ea3c13b)

[geertjan]

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

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


from 7950d3f  Update report-issue.asciidoc
 add 9e00b8a  Add issues.html for in IDE issue dialog
 new ea3c13b  Merge pull request #36 from apache/issue-dialog

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 netbeans.apache.org/src/content/nb/9.0/issues.html | 23 ++
 1 file changed, 23 insertions(+)
 create mode 100644 netbeans.apache.org/src/content/nb/9.0/issues.html

-- 
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-website] 01/01: Merge pull request #36 from apache/issue-dialog

[geertjan]

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-website.git

commit ea3c13b820e0b21fb355d79cb4ff8fbde6e9cb71
Merge: 7950d3f 9e00b8a
Author: Geertjan Wielenga 
AuthorDate: Thu Apr 26 07:40:58 2018 +0200

Merge pull request #36 from apache/issue-dialog

Add issues.html for in IDE issue dialog

 netbeans.apache.org/src/content/nb/9.0/issues.html | 23 ++
 1 file changed, 23 insertions(+)

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

[lbruun (JIRA)]

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

lbruun edited comment on NETBEANS-58 at 4/26/18 5:24 AM:
-

Geertjan Wielenga wrote:
{quote}It is super critical in a specific subset of scenarios, I for one have 
never (working within and without a corporate proxy) have never encountered it, 
as far as I am aware. Has this problem always been in NetBeans and is the only 
solution "to implement more fine grained classloaders"
{quote}
At least two questions there:
 # *Why you've never encountered it?* In my experience sites that deploy a 
proxy with Negotiate/Kerberos are more often than not MS shops, i.e. they use 
AD as the base of everything. Is that really where you've been?  Also you have 
to use a Windows workstation for the problem to occur (due to Oracle's 
historical resistance to implement native support for SSPI on Windows ... it is 
a long story, but in essence in means that the Kerberos implementation in Java 
SE for Windows is extremely crippled when used in desktop scenarios : Java on 
Windows cannot automatically obtain a Kerberos ticket which means it is forced 
to invoke the Authenticator. On Mac OS X and Linux this would all be seamless, 
no need to invoke the Authenticator and therefore no deadlock).
 # *Has the problem always existed?* No, not always. The problem was introduced 
as a consequence of a [JDK bug 
fix|https://bugs.openjdk.java.net/browse/JDK-8032832] which was first 
introduced in Java 8u25 and later backported. This fix works fine for the JDK 
itself because their classloaders use the [Java 7 (and onwards) new 
functionality for 
classloaders|https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html].
 The NB Platform doesn't.  The JDK folks phrase it like this: "Synchronization 
in the {{ClassLoader}} class was previously heavy-handed, or in technical 
terms, _not sufficiently granular_. A request to load a class synchronized on 
the entire {{ClassLoader}} object, which made it prone to deadlock.". That is 
exactly the problem in the NB Platform's classloaders. (discussed in 
NETBEANS-106).

 

In summary: There are a number of conditions that must exist for the freeze bug 
to surface for a user:
 # The site uses a proxy which uses Negotiate/Kerberos for authentication. As 
this method was largely 'invented' by Microsoft and later standardized as an 
RFC, you see this very often on MS centric sites. (it is essentially the same 
as what Microsoft cleverly refers to as "Windows Integrated Authentication", 
clever because it leads people to be believe that this form of seamless 
authentication is only possible on Windows)
 # Workstation is Windows (not Mac OS X, not Linux) *
 # Lastly, if the Platform or IDE user experiences the bug "without having 
touched anything" (which is quite likely) then it is because the Platform 
automatically picks up the proxy from the OS/InternetExplorer settings. Hence 
users will just experience that the Platform app or IDE hangs the first time 
they ever try to use it. Ouch!

Honestly, I think one of the reasons why the problem gets little traction is 
because both JDK developers and NB developers have removed themselves somewhat 
from parts of their user base by using Mac OS X  or Linux as their desktop as 
opposed to Windows. I'm partly guilty myself :P

 *) I suppose theoretically it can happen on Mac OS X and Linux too if you have 
a defunct Kerberos configuration. It is just that on Windows the Java/Kerberos 
stack is by default "defunct" (as explained)

 


was (Author: lbruun):
Geertjan Wielenga wrote:
{quote}It is super critical in a specific subset of scenarios, I for one have 
never (working within and without a corporate proxy) have never encountered it, 
as far as I am aware. Has this problem always been in NetBeans and is the only 
solution "to implement more fine grained classloaders"
{quote}
At least two questions there:
 # *Why you've never encountered it?* In my experience sites that deploy a 
proxy with Negotiate/Kerberos are more often than not MS shops, i.e. they use 
AD as the base of everything. Is that really where you've been?  Also you have 
to use a Windows workstation for the problem to occur (due to Oracle's 
historical resistance to implement native support for SSPI on Windows ... it is 
a long story, but in essence in means that the Kerberos implementation in Java 
SE for Windows is extremely crippled when used in desktop scenarios : Java on 
Windows cannot automatically obtain a Kerberos ticket which means it is forced 
to invoke the Authenticator. On Mac OS X and Linux this would all be seamless, 
no need to invoke the Authenticator and therefore no deadlock). 
 # *Has the problem always existed?* No, not always. The problem was introduced 
as a consequence of a [JDK bug 
fix|https://bugs.openjdk.java.net/browse/JDK-8032832] which was 

[incubator-netbeans] branch master updated: [NETBEANS-710] Ensure the javac's module system is initialized before constructing scope, fixing DeclarativeHintsParserTest tests on JDK 11 by using the def

[jlahoda]

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

jlahoda 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 9a102db  [NETBEANS-710] Ensure the javac's module system is 
initialized before constructing scope, fixing DeclarativeHintsParserTest tests 
on JDK 11 by using the default platform's bootclasspath implicitly rather than 
explicitly.
9a102db is described below

commit 9a102db55c58820f92c94a190528b2ed6ff727ed
Author: Jan Lahoda 
AuthorDate: Sun Apr 22 10:43:31 2018 +0200

[NETBEANS-710] Ensure the javac's module system is initialized before 
constructing scope, fixing DeclarativeHintsParserTest tests on JDK 11 by using 
the default platform's bootclasspath implicitly rather than explicitly.
---
 java.hints.declarative/nbproject/project.xml |  4 
 .../hints/declarative/ClassPathProviderImpl.java |  6 ++
 .../hints/declarative/DeclarativeHintsParser.java|  1 +
 .../modules/java/hints/declarative/Hacks.java|  3 +--
 .../hints/declarative/MethodInvocationContext.java   | 14 +++---
 .../modules/java/TestJavaPlatformProviderImpl.java   | 20 ++--
 6 files changed, 13 insertions(+), 35 deletions(-)

diff --git a/java.hints.declarative/nbproject/project.xml 
b/java.hints.declarative/nbproject/project.xml
index 8908c51..09d333e 100644
--- a/java.hints.declarative/nbproject/project.xml
+++ b/java.hints.declarative/nbproject/project.xml
@@ -373,6 +373,10 @@
 
 
 
+
org.netbeans.modules.java.j2seplatform
+
+
+
 
org.netbeans.modules.java.lexer
 
 
diff --git 
a/java.hints.declarative/src/org/netbeans/modules/java/hints/declarative/ClassPathProviderImpl.java
 
b/java.hints.declarative/src/org/netbeans/modules/java/hints/declarative/ClassPathProviderImpl.java
index 9a13ba4..4d0d37b 100644
--- 
a/java.hints.declarative/src/org/netbeans/modules/java/hints/declarative/ClassPathProviderImpl.java
+++ 
b/java.hints.declarative/src/org/netbeans/modules/java/hints/declarative/ClassPathProviderImpl.java
@@ -33,10 +33,8 @@ public class ClassPathProviderImpl implements 
ClassPathProvider {
 
 public ClassPath findClassPath(FileObject file, String type) {
 if ("hint".equals(file.getExt())) {
-if (ClassPath.BOOT.equals(type)) {
-return MethodInvocationContext.computeClassPaths()[0];
-} else if (ClassPath.COMPILE.equals(type)) {
-return MethodInvocationContext.computeClassPaths()[1];
+if (ClassPath.COMPILE.equals(type)) {
+return MethodInvocationContext.computeCompileClassPath();
 }
 }
 
diff --git 
a/java.hints.declarative/src/org/netbeans/modules/java/hints/declarative/DeclarativeHintsParser.java
 
b/java.hints.declarative/src/org/netbeans/modules/java/hints/declarative/DeclarativeHintsParser.java
index ddfe296..bf4729c 100644
--- 
a/java.hints.declarative/src/org/netbeans/modules/java/hints/declarative/DeclarativeHintsParser.java
+++ 
b/java.hints.declarative/src/org/netbeans/modules/java/hints/declarative/DeclarativeHintsParser.java
@@ -477,6 +477,7 @@ public class DeclarativeHintsParser {
 JavaSource.create(cpInfo).runUserActionTask(new 
Task() {
 @SuppressWarnings("fallthrough")
 public void run(CompilationController parameter) throws Exception {
+parameter.toPhase(JavaSource.Phase.RESOLVED);
 if (invocation == null || invocation.length() == 0) {
 //XXX: report an error
 return ;
diff --git 
a/java.hints.declarative/src/org/netbeans/modules/java/hints/declarative/Hacks.java
 
b/java.hints.declarative/src/org/netbeans/modules/java/hints/declarative/Hacks.java
index fd10dad..7ff8c27 100644
--- 
a/java.hints.declarative/src/org/netbeans/modules/java/hints/declarative/Hacks.java
+++ 
b/java.hints.declarative/src/org/netbeans/modules/java/hints/declarative/Hacks.java
@@ -75,13 +75,12 @@ public class Hacks {
 
 private static final String SOURCE_LEVEL = "1.8"; //TODO: could be 
possibly inferred from the current Java platform
 
-public static Map compile(ClassPath boot, ClassPath 
compile, final String code) throws IOException {
+public static Map compile(ClassPath compile, final String 
code) throws IOException {
 DiagnosticListener devNull = new 
DiagnosticListener() {
 public void report(Diagnostic 
diagnostic) {}
 };
 StandardJavaFileManager sjfm = 
ToolProvider.getSystemJavaCompiler().getStandardFileManager(devNull, null, 
null);
 
-

[jira] [Resolved] (NETBEANS-1) nb-javac

[JIRA]

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

Matthias Bläsing resolved NETBEANS-1.
-
   Resolution: Fixed
Fix Version/s: 9.0

nb-javac was split out from the project and is provided as a plugin from the 
update-center. The IDE was modified to support working with the JDK javac and 
suggests to install nb-javac at first start-up.

I would consider this issue resolved by this.

> nb-javac 
> -
>
> Key: NETBEANS-1
> URL: https://issues.apache.org/jira/browse/NETBEANS-1
> Project: NetBeans
>  Issue Type: Bug
>Reporter: Emilian Bold
>Priority: Major
>  Labels: cleanup
> Fix For: 9.0
>
>
> The Java editor needs lib.javacapi and lib.javacimpl which are produced from 
> the nb-javac repository.
> This repository is a javac fork with some NetBeans / editor-specific patches.
> nb-javac is under GPL w/ CPE so will not be usable as is in an Apache project.



--
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-734) False positive of possible null pointer derefernce in catch

[Austin Stephens (JIRA)]

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

Austin Stephens updated NETBEANS-734:
-
Description: 
{code:java}
    private void someMethod(){}
    private void falsePositive(){
        try{
            someMethod();
        }
        catch(RuntimeException e){
            if (e instanceof NullPointerException){
                throw e;
            }
            //false positive for possible null pointer
            Throwable cause = e.getCause();
        }
    }
{code}
Is it even possible for e to be null?

  was:
{code:java}
    private void someMethod(){}
    private void falsePositive(){
        try{
            someMethod();
        }
        catch(RuntimeException e){
            if (e instanceof NullPointerException){
                throw e;
            }
            //false positive for possible null pointer
            Throwable cause = e.getCause();
        }
    }
{code}
Is it event possible for e to be null?


> False positive of possible null pointer derefernce in catch
> ---
>
> Key: NETBEANS-734
> URL: https://issues.apache.org/jira/browse/NETBEANS-734
> Project: NetBeans
>  Issue Type: Bug
>  Components: java - Source
>Affects Versions: 9.0
>Reporter: Austin Stephens
>Priority: Major
>
> {code:java}
>     private void someMethod(){}
>     private void falsePositive(){
>         try{
>             someMethod();
>         }
>         catch(RuntimeException e){
>             if (e instanceof NullPointerException){
>                 throw e;
>             }
>             //false positive for possible null pointer
>             Throwable cause = e.getCause();
>         }
>     }
> {code}
> Is it even possible for e to be null?



--
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-734) False positive of possible null pointer derefernce in catch

[Austin Stephens (JIRA)]

Austin Stephens created NETBEANS-734:


 Summary: False positive of possible null pointer derefernce in 
catch
 Key: NETBEANS-734
 URL: https://issues.apache.org/jira/browse/NETBEANS-734
 Project: NetBeans
  Issue Type: Bug
  Components: java - Source
Affects Versions: 9.0
Reporter: Austin Stephens


{code:java}
    private void someMethod(){}
    private void falsePositive(){
        try{
            someMethod();
        }
        catch(RuntimeException e){
            if (e instanceof NullPointerException){
                throw e;
            }
            //false positive for possible null pointer
            Throwable cause = e.getCause();
        }
    }
{code}
Is it event possible for e to be null?



--
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-564) Opening .form/.java file raises exception from java parser

[JIRA]

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

Matthias Bläsing resolved NETBEANS-564.
---
   Resolution: Duplicate
Fix Version/s: 9.0

NETBEANS-654 has the same backtrace and testing with the fix for that issue 
fixes also this issue. Resolving as duplicate.

> Opening .form/.java file raises exception from java parser
> --
>
> Key: NETBEANS-564
> URL: https://issues.apache.org/jira/browse/NETBEANS-564
> Project: NetBeans
>  Issue Type: Bug
>  Components: java - Source
>Affects Versions: 9.0
>Reporter: Matthias Bläsing
>Priority: Major
> Fix For: 9.0
>
> Attachments: NotifyHtmlPanel.dump
>
>
> h2. Error
> When opening a .form/.java file combination I get an exception, that is 
> raised from the java parser:
> {noformat}
> Annotation: An error occurred during parsing of 
> '/tmp/vcs-1522660054567/vcs-1522660054568/NotifyHtmlPanel.java'. Please 
> report a bug against java/source and attach dump file 
> '/home/matthias/src/incubator-netbeans/nbbuild/testuserdir/var/log/NotifyHtmlPanel.dump'.
> Annotation: An error occurred during parsing of 
> '/tmp/vcs-1522660054567/vcs-1522660054568/NotifyHtmlPanel.java'. Please 
> report a bug against java/source and attach dump file 
> '/home/matthias/src/incubator-netbeans/nbbuild/testuserdir/var/log/NotifyHtmlPanel.dump'.
> Annotation: An error occurred during parsing of 
> '/tmp/vcs-1522660054567/vcs-1522660054568/NotifyHtmlPanel.java'. Please 
> report a bug against java/source and attach dump file 
> '/home/matthias/src/incubator-netbeans/nbbuild/testuserdir/var/log/NotifyHtmlPanel.dump'.
> Annotation: An error occurred during parsing of 
> '/tmp/vcs-1522660054567/vcs-1522660054568/NotifyHtmlPanel.java'. Please 
> report a bug against java/source and attach dump file 
> '/home/matthias/src/incubator-netbeans/nbbuild/testuserdir/var/log/NotifyHtmlPanel.dump'.
> An error occurred during parsing of 
> '/tmp/vcs-1522660054567/vcs-1522660054568/NotifyHtmlPanel.java'. Please 
> report a bug against java/source and attach dump file 
> '/home/matthias/src/incubator-netbeans/nbbuild/testuserdir/var/log/NotifyHtmlPanel.dump'.
> An error occurred during parsing of 
> '/tmp/vcs-1522660054567/vcs-1522660054568/NotifyHtmlPanel.java'. Please 
> report a bug against java/source and attach dump file 
> '/home/matthias/src/incubator-netbeans/nbbuild/testuserdir/var/log/NotifyHtmlPanel.dump'.
> Caused: 
> org.netbeans.modules.java.source.parsing.FileObjects$InvalidFileException: 
> Invalid or deleted file: 
> /tmp/vcs-1522660054567/vcs-1522660054568/NotifyHtmlPanel.java
>     at 
> org.netbeans.modules.java.source.parsing.FileObjects.sourceFileObject(FileObjects.java:354)
>     at 
> org.netbeans.modules.java.source.parsing.FileObjects.sourceFileObject(FileObjects.java:334)
> Caused: java.lang.IllegalArgumentException
>     at 
> org.netbeans.modules.java.source.parsing.FileObjects.sourceFileObject(FileObjects.java:337)
>     at 
> org.netbeans.modules.java.source.parsing.JavacParser.createJavacTask(JavacParser.java:730)
>     at 
> org.netbeans.modules.java.source.parsing.CompilationInfoImpl.getJavacTask(CompilationInfoImpl.java:374)
> [catch] at 
> org.netbeans.modules.java.source.parsing.JavacParser.moveToPhase(JavacParser.java:580)
>     at 
> org.netbeans.modules.java.source.parsing.CompilationInfoImpl.toPhase(CompilationInfoImpl.java:361)
>     at 
> org.netbeans.api.java.source.CompilationController.toPhase(CompilationController.java:84)
>     at 
> org.netbeans.modules.java.JavaNode$IconTask$SourceIcon$1.run(JavaNode.java:443)
>     at 
> org.netbeans.modules.java.JavaNode$IconTask$SourceIcon$1.run(JavaNode.java:440)
>     at 
> org.netbeans.api.java.source.JavaSource$MultiTask.run(JavaSource.java:501)
>     at 
> org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586)
>     at 
> org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:130)
>     at 
> org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:114)
>     at 
> org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181)
>     at 
> org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178)
>     at 
> org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
>     at 
> org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
>     at 
> org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
>     at 
> org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
>     at 
> 

[jira] [Resolved] (NETBEANS-402) ClassCastException at org.netbeans.lib.profiler.server.ProfilerRuntimeCPU.getParSize()

[Gili (JIRA)]

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

Gili resolved NETBEANS-402.
---
   Resolution: Fixed
 Assignee: Gili
Fix Version/s: 9.0

Yes, this is fixed.

> ClassCastException at 
> org.netbeans.lib.profiler.server.ProfilerRuntimeCPU.getParSize()
> --
>
> Key: NETBEANS-402
> URL: https://issues.apache.org/jira/browse/NETBEANS-402
> Project: NetBeans
>  Issue Type: Bug
>  Components: profiler - Base
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-release-205-on-20180202)
> Updates: Updates available
> 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_CA (nb)
> User directory: C:\Users\Gili\AppData\Roaming\NetBeans\dev
> Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\dev
>Reporter: Gili
>Assignee: Gili
>Priority: Major
>  Labels: pull-request-available
> Fix For: 9.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> When profiling SQL queries I get the following exception consistently:
> {code}java.lang.ClassCastException: java.lang.Short cannot be cast to 
> java.lang.String
>  at 
> org.netbeans.lib.profiler.server.ProfilerRuntimeCPU.getParSize(ProfilerRuntimeCPU.java:684)
>  at 
> org.netbeans.lib.profiler.server.ProfilerRuntimeCPU.writeParametersEvent(ProfilerRuntimeCPU.java:459)
>  at 
> org.netbeans.lib.profiler.server.ProfilerRuntimeCPUFullInstr.markerMethodEntry(ProfilerRuntimeCPUFullInstr.java:92)
>  at 
> com.zaxxer.hikari.pool.HikariProxyPreparedStatement.setShort(HikariProxyPreparedStatement.java)
>  at com.querydsl.sql.types.ShortType.setValue(ShortType.java:50)
>  at com.querydsl.sql.types.ShortType.setValue(ShortType.java:27)
>  at com.querydsl.sql.Configuration.set(Configuration.java:239)
>  at com.querydsl.sql.AbstractSQLQuery.set(AbstractSQLQuery.java:210)
>  at com.querydsl.sql.AbstractSQLQuery.setParameters(AbstractSQLQuery.java:584)
>  at com.querydsl.sql.AbstractSQLQuery.iterateSingle(AbstractSQLQuery.java:365)
>  at com.querydsl.sql.AbstractSQLQuery.iterate(AbstractSQLQuery.java:342)
>  at 
> com.querydsl.sql.ProjectableSQLQuery.fetchOne(ProjectableSQLQuery.java:397)
>  at 
> com.holdmyspot.pyramid.database.row.CurrencyPairRow.getByCurrencies(CurrencyPairRow.java:132)
>  at 
> com.holdmyspot.pyramid.database.row.CurrencyPairRow.insertIfMissing(CurrencyPairRow.java:191)
>  at 
> com.holdmyspot.pyramid.server.Main$SaveToDatabase.getCurrencyPairRow(Main.java:242)
>  at 
> com.holdmyspot.pyramid.server.Main$SaveToDatabase.lambda$onOrder$2(Main.java:154)
>  at 
> java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
>  at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
>  at 
> java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
>  at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
>  at 
> java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157){code}
> This is thrown inside the application being profiled as opposed to showing up 
> in an IDE pop-up.



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

[Thomas Corte (JIRA)]

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

Thomas Corte commented on NETBEANS-373:
---

I can confirm that this still happens with
Apache NetBeans IDE Dev (Build incubator-netbeans-release-205-on-20180202).

> 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
>Assignee: Laszlo Kishalmi
>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    
> EventDispatchThread.pumpOneEventForFilters:199    
> EventDispatchThread.pumpEventsForFilter:124    
> EventDispatchThread.pumpEventsForHierarchy:113    
> EventDispatchThread.pumpEvents:109    
> EventDispatchThread.pumpEvents:101    
> EventDispatchThread.run:90   
> {code}
>  



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

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

For further information about the NetBeans mailing lists, visit:

[jira] [Comment Edited] (NETBEANS-592) Netbeans 9.0 show only the local history

[Thomas Kellerer (JIRA)]

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

Thomas Kellerer edited comment on NETBEANS-592 at 4/25/18 1:38 PM:
---

When using "Git -> Show History" from the project's window context menu, the 
Git history is displayed, however it is not displayed when using the History 
tab in the editor or when using "History -> Show History" from the context menu 
(see screenshot "git history.png")


was (Author: shammat):
When using "Git -> Show History" from the project's window context menu, the 
Git history is displayed, however it is not displayed when using the History 
tab in the editor or when using "History -> Show History" from the context menu 
(see screenshot)

> Netbeans 9.0 show only the local history
> 
>
> Key: NETBEANS-592
> URL: https://issues.apache.org/jira/browse/NETBEANS-592
> Project: NetBeans
>  Issue Type: Bug
>  Components: versioncontrol - Git
>Affects Versions: 9.0
>Reporter: Ivan Melendez
>Priority: Major
> Attachments: Screen Shot 2018-04-04 at 10.29.24 AM.png, git 
> history.png
>
>
> When you have a opened file and you need see the git history, NetBeans only 
> show the local history, not all commits. If the file don't have the local 
> history show a list empty (see screenshot)



--
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-592) Netbeans 9.0 show only the local history

[Thomas Kellerer (JIRA)]

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

Thomas Kellerer commented on NETBEANS-592:
--

When using "Git -> Show History" from the project's window context menu, the 
Git history is displayed, however it is not displayed when using the History 
tab in the editor or when using "History -> Show History" from the context menu 
(see screenshot)

> Netbeans 9.0 show only the local history
> 
>
> Key: NETBEANS-592
> URL: https://issues.apache.org/jira/browse/NETBEANS-592
> Project: NetBeans
>  Issue Type: Bug
>  Components: versioncontrol - Git
>Affects Versions: 9.0
>Reporter: Ivan Melendez
>Priority: Major
> Attachments: Screen Shot 2018-04-04 at 10.29.24 AM.png, git 
> history.png
>
>
> When you have a opened file and you need see the git history, NetBeans only 
> show the local history, not all commits. If the file don't have the local 
> history show a list empty (see screenshot)



--
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] 01/01: Merge pull request #505 from jlahoda/NETBEANS-615

[jtulach]

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

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

commit 284e056b9e74f05046e9eb0daad6f2fd84eef569
Merge: 2c1ad06 95c9c27
Author: Jaroslav Tulach 
AuthorDate: Wed Apr 25 15:25:10 2018 +0200

Merge pull request #505 from jlahoda/NETBEANS-615

[NETBEANS-615] When nb-javac is not installed, don't let CoS run, but…

 java.api.common/nbproject/project.xml  |  2 +-
 .../java/api/common/project/BaseActionProvider.java|  3 +++
 java.j2seproject/nbproject/project.xml |  2 +-
 .../modules/java/j2seproject/J2SEProjectUtil.java  |  3 ++-
 .../modules/java/source/ant/ProjectRunnerImpl.java |  4 +++-
 java.source.base/apichanges.xml| 13 +
 java.source.base/manifest.mf   |  2 +-
 java.source.base/nbproject/project.properties  |  2 +-
 .../netbeans/api/java/source/BuildArtifactMapper.java  | 11 ++-
 .../java/source/indexing/JavaCustomIndexer.java| 18 ++
 .../java/source/usages/BuildArtifactMapperImpl.java|  5 +
 .../netbeans/modules/java/source/JBrowseModule.java|  5 +++--
 maven/nbproject/project.xml|  2 +-
 .../netbeans/modules/maven/api/execute/RunUtils.java   |  3 ++-
 .../modules/maven/customizer/CompilePanel.java | 10 +-
 .../nashorn/execution/actions/ExecJSAction.java|  6 --
 16 files changed, 77 insertions(+), 14 deletions(-)


-- 
To stop receiving notification emails like this one, please contact
jtul...@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 (2c1ad06 -> 284e056)

[jtulach]

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

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


from 2c1ad06  [NETBEANS-654] Ignoring InvalidFileException while 
constructing the JavacTask, it will be thrown again and handled if needed. 
(#510)
 add ccf9061  [NETBEANS-615] When nb-javac is not installed, don't let CoS 
run, but rather suggest installing nb-javac or disabling CoS.
 add 95c9c27  [NETBEANS-615] Adding API to check if compile-on-save is 
supported, using the API in projects.
 new 284e056  Merge pull request #505 from jlahoda/NETBEANS-615

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 java.api.common/nbproject/project.xml  |  2 +-
 .../java/api/common/project/BaseActionProvider.java|  3 +++
 java.j2seproject/nbproject/project.xml |  2 +-
 .../modules/java/j2seproject/J2SEProjectUtil.java  |  3 ++-
 .../modules/java/source/ant/ProjectRunnerImpl.java |  4 +++-
 java.source.base/apichanges.xml| 13 +
 java.source.base/manifest.mf   |  2 +-
 java.source.base/nbproject/project.properties  |  2 +-
 .../netbeans/api/java/source/BuildArtifactMapper.java  | 11 ++-
 .../java/source/indexing/JavaCustomIndexer.java| 18 ++
 .../java/source/usages/BuildArtifactMapperImpl.java|  5 +
 .../netbeans/modules/java/source/JBrowseModule.java|  5 +++--
 maven/nbproject/project.xml|  2 +-
 .../netbeans/modules/maven/api/execute/RunUtils.java   |  3 ++-
 .../modules/maven/customizer/CompilePanel.java | 10 +-
 .../nashorn/execution/actions/ExecJSAction.java|  6 --
 16 files changed, 77 insertions(+), 14 deletions(-)

-- 
To stop receiving notification emails like this one, please contact
jtul...@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] [Created] (NETBEANS-733) The New JAVA LTS Phenomenon and Netbeans

[sagar (JIRA)]

sagar created NETBEANS-733:
--

 Summary: The New JAVA LTS Phenomenon and Netbeans
 Key: NETBEANS-733
 URL: https://issues.apache.org/jira/browse/NETBEANS-733
 Project: NetBeans
  Issue Type: Improvement
Affects Versions: Next
Reporter: sagar
 Fix For: Next


Java now has a new release cycle and a new terminology LTS.

Java 11 to be released in September 2018 will be designated as a LTS release.

Should NETBEANS also follow and Jump to an LTS based release cycle and have a 
Netbeans 11 LTS?

Can we have a NETBEANS 11 LTS release as early as January 2019?

 

 



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

[jmborer (JIRA)]

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

jmborer commented on NETBEANS-58:
-

Done in https://github.com/apache/incubator-netbeans/pull/2

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

[ARUNAVA SINHA (JIRA)]

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

ARUNAVA SINHA updated NETBEANS-481:
---
Labels: JDK10-LVTI pull-request-available  (was: JDK10-LVTI)

> New ErrorRule to fix compiler error on initialization of var type variable 
> with array
> -
>
> Key: NETBEANS-481
> URL: https://issues.apache.org/jira/browse/NETBEANS-481
> Project: NetBeans
>  Issue Type: Improvement
>Reporter: ARUNAVA SINHA
>Assignee: ARUNAVA SINHA
>Priority: Trivial
>  Labels: JDK10-LVTI, pull-request-available
>
> Below statement throws compiler error.
> var arr = \{1,2};
> : error: cannot infer type for local variable var k = \{ 1 , 2 }; ^
> (array initializer needs an explicit target-type)
>  
> Proposed fix would be
>  int[] arr = \{ 1, 2 };
> The fix will be provided for Numeric primitive type array or for array with 
> homogeneous members.
> a)Homogeneous type 
> 1. var arr =  \{ new Object(), new Object()};
> fix: Object[] arr = \{ new Object(), new Object()};
> 2. var arr = \{"hello", "world"};
> fix: String[] arr = \{"hello", "world"};
>  
> b)Primitive Type Numeric array 
>  var arr = \{1,2.2};
> fix: double[] arr = \{1,2.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-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)

[Geertjan Wielenga (JIRA)]

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

Geertjan Wielenga commented on NETBEANS-58:
---

[https://netbeans.apache.org/participate/submit-pr.html]

Comment and see this one for example:

https://github.com/apache/incubator-netbeans/pull/2

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

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

[jmborer (JIRA)]

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

jmborer commented on NETBEANS-58:
-

[~GeertjanWielenga] wrote:
{quote}OK, is this the following, by [~phansson], or are you referring to 
something different?
{quote}
Yes, I am referring to [~phansson] plugins:

[https://bitbucket.org/phansson/netbeansproxy2|https://bitbucket.org/phansson/netbeansnetworkauthenticator]

[https://bitbucket.org/phansson/netbeansnetworkauthenticator]
{quote}Also note that YOU are the NetBeans team, too. :) I.e., please do 
provide a PR or state what you are specifically asking for here.
{quote}
Where can I do that? Jira? Sounds like a silly question, but I am not very used 
to how participate to large OSS projects :P.

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

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

[Geertjan Wielenga (JIRA)]

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

Geertjan Wielenga edited comment on NETBEANS-58 at 4/25/18 7:41 AM:


[~jmborer]: "Conclusion: @Netbeans team, please, bundle ProxySelector and 
Netbeans Authenticator with the NB platform!!"

OK, is this the following, by [~phansson], or are you referring to something 
different?

[https://bitbucket.org/phansson/netbeansnetworkauthenticator]
 
[https://bitbucket.org/phansson/netbeansnetworkauthenticator/wiki/JDK-8068184%20Workaround]

Also note that YOU are the NetBeans team, too. :) I.e., please do provide a PR 
or state what you are specifically asking for here.


was (Author: geertjanwielenga):
[~jmborer]: "Conclusion: @Netbeans team, please, bundle ProxySelector and 
Netbeans Authenticator with the NB platform!!"

OK, is this the following, by [~phansson], or are you referring to something 
different?

[https://bitbucket.org/phansson/netbeansnetworkauthenticator]
[https://bitbucket.org/phansson/netbeansnetworkauthenticator/wiki/JDK-8068184%20Workaround]

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

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

[Stephan Raible (JIRA)]

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

Stephan Raible commented on NETBEANS-58:


I can only confirm this happening on Windows 7 and 10 OS since Linux is not 
supported in our company :(

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

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

[Geertjan Wielenga (JIRA)]

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

Geertjan Wielenga commented on NETBEANS-58:
---

[~jmborer]: "Conclusion: @Netbeans team, please, bundle ProxySelector and 
Netbeans Authenticator with the NB platform!!"

OK, is this the following, by [~phansson], or are you referring to something 
different?

[https://bitbucket.org/phansson/netbeansnetworkauthenticator]
[https://bitbucket.org/phansson/netbeansnetworkauthenticator/wiki/JDK-8068184%20Workaround]

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

[jira] [Commented] (NETBEANS-373) Netbeans sometimes freezes when showing any refactor dialog when running with jdk 1.8.0_152-b16 or later

[Thomas Corte (JIRA)]

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

Thomas Corte commented on NETBEANS-373:
---

Not sure how this issue got assigned to me, but I'm not the maintainer of this 
code, just a user. Assigned back to the previous assignee.

> 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
>Assignee: Laszlo Kishalmi
>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    
> EventDispatchThread.pumpOneEventForFilters:199    
> EventDispatchThread.pumpEventsForFilter:124    
> EventDispatchThread.pumpEventsForHierarchy:113    
> EventDispatchThread.pumpEvents:109    
> EventDispatchThread.pumpEvents:101    
> EventDispatchThread.run:90   
> {code}
>  



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

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

For further information about the NetBeans mailing lists, visit:

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

[Geertjan Wielenga (JIRA)]

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

Geertjan Wielenga commented on NETBEANS-58:
---

The 'Environment' description for this issue is 'Primarily Windows'.

OK, clearly, from the last few comments, this issue applies ONLY to Windows. If 
this is true, please change the Environment item in the description to match 
that. If it is not true, i.e., this may sometimes happen on other operating 
systems too, then please specify that very clearly here once and for all.

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

[jira] [Assigned] (NETBEANS-373) Netbeans sometimes freezes when showing any refactor dialog when running with jdk 1.8.0_152-b16 or later

[Thomas Corte (JIRA)]

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

Thomas Corte reassigned NETBEANS-373:
-

Assignee: Laszlo Kishalmi  (was: Thomas Corte)

> 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
>Assignee: Laszlo Kishalmi
>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    
> EventDispatchThread.pumpOneEventForFilters:199    
> EventDispatchThread.pumpEventsForFilter:124    
> EventDispatchThread.pumpEventsForHierarchy:113    
> EventDispatchThread.pumpEvents:109    
> EventDispatchThread.pumpEvents:101    
> EventDispatchThread.run:90   
> {code}
>  



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

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

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

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

[Geertjan Wielenga (JIRA)]

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

Geertjan Wielenga commented on NETBEANS-58:
---

Yes, I use Mac and Windows interchangeably and I work for Oracle, i.e., I am 
frequently within a corporate proxy and NetBeans runs on JDK 8 and above and 
normally the JDK 8 version I use is update 25.

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

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

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr commented on NETBEANS-58:
-

{quote}
It is super critical in a specific subset of scenarios, I for one have never 
(working within and without a corporate proxy) have never encountered it, as 
far as I am aware. 
{quote}
[~GeertjanWielenga] have you ever worked with windows when within a corporate 
proxy since jdk 1.8.25?

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

[incubator-netbeans-html4j] branch master updated (c7702ec -> 4d46687)

[jtulach]

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

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


from c7702ec  Merge pull request #7 from dukescript/update-overview
 add 29818fa  Gradle task to process the js annotations
 add 8dabec2  Process all classes directories at once
 add 7b1345b  Hook the task after compilations and before test, jar and run 
phases
 add ce14e6f  Testing the result of the Gradle build
 add e7f8eef  Automatically add asm if it is missing on the application 
classpath
 new 4d46687  Merge pull request #6 from jtulach/jtulach/GradlePlugin

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 .gitignore |   4 +-
 html4j-maven-plugin/pom.xml|  58 +++-
 .../netbeans/html/mojo/ProcessJsAnnotations.java   | 309 +
 .../html/mojo/ProcessJsAnnotationsGradle.java  |  65 +
 .../html/mojo/ProcessJsAnnotationsMojo.java| 146 +-
 .../html/mojo/ProcessJsAnnotationsTask.java|  70 +
 .../META-INF/gradle-plugins/html4j.properties  |   3 +-
 .../java/org/netbeans/html/mojo/Gradle1Test.java   |  85 ++
 .../org/netbeans/html/mojo/gradle1/build.gradle|  29 +-
 .../mojo/gradle1/src/main/java/Gradle1Check.java   |  18 +-
 pom.xml|   3 +
 11 files changed, 635 insertions(+), 155 deletions(-)
 create mode 100644 
html4j-maven-plugin/src/main/java/org/netbeans/html/mojo/ProcessJsAnnotations.java
 create mode 100644 
html4j-maven-plugin/src/main/java/org/netbeans/html/mojo/ProcessJsAnnotationsGradle.java
 create mode 100644 
html4j-maven-plugin/src/main/java/org/netbeans/html/mojo/ProcessJsAnnotationsTask.java
 copy equinox-agentclass-hook/src/main/resources/hookconfigurators.properties 
=> 
html4j-maven-plugin/src/main/resources/META-INF/gradle-plugins/html4j.properties
 (91%)
 create mode 100644 
html4j-maven-plugin/src/test/java/org/netbeans/html/mojo/Gradle1Test.java
 copy json/src/main/java/org/netbeans/html/json/impl/ClassValueTypes.java => 
html4j-maven-plugin/src/test/resources/org/netbeans/html/mojo/gradle1/build.gradle
 (66%)
 copy json-tck/src/main/java/net/java/html/js/tests/Global2String.java => 
html4j-maven-plugin/src/test/resources/org/netbeans/html/mojo/gradle1/src/main/java/Gradle1Check.java
 (73%)

-- 
To stop receiving notification emails like this one, please contact
jtul...@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-html4j] 01/01: Merge pull request #6 from jtulach/jtulach/GradlePlugin

[jtulach]

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

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

commit 4d46687d0334bb5ac269cd66bcac548ad021cca5
Merge: c7702ec e7f8eef
Author: Jaroslav Tulach 
AuthorDate: Wed Apr 25 09:07:34 2018 +0200

Merge pull request #6 from jtulach/jtulach/GradlePlugin

Gradle plugin to process the @JavaScriptBody annotations

 .gitignore |   4 +-
 html4j-maven-plugin/pom.xml|  58 +++-
 .../netbeans/html/mojo/ProcessJsAnnotations.java   | 309 +
 .../html/mojo/ProcessJsAnnotationsGradle.java  |  65 +
 .../html/mojo/ProcessJsAnnotationsMojo.java| 146 +-
 .../html/mojo/ProcessJsAnnotationsTask.java|  70 +
 .../META-INF/gradle-plugins/html4j.properties  |  21 ++
 .../java/org/netbeans/html/mojo/Gradle1Test.java   |  85 ++
 .../org/netbeans/html/mojo/gradle1/build.gradle|  42 +++
 .../mojo/gradle1/src/main/java/Gradle1Check.java   |  34 +++
 pom.xml|   3 +
 11 files changed, 700 insertions(+), 137 deletions(-)


-- 
To stop receiving notification emails like this one, please contact
jtul...@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] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)

[Jean-Marc Borer (JIRA)]

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

Jean-Marc Borer commented on NETBEANS-58:
-

lbruun wrote:
{quote}I'm partly guilty myself
{quote}
I wish I had the choice at my office :(

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