[jira] [Created] (NETBEANS-6008) Update FlatLAF to 1.6 as 1.4 has several regressions

2021-09-16 Thread Markus Sunela (Jira)
Markus Sunela created NETBEANS-6008:
---

 Summary: Update FlatLAF to 1.6 as 1.4 has several regressions
 Key: NETBEANS-6008
 URL: https://issues.apache.org/jira/browse/NETBEANS-6008
 Project: NetBeans
  Issue Type: Bug
  Components: FlatLaf
Affects Versions: 12.5
Reporter: Markus Sunela


The current FlatLaf version, 1.4, has several regressions compared to the old 
1.1.2. For example [https://github.com/JFormDesigner/FlatLaf/issues/371] causes 
severe problems in our software built on NetBeans platform.

FlatLaf has just released a new version 1.6 that addresses many regressions. 
The new version should be used in NetBeans: 
[https://github.com/JFormDesigner/FlatLaf/releases/tag/1.6|https://github.com/JFormDesigner/FlatLaf/releases/tag/1.6.].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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



[jira] [Updated] (NETBEANS-5104) NetBeans cannot be launched on Windows if UTF-8 encoding is enabled in locale and the user profile directory contains non-ASCII characters.

2020-12-11 Thread Markus Sunela (Jira)


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

Markus Sunela updated NETBEANS-5104:

Description: 
There seems to be an encoding issue in the Windows platform launcher when the 
quite new UTF-8 encoding feature in Windows local settings is being used. At 
least Dell has started to enable that feature by default.

When the settings is enabled an the user profile directory contains non-ASCII 
characters like ä,ö and ü, an error is displayed:
{quote}An instance of the program cannot access specified user directory. This 
is a serious problem that may prevent the program to function properly. Make 
sure C:\Users\\.netbeans\12.1 is writable.
{quote}
The error clearly hints that an UTF-8 string is interpreted somewhere as being 
ISO8859-1/ANSI encoded. This causes the software fail.

As a related note, the non-ASCII umlauts cause no problem, when the system code 
page is ISO8859-15 and the NetBeans laucher handles them just fine.

  was:
There seems to be an encoding issue in the Windows platform launcher when the 
quite new UTF-8 encoding feature in Windows local settings is being used. At 
least Dell has started to enable that feature by default.

When the settings is enabled an the user profile directory contains non-ASCII 
characters like ä,ö and ü, an error is displayed:
{quote}An instance of the program cannot access specified user directory. This 
is a serious problem that may prevent the program to function properly. Make 
sure C:\Users\\.netbeans\12.1 is writable.
{quote}
The error clearly hints that an UTF-8 string is interpreted somewhere as being 
ISO8859-1/ANSI encoded. This causes the software fail.


> NetBeans cannot be launched on Windows if UTF-8 encoding is enabled in locale 
> and the user profile directory contains non-ASCII characters.
> ---
>
> Key: NETBEANS-5104
> URL: https://issues.apache.org/jira/browse/NETBEANS-5104
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 12.1
> Environment: Windows 10 version 2010 with the beta UTF-8 encoding 
> enabled in the locale settings.
>Reporter: Markus Sunela
>Priority: Major
>
> There seems to be an encoding issue in the Windows platform launcher when the 
> quite new UTF-8 encoding feature in Windows local settings is being used. At 
> least Dell has started to enable that feature by default.
> When the settings is enabled an the user profile directory contains non-ASCII 
> characters like ä,ö and ü, an error is displayed:
> {quote}An instance of the program cannot access specified user directory. 
> This is a serious problem that may prevent the program to function properly. 
> Make sure C:\Users\ ü>\.netbeans\12.1 is writable.
> {quote}
> The error clearly hints that an UTF-8 string is interpreted somewhere as 
> being ISO8859-1/ANSI encoded. This causes the software fail.
> As a related note, the non-ASCII umlauts cause no problem, when the system 
> code page is ISO8859-15 and the NetBeans laucher handles them just fine.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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



[jira] [Commented] (NETBEANS-5104) NetBeans cannot be launched on Windows if UTF-8 encoding is enabled in locale and the user profile directory contains non-ASCII characters.

2020-12-11 Thread Markus Sunela (Jira)


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

Markus Sunela commented on NETBEANS-5104:
-

Yes, the --user-dir commandline override and friends do work nicely. But of 
course, it would be nice, if this would "just work", as it does, when the 
system encoding is ISO8859-15: in this case the NetBeans launcher handles the 
non-ASCII characters just fine. It is just the UTF-8 system encoding wrecking 
havoc.

> NetBeans cannot be launched on Windows if UTF-8 encoding is enabled in locale 
> and the user profile directory contains non-ASCII characters.
> ---
>
> Key: NETBEANS-5104
> URL: https://issues.apache.org/jira/browse/NETBEANS-5104
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - LaunchersCLI
>Affects Versions: 12.1
> Environment: Windows 10 version 2010 with the beta UTF-8 encoding 
> enabled in the locale settings.
>Reporter: Markus Sunela
>Priority: Major
>
> There seems to be an encoding issue in the Windows platform launcher when the 
> quite new UTF-8 encoding feature in Windows local settings is being used. At 
> least Dell has started to enable that feature by default.
> When the settings is enabled an the user profile directory contains non-ASCII 
> characters like ä,ö and ü, an error is displayed:
> {quote}An instance of the program cannot access specified user directory. 
> This is a serious problem that may prevent the program to function properly. 
> Make sure C:\Users\ ü>\.netbeans\12.1 is writable.
> {quote}
> The error clearly hints that an UTF-8 string is interpreted somewhere as 
> being ISO8859-1/ANSI encoded. This causes the software fail.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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



[jira] [Created] (NETBEANS-5104) NetBeans cannot be launched on Windows if UTF-8 encoding is enabled in locale and the user profile directory contains non-ASCII characters.

2020-12-07 Thread Markus Sunela (Jira)
Markus Sunela created NETBEANS-5104:
---

 Summary: NetBeans cannot be launched on Windows if UTF-8 encoding 
is enabled in locale and the user profile directory contains non-ASCII 
characters.
 Key: NETBEANS-5104
 URL: https://issues.apache.org/jira/browse/NETBEANS-5104
 Project: NetBeans
  Issue Type: Bug
  Components: platform - LaunchersCLI
Affects Versions: 12.1
 Environment: Windows 10 version 2010 with the beta UTF-8 encoding 
enabled in the locale settings.
Reporter: Markus Sunela


There seems to be an encoding issue in the Windows platform launcher when the 
quite new UTF-8 encoding feature in Windows local settings is being used. At 
least Dell has started to enable that feature by default.

When the settings is enabled an the user profile directory contains non-ASCII 
characters like ä,ö and ü, an error is displayed:
{quote}An instance of the program cannot access specified user directory. This 
is a serious problem that may prevent the program to function properly. Make 
sure C:\Users\\.netbeans\12.1 is writable.
{quote}
The error clearly hints that an UTF-8 string is interpreted somewhere as being 
ISO8859-1/ANSI encoded. This causes the software fail.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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



[jira] [Commented] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet

2020-04-24 Thread Markus Sunela (Jira)


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

Markus Sunela commented on NETBEANS-4222:
-

Cool, thanks Geertjan! That sounds viable and probably much less invasive 
approach. Still, there are be many more locations besides the ProxyNode, where 
being able to change or extend the functionality would be worthwhile, but let's 
start with a thing at a time.

> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior, 
> because there are too many private instead of protected methods, package 
> private and final classes in the API.
> Some examples I have stumbled on include
>  * private doSetNodes method in PropertySheet (no way to override the use of 
> ProxyNodes)
>  * final and package private ProxyNode class
>  * package private constructor in ProxyNode
>  * package private getOriginalNodes method in ProxyNode
>  * package private and final {color:#00}ProxyProperty{color} class in 
> ProxyNode
>  * final Sheet class and its inner class Sheet.Set
>  * most private methods in Sheet and Sheet.Set should be protected instead
>  * PropertySupport.Reflection class should have getters for read and write 
> methods
> I wonder, what is the rationale for so strict and static API design? I would 
> assume the performance gains from these limitations are meager. Opening these 
> classes for sub-classing and modifications would result in much more flexible 
> system with much less code duplication.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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



[jira] [Comment Edited] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet

2020-04-24 Thread Markus Sunela (Jira)


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

Markus Sunela edited comment on NETBEANS-4222 at 4/24/20, 1:34 PM:
---

Thanks for the comments and the book links. They're good read!

You have all the freedom and rights to not to accept the patch, and your 
reasons are much more well thought and better founded than mine. Good API 
design of course is hard and delicate work, and I am not qualified to argue 
that and the long experience of you both working with NetBeans platform. What I 
am putting forward is a suggestion.

Personally, I just don't see value in making and keeping API closed down just 
because it is considered good design, when it severely limits the future 
possibilities what could be achieved using and extending the classes that are 
already there. Documenting the opened APIs is easy enough and no, I am not 
proposing any changes without test coverage and or versioning. The pull request 
was just an answer to Geertjan's idea to "make the changes yourself" - here are 
the changes. Creating the tests, documentation and all would be wasted, if 
there wouldn't be any interest in the changes.

In my opinion any specific use-cases are not that matters, when the problem is 
overall API rigidity (which is, I guess, at least in part subjective notion), 
but if you need some use-cases, here's the acute one I am trying to solve: 
being able to replace ProxyNode usage in PropertySheet with more efficient 
implementation, that can ignore most of the properties and tabs and that can 
properly cache available properties based on the common base class of the 
(Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes 
being edited and once, and the performance starts to be very poor. As 
PropertySheet.doSetNodes is private and the method is called from many more 
private functions and classes, there is no way how I could override that. I 
cannot also create my own PropertySheet copy, as it again depends on many 
package private classes and so on. Creating a separate copy of whole 
org.openide.nodes and org.openide.explorer modules seems so wasteful just to 
change one method. That's why I would like to argue, that the whole API could 
be made more flexible to begin with, as there would be many other.

 


was (Author: markus.sun...@fluidit.fi):
Thanks for the comments and the book links. They're good read!

You have all the freedom and rights to not to accept the patch, and your 
reasons are much more well thought and better founded than mine. Good API 
design of course is hard and delicate work, and I am not qualified to argue 
that and the long experience of you both working with NetBeans platform. What I 
am putting forward is a suggestion.

Personally, I just don't see value in making and keeping API closed down just 
because it is considered good design, when it severely limits the future 
possibilities what could be achieved using and extending the classes that are 
already there. Documenting the opened APIs is easy enough and no, I am not 
proposing any changes without test coverage and or versioning. The pull request 
was just an answer to Geertjan's idea to "make the changes yourself" - here are 
the changes. Creating the tests, documentation and all would be wasted, if 
there wouldn't be any interested in the changes.

In my opinion any specific use-cases are not that matters, when the problem is 
overall API rigidity (which is, I guess, at least in part subjective notion), 
but if you some use-cases, here's the acute one I am trying to solve: being 
able to replace ProxyNode usage in PropertySheet with more efficient 
implementation, that can ignore most of the properties and tabs and that can 
properly cache available properties based on the common base class of the 
(Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes 
being edited and once, and the performance starts to be very poor. As 
PropertySheet.doSetNodes is private and the method is called from many more 
private functions and classes, there is no way how I could override that. I 
cannot also create my own PropertySheet copy, as it again depends on many 
package private classes and so on. Creating a separate copy of whole 
org.openide.nodes and org.openide.explorer modules seems so wasteful just to 
change one method. That's why I would like to argue, that the whole API could 
be made more flexible to begin with, as there would be many other.

 

> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela

[jira] [Comment Edited] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet

2020-04-24 Thread Markus Sunela (Jira)


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

Markus Sunela edited comment on NETBEANS-4222 at 4/24/20, 1:17 PM:
---

Thanks for the comments and the book links. They're good read!

You have all the freedom and rights to not to accept the patch, and your 
reasons are much more well thought and better founded than mine. Good API 
design of course is hard and delicate work, and I am not qualified to argue 
that and the long experience of you both working with NetBeans platform. What I 
am putting forward is a suggestion.

Personally, I just don't see value in making and keeping API closed down just 
because it is considered good design, when it severely limits the future 
possibilities what could be achieved using and extending the classes that are 
already there. Documenting the opened APIs is easy enough and no, I am not 
proposing any changes without test coverage and or versioning. The pull request 
was just an answer to Geertjan's idea to "make the changes yourself" - here are 
the changes. Creating the tests, documentation and all would be wasted, if 
there wouldn't be any interested in the changes.

In my opinion any specific use-cases are not that matters, when the problem is 
overall API rigidity (which is, I guess, at least in part subjective notion), 
but if you some use-cases, here's the acute one I am trying to solve: being 
able to replace ProxyNode usage in PropertySheet with more efficient 
implementation, that can ignore most of the properties and tabs and that can 
properly cache available properties based on the common base class of the 
(Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes 
being edited and once, and the performance starts to be very poor. As 
PropertySheet.doSetNodes is private and the method is called from many more 
private functions and classes, there is no way how I could override that. I 
cannot also create my own PropertySheet copy, as it again depends on many 
package private classes and so on. Creating a separate copy of whole 
org.openide.nodes and org.openide.explorer modules seems so wasteful just to 
change one method. That's why I would like to argue, that the whole API could 
be made more flexible to begin with, as there would be many other.

 


was (Author: markus.sun...@fluidit.fi):
You have all the freedom and rights to not to accept the patch, and your 
reasons are much more well thought and better founded than mine. Good API 
design of course is hard and delicate work, and I am not qualified to argue 
that and the long experience of you both working with NetBeans platform. What I 
am putting forward is a suggestion.

Personally, I just don't see value in making and keeping API closed down just 
because it is considered good design, when it severely limits the future 
possibilities what could be achieved using and extending the classes that are 
already there. Documenting the opened APIs is easy enough and no, I am not 
proposing any changes without test coverage and or versioning. The pull request 
was just an answer to Geertjan's idea to "make the changes yourself" - here are 
the changes. Creating the tests, documentation and all would be wasted, if 
there wouldn't be any interested in the changes.

In my opinion any specific use-cases are not that matters, when the problem is 
overall API rigidity (which is, I guess, at least in part subjective notion), 
but if you some use-cases, here's the acute one I am trying to solve: being 
able to replace ProxyNode usage in PropertySheet with more efficient 
implementation, that can ignore most of the properties and tabs and that can 
properly cache available properties based on the common base class of the 
(Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes 
being edited and once, and the performance starts to be very poor. As 
PropertySheet.doSetNodes is private and the method is called from many more 
private functions and classes, there is no way how I could override that. I 
cannot also create my own PropertySheet copy, as it again depends on many 
package private classes and so on. Creating a separate copy of whole 
org.openide.nodes and org.openide.explorer modules seems so wasteful just to 
change one method. That's why I would like to argue, that the whole API could 
be made more flexible to begin with, as there would be many other.

 

> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize 

[jira] [Commented] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet

2020-04-24 Thread Markus Sunela (Jira)


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

Markus Sunela commented on NETBEANS-4222:
-

You have all the freedom and rights to not to accept the patch, and your 
reasons are much more well thought and better founded than mine. Good API 
design of course is hard and delicate work, and I am not qualified to argue 
that and the long experience of you both working with NetBeans platform. What I 
am putting forward is a suggestion.

Personally, I just don't see value in making and keeping API closed down just 
because it is considered good design, when it severely limits the future 
possibilities what could be achieved using and extending the classes that are 
already there. Documenting the opened APIs is easy enough and no, I am not 
proposing any changes without test coverage and or versioning. The pull request 
was just an answer to Geertjan's idea to "make the changes yourself" - here are 
the changes. Creating the tests, documentation and all would be wasted, if 
there wouldn't be any interested in the changes.

In my opinion any specific use-cases are not that matters, when the problem is 
overall API rigidity (which is, I guess, at least in part subjective notion), 
but if you some use-cases, here's the acute one I am trying to solve: being 
able to replace ProxyNode usage in PropertySheet with more efficient 
implementation, that can ignore most of the properties and tabs and that can 
properly cache available properties based on the common base class of the 
(Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes 
being edited and once, and the performance starts to be very poor. As 
PropertySheet.doSetNodes is private and the method is called from many more 
private functions and classes, there is no way how I could override that. I 
cannot also create my own PropertySheet copy, as it again depends on many 
package private classes and so on. Creating a separate copy of whole 
org.openide.nodes and org.openide.explorer modules seems so wasteful just to 
change one method. That's why I would like to argue, that the whole API could 
be made more flexible to begin with, as there would be many other.

 

> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior, 
> because there are too many private instead of protected methods, package 
> private and final classes in the API.
> Some examples I have stumbled on include
>  * private doSetNodes method in PropertySheet (no way to override the use of 
> ProxyNodes)
>  * final and package private ProxyNode class
>  * package private constructor in ProxyNode
>  * package private getOriginalNodes method in ProxyNode
>  * package private and final {color:#00}ProxyProperty{color} class in 
> ProxyNode
>  * final Sheet class and its inner class Sheet.Set
>  * most private methods in Sheet and Sheet.Set should be protected instead
>  * PropertySupport.Reflection class should have getters for read and write 
> methods
> I wonder, what is the rationale for so strict and static API design? I would 
> assume the performance gains from these limitations are meager. Opening these 
> classes for sub-classing and modifications would result in much more flexible 
> system with much less code duplication.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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



[jira] [Updated] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet

2020-04-23 Thread Markus Sunela (Jira)


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

Markus Sunela updated NETBEANS-4222:

External issue URL: https://github.com/apache/netbeans/pull/2099

Added a pull request on Github for this.

> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior, 
> because there are too many private instead of protected methods, package 
> private and final classes in the API.
> Some examples I have stumbled on include
>  * private doSetNodes method in PropertySheet (no way to override the use of 
> ProxyNodes)
>  * final and package private ProxyNode class
>  * package private constructor in ProxyNode
>  * package private getOriginalNodes method in ProxyNode
>  * package private and final {color:#00}ProxyProperty{color} class in 
> ProxyNode
>  * final Sheet class and its inner class Sheet.Set
>  * most private methods in Sheet and Sheet.Set should be protected instead
>  * PropertySupport.Reflection class should have getters for read and write 
> methods
> I wonder, what is the rationale for so strict and static API design? I would 
> assume the performance gains from these limitations are meager. Opening these 
> classes for sub-classing and modifications would result in much more flexible 
> system with much less code duplication.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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



[jira] [Comment Edited] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet

2020-04-23 Thread Markus Sunela (Jira)


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

Markus Sunela edited comment on NETBEANS-4222 at 4/23/20, 7:59 AM:
---

Added a pull request on Github for this: 
https://github.com/apache/netbeans/pull/2099.


was (Author: markus.sun...@fluidit.fi):
Added a pull request on Github for this.

> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior, 
> because there are too many private instead of protected methods, package 
> private and final classes in the API.
> Some examples I have stumbled on include
>  * private doSetNodes method in PropertySheet (no way to override the use of 
> ProxyNodes)
>  * final and package private ProxyNode class
>  * package private constructor in ProxyNode
>  * package private getOriginalNodes method in ProxyNode
>  * package private and final {color:#00}ProxyProperty{color} class in 
> ProxyNode
>  * final Sheet class and its inner class Sheet.Set
>  * most private methods in Sheet and Sheet.Set should be protected instead
>  * PropertySupport.Reflection class should have getters for read and write 
> methods
> I wonder, what is the rationale for so strict and static API design? I would 
> assume the performance gains from these limitations are meager. Opening these 
> classes for sub-classing and modifications would result in much more flexible 
> system with much less code duplication.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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



[jira] [Commented] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet

2020-04-23 Thread Markus Sunela (Jira)


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

Markus Sunela commented on NETBEANS-4222:
-

Thanks for the really quick reply. Of course I could, but when the nice and 
working infrastructure is already there, it would feel such a shame to 
duplicate its code and functionality just change certain small bits.

> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior, 
> because there are too many private instead of protected methods, package 
> private and final classes in the API.
> Some examples I have stumbled on include
>  * private doSetNodes method in PropertySheet (no way to override the use of 
> ProxyNodes)
>  * final and package private ProxyNode class
>  * package private constructor in ProxyNode
>  * package private getOriginalNodes method in ProxyNode
>  * package private and final {color:#00}ProxyProperty{color} class in 
> ProxyNode
>  * final Sheet class and its inner class Sheet.Set
>  * most private methods in Sheet and Sheet.Set should be protected instead
>  * PropertySupport.Reflection class should have getters for read and write 
> methods
> I wonder, what is the rationale for so strict and static API design? I would 
> assume the performance gains from these limitations are meager. Opening these 
> classes for sub-classing and modifications would result in much more flexible 
> system with much less code duplication.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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



[jira] [Created] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet

2020-04-23 Thread Markus Sunela (Jira)
Markus Sunela created NETBEANS-4222:
---

 Summary: Open up more of APIs in Node and PropertySheet
 Key: NETBEANS-4222
 URL: https://issues.apache.org/jira/browse/NETBEANS-4222
 Project: NetBeans
  Issue Type: Improvement
  Components: platform - Explorer, platform - Nodes
Reporter: Markus Sunela


Currently it is hard to customize Node, Explorer and PropertySheet behavior, 
because there are too many private instead of protected methods, package 
private and final classes in the API.

Some examples I have stumbled on include
 * private doSetNodes method in PropertySheet (no way to override the use of 
ProxyNodes)
 * final and package private ProxyNode class
 * package private constructor in ProxyNode
 * package private getOriginalNodes method in ProxyNode
 * package private and final {color:#00}ProxyProperty{color} class in 
ProxyNode
 * final Sheet class and its inner class Sheet.Set
 * most private methods in Sheet and Sheet.Set should be protected instead
 * PropertySupport.Reflection class should have getters for read and write 
methods

I wonder, what is the rationale for so strict and static API design? I would 
assume the performance gains from these limitations are meager. Opening these 
classes for sub-classing and modifications would result in much more flexible 
system with much less code duplication.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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



[jira] [Created] (NETBEANS-2982) UndoRedo class causes ArrayIndexOutOfBoundsException

2019-08-13 Thread Markus Sunela (JIRA)
Markus Sunela created NETBEANS-2982:
---

 Summary: UndoRedo class causes ArrayIndexOutOfBoundsException
 Key: NETBEANS-2982
 URL: https://issues.apache.org/jira/browse/NETBEANS-2982
 Project: NetBeans
  Issue Type: Bug
  Components: platform - Window System
Affects Versions: 11.1, 11.0, 10.0
Reporter: Markus Sunela


After a lot of UndoableEdits have been added to an UndoManager in a platform 
application, the UI sometimes starts to show the exception as it tries to 
update the name of the next undoable edit for the menus:

 
{code:java}
java.lang.ArrayIndexOutOfBoundsException: 100 >= 100
at java.base/java.util.Vector.elementAt(Vector.java:496)
at org.openide.awt.UndoRedo$Manager.editToBeUndone(UndoRedo.java:403)
at org.openide.awt.UndoRedo$Manager.canUndo(UndoRedo.java:224)
at 
org.openide.awt.UndoRedo$Manager.getUndoPresentationName(UndoRedo.java:501)
at org.openide.actions.UndoRedoAction.getName(UndoRedoAction.java:171)
at org.openide.actions.UndoRedoAction.run(UndoRedoAction.java:139)
at 
java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at 
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
at 
org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:136)
{code}
 

 

This seems to be due to incorrect handling of indexOfNextAdd in the 
UndoRedo.java 
([https://github.com/apache/netbeans/blob/master/platform/openide.awt/src/org/openide/awt/UndoRedo.java)].
 The indexOfNextAdd can be larger (more than by one) than the length of the 
edits Vector, and especially in editToBeUndone the edits Vector is directly 
accessed at indexOfNextAdd without any bounds checking:

 
{code:java}
@Override
protected UndoableEdtit editToBeUndone() {
int i = indexOfNextAdd;
while (i > 0) {
UndoableEdit edit = edits.elementAt(--i);
if (edit.isSignificant()) {
return edit;
}
}

return null;
}
{code}
For example editToBeRedone returns null in the case indexOfNextAdd >= 
edit.size().

 

I assume the root cause to be the trimEdits method incorrectly updating the 
indexOfNextAdd, possibly due to a negative value being passed from trimToLimits:
{code:java}
if (keepFrom < 0) {
keepTo -= keepFrom;
keepFrom = 0;
}
if (keepTo >= size) {
int delta = size - keepTo - 1;
keepTo += delta;
keepFrom += delta;
}
{code}
At least, the latter if doesn't ensure non-negative values for either keepTo or 
keepFrom, which could cause the bug.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
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] [Reopened] (NETBEANS-1638) OSGi support is broken

2019-04-10 Thread Markus Sunela (JIRA)


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

Markus Sunela reopened NETBEANS-1638:
-

With NetBeans 11.0 following exception is thrown due to the missing package 
exports in the OSGi module:

 

{{java.lang.NoClassDefFoundError: 
org/apache/felix/resolver/reason/ReasonException}}
{{    at 
org.apache.felix.resolver.ResolverImpl.permuteUsedBlames(ResolverImpl.java:1548)}}
{{    at 
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1440)}}
{{    at 
org.apache.felix.resolver.ResolverImpl.checkConsistency(ResolverImpl.java:622)}}
{{    at 
org.apache.felix.resolver.ResolverImpl.findValidCandidates(ResolverImpl.java:575)}}
{{    at 
org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:438)}}
{{    at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:421)}}
{{    at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:375)}}
{{    at 
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:478)}}
{{    at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4363)}}
{{    at org.apache.felix.framework.Felix.findBundleEntries(Felix.java:1972)}}
{{    at 
org.apache.felix.framework.BundleImpl.findEntries(BundleImpl.java:333)}}
{{    at org.netbeans.core.netigso.Netigso.createLoader(Netigso.java:278)}}
{{    at org.netbeans.NetigsoModule.start(NetigsoModule.java:95)}}
{{    at org.netbeans.NetigsoHandle.delayedInit(NetigsoHandle.java:147)}}
{{    at org.netbeans.NetigsoHandle.turnOn(NetigsoHandle.java:120)}}
{{    at org.netbeans.ModuleManager.enable(ModuleManager.java:1437)}}
{{    at org.netbeans.ModuleManager.enable(ModuleManager.java:1254)}}
{{    at org.netbeans.core.startup.ModuleList.installNew(ModuleList.java:315)}}
{{    at org.netbeans.core.startup.ModuleList.trigger(ModuleList.java:251)}}
{{    at org.netbeans.core.startup.ModuleSystem.restore(ModuleSystem.java:298)}}
{{    at org.netbeans.core.startup.Main.getModuleSystem(Main.java:156)}}
{{    at org.netbeans.core.startup.Main.getModuleSystem(Main.java:125)}}
{{    at org.netbeans.core.startup.Main.start(Main.java:282)}}
{{    at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:98)}}
{{    at java.base/java.lang.Thread.run(Thread.java:834)}}
{{Caused by: java.lang.ClassNotFoundException: 
org.apache.felix.resolver.reason.ReasonException starting from 
ModuleCL@37b7073f[org.netbeans.libs.felix] with possible defining loaders null 
and declared parents [ModuleCL@12d0e6ed[org.netbeans.libs.osgi]]}}
{{    at org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:199)}}
{{    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)}}
{{    ... 25 more}}
{{Caused by: java.lang.ClassNotFoundException: 
org.apache.felix.resolver.reason.ReasonException}}
{{    at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)}}
{{    at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)}}
{{    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)}}
{{    at org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:197)}}
{{    ... 26 more}}

