[jira] [Commented] (NETBEANS-3744) NetBeans should load multi-project gradle projects in one shot
[ https://issues.apache.org/jira/browse/NETBEANS-3744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023347#comment-17023347 ] Shevek commented on NETBEANS-3744: -- Not that much changes, but I think NB is watching some files which cause a total reload, e.g. adding/removing a module by editing settings.gradle is basically fatal. > NetBeans should load multi-project gradle projects in one shot > -- > > Key: NETBEANS-3744 > URL: https://issues.apache.org/jira/browse/NETBEANS-3744 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.1, 11.2 > Environment: Gradle 5.6 definitely exhibits this. Haven't tried 6.x > yet. > I think Gradle 4.10.3 did not have the issue, but we didn't have 100 > subprojects and/or use a shared build cache back then either. >Reporter: Shevek >Priority: Major > > It appears that NB does a gradle "build" (model, whatever) per subproject in > a multi module project. Given a project with say 100 subprojects, two things > happen: > 1. It takes FOREVER, because 100 invocations of gradle takes FOREVER. > 2. It never completes, because after 30 or 40 projects, Gradle runs out of > RAM, and the Gradle JVM goes into GC Ergonomics while holding various > system-wide Gradle locks, and now the entire system is hung and NO Gradle > invocation on that system can proceed. > Please can NetBeans load this project-set in one bite, with a single > invocation, from which it can get all the model data (like it used to with > the old Gradle plugin)? > This is the major reason why NetBeans takes such a long time to load, and > frequently, when it detects file changes, I can only get NB to be usable > again by restarting it. > I already gave Gradle 10Gb of RAM; the project is definitely buildable and > testable in 2Gb, the rest is caches/leaks/whatever, that's Gradle's proble > but it's vastly exacerbated by the NB Gradle model-loading strategy. > Related: NETBEANS-3041 which at least gives me the 10Gb. Before that, I think > NB just used to crash. -- 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] [Assigned] (NETBEANS-3715) Project properties cannot be selected if the taskbar is at the bottom of the screen
[ https://issues.apache.org/jira/browse/NETBEANS-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke reassigned NETBEANS-3715: - Assignee: (was: Eirik Bakke) > Project properties cannot be selected if the taskbar is at the bottom of the > screen > --- > > Key: NETBEANS-3715 > URL: https://issues.apache.org/jira/browse/NETBEANS-3715 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.2 > Environment: RELEASE=19.3 > CODENAME=tricia > EDITION="Cinnamon" > DESCRIPTION="Linux Mint 19.3 Tricia" > DESKTOP=Gnome > TOOLKIT=GTK > NEW_FEATURES_URL=https://www.linuxmint.com/rel_tricia_cinnamon_whatsnew.php > RELEASE_NOTES_URL=https://www.linuxmint.com/rel_tricia_cinnamon.php > USER_GUIDE_URL=https://www.linuxmint.com/documentation.php > GRUB_TITLE=Linux Mint 19.3 Cinnamon >Reporter: Gergely Turi >Priority: Minor > Labels: features > Attachments: Menu_001.jpg, Menu_002.jpg > > > When right-clicking on the project the menu appears but Properties can > neither be selected nor clicked. > The cause of the issue is that the taskbar seems to be somehow "in the way". > If you try to click on Properties it will activate whatever application is > behind it. > But this doesn't occur if the taskbar is moved to either sides (or up). -- 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-3715) Project properties cannot be selected if the taskbar is at the bottom of the screen
[ https://issues.apache.org/jira/browse/NETBEANS-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023266#comment-17023266 ] Eirik Bakke commented on NETBEANS-3715: --- Does not happen on Windows or MacOS--it's probably a Linux-specific issue. I don't have a Linux box to try on, unfortunately. Could also be a JDK bug, but determining that would require further experimentation, on Linux. > Project properties cannot be selected if the taskbar is at the bottom of the > screen > --- > > Key: NETBEANS-3715 > URL: https://issues.apache.org/jira/browse/NETBEANS-3715 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.2 > Environment: RELEASE=19.3 > CODENAME=tricia > EDITION="Cinnamon" > DESCRIPTION="Linux Mint 19.3 Tricia" > DESKTOP=Gnome > TOOLKIT=GTK > NEW_FEATURES_URL=https://www.linuxmint.com/rel_tricia_cinnamon_whatsnew.php > RELEASE_NOTES_URL=https://www.linuxmint.com/rel_tricia_cinnamon.php > USER_GUIDE_URL=https://www.linuxmint.com/documentation.php > GRUB_TITLE=Linux Mint 19.3 Cinnamon >Reporter: Gergely Turi >Assignee: Eirik Bakke >Priority: Minor > Labels: features > Attachments: Menu_001.jpg, Menu_002.jpg > > > When right-clicking on the project the menu appears but Properties can > neither be selected nor clicked. > The cause of the issue is that the taskbar seems to be somehow "in the way". > If you try to click on Properties it will activate whatever application is > behind it. > But this doesn't occur if the taskbar is moved to either sides (or up). -- 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-3715) Project properties cannot be selected if the taskbar is at the bottom of the screen
[ https://issues.apache.org/jira/browse/NETBEANS-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023237#comment-17023237 ] Laszlo Kishalmi commented on NETBEANS-3715: --- Hmm. Seems to be either an issue in the Used windowing system or JDK. All we could do is not placing a popupmenu over that area. Assigned this one to Eirik he is more familiar with the UI stuff than me. > Project properties cannot be selected if the taskbar is at the bottom of the > screen > --- > > Key: NETBEANS-3715 > URL: https://issues.apache.org/jira/browse/NETBEANS-3715 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.2 > Environment: RELEASE=19.3 > CODENAME=tricia > EDITION="Cinnamon" > DESCRIPTION="Linux Mint 19.3 Tricia" > DESKTOP=Gnome > TOOLKIT=GTK > NEW_FEATURES_URL=https://www.linuxmint.com/rel_tricia_cinnamon_whatsnew.php > RELEASE_NOTES_URL=https://www.linuxmint.com/rel_tricia_cinnamon.php > USER_GUIDE_URL=https://www.linuxmint.com/documentation.php > GRUB_TITLE=Linux Mint 19.3 Cinnamon >Reporter: Gergely Turi >Assignee: Eirik Bakke >Priority: Minor > Labels: features > Attachments: Menu_001.jpg, Menu_002.jpg > > > When right-clicking on the project the menu appears but Properties can > neither be selected nor clicked. > The cause of the issue is that the taskbar seems to be somehow "in the way". > If you try to click on Properties it will activate whatever application is > behind it. > But this doesn't occur if the taskbar is moved to either sides (or up). -- 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-3715) Project properties cannot be selected if the taskbar is at the bottom of the screen
[ https://issues.apache.org/jira/browse/NETBEANS-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023238#comment-17023238 ] Laszlo Kishalmi commented on NETBEANS-3715: --- [https://stackoverflow.com/questions/50763440/prevent-jpopupmenu-from-being-covered-by-task-bar] > Project properties cannot be selected if the taskbar is at the bottom of the > screen > --- > > Key: NETBEANS-3715 > URL: https://issues.apache.org/jira/browse/NETBEANS-3715 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.2 > Environment: RELEASE=19.3 > CODENAME=tricia > EDITION="Cinnamon" > DESCRIPTION="Linux Mint 19.3 Tricia" > DESKTOP=Gnome > TOOLKIT=GTK > NEW_FEATURES_URL=https://www.linuxmint.com/rel_tricia_cinnamon_whatsnew.php > RELEASE_NOTES_URL=https://www.linuxmint.com/rel_tricia_cinnamon.php > USER_GUIDE_URL=https://www.linuxmint.com/documentation.php > GRUB_TITLE=Linux Mint 19.3 Cinnamon >Reporter: Gergely Turi >Assignee: Eirik Bakke >Priority: Minor > Labels: features > Attachments: Menu_001.jpg, Menu_002.jpg > > > When right-clicking on the project the menu appears but Properties can > neither be selected nor clicked. > The cause of the issue is that the taskbar seems to be somehow "in the way". > If you try to click on Properties it will activate whatever application is > behind it. > But this doesn't occur if the taskbar is moved to either sides (or up). -- 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] [Assigned] (NETBEANS-3715) Project properties cannot be selected if the taskbar is at the bottom of the screen
[ https://issues.apache.org/jira/browse/NETBEANS-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laszlo Kishalmi reassigned NETBEANS-3715: - Assignee: Eirik Bakke > Project properties cannot be selected if the taskbar is at the bottom of the > screen > --- > > Key: NETBEANS-3715 > URL: https://issues.apache.org/jira/browse/NETBEANS-3715 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.2 > Environment: RELEASE=19.3 > CODENAME=tricia > EDITION="Cinnamon" > DESCRIPTION="Linux Mint 19.3 Tricia" > DESKTOP=Gnome > TOOLKIT=GTK > NEW_FEATURES_URL=https://www.linuxmint.com/rel_tricia_cinnamon_whatsnew.php > RELEASE_NOTES_URL=https://www.linuxmint.com/rel_tricia_cinnamon.php > USER_GUIDE_URL=https://www.linuxmint.com/documentation.php > GRUB_TITLE=Linux Mint 19.3 Cinnamon >Reporter: Gergely Turi >Assignee: Eirik Bakke >Priority: Minor > Labels: features > Attachments: Menu_001.jpg, Menu_002.jpg > > > When right-clicking on the project the menu appears but Properties can > neither be selected nor clicked. > The cause of the issue is that the taskbar seems to be somehow "in the way". > If you try to click on Properties it will activate whatever application is > behind it. > But this doesn't occur if the taskbar is moved to either sides (or up). -- 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-3715) Project properties cannot be selected if the taskbar is at the bottom of the screen
[ https://issues.apache.org/jira/browse/NETBEANS-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gergely Turi updated NETBEANS-3715: --- Attachment: Menu_001.jpg Menu_002.jpg > Project properties cannot be selected if the taskbar is at the bottom of the > screen > --- > > Key: NETBEANS-3715 > URL: https://issues.apache.org/jira/browse/NETBEANS-3715 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.2 > Environment: RELEASE=19.3 > CODENAME=tricia > EDITION="Cinnamon" > DESCRIPTION="Linux Mint 19.3 Tricia" > DESKTOP=Gnome > TOOLKIT=GTK > NEW_FEATURES_URL=https://www.linuxmint.com/rel_tricia_cinnamon_whatsnew.php > RELEASE_NOTES_URL=https://www.linuxmint.com/rel_tricia_cinnamon.php > USER_GUIDE_URL=https://www.linuxmint.com/documentation.php > GRUB_TITLE=Linux Mint 19.3 Cinnamon >Reporter: Gergely Turi >Priority: Minor > Labels: features > Attachments: Menu_001.jpg, Menu_002.jpg > > > When right-clicking on the project the menu appears but Properties can > neither be selected nor clicked. > The cause of the issue is that the taskbar seems to be somehow "in the way". > If you try to click on Properties it will activate whatever application is > behind it. > But this doesn't occur if the taskbar is moved to either sides (or up). -- 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-3747) Package rename causes bogus error
Bernard created NETBEANS-3747:
-
Summary: Package rename causes bogus error
Key: NETBEANS-3747
URL: https://issues.apache.org/jira/browse/NETBEANS-3747
Project: NetBeans
Issue Type: Bug
Components: java - Refactoring
Affects Versions: 11.2
Reporter: Bernard
How to reproduce:
All defaults, hello world application as simple as possible.
Menu|File|New Project|Java with Maven|Java Application|Finish
Projects|New|java Class|NewClass|Finish
[Alt+Insert]|Generate|Constructor
Remove public from public NewClass()
Add a method:
void hello() {
System.out.println("Hello");
}
Save.
[Ctrl+Shift+U] Create / Update Tests|JUnit|OK
In the source packages tree, rename mavenproject1 to mavenproject2.
Click button "refactor"
The following warnings and errors were found. You can continue only with
warnings.
List or errors:
Warning:
Class "NewClassTest" within the same package is using feature "hello()" of
class you want to move ("NewClass").
Click "Refactor"
That actually creates an import in the test class:
import my.mavenproject2.NewClass;
But the test class has 2 errors as can be expected:
NewClass() is not public in NewClass; cannot be accessed from outside package
hello() is not public in NewClass; cannot be accessed from outside package
Rename the test package mavenproject1 to mavenproject2 to fix the error.
NewClassTest does not have any more errors.
The new import statement in the test class is now "Import From The Same
Package".
But the test package has a red badge "Contains files with errors."
--
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-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023082#comment-17023082
]
Lars Bruun-Hansen commented on NETBEANS-58:
---
My 2c:
The real fix, rather than the workarounds I've created in the past, is indeed
NETBEANS-106. The main problem is that NetBeans' classloader is simply too lock
happy. (it uses a global lock rather than a targeted one, something which - in
my opinion - will ultimately lead to deadlocks, not just in this case but in
other cases too).
I don't think NETBEANS-106 is being worked on, AFAIK.
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator
> does something wrong? No, of course it doesn't. The real problem is the lock
> on the classloader. It is
[jira] [Updated] (NETBEANS-3746) [FlatLaF] Change theme for FlatLaF
[ https://issues.apache.org/jira/browse/NETBEANS-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Lenz updated NETBEANS-3746: - Environment: Product Version: Apache NetBeans IDE 11.1 Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2 Java: 11.0.2; Java HotSpot(TM) 64-Bit Server VM 11.0.2+9-LTS Runtime: Java(TM) SE Runtime Environment 11.0.2+9-LTS System: Windows 10 version 10.0 running on amd64; Cp1252; de_DE (nb) User directory: C:\Users\Chrl\AppData\Roaming\NetBeans\11.1 Cache directory: C:\Users\Chrl\AppData\Local\NetBeans\Cache\11.1 > [FlatLaF] Change theme for FlatLaF > -- > > Key: NETBEANS-3746 > URL: https://issues.apache.org/jira/browse/NETBEANS-3746 > Project: NetBeans > Issue Type: New Feature > Components: platform - OptionsSettings, platform - Window System > Environment: Product Version: Apache NetBeans IDE 11.1 > Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2 > Java: 11.0.2; Java HotSpot(TM) 64-Bit Server VM 11.0.2+9-LTS > Runtime: Java(TM) SE Runtime Environment 11.0.2+9-LTS > System: Windows 10 version 10.0 running on amd64; Cp1252; de_DE (nb) > User directory: C:\Users\Chrl\AppData\Roaming\NetBeans\11.1 > Cache directory: C:\Users\Chrl\AppData\Local\NetBeans\Cache\11.1 >Reporter: Christian Lenz >Assignee: Karl Tauber >Priority: Major > Labels: Look, theme > Attachments: flat-laf-changing-theme.gif > > > As far as I know, there ia theming option for FlatLaF inside the FlatLaF > demo. See my screencapture for more info. So it is possible via JSON to theme > the LaF easy and restartless. IntelliJ is doing that and it works like a > charm. > The problem of NetBeans changing LaF is you often need to restart, because > not all components are repainted correctly. But it seems that theming of > FlatLaF is independent from NetBeans. > So it would be nice, if we can switch the FlatLaF theme easy via NetBeans as > it is possible in the FlatLaF demo which is located here: > https://github.com/JFormDesigner/FlatLaf > I already asked here: https://github.com/JFormDesigner/FlatLaf/issues/29 -- 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-3746) [FlatLaF] Change theme for FlatLaF
[ https://issues.apache.org/jira/browse/NETBEANS-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Lenz updated NETBEANS-3746: - Issue Type: New Feature (was: Bug) > [FlatLaF] Change theme for FlatLaF > -- > > Key: NETBEANS-3746 > URL: https://issues.apache.org/jira/browse/NETBEANS-3746 > Project: NetBeans > Issue Type: New Feature > Components: platform - OptionsSettings, platform - Window System >Reporter: Christian Lenz >Assignee: Karl Tauber >Priority: Major > Labels: Look, theme > Attachments: flat-laf-changing-theme.gif > > > As far as I know, there ia theming option for FlatLaF inside the FlatLaF > demo. See my screencapture for more info. So it is possible via JSON to theme > the LaF easy and restartless. IntelliJ is doing that and it works like a > charm. > The problem of NetBeans changing LaF is you often need to restart, because > not all components are repainted correctly. But it seems that theming of > FlatLaF is independent from NetBeans. > So it would be nice, if we can switch the FlatLaF theme easy via NetBeans as > it is possible in the FlatLaF demo which is located here: > https://github.com/JFormDesigner/FlatLaf > I already asked here: https://github.com/JFormDesigner/FlatLaf/issues/29 -- 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-3746) [FlatLaF] Change theme for FlatLaF
Christian Lenz created NETBEANS-3746: Summary: [FlatLaF] Change theme for FlatLaF Key: NETBEANS-3746 URL: https://issues.apache.org/jira/browse/NETBEANS-3746 Project: NetBeans Issue Type: Bug Components: platform - OptionsSettings, platform - Window System Reporter: Christian Lenz Assignee: Karl Tauber Attachments: flat-laf-changing-theme.gif As far as I know, there ia theming option for FlatLaF inside the FlatLaF demo. See my screencapture for more info. So it is possible via JSON to theme the LaF easy and restartless. IntelliJ is doing that and it works like a charm. The problem of NetBeans changing LaF is you often need to restart, because not all components are repainted correctly. But it seems that theming of FlatLaF is independent from NetBeans. So it would be nice, if we can switch the FlatLaF theme easy via NetBeans as it is possible in the FlatLaF demo which is located here: https://github.com/JFormDesigner/FlatLaf I already asked here: https://github.com/JFormDesigner/FlatLaf/issues/29 -- 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-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022951#comment-17022951
]
guillaume canivet edited comment on NETBEANS-58 at 1/24/20 4:36 PM:
I Experience a similar issue, in my case the freeze is not during startup,
indeed, within my NB platform based application (RELEASE112), I have a module
able to perform REST call (trigger by user click), and I am behind a corporate
transparent proxy (with Kerberos token).
Note: using Windows 10, Java 8 and NetBeans Version: RELEASE112.
The freeze only occurred when the Kerberos token need to be refresh (or it
seems).
Also in our case:
*#1* and *#4* does not work, freeze still occurred.
Only *#3* is working (rebuild with RELEASE112).
The behavior of the *#3* is fine with us, but I really want to have an official
NetBeans fix.
Is there something we can do to have an official NetBeans fix?
was (Author: guillaumecanivet):
I Experience a similar issue, in my case the freeze is not during startup,
indeed, within my NB platform based application (RELEASE112), I have a module
able to perform REST call (trigger by user click), and I am behind a corporate
transparent proxy (with Kerberos token).
Note: using Windows 10, Java 8 and NetBeans Version: RELEASE112.
The freeze only occurred when the Kerberos token need to be refresh (or it
seems).
Also in our case:
*#1* and *#4* does not work, freeze still occurred.
Only *#3* is working (rebuild with RELEASE112).
The behavior of the *#3* is fine with us, but I really want to have an official
NetBeans fix.
Is there something we can do to have an official NetBeans fix?
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
>
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022951#comment-17022951
]
guillaume canivet edited comment on NETBEANS-58 at 1/24/20 4:35 PM:
I Experience a similar issue, in my case the freeze is not during startup,
indeed, within my NB platform based application (RELEASE112), I have a module
able to perform REST call (trigger by user click), and I am behind a corporate
transparent proxy (with Kerberos token).
Note: using Windows 10, Java 8 and NetBeans Version: RELEASE112.
The freeze only occurred when the Kerberos token need to be refresh (or it
seems).
Also in our case:
*#1* and *#4* does not work, freeze still occurred.
Only *#3* is working (rebuild with RELEASE112).
The behavior of the *#3* is fine with us, but I really want to have an official
NetBeans fix.
Is there something we can do to have an official NetBeans fix?
was (Author: guillaumecanivet):
I Experience a similar issue, in my case the freeze is not during startup,
indeed, within my NB platform based application (RELEASE112), I have a module
able to perform REST call (trigger by user click), and I am behind a corporate
transparent proxy (with Kerberos token).
Note: using Java 8 and NetBeans Version: RELEASE112.
The freeze only occurred when the token need to be refresh (or it seems).
Also in our case:
*#1* and *#4* does not work, freeze still occurred.
Only *#3* is working (rebuild with RELEASE112).
The behavior of the *#3* is fine with us, but I really want to have an official
NetBeans fix.
Is there something we can do to have an official NetBeans fix?
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
>
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022951#comment-17022951
]
guillaume canivet edited comment on NETBEANS-58 at 1/24/20 4:23 PM:
I Experience a similar issue, in my case the freeze is not during startup,
indeed, within my NB platform based application (RELEASE112), I have a module
able to perform REST call (trigger by user click), and I am behind a corporate
transparent proxy (with Kerberos token).
Note: using Java 8 and NetBeans Version: RELEASE112.
The freeze only occurred when the token need to be refresh (or it seems).
Also in our case:
*#1* and *#4* does not work, freeze still occurred.
Only *#3* is working (rebuild with RELEASE112).
The behavior of the *#3* is fine with us, but I really want to have an official
NetBeans fix.
Is there something we can do to have an official NetBeans fix?
was (Author: guillaumecanivet):
I Experience a similar issue, in my case the freeze is not during startup,
indeed I have a module within the studio (RCP) able to perform REST call
(trigger by user click), and I am behind a corporate transparent proxy (with
Kerberos token).
Note: using Java 8 and NetBeans Version: RELEASE112.
The freeze only occurred when the token need to be refresh (or it seems).
Also in our case:
*#1* and *#4* does not work, freeze still occurred.
Only *#3* is working (rebuild with RELEASE112).
The behavior of the *#3* is fine with us, but I really want to have an official
NetBeans fix.
Is there something we can do to have an official NetBeans fix?
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
>
[jira] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022951#comment-17022951
]
guillaume canivet commented on NETBEANS-58:
---
I Experience a similar issue, in my case the freeze is not during startup,
indeed I have a module within the studio (RCP) able to perform REST call
(trigger by user click), and I am behind a corporate transparent proxy (with
Kerberos token).
Note: using Java 8 and NetBeans Version: RELEASE112.
The freeze only occurred when the token need to be refresh (or it seems).
Also in our case:
*#1* and *#4* does not work, freeze still occurred.
Only *#3* is working (rebuild with RELEASE112).
The behavior of the *#3* is fine with us, but I really want to have an official
NetBeans fix.
Is there something we can do to have an official NetBeans fix?
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
>
[jira] [Updated] (NETBEANS-3745) Remove abandoned user and cache directories
[ https://issues.apache.org/jira/browse/NETBEANS-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated NETBEANS-3745: - Labels: pull-request-available (was: ) > Remove abandoned user and cache directories > --- > > Key: NETBEANS-3745 > URL: https://issues.apache.org/jira/browse/NETBEANS-3745 > Project: NetBeans > Issue Type: New Feature >Reporter: Laszlo Kishalmi >Assignee: Laszlo Kishalmi >Priority: Major > Labels: pull-request-available > > As netbeans releases are more frequent, several user and cache directories > can be accumulated. It would be good to have a notification to remove those > if they are not used any more. -- 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-3745) Remove abandoned user and cache directories
Laszlo Kishalmi created NETBEANS-3745: - Summary: Remove abandoned user and cache directories Key: NETBEANS-3745 URL: https://issues.apache.org/jira/browse/NETBEANS-3745 Project: NetBeans Issue Type: New Feature Reporter: Laszlo Kishalmi Assignee: Laszlo Kishalmi As netbeans releases are more frequent, several user and cache directories can be accumulated. It would be good to have a notification to remove those if they are not used any more. -- 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-3744) NetBeans should load multi-project gradle projects in one shot
[ https://issues.apache.org/jira/browse/NETBEANS-3744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022789#comment-17022789 ] Laszlo Kishalmi commented on NETBEANS-3744: --- Well, I really doubt that I can hack that in into the current architecture. I'm planning a major rework on the core as C++ support is coming into NetBeans soon. I wonder what codebase are you working on that it needs to ditch all the caches whenever you do a rebase... > NetBeans should load multi-project gradle projects in one shot > -- > > Key: NETBEANS-3744 > URL: https://issues.apache.org/jira/browse/NETBEANS-3744 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.1, 11.2 > Environment: Gradle 5.6 definitely exhibits this. Haven't tried 6.x > yet. > I think Gradle 4.10.3 did not have the issue, but we didn't have 100 > subprojects and/or use a shared build cache back then either. >Reporter: Shevek >Priority: Major > > It appears that NB does a gradle "build" (model, whatever) per subproject in > a multi module project. Given a project with say 100 subprojects, two things > happen: > 1. It takes FOREVER, because 100 invocations of gradle takes FOREVER. > 2. It never completes, because after 30 or 40 projects, Gradle runs out of > RAM, and the Gradle JVM goes into GC Ergonomics while holding various > system-wide Gradle locks, and now the entire system is hung and NO Gradle > invocation on that system can proceed. > Please can NetBeans load this project-set in one bite, with a single > invocation, from which it can get all the model data (like it used to with > the old Gradle plugin)? > This is the major reason why NetBeans takes such a long time to load, and > frequently, when it detects file changes, I can only get NB to be usable > again by restarting it. > I already gave Gradle 10Gb of RAM; the project is definitely buildable and > testable in 2Gb, the rest is caches/leaks/whatever, that's Gradle's proble > but it's vastly exacerbated by the NB Gradle model-loading strategy. > Related: NETBEANS-3041 which at least gives me the 10Gb. Before that, I think > NB just used to crash. -- 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
