[jira] [Created] (NETBEANS-6008) Update FlatLAF to 1.6 as 1.4 has several regressions
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.
[
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 - Launchers&CLI
>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.
[
https://issues.apache.org/jira/browse/NETBEANS-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 - Launchers&CLI
>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.
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 - Launchers&CLI
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
[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 >Reporte
[jira] [Comment Edited] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet
[ https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 h
[jira] [Commented] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet
[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
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
[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
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
[
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
[
https://issues.apache.org/jira/browse/NETBEANS-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/NETBEANS-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/NETBEANS-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/NETBEANS-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