> OSGi support is broken
> --
>
> Key: NETBEANS-1638
> URL: https://issues.apache.org/jira/browse/NETBEANS-1638
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Module System
>Affects Versions: 9.0, 10.0
>Reporter: Peter Nabbefeld
>Assignee: Jaroslav Tulach
>Priority: Critical
> Fix For: 11.0
>
> Attachments: 
> Updated_felix_to_5_6_10_to_enable_osgi_bundles_for_java_9_and_later_.patch
>
>
> The included Felix jar (in module lib.felix) is outdated and does not work 
> with JDK > 9.
> Included version: 4.2.1
> Current version: 6.0.1
> For a short discussion of the problem see: 
> https://github.com/mojohaus/nbm-maven-plugin/issues/52



--
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-1638) OSGi support is broken

2019-03-27 Thread Markus Sunela (JIRA)


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

Markus Sunela commented on NETBEANS-1638:
-

If there are any OSGi exceptions during resolving or activating the bundles, 
the process will fail without {{org.apache.felix.resolver.reason}} being 
exported by the OSGi framework module. With it being exported, the exceptions 
are reported properly.

> OSGi support is broken
> --
>
> Key: NETBEANS-1638
> URL: https://issues.apache.org/jira/browse/NETBEANS-1638
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Module System
>Affects Versions: 9.0, 10.0
>Reporter: Peter Nabbefeld
>Assignee: Jaroslav Tulach
>Priority: Critical
> Fix For: 11.0
>
> Attachments: 
> Updated_felix_to_5_6_10_to_enable_osgi_bundles_for_java_9_and_later_.patch
>
>
> The included Felix jar (in module lib.felix) is outdated and does not work 
> with JDK > 9.
> Included version: 4.2.1
> Current version: 6.0.1
> For a short discussion of the problem see: 
> https://github.com/mojohaus/nbm-maven-plugin/issues/52



