[jira] [Comment Edited] (NETBEANS-538) A java.lang.StackOverflowError exception has occurred.

2018-06-14 Thread Junichi Yamamoto (JIRA)


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

Junichi Yamamoto edited comment on NETBEANS-538 at 6/15/18 12:04 AM:
-

[~rtaneja] I guess that this relates to your changes. Is it possible to create 
a patch?


was (Author: junichi11):
[~rtaneja] I guess that this is related to your changes. Is it possible to 
create a patch?

> A java.lang.StackOverflowError exception has occurred.
> --
>
> Key: NETBEANS-538
> URL: https://issues.apache.org/jira/browse/NETBEANS-538
> Project: NetBeans
>  Issue Type: Bug
>  Components: javascript - Editor
>Affects Versions: Next
> Environment: openjdk-9 
> Arch Linux, kernel 4.15.13
>Reporter: Viktorie Novotná
>Priority: Critical
> Attachments: Snímek obrazovky pořízený 2018-03-28 21-14-01.png
>
>
> Simple javascript code emits exception on every edit, IDE start, save and so 
> on.
> {{Example of such code:}}
> a.b=a.b;
>  
> While this code seems useless it's used quite often, like in google analytics:
> {{window.dataLayer = window.dataLayer || [];}}
> (emitting same exception)
> Stack trace:
> java.lang.StackOverflowError at java.util.HashMap.hash(HashMap.java:339) at 
> java.util.HashMap.put(HashMap.java:612) at 
> java.util.HashSet.add(HashSet.java:220) at 
> org.netbeans.modules.javascript2.model.api.ModelUtils.resolveTypeFromSemiType(ModelUtils.java:639)
>  at 
> org.netbeans.modules.javascript2.model.api.ModelUtils.resolveAssignments(ModelUtils.java:1294)
>  at 
> org.netbeans.modules.javascript2.model.api.ModelUtils.resolveAssignments(ModelUtils.java:1262)
>  at 
> org.netbeans.modules.javascript2.model.api.ModelUtils.resolveTypes(ModelUtils.java:1215)
>  at 
> org.netbeans.modules.javascript2.model.api.ModelUtils.resolveTypes(ModelUtils.java:1232)
>  at 
> org.netbeans.modules.javascript2.model.api.ModelUtils.resolveTypes(ModelUtils.java:1232)
>  at 
> org.netbeans.modules.javascript2.model.api.ModelUtils.resolveTypes(ModelUtils.java:1232)
>  at 
> org.netbeans.modules.javascript2.model.api.ModelUtils.resolveTypes(ModelUtils.java:1232)
>  ...
>  ...
> and so on.
>  



--
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-538) A java.lang.StackOverflowError exception has occurred.

2018-06-14 Thread Junichi Yamamoto (JIRA)


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

Junichi Yamamoto commented on NETBEANS-538:
---

[~rtaneja] I guess that this is related to your changes. Is it possible to 
create a patch?

> A java.lang.StackOverflowError exception has occurred.
> --
>
> Key: NETBEANS-538
> URL: https://issues.apache.org/jira/browse/NETBEANS-538
> Project: NetBeans
>  Issue Type: Bug
>  Components: javascript - Editor
>Affects Versions: Next
> Environment: openjdk-9 
> Arch Linux, kernel 4.15.13
>Reporter: Viktorie Novotná
>Priority: Critical
> Attachments: Snímek obrazovky pořízený 2018-03-28 21-14-01.png
>
>
> Simple javascript code emits exception on every edit, IDE start, save and so 
> on.
> {{Example of such code:}}
> a.b=a.b;
>  
> While this code seems useless it's used quite often, like in google analytics:
> {{window.dataLayer = window.dataLayer || [];}}
> (emitting same exception)
> Stack trace:
> java.lang.StackOverflowError at java.util.HashMap.hash(HashMap.java:339) at 
> java.util.HashMap.put(HashMap.java:612) at 
> java.util.HashSet.add(HashSet.java:220) at 
> org.netbeans.modules.javascript2.model.api.ModelUtils.resolveTypeFromSemiType(ModelUtils.java:639)
>  at 
> org.netbeans.modules.javascript2.model.api.ModelUtils.resolveAssignments(ModelUtils.java:1294)
>  at 
> org.netbeans.modules.javascript2.model.api.ModelUtils.resolveAssignments(ModelUtils.java:1262)
>  at 
> org.netbeans.modules.javascript2.model.api.ModelUtils.resolveTypes(ModelUtils.java:1215)
>  at 
> org.netbeans.modules.javascript2.model.api.ModelUtils.resolveTypes(ModelUtils.java:1232)
>  at 
> org.netbeans.modules.javascript2.model.api.ModelUtils.resolveTypes(ModelUtils.java:1232)
>  at 
> org.netbeans.modules.javascript2.model.api.ModelUtils.resolveTypes(ModelUtils.java:1232)
>  at 
> org.netbeans.modules.javascript2.model.api.ModelUtils.resolveTypes(ModelUtils.java:1232)
>  ...
>  ...
> and so on.
>  



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

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

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



[jira] [Assigned] (NETBEANS-837) winp-1.14-patched.jar license/notice

2018-06-14 Thread JIRA


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

Matthias Bläsing reassigned NETBEANS-837:
-

Assignee: Matthias Bläsing

> winp-1.14-patched.jar license/notice
> 
>
> Key: NETBEANS-837
> URL: https://issues.apache.org/jira/browse/NETBEANS-837
> Project: NetBeans
>  Issue Type: Bug
>Reporter: Emilian Bold
>Assignee: Matthias Bläsing
>Priority: Major
>
> ./ide/modules/ext/winp-1.14-patched.jar
> - LICENSE is missing this MIT licensed
> Additional notes on LICENSE and NOTICE: 
> http://mail-archives.apache.org/mod_mbox/incubator-general/201801.mbox/%3cc4c5d5c4-ab44-4afe-ade2-9e91f593a...@classsoftware.com%3e



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

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

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



[jira] [Assigned] (NETBEANS-848) testng-6.8.1-dist.jar license/notice

2018-06-14 Thread JIRA


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

Matthias Bläsing reassigned NETBEANS-848:
-

Assignee: Matthias Bläsing

> testng-6.8.1-dist.jar license/notice
> 
>
> Key: NETBEANS-848
> URL: https://issues.apache.org/jira/browse/NETBEANS-848
> Project: NetBeans
>  Issue Type: Bug
>Reporter: Emilian Bold
>Assignee: Matthias Bläsing
>Priority: Major
>
> ./platform/modules/ext/testng-6.8.1-dist.jar
> - contains apache licensed jcommander and MIT licensed jquery
> - jcommander has a notice that would effect NOTICE
> Additional notes on LICENSE and NOTICE: 
> http://mail-archives.apache.org/mod_mbox/incubator-general/201801.mbox/%3cc4c5d5c4-ab44-4afe-ade2-9e91f593a...@classsoftware.com%3e



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

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

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



[jira] [Assigned] (NETBEANS-846) spring-context-3.2.7.RELEASE.jar license/notice

2018-06-14 Thread JIRA


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

Matthias Bläsing reassigned NETBEANS-846:
-

Assignee: Matthias Bläsing

> spring-context-3.2.7.RELEASE.jar license/notice
> ---
>
> Key: NETBEANS-846
> URL: https://issues.apache.org/jira/browse/NETBEANS-846
> Project: NetBeans
>  Issue Type: Bug
>Reporter: Emilian Bold
>Assignee: Matthias Bläsing
>Priority: Major
>
> ./java/modules/ext/spring-3.0/spring-context-3.2.7.RELEASE.jar
> ./java/modules/ext/spring-3.0/spring-context-support-3.2.7.RELEASE.jar
> (and other spring jars)
> - has a NOTICE file that would effect the NOTICE file
> Additional notes on LICENSE and NOTICE: 
> http://mail-archives.apache.org/mod_mbox/incubator-general/201801.mbox/%3cc4c5d5c4-ab44-4afe-ade2-9e91f593a...@classsoftware.com%3e



--
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-958) inexplicable "throwable method result is ignored" warning

2018-06-14 Thread Alvin Thompson (JIRA)


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

Alvin Thompson updated NETBEANS-958:

Description: 
I have the following code:

{code:java}
public Map sendStandingOrders() {
  Map out = new LinkedHashMap<>();
  List standingOrders = getStandingOrdersThatNeedToRunNow();
  for (StandingOrderInfo standingOrderInfo : standingOrders) {
try {
  sendStandingOrder(standingOrderInfo);
  out.put(standingOrderInfo, null); // warning here
} catch (Exception ex) {
  // TODO: send emails
  logger.log(Level.SEVERE, "could not send standing order ", ex);
  out.put(standingOrderInfo, ex); // warning here
}
  }
  return out;
}
{code}