--
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-1638) OSGi support is broken

2019-01-07 Thread Markus Sunela (JIRA)


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

Markus Sunela commented on NETBEANS-1638:
-

Splendid!

> OSGi support is broken
> --
>
> Key: NETBEANS-1638
> URL: https://issues.apache.org/jira/browse/NETBEANS-1638
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Module System
>Affects Versions: 9.0, 10.0
>Reporter: Peter Nabbefeld
>Assignee: Jaroslav Tulach
>Priority: Critical
> Fix For: 11.0
>
> Attachments: 
> Updated_felix_to_5_6_10_to_enable_osgi_bundles_for_java_9_and_later_.patch
>
>
> The included Felix jar (in module lib.felix) is outdated and does not work 
> with JDK > 9.
> Included version: 4.2.1
> Current version: 6.0.1
> For a short discussion of the problem see: 
> https://github.com/mojohaus/nbm-maven-plugin/issues/52



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

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

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



[jira] [Comment Edited] (NETBEANS-1638) OSGi support is broken

2019-01-07 Thread Markus Sunela (JIRA)


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

Markus Sunela edited comment on NETBEANS-1638 at 1/7/19 8:21 PM:
-

I successfully applied the patch (well monkey-patched similar changes as in the 
attached patch to the pre-build platform cluster). I am now able to run our 
complex NetBeans RCP (10.0) application, consisting of our pure-OSGi bundles 
with Java 10 and Java 11.

I actually replaced the modules/ext/org.apache.felix.main-4.2.1.jar with the 
newest 6.0.1 and updated the manifest in modules/org-netbeans-libs-felix.jar 
with the new packages as in the attached patch. A new package (w.r.t the 
patch), org.apache.felix.resolver.reason, had to be added to the manifest too.


was (Author: markus.sun...@fluidit.fi):
I successfully applied the patch (well monkey-patched the similar to the 
pre-build platform cluster). I am now able to run our complex NetBeans RCP 
(10.0) application, consisting of our pure-OSGi bundles with Java 10 and Java 
11.

I actually replaced the modules/ext/org.apache.felix.main-4.2.1.jar with the 
newest 6.0.1 and updated the manifest in modules/org-netbeans-libs-felix.jar 
with the new packages as in the attached patch. A new package (w.r.t the 
patch), org.apache.felix.resolver.reason, had to be added to the manifest too.

> OSGi support is broken
> --
>
> Key: NETBEANS-1638
> URL: https://issues.apache.org/jira/browse/NETBEANS-1638
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Module System
>Affects Versions: 9.0, 10.0
>Reporter: Peter Nabbefeld
>Priority: Critical
> Attachments: 
> Updated_felix_to_5_6_10_to_enable_osgi_bundles_for_java_9_and_later_.patch
>
>
> The included Felix jar (in module lib.felix) is outdated and does not work 
> with JDK > 9.
> Included version: 4.2.1
> Current version: 6.0.1
> For a short discussion of the problem see: 
> https://github.com/mojohaus/nbm-maven-plugin/issues/52