Judging from the warning description, this warning shouldn't even apply to the 
method that's returning the Throwable, but rather the code that calls the 
method. In any case, the catch clause is clearly doing something with the 
exception. If the warning is intended behavior (that I don't understand), I 
don't see how the code above rises to the level of "probable bug". Can you 
please explain?

What's even more puzzling is that this similar but simpler code works:


{code:java}
private Throwable foo() {
  try {
Thread.sleep(0);
return null;
  } catch (Exception ex) {
return ex;
  }
}
{code}


  was:
I have the following code:

{code:java}
public Map sendStandingOrders() {
  Map out = new LinkedHashMap<>();
  List standingOrders = getStandingOrdersThatNeedToRunNow();
  for (StandingOrderInfo standingOrderInfo : standingOrders) {
try {
  sendStandingOrder(standingOrderInfo);
  out.put(standingOrderInfo, null);
} catch (Exception ex) {
  // TODO: send emails
  logger.log(Level.SEVERE, "could not send standing order ", ex);
  out.put(standingOrderInfo, ex);
}
  }
  return out;
}
{code}

Judging from the warning description, this warning shouldn't even apply to the 
method that's returning the Throwable, but rather the code that calls the 
method. In any case, the catch clause is clearly doing something with the 
exception. If the warning is intended behavior (that I don't understand), I 
don't see how the code above rises to the level of "probable bug". Can you 
please explain?

What's even more puzzling is that this similar but simpler code works:


{code:java}
private Throwable foo() {
  try {
Thread.sleep(0);
return null;
  } catch (Exception ex) {
return ex;
  }
}
{code}



> inexplicable "throwable method result is ignored" warning
> -
>
> Key: NETBEANS-958
> URL: https://issues.apache.org/jira/browse/NETBEANS-958
> Project: NetBeans
>  Issue Type: Bug
>  Components: cnd - Editor
>Affects Versions: 9.0
> Environment: project JDK: 8
> IDE JDK: 10
>Reporter: Alvin Thompson
>Priority: Major
>
> I have the following code:
> {code:java}
> public Map sendStandingOrders() {
>   Map out = new LinkedHashMap<>();
>   List standingOrders = 
> getStandingOrdersThatNeedToRunNow();
>   for (StandingOrderInfo standingOrderInfo : standingOrders) {
> try {
>   sendStandingOrder(standingOrderInfo);
>   out.put(standingOrderInfo, null); // warning here
> } catch (Exception ex) {
>   // TODO: send emails
>   logger.log(Level.SEVERE, "could not send standing order ", ex);
>   out.put(standingOrderInfo, ex); // warning here
> }
>   }
>   return out;
> }
> {code}
> Judging from the warning description, this warning shouldn't even apply to 
> the method that's returning the Throwable, but rather the code that calls the 
> method. In any case, the catch clause is clearly doing something with the 
> exception. If the warning is intended behavior (that I don't understand), I 
> don't see how the code above rises to the level of "probable bug". Can you 
> please explain?
> What's even more puzzling is that this similar but simpler code works:
> {code:java}
> private Throwable foo() {
>   try {
> Thread.sleep(0);
> return null;
>   } catch (Exception ex) {
> return ex;
>   }
> }
> {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] [Updated] (NETBEANS-958) inexplicable "throwable method result is ignored" warning

2018-06-14 Thread Alvin Thompson (JIRA)


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

Alvin Thompson updated NETBEANS-958:

Description: 
I have the following code:

{code:java}
public Map sendStandingOrders() {
  Map out = new LinkedHashMap<>();
  List standingOrders = getStandingOrdersThatNeedToRunNow();
  for (StandingOrderInfo standingOrderInfo : standingOrders) {
try {
  sendStandingOrder(standingOrderInfo);
  out.put(standingOrderInfo, null);
} catch (Exception ex) {
  // TODO: send emails
  logger.log(Level.SEVERE, "could not send standing order ", ex);
  out.put(standingOrderInfo, ex);
}
  }
  return out;
}
{code}

Judging from the warning description, this warning shouldn't even apply to the 
method that's returning the Throwable, but rather the code that calls the 
method. In any case, the catch clause is clearly doing something with the 
exception. If the warning is intended behavior (that I don't understand), I 
don't see how the code above rises to the level of "probable bug". Can you 
please explain?

What's even more puzzling is that this similar but simpler code works:


{code:java}
private Throwable foo() {
  try {
Thread.sleep(0);
return null;
  } catch (Exception ex) {
return ex;
  }
}
{code}


  was:
I have the following code:

{code:java}
public Map sendStandingOrders() {
Map out = new LinkedHashMap<>();
List standingOrders = 
getStandingOrdersThatNeedToRunNow();
for (StandingOrderInfo standingOrderInfo : standingOrders) {
try {
sendStandingOrder(standingOrderInfo);
out.put(standingOrderInfo, null);
} catch (Exception ex) {
// TODO: send emails
logger.log(
Level.SEVERE,
"could not send standing order ",
ex
);
out.put(standingOrderInfo, ex);
}
}
return out;
}
{code}

Judging from the warning description, this warning shouldn't even apply to the 
method that's returning the Throwable, but rather the code that calls the 
method. In any case, the catch clause is clearly doing something with the 
exception. If the warning is intended behavior (that I don't understand), I 
don't see how the code above rises to the level of "probable bug". Can you 
please explain?

What's even more puzzling is that this similar but simpler code works:


{code:java}
private Throwable foo() {
  try {
Thread.sleep(0);
return null;
  } catch (Exception ex) {
return ex;
  }
}
{code}



> inexplicable "throwable method result is ignored" warning
> -
>
> Key: NETBEANS-958
> URL: https://issues.apache.org/jira/browse/NETBEANS-958
> Project: NetBeans
>  Issue Type: Bug
>  Components: cnd - Editor
>Affects Versions: 9.0
> Environment: project JDK: 8
> IDE JDK: 10
>Reporter: Alvin Thompson
>Priority: Major
>
> I have the following code:
> {code:java}
> public Map sendStandingOrders() {
>   Map out = new LinkedHashMap<>();
>   List standingOrders = 
> getStandingOrdersThatNeedToRunNow();
>   for (StandingOrderInfo standingOrderInfo : standingOrders) {
> try {
>   sendStandingOrder(standingOrderInfo);
>   out.put(standingOrderInfo, null);
> } catch (Exception ex) {
>   // TODO: send emails
>   logger.log(Level.SEVERE, "could not send standing order ", ex);
>   out.put(standingOrderInfo, ex);
> }
>   }
>   return out;
> }
> {code}
> Judging from the warning description, this warning shouldn't even apply to 
> the method that's returning the Throwable, but rather the code that calls the 
> method. In any case, the catch clause is clearly doing something with the 
> exception. If the warning is intended behavior (that I don't understand), I 
> don't see how the code above rises to the level of "probable bug". Can you 
> please explain?
> What's even more puzzling is that this similar but simpler code works:
> {code:java}
> private Throwable foo() {
>   try {
> Thread.sleep(0);
> return null;
>   } catch (Exception ex) {
> return ex;
>   }
> }
> {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] [Updated] (NETBEANS-958) inexplicable "throwable method result is ignored" warning

2018-06-14 Thread Alvin Thompson (JIRA)


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

Alvin Thompson updated NETBEANS-958:

Description: 
I have the following code:

{code:java}
public Map sendStandingOrders() {
Map out = new LinkedHashMap<>();
List standingOrders = 
getStandingOrdersThatNeedToRunNow();
for (StandingOrderInfo standingOrderInfo : standingOrders) {
try {
sendStandingOrder(standingOrderInfo);
out.put(standingOrderInfo, null);
} catch (Exception ex) {
// TODO: send emails
logger.log(
Level.SEVERE,
"could not send standing order ",
ex
);
out.put(standingOrderInfo, ex);
}
}
return out;
}
{code}

Judging from the warning description, this warning shouldn't even apply to the 
method that's returning the Throwable, but rather the code that calls the 
method. In any case, the catch clause is clearly doing something with the 
exception. If the warning is intended behavior (that I don't understand), I 
don't see how the code above rises to the level of "probable bug". Can you 
please explain?

What's even more puzzling is that this similar but simpler code works:


{code:java}
private Throwable foo() {
  try {
Thread.sleep(0);
return null;
  } catch (Exception ex) {
return ex;
  }
}
{code}


  was:
I have the following code:

{code:java}
public Map sendStandingOrders() {
Map out = new LinkedHashMap<>();
List standingOrders = 
getStandingOrdersThatNeedToRunNow();
for (StandingOrderInfo standingOrderInfo : standingOrders) {
try {
sendStandingOrder(standingOrderInfo);
out.put(standingOrderInfo, null);
} catch (Exception ex) {
// TODO: send emails
logger.log(
Level.SEVERE,
"could not send standing order ",
ex
);
out.put(standingOrderInfo, ex);
}
}
return out;
}
{code}

Judging from the warning description, this warning shouldn't even apply to the 
method that's returning the Throwable, but rather the code that calls the 
method. In any case, the catch clause is clearly doing something with the 
exception. If the warning is intended behavior (that I don't understand), I 
don't see how the code above rises to the level of "probable bug". Can you 
please explain?

What's even more puzzling is that this similar but simpler code works:


{code:java}
private Throwable foo() {
try {
Thread.sleep(0);
return null;
} catch (Exception ex) {
return ex;
}
}
{code}



> inexplicable "throwable method result is ignored" warning
> -
>
> Key: NETBEANS-958
> URL: https://issues.apache.org/jira/browse/NETBEANS-958
> Project: NetBeans
>  Issue Type: Bug
>  Components: cnd - Editor
>Affects Versions: 9.0
> Environment: project JDK: 8
> IDE JDK: 10
>Reporter: Alvin Thompson
>Priority: Major
>
> I have the following code:
> {code:java}
> public Map sendStandingOrders() {
>   Map out = new LinkedHashMap<>();
>   List standingOrders = 
> getStandingOrdersThatNeedToRunNow();
>   for (StandingOrderInfo standingOrderInfo : standingOrders) {
>   try {
>   sendStandingOrder(standingOrderInfo);
>   out.put(standingOrderInfo, null);
>   } catch (Exception ex) {
>   // TODO: send emails
>   logger.log(
>   Level.SEVERE,
>   "could not send standing order ",
>   ex
>   );
>   out.put(standingOrderInfo, ex);
>   }
>   }
>   return out;
> }
> {code}
> Judging from the warning description, this warning shouldn't even apply to 
> the method that's returning the Throwable, but rather the code that calls the 
> method. In any case, the catch clause is clearly doing something with the 
> exception. If the warning is intended behavior (that I don't understand), I 
> don't see how the code above rises to the level of "probable bug". Can you 
> please explain?
> What's even more puzzling is that this similar but simpler code works:
> {code:java}
> private Throwable foo() {

[jira] [Updated] (NETBEANS-958) inexplicable "throwable method result is ignored" warning

2018-06-14 Thread Alvin Thompson (JIRA)


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

Alvin Thompson updated NETBEANS-958:

Description: 
I have the following code:

{code:java}
public Map sendStandingOrders() {
Map out = new LinkedHashMap<>();
List standingOrders = 
getStandingOrdersThatNeedToRunNow();
for (StandingOrderInfo standingOrderInfo : standingOrders) {
try {
sendStandingOrder(standingOrderInfo);
out.put(standingOrderInfo, null);
} catch (Exception ex) {
// TODO: send emails
logger.log(
Level.SEVERE,
"could not send standing order ",
ex
);
out.put(standingOrderInfo, ex);
}
}
return out;
}
{code}

Judging from the warning description, this warning shouldn't even apply to the 
method that's returning the Throwable, but rather the code that calls the 
method. In any case, the catch clause is clearly doing something with the 
exception. If the warning is intended behavior (that I don't understand), I 
don't see how the code above rises to the level of "probable bug". Can you 
please explain?

What's even more puzzling is that this similar but simpler code works:


{code:java}
private Throwable foo() {
try {
Thread.sleep(0);
return null;
} catch (Exception ex) {
return ex;
}
}
{code}


  was:
I have the following code:

{code:java}
public Map sendStandingOrders() {
Map out = new LinkedHashMap<>();
List standingOrders = 
getStandingOrdersThatNeedToRunNow();
for (StandingOrderInfo standingOrderInfo : standingOrders) {
try {
sendStandingOrder(standingOrderInfo);
out.put(standingOrderInfo, null);
} catch (Exception ex) {
// TODO: send emails
logger.log(Level.SEVERE, "could not send 
standing order ", ex);
out.put(standingOrderInfo, ex);
}
}
return out;
}
{code}

Judging from the warning description, this warning shouldn't even apply to the 
method that's returning the Throwable, but rather the code that calls the 
method. In any case, the catch clause is clearly doing something with the 
exception. If the warning is intended behavior (that I don't understand), I 
don't see how the code above rises to the level of "probable bug". Can you 
please explain?

What's even more puzzling is that this similar but simpler code works:


{code:java}
private Throwable foo() {
try {
Thread.sleep(0);
return null;
} catch (Exception ex) {
return ex;
}
}
{code}



> inexplicable "throwable method result is ignored" warning
> -
>
> Key: NETBEANS-958
> URL: https://issues.apache.org/jira/browse/NETBEANS-958
> Project: NetBeans
>  Issue Type: Bug
>  Components: cnd - Editor
>Affects Versions: 9.0
> Environment: project JDK: 8
> IDE JDK: 10
>Reporter: Alvin Thompson
>Priority: Major
>
> I have the following code:
> {code:java}
> public Map sendStandingOrders() {
>   Map out = new LinkedHashMap<>();
>   List standingOrders = 
> getStandingOrdersThatNeedToRunNow();
>   for (StandingOrderInfo standingOrderInfo : standingOrders) {
>   try {
>   sendStandingOrder(standingOrderInfo);
>   out.put(standingOrderInfo, null);
>   } catch (Exception ex) {
>   // TODO: send emails
>   logger.log(
>   Level.SEVERE,
>   "could not send standing order ",
>   ex
>   );
>   out.put(standingOrderInfo, ex);
>   }
>   }
>   return out;
> }
> {code}
> Judging from the warning description, this warning shouldn't even apply to 
> the method that's returning the Throwable, but rather the code that calls the 
> method. In any case, the catch clause is clearly doing something with the 
> exception. If the warning is intended behavior (that I don't understand), I 
> don't see how the code above rises to the level of "probable bug". Can you 
> please explai

[jira] [Updated] (NETBEANS-958) inexplicable "throwable method result is ignored" warning

2018-06-14 Thread Alvin Thompson (JIRA)


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

Alvin Thompson updated NETBEANS-958:

Description: 
I have the following code:

{code:java}
public Map sendStandingOrders() {
Map out = new LinkedHashMap<>();
List standingOrders = 
getStandingOrdersThatNeedToRunNow();
for (StandingOrderInfo standingOrderInfo : standingOrders) {
try {
sendStandingOrder(standingOrderInfo);
out.put(standingOrderInfo, null);
} catch (Exception ex) {
// TODO: send emails
logger.log(Level.SEVERE, "could not send 
standing order ", ex);
out.put(standingOrderInfo, ex);
}
}
return out;
}
{code}

Judging from the warning description, this warning shouldn't even apply to the 
method that's returning the Throwable, but rather the code that calls the 
method. In any case, the catch clause is clearly doing something with the 
exception. If the warning is intended behavior (that I don't understand), I 
don't see how the code above rises to the level of "probable bug". Can you 
please explain?

What's even more puzzling is that this similar but simpler code works:


{code:java}
private Throwable foo() {
try {
Thread.sleep(0);
return null;
} catch (Exception ex) {
return ex;
}
}
{code}


  was:
I have the following code:

{code:java}
public Map sendStandingOrders() {
Map out = new LinkedHashMap<>();
List standingOrders = 
getStandingOrdersThatNeedToRunNow();
for (StandingOrderInfo standingOrderInfo : standingOrders) {
try {
sendStandingOrder(standingOrderInfo);
out.put(standingOrderInfo, null);
} catch (Exception ex) {
// TODO: send emails
logger.log(
Level.SEVERE,
"could not send standing order " + 
standingOrderInfo.standingOrder.getId() + " for "
+ standingOrderInfo.dayOfWeek + 
", " + standingOrderInfo.dateRequested,
ex
);
out.put(standingOrderInfo, ex);
}
}
return out;
}
{code}

Judging from the warning description, this warning shouldn't even apply to the 
method that's returning the Throwable, but rather the code that calls the 
method. In any case, the catch clause is clearly doing something with the 
exception. If the warning is intended behavior (that I don't understand), I 
don't see how the code above rises to the level of "probable bug". Can you 
please explain?

What's even more puzzling is that this similar but simpler code works:


{code:java}
private Throwable foo() {
try {
Thread.sleep(0);
return null;
} catch (Exception ex) {
return ex;
}
}
{code}



> inexplicable "throwable method result is ignored" warning
> -
>
> Key: NETBEANS-958
> URL: https://issues.apache.org/jira/browse/NETBEANS-958
> Project: NetBeans
>  Issue Type: Bug
>  Components: cnd - Editor
>Affects Versions: 9.0
> Environment: project JDK: 8
> IDE JDK: 10
>Reporter: Alvin Thompson
>Priority: Major
>
> I have the following code:
> {code:java}
>   public Map sendStandingOrders() {
>   Map out = new LinkedHashMap<>();
>   List standingOrders = 
> getStandingOrdersThatNeedToRunNow();
>   for (StandingOrderInfo standingOrderInfo : standingOrders) {
>   try {
>   sendStandingOrder(standingOrderInfo);
>   out.put(standingOrderInfo, null);
>   } catch (Exception ex) {
>   // TODO: send emails
>   logger.log(Level.SEVERE, "could not send 
> standing order ", ex);
>   out.put(standingOrderInfo, ex);
>   }
>   }
>   return out;
>   }
> {code}
> Judging from the warning description, this warning shouldn't even apply to 
> the me

[jira] [Updated] (NETBEANS-958) inexplicable "throwable method result is ignored" warning

2018-06-14 Thread Alvin Thompson (JIRA)


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

Alvin Thompson updated NETBEANS-958:

Description: 
I have the following code:

{code:java}
public Map sendStandingOrders() {
Map out = new LinkedHashMap<>();
List standingOrders = 
getStandingOrdersThatNeedToRunNow();
for (StandingOrderInfo standingOrderInfo : standingOrders) {
try {
sendStandingOrder(standingOrderInfo);
out.put(standingOrderInfo, null);
} catch (Exception ex) {
// TODO: send emails
logger.log(
Level.SEVERE,
"could not send standing order " + 
standingOrderInfo.standingOrder.getId() + " for "
+ standingOrderInfo.dayOfWeek + 
", " + standingOrderInfo.dateRequested,
ex
);
out.put(standingOrderInfo, ex);
}
}
return out;
}
{code}

Judging from the warning description, this warning shouldn't even apply to the 
method that's returning the Throwable, but rather the code that calls the 
method. In any case, the catch clause is clearly doing something with the 
exception. If the warning is intended behavior (that I don't understand), I 
don't see how the code above rises to the level of "probable bug". Can you 
please explain?

What's even more puzzling is that this similar but simpler code works:


{code:java}
private Throwable foo() {
try {
Thread.sleep(0);
return null;
} catch (Exception ex) {
return ex;
}
}
{code}


  was:
I have the following code:

{{
foo
}}

{{public Map sendStandingOrders() {}}
 {{  Map out = new LinkedHashMap<>();}}
 {{  List standingOrders = 
getStandingOrdersThatNeedToRunNow();}}
 {{  for (StandingOrderInfo standingOrderInfo : standingOrders) {}}
 {{    try {}}
 {{      sendStandingOrder(standingOrderInfo);}}
 {{      out.put(standingOrderInfo, null); // warning here}}
 {{    } catch (Exception ex) {}}
 {{      // TODO: send emails}}
 {{      logger.log(}}
 {{        Level.SEVERE,}}
 {{        "could not send standing order " + 
standingOrderInfo.standingOrder.getId() + " for "}}
 \{{ + standingOrderInfo.dayOfWeek + ", " + standingOrderInfo.dateRequested,}}
 {{        ex}}
 {{      );}}
 {{      out.put(standingOrderInfo, ex); // warning here}}
 \{{    }}}
 \{{  }}}
 {{  return out;}}
 \{{ }}}

Judging from the warning description, this warning shouldn't even apply to the 
method that's returning the Throwable, but rather the code that calls the 
method. In any case, the catch clause is clearly doing something with the 
exception. If the warning is intended behavior (that I don't understand), I 
don't see how the code above rises to the level of "probable bug". Can you 
please explain?

What's even more puzzling is that this similar but simpler code works:

{\{ private Throwable foo() {}}
 {{  try {}}
 {{    Thread.sleep(0);}}
 {{    return null;}}
 {{  } catch (Exception ex) {}}
 {{    return ex;}}
 \{{  }}}
 \{{ }}}

 


> inexplicable "throwable method result is ignored" warning
> -
>
> Key: NETBEANS-958
> URL: https://issues.apache.org/jira/browse/NETBEANS-958
> Project: NetBeans
>  Issue Type: Bug
>  Components: cnd - Editor
>Affects Versions: 9.0
> Environment: project JDK: 8
> IDE JDK: 10
>Reporter: Alvin Thompson
>Priority: Major
>
> I have the following code:
> {code:java}
>   public Map sendStandingOrders() {
>   Map out = new LinkedHashMap<>();
>   List standingOrders = 
> getStandingOrdersThatNeedToRunNow();
>   for (StandingOrderInfo standingOrderInfo : standingOrders) {
>   try {
>   sendStandingOrder(standingOrderInfo);
>   out.put(standingOrderInfo, null);
>   } catch (Exception ex) {
>   // TODO: send emails
>   logger.log(
>   Level.SEVERE,
>   "could not send standing order " + 
> standingOrderInfo.standingOrder.getId() + " for "
>   + standingOrderInfo.dayOfWeek + 
> ", " + standingOrderInfo.dateRequested,
>   ex
>   

[jira] [Updated] (NETBEANS-958) inexplicable "throwable method result is ignored" warning

2018-06-14 Thread Alvin Thompson (JIRA)


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

Alvin Thompson updated NETBEANS-958:

Description: 
I have the following code:

{{
foo
}}

{{public Map sendStandingOrders() {}}
 {{  Map out = new LinkedHashMap<>();}}
 {{  List standingOrders = 
getStandingOrdersThatNeedToRunNow();}}
 {{  for (StandingOrderInfo standingOrderInfo : standingOrders) {}}
 {{    try {}}
 {{      sendStandingOrder(standingOrderInfo);}}
 {{      out.put(standingOrderInfo, null); // warning here}}
 {{    } catch (Exception ex) {}}
 {{      // TODO: send emails}}
 {{      logger.log(}}
 {{        Level.SEVERE,}}
 {{        "could not send standing order " + 
standingOrderInfo.standingOrder.getId() + " for "}}
 \{{ + standingOrderInfo.dayOfWeek + ", " + standingOrderInfo.dateRequested,}}
 {{        ex}}
 {{      );}}
 {{      out.put(standingOrderInfo, ex); // warning here}}
 \{{    }}}
 \{{  }}}
 {{  return out;}}
 \{{ }}}

Judging from the warning description, this warning shouldn't even apply to the 
method that's returning the Throwable, but rather the code that calls the 
method. In any case, the catch clause is clearly doing something with the 
exception. If the warning is intended behavior (that I don't understand), I 
don't see how the code above rises to the level of "probable bug". Can you 
please explain?

What's even more puzzling is that this similar but simpler code works:

{\{ private Throwable foo() {}}
 {{  try {}}
 {{    Thread.sleep(0);}}
 {{    return null;}}
 {{  } catch (Exception ex) {}}
 {{    return ex;}}
 \{{  }}}
 \{{ }}}

 

  was:
I have the following code:

{{public Map sendStandingOrders() {}}
 {{  Map out = new LinkedHashMap<>();}}
 {{  List standingOrders = 
getStandingOrdersThatNeedToRunNow();}}
 {{  for (StandingOrderInfo standingOrderInfo : standingOrders) {}}
 {{    try {}}
 {{      sendStandingOrder(standingOrderInfo);}}
 {{      out.put(standingOrderInfo, null); // warning here}}
 {{    } catch (Exception ex) {}}
 {{      // TODO: send emails}}
 {{      logger.log(}}
 {{        Level.SEVERE,}}
 {{        "could not send standing order " + 
standingOrderInfo.standingOrder.getId() + " for "}}
 \{{ + standingOrderInfo.dayOfWeek + ", " + standingOrderInfo.dateRequested,}}
 {{        ex}}
 {{      );}}
 {{      out.put(standingOrderInfo, ex); // warning here}}
 \{{    }}}
 \{{  }}}
 {{  return out;}}
 \{{ }}}

Judging from the warning description, this warning shouldn't even apply to the 
method that's returning the Throwable, but rather the code that calls the 
method. In any case, the catch clause is clearly doing something with the 
exception. If the warning is intended behavior (that I don't understand), I 
don't see how the code above rises to the level of "probable bug". Can you 
please explain?

What's even more puzzling is that this similar but simpler code works:

{\{ private Throwable foo() {}}
 {{  try {}}
 {{    Thread.sleep(0);}}
 {{    return null;}}
 {{  } catch (Exception ex) {}}
 {{    return ex;}}
 \{{  }}}
 \{{ }}}

 


> inexplicable "throwable method result is ignored" warning
> -
>
> Key: NETBEANS-958
> URL: https://issues.apache.org/jira/browse/NETBEANS-958
> Project: NetBeans
>  Issue Type: Bug
>  Components: cnd - Editor
>Affects Versions: 9.0
> Environment: project JDK: 8
> IDE JDK: 10
>Reporter: Alvin Thompson
>Priority: Major
>
> I have the following code:
> {{
> foo
> }}
> {{public Map sendStandingOrders() {}}
>  {{  Map out = new LinkedHashMap<>();}}
>  {{  List standingOrders = 
> getStandingOrdersThatNeedToRunNow();}}
>  {{  for (StandingOrderInfo standingOrderInfo : standingOrders) {}}
>  {{    try {}}
>  {{      sendStandingOrder(standingOrderInfo);}}
>  {{      out.put(standingOrderInfo, null); // warning here}}
>  {{    } catch (Exception ex) {}}
>  {{      // TODO: send emails}}
>  {{      logger.log(}}
>  {{        Level.SEVERE,}}
>  {{        "could not send standing order " + 
> standingOrderInfo.standingOrder.getId() + " for "}}
>  \{{ + standingOrderInfo.dayOfWeek + ", " + standingOrderInfo.dateRequested,}}
>  {{        ex}}
>  {{      );}}
>  {{      out.put(standingOrderInfo, ex); // warning here}}
>  \{{    }}}
>  \{{  }}}
>  {{  return out;}}
>  \{{ }}}
> Judging from the warning description, this warning shouldn't even apply to 
> the method that's returning the Throwable, but rather the code that calls the 
> method. In any case, the catch clause is clearly doing something with the 
> exception. If the warning is intended behavior (that I don't understand), I 
> don't see how the code above rises to the level of "probable bug". Can you 
> please explain?
> What's even more puzzling is that this similar but simpler code works:
> {\{ private Throwable foo() {}}
>  {{  try {}}
>  {{    

[jira] [Updated] (NETBEANS-958) inexplicable "throwable method result is ignored" warning

2018-06-14 Thread Alvin Thompson (JIRA)


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

Alvin Thompson updated NETBEANS-958:

Description: 
I have the following code:

{{public Map sendStandingOrders() {}}
 {{  Map out = new LinkedHashMap<>();}}
 {{  List standingOrders = 
getStandingOrdersThatNeedToRunNow();}}
 {{  for (StandingOrderInfo standingOrderInfo : standingOrders) {}}
 {{    try {}}
 {{      sendStandingOrder(standingOrderInfo);}}
 {{      out.put(standingOrderInfo, null); // warning here}}
 {{    } catch (Exception ex) {}}
 {{      // TODO: send emails}}
 {{      logger.log(}}
 {{        Level.SEVERE,}}
 {{        "could not send standing order " + 
standingOrderInfo.standingOrder.getId() + " for "}}
 \{{ + standingOrderInfo.dayOfWeek + ", " + standingOrderInfo.dateRequested,}}
 {{        ex}}
 {{      );}}
 {{      out.put(standingOrderInfo, ex); // warning here}}
 \{{    }}}
 \{{  }}}
 {{  return out;}}
 \{{ }}}

Judging from the warning description, this warning shouldn't even apply to the 
method that's returning the Throwable, but rather the code that calls the 
method. In any case, the catch clause is clearly doing something with the 
exception. If the warning is intended behavior (that I don't understand), I 
don't see how the code above rises to the level of "probable bug". Can you 
please explain?

What's even more puzzling is that this similar but simpler code works:

{\{ private Throwable foo() {}}
 {{  try {}}
 {{    Thread.sleep(0);}}
 {{    return null;}}
 {{  } catch (Exception ex) {}}
 {{    return ex;}}
 \{{  }}}
 \{{ }}}

 

  was:
I have the following code:

{{public Map sendStandingOrders() {}}
{{  Map out = new LinkedHashMap<>();}}
{{  List standingOrders = 
getStandingOrdersThatNeedToRunNow();}}
{{  for (StandingOrderInfo standingOrderInfo : standingOrders) {}}
{{    try {}}
{{      sendStandingOrder(standingOrderInfo);}}
{{      out.put(standingOrderInfo, null); // warning here}}
{{    } catch (Exception ex) {}}
{{      // TODO: send emails}}
{{      logger.log(}}
{{        Level.SEVERE,}}
{{        "could not send standing order " + 
standingOrderInfo.standingOrder.getId() + " for "}}
{{ + standingOrderInfo.dayOfWeek + ", " + standingOrderInfo.dateRequested,}}
{{        ex}}
{{      );}}
{{      out.put(standingOrderInfo, ex); // warning here}}
{{    }}}
{{  }}}
{{  return out;}}
{{ }}}

Judging from the warning description, this warning shouldn't even apply to the 
method that's returning the Throwable, but rather the code that calls the 
method. In any case, the catch clause is clearly doing something with the 
exception. If the warning is intended behavior (that I don't understand), I 
don't see how the code above rises to the level of "probable bug". Can you 
please explain?

What's even more puzzling is that this similar but simpler code works:

{{ private Throwable foo() {}}
{{  try {}}
{{    Thread.sleep(0);}}
{{    return null;}}
{{  } catch (Exception ex) {}}
{{    return ex;}}
{{  }}}
{{ }}}

 


> inexplicable "throwable method result is ignored" warning
> -
>
> Key: NETBEANS-958
> URL: https://issues.apache.org/jira/browse/NETBEANS-958
> Project: NetBeans
>  Issue Type: Bug
>  Components: cnd - Editor
>Affects Versions: 9.0
> Environment: project JDK: 8
> IDE JDK: 10
>Reporter: Alvin Thompson
>Priority: Major
>
> I have the following code:
> {{public Map sendStandingOrders() {}}
>  {{  Map out = new LinkedHashMap<>();}}
>  {{  List standingOrders = 
> getStandingOrdersThatNeedToRunNow();}}
>  {{  for (StandingOrderInfo standingOrderInfo : standingOrders) {}}
>  {{    try {}}
>  {{      sendStandingOrder(standingOrderInfo);}}
>  {{      out.put(standingOrderInfo, null); // warning here}}
>  {{    } catch (Exception ex) {}}
>  {{      // TODO: send emails}}
>  {{      logger.log(}}
>  {{        Level.SEVERE,}}
>  {{        "could not send standing order " + 
> standingOrderInfo.standingOrder.getId() + " for "}}
>  \{{ + standingOrderInfo.dayOfWeek + ", " + standingOrderInfo.dateRequested,}}
>  {{        ex}}
>  {{      );}}
>  {{      out.put(standingOrderInfo, ex); // warning here}}
>  \{{    }}}
>  \{{  }}}
>  {{  return out;}}
>  \{{ }}}
> Judging from the warning description, this warning shouldn't even apply to 
> the method that's returning the Throwable, but rather the code that calls the 
> method. In any case, the catch clause is clearly doing something with the 
> exception. If the warning is intended behavior (that I don't understand), I 
> don't see how the code above rises to the level of "probable bug". Can you 
> please explain?
> What's even more puzzling is that this similar but simpler code works:
> {\{ private Throwable foo() {}}
>  {{  try {}}
>  {{    Thread.sleep(0);}}
>  {{    return null;}}
>  {{  } catch (E

[jira] [Created] (NETBEANS-958) inexplicable "throwable method result is ignored" warning

2018-06-14 Thread Alvin Thompson (JIRA)
Alvin Thompson created NETBEANS-958:
---

 Summary: inexplicable "throwable method result is ignored" warning
 Key: NETBEANS-958
 URL: https://issues.apache.org/jira/browse/NETBEANS-958
 Project: NetBeans
  Issue Type: Bug
  Components: cnd - Editor
Affects Versions: 9.0
 Environment: project JDK: 8
IDE JDK: 10
Reporter: Alvin Thompson


I have the following code:

{{public Map sendStandingOrders() {}}
{{  Map out = new LinkedHashMap<>();}}
{{  List standingOrders = 
getStandingOrdersThatNeedToRunNow();}}
{{  for (StandingOrderInfo standingOrderInfo : standingOrders) {}}
{{    try {}}
{{      sendStandingOrder(standingOrderInfo);}}
{{      out.put(standingOrderInfo, null); // warning here}}
{{    } catch (Exception ex) {}}
{{      // TODO: send emails}}
{{      logger.log(}}
{{        Level.SEVERE,}}
{{        "could not send standing order " + 
standingOrderInfo.standingOrder.getId() + " for "}}
{{ + standingOrderInfo.dayOfWeek + ", " + standingOrderInfo.dateRequested,}}
{{        ex}}
{{      );}}
{{      out.put(standingOrderInfo, ex); // warning here}}
{{    }}}
{{  }}}
{{  return out;}}
{{ }}}

Judging from the warning description, this warning shouldn't even apply to the 
method that's returning the Throwable, but rather the code that calls the 
method. In any case, the catch clause is clearly doing something with the 
exception. If the warning is intended behavior (that I don't understand), I 
don't see how the code above rises to the level of "probable bug". Can you 
please explain?

What's even more puzzling is that this similar but simpler code works:

{{ private Throwable foo() {}}
{{  try {}}
{{    Thread.sleep(0);}}
{{    return null;}}
{{  } catch (Exception ex) {}}
{{    return ex;}}
{{  }}}
{{ }}}

 



--
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-707) add an option to remember open tabs according to vcs branch

2018-06-14 Thread Alvin Thompson (JIRA)


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

Alvin Thompson updated NETBEANS-707:

Description: Usually, when you have to switch branches in git/svn/whatever, 
you'll be working on different files. It would be nice if the IDE remembered 
what tabs were open when you were last on that particular branch. When you next 
switch to that branch, that set of tabs should be used.  (was: Usually, when 
you have to switch branches in git/svn/whatever, you'll be working on different 
files. It would be nice if the IDE remembered what tabs were open when you were 
last on that particular branch, and remembered them. When you next switch to 
that branch, that set of tabs should be used.)

> add an option to remember open tabs according to vcs branch
> ---
>
> Key: NETBEANS-707
> URL: https://issues.apache.org/jira/browse/NETBEANS-707
> Project: NetBeans
>  Issue Type: New Feature
>  Components: ide - UI
>Reporter: Alvin Thompson
>Priority: Major
>
> Usually, when you have to switch branches in git/svn/whatever, you'll be 
> working on different files. It would be nice if the IDE remembered what tabs 
> were open when you were last on that particular branch. When you next switch 
> to that branch, that set of tabs should be used.



--
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-934) A lock is kept on window settings file

2018-06-14 Thread Thierry Danard (JIRA)


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

Thierry Danard commented on NETBEANS-934:
-

Running from code, we found that calling Mode.getTopComponents() prior to 
clearing the .settings files was the culprit. Hard to tell, but it seems 
NetBeans keeps input streams open for a while when Mode.getTopComponents() is 
called

> A lock is kept on window settings file
> --
>
> Key: NETBEANS-934
> URL: https://issues.apache.org/jira/browse/NETBEANS-934
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Window System
>Affects Versions: 9.0
>Reporter: Thierry Danard
>Priority: Minor
> Fix For: 9.0
>
>
> I have an application that is based upon the NetBeans platform. In this 
> application, we have a session mechanism where users can save and restore the 
> state of the windows. The way this session mechanism works is:
> To save:
>  * force a serialization of the window state (calling 
> org.netbeans.core.WindowSystem.save)
>  * save the content of all files in Windows2Local in a "session" file
>  * save the content of the tracker.properties file in the same "session" file
> To restore:
>  * wipe out the content of the Windows2Local directory and replace it with 
> the saved content, then
>  * replace the content of the tracker.properties file
>  * force a clear/reload using reflection:
> // load netbeans state from disk
>  System.gc();
>  System.gc();
>  FileUtil.refreshAll(); // needed to discard any caches copy of the setting 
> files
> Class windowSystemClass = 
> Thread.currentThread().getContextClassLoader().loadClass("org.netbeans.core.WindowSystem");
>  Class windowManagerClass = 
> Thread.currentThread().getContextClassLoader().loadClass("org.netbeans.core.windows.WindowManagerImpl");
>  Class persistenceHandlerClass = 
> Thread.currentThread().getContextClassLoader().loadClass("org.netbeans.core.windows.PersistenceHandler");
>  Class persistenceManagerClass = 
> Thread.currentThread().getContextClassLoader().loadClass("org.netbeans.core.windows.persistence.PersistenceManager");
> Object windowSystem = Lookup.getDefault().lookup(windowSystemClass);
> Method method = windowSystemClass.getMethod("hide");
>  method.invoke(windowSystem);
> method = windowManagerClass.getMethod("getInstance");
>  Object windowManager = method.invoke(windowManagerClass);
>  windowManager.getClass().getMethod("resetModel").invoke(windowManager);
>  windowManagerClass.getMethod("setRecentViewList", 
> String[].class).invoke(windowManager, new Object[]{new String[0]});
> method = persistenceManagerClass.getMethod("getDefault");
>  Object persistenceManager = method.invoke(persistenceManagerClass);
>  persistenceManager.getClass().getMethod("clear").invoke(persistenceManager);
> method = persistenceHandlerClass.getMethod("getDefault");
>  Object persistenceHandler = method.invoke(persistenceHandlerClass);
>  persistenceHandler.getClass().getMethod("clear").invoke(persistenceHandler);
> method = windowSystemClass.getMethod("load");
>  method.invoke(windowSystem);
> method = windowSystemClass.getMethod("show");
>  method.invoke(windowSystem);
> This used to work in versions 8.x, but no longer. Some ".settings" files are 
> locked. The files that stay locked vary, which points to something related to 
> garbage collection. File.canWrite() actually returns false for some files. 
> After some investigation, I found that the lock issue is probably a 
> permission issue (I am on Windows). It looks like that some process is 
> removing the ownership/permissions of the .settings files that are being 
> created. Some .settings files have no owner and no permissions. This explains 
> why File.canWrite returns false for these files.
> What is this mechanism in NetBeans that changes the ownership or permissions 
> of the settings files?
>  
>  



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

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

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



[jira] [Updated] (NETBEANS-957) Folded code blocks expands automatically

2018-06-14 Thread roger (JIRA)


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

roger updated NETBEANS-957:
---
Environment: Windows 10  (was: Windows)
Description: 
I am finding a strange issue that is causing my folded code blocks to 
automatically expand.

I am using windows 10, and the file I am using is any PHP file. 

The editor lets me collapse the code block, but then when I move down the page 
(scrolling for example, it automatically expands again.) I turn code preview 
off in the settings, no avail.

Also, when I hit enter on new line to start typing, it then expands and shifts 
my cursor to the previously closed tag and auto expands. Very annoying. 

 

There was a user I searched with a similar issue and it doesnt seem like it was 
resolved. I consider this a bug. At the moment the only way to make this work 
is to not use collapsing at all. But that is not a great option.

 

Please advise. 

 

Here is IDE data:
 *Product Version:* NetBeans IDE 8.2 (Build 201705191307)

*Updates:* NetBeans IDE is updated to version [NetBeans 8.2 Patch 
2|http://wiki.netbeans.org/NetBeans8.2PatchesInfo]

*Java:* 1.8.0_101; Java HotSpot(TM) 64-Bit Server VM 25.101-b13

*Runtime:* Java(TM) SE Runtime Environment 1.8.0_101-b13

*System:* Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb)

*User directory:* C:\Users\roger\AppData\Roaming\NetBeans\8.2

*Cache directory:* C:\Users\roger\AppData\Local\NetBeans\Cache\8.2

  was:
I am finding a strange issue that is causing my folded code blocks to 
automatically expand.

I am using windows, and the file I am using is any PHP file. 

The editor lets me collapse the code block, but then when I move down the page 
(scrolling for example, it automatically expands again.) I turn code preview 
off in the settings, no avail.

Also, when I hit enter on new line to start typing, it then expands and shifts 
my cursor to the previously closed tag and auto expands. Very annoying. 

 

There was a user I searched with a similar issue and it doesnt seem like it was 
resolved. I consider this a bug. At the moment the only way to make this work 
is to not use collapsing at all. But that is not a great option.

 

Please advise. 

 

Here is IDE data:
*Product Version:* NetBeans IDE 8.2 (Build 201705191307)

*Updates:* NetBeans IDE is updated to version [NetBeans 8.2 Patch 
2|http://wiki.netbeans.org/NetBeans8.2PatchesInfo]

*Java:* 1.8.0_101; Java HotSpot(TM) 64-Bit Server VM 25.101-b13

*Runtime:* Java(TM) SE Runtime Environment 1.8.0_101-b13

*System:* Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb)

*User directory:* C:\Users\roger\AppData\Roaming\NetBeans\8.2

*Cache directory:* C:\Users\roger\AppData\Local\NetBeans\Cache\8.2


> Folded code blocks expands automatically
> 
>
> Key: NETBEANS-957
> URL: https://issues.apache.org/jira/browse/NETBEANS-957
> Project: NetBeans
>  Issue Type: Bug
>  Components: cnd - Editor
>Affects Versions: 8.2
> Environment: Windows 10
>Reporter: roger
>Priority: Major
>
> I am finding a strange issue that is causing my folded code blocks to 
> automatically expand.
> I am using windows 10, and the file I am using is any PHP file. 
> The editor lets me collapse the code block, but then when I move down the 
> page (scrolling for example, it automatically expands again.) I turn code 
> preview off in the settings, no avail.
> Also, when I hit enter on new line to start typing, it then expands and 
> shifts my cursor to the previously closed tag and auto expands. Very 
> annoying. 
>  
> There was a user I searched with a similar issue and it doesnt seem like it 
> was resolved. I consider this a bug. At the moment the only way to make this 
> work is to not use collapsing at all. But that is not a great option.
>  
> Please advise. 
>  
> Here is IDE data:
>  *Product Version:* NetBeans IDE 8.2 (Build 201705191307)
> *Updates:* NetBeans IDE is updated to version [NetBeans 8.2 Patch 
> 2|http://wiki.netbeans.org/NetBeans8.2PatchesInfo]
> *Java:* 1.8.0_101; Java HotSpot(TM) 64-Bit Server VM 25.101-b13
> *Runtime:* Java(TM) SE Runtime Environment 1.8.0_101-b13
> *System:* Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb)
> *User directory:* C:\Users\roger\AppData\Roaming\NetBeans\8.2
> *Cache directory:* C:\Users\roger\AppData\Local\NetBeans\Cache\8.2



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

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

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



[jira] [Created] (NETBEANS-957) Folded code blocks expands automatically

2018-06-14 Thread roger (JIRA)
roger created NETBEANS-957:
--

 Summary: Folded code blocks expands automatically
 Key: NETBEANS-957
 URL: https://issues.apache.org/jira/browse/NETBEANS-957
 Project: NetBeans
  Issue Type: Bug
  Components: cnd - Editor
Affects Versions: 8.2
 Environment: Windows
Reporter: roger


I am finding a strange issue that is causing my folded code blocks to 
automatically expand.

I am using windows, and the file I am using is any PHP file. 

The editor lets me collapse the code block, but then when I move down the page 
(scrolling for example, it automatically expands again.) I turn code preview 
off in the settings, no avail.

Also, when I hit enter on new line to start typing, it then expands and shifts 
my cursor to the previously closed tag and auto expands. Very annoying. 

 

There was a user I searched with a similar issue and it doesnt seem like it was 
resolved. I consider this a bug. At the moment the only way to make this work 
is to not use collapsing at all. But that is not a great option.

 

Please advise. 

 

Here is IDE data:
*Product Version:* NetBeans IDE 8.2 (Build 201705191307)

*Updates:* NetBeans IDE is updated to version [NetBeans 8.2 Patch 
2|http://wiki.netbeans.org/NetBeans8.2PatchesInfo]

*Java:* 1.8.0_101; Java HotSpot(TM) 64-Bit Server VM 25.101-b13

*Runtime:* Java(TM) SE Runtime Environment 1.8.0_101-b13

*System:* Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb)

*User directory:* C:\Users\roger\AppData\Roaming\NetBeans\8.2

*Cache directory:* C:\Users\roger\AppData\Local\NetBeans\Cache\8.2



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

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

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



[jira] [Resolved] (NETBEANS-896) Defining generic method throws Exception on without nbjavac

2018-06-14 Thread Laszlo Kishalmi (JIRA)


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

Laszlo Kishalmi resolved NETBEANS-896.
--
   Resolution: Fixed
Fix Version/s: 9.0

> Defining generic method throws Exception on without nbjavac
> ---
>
> Key: NETBEANS-896
> URL: https://issues.apache.org/jira/browse/NETBEANS-896
> Project: NetBeans
>  Issue Type: Bug
>  Components: java - Editor
>Affects Versions: 9.0
> Environment: release-302-on-20180517 without nbjavac
>Reporter: Naoki Kishida
>Priority: Major
>  Labels: pull-request-available
> Fix For: 9.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Defining a generic method throws NPE.
> After inputing ``, NPE is thrown.
>  {code}
> class Foo {
>   
> }{code}
> {code}
> java.lang.NullPointerException
>   at 
> org.netbeans.modules.java.source.usages.SourceAnalyzerFactory$UsagesVisitor.visitErroneous(SourceAnalyzerFactory.java:752)
>   at 
> org.netbeans.modules.java.source.usages.SourceAnalyzerFactory$UsagesVisitor.visitErroneous(SourceAnalyzerFactory.java:274)
>   at 
> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCErroneous.accept(JCTree.java:2927)
>   at 
> jdk.compiler/com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
>   at 
> org.netbeans.modules.java.source.usages.SourceAnalyzerFactory$UsagesVisitor.scan(SourceAnalyzerFactory.java:385)
>   at 
> org.netbeans.modules.java.source.usages.SourceAnalyzerFactory$UsagesVisitor.scan(SourceAnalyzerFactory.java:274)
>   at 
> jdk.compiler/com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:90)
>   at 
> jdk.compiler/com.sun.source.util.TreeScanner.scan(TreeScanner.java:105)
>   at 
> org.netbeans.modules.java.source.usages.SourceAnalyzerFactory$UsagesVisitor.visitClass(SourceAnalyzerFactory.java:716)
>   at 
> org.netbeans.modules.java.source.usages.SourceAnalyzerFactory$UsagesVisitor.visitClass(SourceAnalyzerFactory.java:274)
>   at 
> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:808)
>   at 
> jdk.compiler/com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
>   at 
> org.netbeans.modules.java.source.usages.SourceAnalyzerFactory$UsagesVisitor.scan(SourceAnalyzerFactory.java:385)
>   at 
> org.netbeans.modules.java.source.usages.SourceAnalyzerFactory$UsagesVisitor.scan(SourceAnalyzerFactory.java:274)
>   at 
> jdk.compiler/com.sun.source.util.TreeScanner.scan(TreeScanner.java:105)
>   at 
> org.netbeans.modules.java.source.usages.SourceAnalyzerFactory$UsagesVisitor.visitCompilationUnit(SourceAnalyzerFactory.java:402)
>   at 
> org.netbeans.modules.java.source.usages.SourceAnalyzerFactory$UsagesVisitor.visitCompilationUnit(SourceAnalyzerFactory.java:274)
>   at 
> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:591)
>   at 
> jdk.compiler/com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
>   at 
> org.netbeans.modules.java.source.usages.SourceAnalyzerFactory$UsagesVisitor.scan(SourceAnalyzerFactory.java:385)
>   at 
> org.netbeans.modules.java.source.usages.SourceAnalyzerFactory$SimpleAnalyzer.analyseUnit(SourceAnalyzerFactory.java:242)
>   at 
> org.netbeans.modules.java.source.usages.PersistentClassIndex$IndexPatch.lambda$updateDirty$0(PersistentClassIndex.java:575)
>   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 
> org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178)
>   at 
> org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:81)
>   at 
> org.netbeans.api.java.source.JavaSource.runUserActionTaskImpl(JavaSource.java:451)
>   at 
> org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:42

[jira] [Updated] (NETBEANS-892) Refactor -> Move Class into other class breaks multicatches and lambas in destination class

2018-06-14 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot updated NETBEANS-892:

Labels: pull-request-available  (was: )

> Refactor -> Move Class into other class breaks multicatches and lambas in 
> destination class
> ---
>
> Key: NETBEANS-892
> URL: https://issues.apache.org/jira/browse/NETBEANS-892
> Project: NetBeans
>  Issue Type: Bug
>  Components: java - Refactoring
>Affects Versions: 9.0
>Reporter: Austin Stephens
>Assignee: Reema Taneja
>Priority: Blocker
>  Labels: pull-request-available
> Fix For: 9.0
>
> Attachments: EvilRefactorBug.zip
>
>
> Move the class "MoveMeIn" into the class "MoveTo". Things break. Many, many 
> thing break.



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

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

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



[incubator-netbeans] branch master updated: [NetBeans-778] Formatting issue with var declaration statement (#568)

2018-06-14 Thread sdedic
This is an automated email from the ASF dual-hosted git repository.

sdedic 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 9cac272  [NetBeans-778] Formatting issue with var declaration 
statement (#568)
9cac272 is described below

commit 9cac2724c8610d556d8c01681543201f76df7103
Author: Vikas Prabhakar 
AuthorDate: Thu Jun 14 14:44:14 2018 +0530

[NetBeans-778] Formatting issue with var declaration statement (#568)

[NetBeans-778] Formatting issue with var declaration statement
---
 .../modules/java/source/save/Reformatter.java  | 10 +++-
 .../modules/java/source/save/FormatingTest.java| 58 ++
 2 files changed, 66 insertions(+), 2 deletions(-)

diff --git 
a/java.source.base/src/org/netbeans/modules/java/source/save/Reformatter.java 
b/java.source.base/src/org/netbeans/modules/java/source/save/Reformatter.java
index 20af393..5b359c5 100644
--- 
a/java.source.base/src/org/netbeans/modules/java/source/save/Reformatter.java
+++ 
b/java.source.base/src/org/netbeans/modules/java/source/save/Reformatter.java
@@ -1196,9 +1196,15 @@ public class Reformatter implements ReformatTask {
 } else {
 if (!insideForTryOrCatch)
 continuationIndent = true;
-if (node.getType() == null || scan(node.getType(), p)) {
-if (node.getType() != null) {
+if (node.getType() == null || tokens.token().id() == 
JavaTokenId.VAR || scan(node.getType(), p)) {
+if (node.getType() != null && tokens.token().id() != 
JavaTokenId.VAR) {
 spaces(1, fieldGroup);
+} else {
+if (tokens.token().id() == JavaTokenId.VAR) {
+//Add space after 'var' token
+addDiff(new Diff(tokens.offset() + 3, 
tokens.offset() + 3, " "));
+tokens.moveNext();
+}
 }
 if (!ERROR.contentEquals(node.getName()))
 accept(IDENTIFIER, UNDERSCORE);
diff --git 
a/java.source.base/test/unit/src/org/netbeans/modules/java/source/save/FormatingTest.java
 
b/java.source.base/test/unit/src/org/netbeans/modules/java/source/save/FormatingTest.java
index 59e8969..cda1c9f 100644
--- 
a/java.source.base/test/unit/src/org/netbeans/modules/java/source/save/FormatingTest.java
+++ 
b/java.source.base/test/unit/src/org/netbeans/modules/java/source/save/FormatingTest.java
@@ -4457,6 +4457,64 @@ public class FormatingTest extends NbTestCase {
 reformat(doc, content, golden);
 }
 
+public void testForVar1() throws Exception {
+testFile = new File(getWorkDir(), "Test.java");
+TestUtilities.copyStringToFile(testFile, "");
+FileObject testSourceFO = FileUtil.toFileObject(testFile);
+DataObject testSourceDO = DataObject.find(testSourceFO);
+EditorCookie ec = (EditorCookie) 
testSourceDO.getCookie(EditorCookie.class);
+String oldLevel = JavaSourceTest.SourceLevelQueryImpl.sourceLevel;
+JavaSourceTest.SourceLevelQueryImpl.sourceLevel = "1.10";
+final Document doc = ec.openDocument();
+doc.putProperty(Language.class, JavaTokenId.language());
+String content
+= "package hierbas.del.litoral;\n\n"
++ "public class Test {\n\n"
++ "public static void main(String[] args) {\n"
++ "varv=   10; \n"
++ "}\n"
++ "}\n";
+
+String golden
+= "package hierbas.del.litoral;\n\n"
++ "public class Test {\n\n"
++ "public static void main(String[] args) {\n"
++ "var v = 10;\n"
++ "}\n"
++ "}\n";
+reformat(doc, content, golden);
+JavaSourceTest.SourceLevelQueryImpl.sourceLevel = oldLevel;
+}
+
+public void testForVar2() throws Exception {
+testFile = new File(getWorkDir(), "Test.java");
+TestUtilities.copyStringToFile(testFile, "");
+FileObject testSourceFO = FileUtil.toFileObject(testFile);
+DataObject testSourceDO = DataObject.find(testSourceFO);
+EditorCookie ec = (EditorCookie) 
testSourceDO.getCookie(EditorCookie.class);
+String oldLevel = JavaSourceTest.SourceLevelQueryImpl.sourceLevel;
+JavaSourceTest.SourceLevelQueryImpl.sourceLevel = "1.10";
+final Document doc = ec.openDocument();
+doc.putProperty(Language.class, JavaTokenId.language());
+String content
+= "package hierbas.del.litoral;\n\n"
++ "public class Test {\n\n"
++ "public static 

[jira] [Updated] (NETBEANS-910) Editing annotation parameters results in Exceptions thrown

2018-06-14 Thread Peter Nabbefeld (JIRA)


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

Peter Nabbefeld updated NETBEANS-910:
-
Component/s: apisupport - Maven

> Editing annotation parameters results in Exceptions thrown
> --
>
> Key: NETBEANS-910
> URL: https://issues.apache.org/jira/browse/NETBEANS-910
> Project: NetBeans
>  Issue Type: Bug
>  Components: apisupport - Maven
>Affects Versions: 9.0
> Environment: Linux
>Reporter: Peter Nabbefeld
>Priority: Major
>
> I got these exceptions when editing a @TemplateRegistration in a 
> package-info.java file:
> INFO [com.sun.tools.javac.processing.JavacProcessingEnvironment]: Annotation 
> processing error:
> java.lang.annotation.AnnotationTypeMismatchException: Incorrectly typed data 
> found for annotation element public abstract java.lang.String 
> org.netbeans.api.templates.TemplateRegistration.description() (Found data of 
> type )
>     at 
> com.sun.tools.javac.model.AnnotationProxyMaker$ValueVisitor$1AnnotationTypeMismatchExceptionProxy.generateException(AnnotationProxyMaker.java:275)
>     at 
> sun.reflect.annotation.AnnotationInvocationHandler.invoke(AnnotationInvocationHandler.java:84)
>     at com.sun.proxy.$Proxy60.description(Unknown Source)
>     at 
> org.netbeans.modules.templates.TemplateProcessor.process(TemplateProcessor.java:128)
>     at 
> org.netbeans.modules.templates.TemplateProcessor.handleProcess(TemplateProcessor.java:82)
>     at 
> org.openide.filesystems.annotations.LayerGeneratingProcessor.process(LayerGeneratingProcessor.java:122)
> [catch] at 
> com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:856)
>     at 
> com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:752)
>     at 
> com.sun.tools.javac.processing.JavacProcessingEnvironment.access$2200(JavacProcessingEnvironment.java:99)
>     at 
> com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1081)
>     at 
> com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1157)
>     at 
> com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1210)
>     at 
> com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1099)
>     at com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:374)
>     at com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:311)
>     at 
> org.netbeans.modules.java.source.parsing.JavacParser.moveToPhase(JavacParser.java:630)
>     at 
> org.netbeans.modules.java.source.parsing.JavacParser.getResult(JavacParser.java:496)
>     at 
> org.netbeans.modules.java.source.parsing.JavacParser.getResult(JavacParser.java:163)
>     at 
> org.netbeans.modules.parsing.impl.TaskProcessor.callGetResult(TaskProcessor.java:631)
>     at 
> org.netbeans.modules.parsing.impl.SourceCache.getResult(SourceCache.java:262)
>     at 
> org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.run(TaskProcessor.java:798)
>     at org.openide.util.lookup.Lookups.executeWith(Lookups.java:304)
>     at 
> org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.execute(TaskProcessor.java:725)
>     at 
> org.netbeans.modules.parsing.impl.TaskProcessor$CompilationJob.run(TaskProcessor.java:686)
>     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>     at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>     at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443)
>     at 
> org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68)
>     at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303)
>     at 
> org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058)
> INFO [com.sun.tools.javac.processing.JavacProcessingEnvironment]: Annotation 
> processing error:
> java.lang.annotation.AnnotationTypeMismatchException: Incorrectly typed data 
> found for annotation element public abstract java.lang.String 
> org.netbeans.api.templates.TemplateRegistration.scriptEngine() (Found data of 
> type )
>     at 
> com.sun.tools.javac.model.AnnotationProxyMaker$ValueVisitor$1AnnotationTypeMismatchExceptionProxy.generateException(AnnotationProxyMaker.java:275)
>     at 
> sun.reflect.annotation.AnnotationInvocationHandler.invoke(AnnotationInvocationHandler.java:84)
>     at com.sun.proxy.$Proxy60.scriptEngine(Unknown Source)
>     at 
> org.netbeans.modules.templates.TemplateProcessor.process(TemplateProcessor.java:153)
>     at 
> org.netbeans.modules.templates.TemplateProcessor.handleProcess(TemplateProcessor.java:82)
>     at 
> org.openide.filesystems.annotations.LayerGeneratingProcesso

[jira] [Updated] (NETBEANS-914) Generated WizardDescriptor.InstantiatingIterator contains suspicious code

2018-06-14 Thread Peter Nabbefeld (JIRA)


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

Peter Nabbefeld updated NETBEANS-914:
-
Component/s: apisupport - Project

> Generated WizardDescriptor.InstantiatingIterator contains suspicious code
> -
>
> Key: NETBEANS-914
> URL: https://issues.apache.org/jira/browse/NETBEANS-914
> Project: NetBeans
>  Issue Type: Improvement
>  Components: apisupport - Project
>Affects Versions: 9.0
> Environment: Linux
>Reporter: Peter Nabbefeld
>Priority: Minor
>
> The InstantiatingIterator contains following code:
>     String[] steps = createSteps();
>     for (int i = 0; i < panels.size(); i++) {
>     Component c = panels.get(i).getComponent();
>     if (steps[i] == null) {
>     // Default step name to component name of panel. Mainly
>     // useful for getting the name of the target chooser to
>     // appear in the list of steps.
>     steps[i] = c.getName();
>     }
> Here, "steps" is used as a zero-based array.
> It uses following method:
> private String[] createSteps() {
>     String[] beforeSteps = 
> (String[])wizard.getProperty("WizardPanel_contentData");
>     assert beforeSteps != null : "This wizard may only be used embedded in 
> the template wizard";
>     String[] res = new String[(beforeSteps.length - 1) + panels.size()];
>     for (int i = 0; i < res.length; i++) {
>     if (i < (beforeSteps.length - 1)) {
>     res[i] = beforeSteps[i];
>     } else {
>     res[i] = panels.get(i - beforeSteps.length + 
> 1).getComponent().getName();
>     }
>     }
>     return res;
> }
> Here, "steps" has a bias-value (the size of beforeSteps - 1), which seems to 
> be zero in most cases, but the different usage may cause errors if bias > 0.
> Probably it should be made clear, what this bias value exactly is, and then 
> it should also be used in the code above, if needed.



--
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-911) generated-layer.xml not rebuilt after annotation changes

2018-06-14 Thread Peter Nabbefeld (JIRA)


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

Peter Nabbefeld updated NETBEANS-911:
-
Component/s: apisupport - Maven

> generated-layer.xml not rebuilt after annotation changes
> 
>
> Key: NETBEANS-911
> URL: https://issues.apache.org/jira/browse/NETBEANS-911
> Project: NetBeans
>  Issue Type: Bug
>  Components: apisupport - Maven
>Affects Versions: 9.0
>Reporter: Peter Nabbefeld
>Priority: Major
>
> I've created a module for a new file type, containing a package-info.java 
> file with a @TemplateRegistration annotation.
> When I change the parameters of this annotation, the generated-layer.xml 
> isn't rebuilt, thus changes are ignored.
> When I change some target directories (I don't want to do a clean build 
> because I don't want to remove userdir), I sometimes get Exceptions when I 
> try running after rebuilding, so removing is not really a good workaround. As 
> it doesn't happen always, I had to investigate, when this happens, but it's 
> also useless, if this bug gets fixed.



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