--
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-1638) OSGi support is broken

2019-01-07 Thread Markus Sunela (JIRA)


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

Markus Sunela commented on NETBEANS-1638:
-

I successfully applied the patch (well monkey-patched the similar to the 
pre-build platform cluster). I am now able to run our complex NetBeans RCP 
(10.0) application, consisting of our pure-OSGi bundles with Java 10 and Java 
11.

I actually replaced the modules/ext/org.apache.felix.main-4.2.1.jar with the 
newest 6.0.1 and updated the manifest in modules/org-netbeans-libs-felix.jar 
with the new packages as in the attached patch. A new package (w.r.t the 
patch), org.apache.felix.resolver.reason, had to be added to the manifest too.

> OSGi support is broken
> --
>
> Key: NETBEANS-1638
> URL: https://issues.apache.org/jira/browse/NETBEANS-1638
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Module System
>Affects Versions: 9.0, 10.0
>Reporter: Peter Nabbefeld
>Priority: Critical
> Attachments: 
> Updated_felix_to_5_6_10_to_enable_osgi_bundles_for_java_9_and_later_.patch
>
>
> The included Felix jar (in module lib.felix) is outdated and does not work 
> with JDK > 9.
> Included version: 4.2.1
> Current version: 6.0.1
> For a short discussion of the problem see: 
> https://github.com/mojohaus/nbm-maven-plugin/issues/52



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