[jira] [Created] (NETBEANS-2650) NPE while renaming a local symbol
Shevek created NETBEANS-2650: Summary: NPE while renaming a local symbol Key: NETBEANS-2650 URL: https://issues.apache.org/jira/browse/NETBEANS-2650 Project: NetBeans Issue Type: Bug Components: editor - Refactoring, java - Refactoring Reporter: Shevek Renaming the local variable in a for(String x in list) loop: java.lang.NullPointerException at org.netbeans.modules.j2ee.jpa.refactoring.rename.RelationshipMappingRename$1.run(RelationshipMappingRename.java:126) at org.netbeans.modules.j2ee.jpa.refactoring.rename.RelationshipMappingRename$1.run(RelationshipMappingRename.java:117) at org.netbeans.api.java.source.JavaSource$MultiTask.run(JavaSource.java:501) at org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586) at org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:130) at org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:114) at org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181) at org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178) at org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153) at org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335) at org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118) at org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67) at org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178) at org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:81) at org.netbeans.api.java.source.JavaSource.runUserActionTaskImpl(JavaSource.java:451) at org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:422) at org.netbeans.modules.j2ee.jpa.refactoring.rename.RelationshipMappingRename.prepare(RelationshipMappingRename.java:117) [catch] at org.netbeans.modules.refactoring.api.AbstractRefactoring.pluginsPrepare2(AbstractRefactoring.java:417) at org.netbeans.modules.refactoring.api.AbstractRefactoring.pluginsPrepare(AbstractRefactoring.java:401) at org.netbeans.modules.refactoring.api.AbstractRefactoring.prepare(AbstractRefactoring.java:212) at org.netbeans.modules.refactoring.spi.impl.ParametersPanel$Prepare.run(ParametersPanel.java:1063) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418) at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45) at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033) -- 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
[netbeans] 10/10: Add more tests for ImageUtilities, and fix some broken ones.
This is an automated email from the ASF dual-hosted git repository.
ebakke pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/netbeans.git
commit 5f7820042fcc229a9ad8bd9c84398bc96cdbfe10
Author: Eirik Bakke
AuthorDate: Thu Jun 6 16:18:49 2019 -0400
Add more tests for ImageUtilities, and fix some broken ones.
---
.../src/org/openide/util/ImageUtilities.java | 28 ++-
.../src/org/openide/util/ImageUtilitiesTest.java | 234 +++--
2 files changed, 243 insertions(+), 19 deletions(-)
diff --git a/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
b/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
index b133ad9..5171bd9 100644
--- a/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
+++ b/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
@@ -20,6 +20,7 @@
package org.openide.util;
import java.awt.Component;
+import java.awt.EventQueue;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.GraphicsConfiguration;
@@ -54,6 +55,7 @@ import javax.imageio.stream.ImageInputStream;
import javax.swing.Icon;
import javax.swing.ImageIcon;
import javax.swing.JLabel;
+import javax.swing.SwingUtilities;
import javax.swing.UIManager;
/**
@@ -113,12 +115,18 @@ public final class ImageUtilities {
private static volatile Component dummyIconComponent;
static {
-Mutex.EVENT.writeAccess(new Runnable() {
-@Override
-public void run() {
-dummyIconComponent = new JLabel();
-}
-});
+/* Could have used Mutex.EVENT.writeAccess here, but it doesn't seem
to be available during
+testing. */
+if (EventQueue.isDispatchThread()) {
+dummyIconComponent = new JLabel();
+} else {
+SwingUtilities.invokeLater(new Runnable() {
+@Override
+public void run() {
+dummyIconComponent = new JLabel();
+}
+});
+}
}
private ImageUtilities() {
@@ -973,7 +981,9 @@ public final class ImageUtilities {
}
public ToolTipImage(Icon delegateIcon, String toolTipText, int
imageType) {
-super(delegateIcon.getIconWidth(), delegateIcon.getIconHeight(),
imageType);
+// BufferedImage must have width/height > 0.
+super(Math.max(1, delegateIcon.getIconWidth()),
+Math.max(1, delegateIcon.getIconHeight()), imageType);
this.delegateIcon = delegateIcon;
this.toolTipText = toolTipText;
this.url = null;
@@ -1044,6 +1054,10 @@ public final class ImageUtilities {
@Override
public Object getProperty(String name, ImageObserver observer) {
if ("url".equals(name)) { // NOI18N
+/* In some cases it might strictly be more appropriate to
return
+Image.UndefinedProperty rather than null (see Javadoc spec for
this method), but
+retain the existing behavior and use null instead here. That
way there won't be a
+ClassCastException if someone tries to cast to URL. */
if (url != null) {
return url;
} else if (!(delegateIcon instanceof ImageIcon)) {
diff --git
a/platform/openide.util.ui/test/unit/src/org/openide/util/ImageUtilitiesTest.java
b/platform/openide.util.ui/test/unit/src/org/openide/util/ImageUtilitiesTest.java
index 087a49d..de8f537 100644
---
a/platform/openide.util.ui/test/unit/src/org/openide/util/ImageUtilitiesTest.java
+++
b/platform/openide.util.ui/test/unit/src/org/openide/util/ImageUtilitiesTest.java
@@ -19,13 +19,22 @@
package org.openide.util;
import java.awt.Color;
+import java.awt.Component;
+import java.awt.Graphics;
+import java.awt.Graphics2D;
import java.awt.Image;
+import java.awt.geom.AffineTransform;
import java.awt.image.BufferedImage;
+import java.lang.reflect.InvocationTargetException;
import java.net.URL;
+import java.util.function.Function;
import javax.swing.Icon;
import javax.swing.ImageIcon;
+import javax.swing.SwingUtilities;
import javax.swing.UIManager;
import junit.framework.*;
+import static org.openide.util.ImageUtilities.icon2Image;
+import static org.openide.util.ImageUtilities.image2Icon;
/**
*
@@ -234,23 +243,224 @@ public class ImageUtilitiesTest extends TestCase {
}
public void testConversions() {
-Image image =
ImageUtilities.loadImage("org/openide/util/testimage.png", false);
-Icon icon =
ImageUtilities.loadImageIcon("org/openide/util/testimage.png", false);
+/* Note: these are rather implementation-oriented tests.
Implementation changes in
+ImageUtilities (addition or removal of caches etc.) might require this
test to be
+updated, even when the API is unchanged. */
-assertNotNull("Should not be null",
[netbeans] 08/10: Fix a few comment typos.
This is an automated email from the ASF dual-hosted git repository.
ebakke pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/netbeans.git
commit 73a3f68275cfb4483be9bc2b0ca6ffda6922855d
Author: Eirik Bakke
AuthorDate: Fri May 31 10:19:36 2019 -0400
Fix a few comment typos.
---
platform/openide.util.ui/src/org/openide/util/CachedHiDPIIcon.java | 4 ++--
platform/openide.util.ui/src/org/openide/util/FilteredIcon.java| 2 +-
platform/openide.util.ui/src/org/openide/util/VectorIcon.java | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/platform/openide.util.ui/src/org/openide/util/CachedHiDPIIcon.java
b/platform/openide.util.ui/src/org/openide/util/CachedHiDPIIcon.java
index ecce663..107469c 100644
--- a/platform/openide.util.ui/src/org/openide/util/CachedHiDPIIcon.java
+++ b/platform/openide.util.ui/src/org/openide/util/CachedHiDPIIcon.java
@@ -34,7 +34,7 @@ import javax.swing.ImageIcon;
/**
* Abstract base class for {@link javax.swing.Icon} implementations that need
to cache scaled bitmap
* representations for HiDPI displays. Bitmaps for multiple HiDPI scaling
factors can be cached at
- * the same time, e.g. for multi-monitor setups.
+ * the same time, e.g. for multi-monitor setups. Thread-safe.
*/
abstract class CachedHiDPIIcon extends ImageIcon {
/**
@@ -143,7 +143,7 @@ abstract class CachedHiDPIIcon extends ImageIcon {
*Future implementations might also elect to simply pass a dummy
Component instance
*here.
* @param graphicsConfiguration the configuration of the surface on which
the image will be
- * painted
+ *painted
* @param deviceWidth the required width of the image, with scaling
already applied
* @param deviceHeight the required height of the image, with scaling
already applied
* @param scale the HiDPI scaling factor detected in {@code
graphicsConfiguration}
diff --git a/platform/openide.util.ui/src/org/openide/util/FilteredIcon.java
b/platform/openide.util.ui/src/org/openide/util/FilteredIcon.java
index 94499eb..0496c3b 100644
--- a/platform/openide.util.ui/src/org/openide/util/FilteredIcon.java
+++ b/platform/openide.util.ui/src/org/openide/util/FilteredIcon.java
@@ -38,7 +38,7 @@ import javax.swing.ImageIcon;
* of {@link VectorIcon}, or {@link ImageIcon} instances delegating to a
* {@code java.awt.image.MultiResolutionImage} (available since Java 9 and
above).
*
- * Note that state passed through the {code Component} parameter of the
+ * Note that state passed through the {@code Component} parameter of the
* {@link Icon#paintIcon(Component,Graphics,int,int)} method will only be
current as of the time the
* icon is initially entered into the cache.
*/
diff --git a/platform/openide.util.ui/src/org/openide/util/VectorIcon.java
b/platform/openide.util.ui/src/org/openide/util/VectorIcon.java
index e961753..07a9f5b 100644
--- a/platform/openide.util.ui/src/org/openide/util/VectorIcon.java
+++ b/platform/openide.util.ui/src/org/openide/util/VectorIcon.java
@@ -178,7 +178,7 @@ public abstract class VectorIcon implements Icon,
Serializable {
* Paint the icon at the given width and height. The dimensions given are
the device pixels onto
* which the icon must be drawn after it has been scaled up from its
originally constant logical
* dimensions and aligned onto the device pixel grid. Painting onto the
supplied
- * {@code Graphics2D} instance using whole number coordinates (for
horizontal and veritcal
+ * {@code Graphics2D} instance using whole number coordinates (for
horizontal and vertical
* lines) will encourage sharp and well-aligned icons.
*
* The icon should be painted with its upper left-hand corner at
position (0, 0). Icons need
-
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
[netbeans] 01/10: Replace 'new ImageIcon' with image2Icon for commonly visible icons.
This is an automated email from the ASF dual-hosted git repository.
ebakke pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/netbeans.git
commit b8312bdd4ac5b8fbaf0866f1cfb3ec6f28e34a19
Author: Eirik Bakke
AuthorDate: Wed May 29 15:20:59 2019 -0400
Replace 'new ImageIcon' with image2Icon for commonly visible icons.
The ImageUtilities class now supports HiDPI icons via custom
implementations of
the Icon interface. For this to work, client code must let ImageUtilities
manage
the creation of new Icon instances, using "ImageUtilities.image2Icon(image)"
instead of "new ImageIcon(image)". This is already common throughout the
NetBeans codebase, but there are still quite a few direct uses of ImageIcon.
This commit replaces a few of the direct uses of ImageIcon, for most of the
icons that are commonly seen during a Java editing session in the IDE.
---
java/java.source/src/org/netbeans/modules/java/ui/Icons.java | 4 ++--
.../core.windows/src/org/netbeans/core/windows/view/EditorView.java | 2 +-
.../src/org/netbeans/core/windows/view/ui/TabbedHandler.java | 5 +++--
.../org/netbeans/core/windows/view/ui/slides/TabbedSlideAdapter.java | 4 ++--
.../netbeans/core/windows/view/ui/tabcontrol/AbstractTabbedImpl.java | 3 ++-
.../src/org/netbeans/core/windows/view/ui/toolbars/DnDSupport.java | 2 +-
.../src/org/netbeans/core/windows/view/ui/toolbars/ToolbarRow.java | 4 ++--
.../src/org/openide/explorer/view/NodeRenderDataProvider.java| 4 ++--
8 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/java/java.source/src/org/netbeans/modules/java/ui/Icons.java
b/java/java.source/src/org/netbeans/modules/java/ui/Icons.java
index 1f6a2fd..6dc9b67 100644
--- a/java/java.source/src/org/netbeans/modules/java/ui/Icons.java
+++ b/java/java.source/src/org/netbeans/modules/java/ui/Icons.java
@@ -50,7 +50,7 @@ public final class Icons {
return null;
}
else {
-return new ImageIcon (img);
+return ImageUtilities.image2Icon (img);
}
}
@@ -101,7 +101,7 @@ public final class Icons {
default:
img = null;
}
- return img == null ? null : new ImageIcon (img);
+ return img == null ? null : ImageUtilities.image2Icon (img);
}
diff --git
a/platform/core.windows/src/org/netbeans/core/windows/view/EditorView.java
b/platform/core.windows/src/org/netbeans/core/windows/view/EditorView.java
index 6da4ff8..b6afebb 100644
--- a/platform/core.windows/src/org/netbeans/core/windows/view/EditorView.java
+++ b/platform/core.windows/src/org/netbeans/core/windows/view/EditorView.java
@@ -202,7 +202,7 @@ public class EditorView extends ViewElement {
if(imageSource != null) {
Image image = ImageUtilities.loadImage(imageSource);
if(image != null) {
-JLabel label = new JLabel(new ImageIcon(image));
+JLabel label = new
JLabel(ImageUtilities.image2Icon(image));
label.setMinimumSize(new Dimension(0, 0)); // XXX To be
able shrink the area.
add(label, BorderLayout.CENTER);
} else {
diff --git
a/platform/core.windows/src/org/netbeans/core/windows/view/ui/TabbedHandler.java
b/platform/core.windows/src/org/netbeans/core/windows/view/ui/TabbedHandler.java
index e58c04a..bc1b284 100644
---
a/platform/core.windows/src/org/netbeans/core/windows/view/ui/TabbedHandler.java
+++
b/platform/core.windows/src/org/netbeans/core/windows/view/ui/TabbedHandler.java
@@ -48,6 +48,7 @@ import org.netbeans.core.windows.Switches;
import org.netbeans.core.windows.view.ui.slides.SlideBar;
import org.netbeans.core.windows.view.ui.slides.SlideBarActionEvent;
import org.netbeans.core.windows.view.ui.slides.SlideOperationFactory;
+import org.openide.util.ImageUtilities;
import org.openide.util.Lookup;
@@ -163,7 +164,7 @@ public final class TabbedHandler implements ChangeListener,
ActionListener {
}
tabbed.addTopComponent(
title,
-icon == null ? null : new ImageIcon(icon),
+icon == null ? null : ImageUtilities.image2Icon(icon),
tc, tc.getToolTipText());
} finally {
ignoreChange = false;
@@ -205,7 +206,7 @@ public final class TabbedHandler implements ChangeListener,
ActionListener {
Image icon = tc.getIcon();
if( null != icon ) {
-tabbed.setIconAt(index, new ImageIcon(tc.getIcon()));
+tabbed.setIconAt(index, ImageUtilities.image2Icon(tc.getIcon()));
} else {
Logger.getLogger(TabbedHandler.class.getName()).log(Level.INFO,
"TopComponent has no icon: " + tc);
tabbed.setIconAt(index, null);
diff --git
[netbeans] 07/10: Support HiDPI icons from ImageUtilities.mergeImages.
This is an automated email from the ASF dual-hosted git repository.
ebakke pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/netbeans.git
commit c6bf0a5e11b642efd8331b298dfa69e895bfbe6d
Author: Eirik Bakke
AuthorDate: Thu May 30 18:56:48 2019 -0400
Support HiDPI icons from ImageUtilities.mergeImages.
The old Image-based implementation of mergeImages remains together with
the new
Icon-based implementation. This ensures backwards-compatibility when icons
are
drawn using Graphics.drawImage instead of Icon.paintIcon. (The new
implementation was confirmed to be invoked and working by adding some
now-removed temporary drawing code.)
This completes the changes needed to make all of ImageUtilities' APIs work
with
scalable Icon implementations. An SVGIcon class will be added in a future
commit.
---
.../src/org/openide/util/ImageUtilities.java | 44 +-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
b/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
index e39a306..e7f8121 100644
--- a/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
+++ b/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
@@ -22,9 +22,11 @@ package org.openide.util;
import java.awt.Component;
import java.awt.Graphics;
import java.awt.Graphics2D;
+import java.awt.GraphicsConfiguration;
import java.awt.HeadlessException;
import java.awt.Image;
import java.awt.MediaTracker;
+import java.awt.Rectangle;
import java.awt.RenderingHints;
import java.awt.Toolkit;
import java.awt.Transparency;
@@ -721,10 +723,13 @@ public final class ImageUtilities {
Object firstUrl = image1.getProperty("url", null);
ColorModel model = colorModel(bitmask? Transparency.BITMASK:
Transparency.TRANSLUCENT);
-ToolTipImage buffImage = new ToolTipImage(str.toString(), null,
+// Provide a delegate Icon for scalable rendering.
+Icon delegateIcon = new MergedIcon(image2Icon(image1),
image2Icon(image2), x, y);
+ToolTipImage buffImage = new ToolTipImage(str.toString(), delegateIcon,
model, model.createCompatibleWritableRaster(w, h),
model.isAlphaPremultiplied(), null, firstUrl instanceof URL ? (URL)firstUrl :
null
);
+// Also provide an Image-based rendering for backwards-compatibility.
java.awt.Graphics g = buffImage.createGraphics();
g.drawImage(image1, 0, 0, null);
g.drawImage(image2, x, y, null);
@@ -733,6 +738,43 @@ public final class ImageUtilities {
return buffImage;
}
+/**
+ * Alternative image merging implementation using the {@link Icon} API.
This preserves
+ * scalability of the delegate {@code Icon}s on HiDPI displays.
+ */
+private static final class MergedIcon extends CachedHiDPIIcon {
+private final Icon icon1;
+private final Icon icon2;
+private final int x, y;
+
+public MergedIcon(Icon icon1, Icon icon2, int x, int y) {
+super(Math.max(icon1.getIconWidth(), x + icon2.getIconWidth()),
+ Math.max(icon1.getIconHeight(), y + icon2.getIconHeight()));
+this.icon1 = icon1;
+this.icon2 = icon2;
+this.x = x;
+this.y = y;
+}
+
+@Override
+protected Image createImage(Component c, GraphicsConfiguration
graphicsConfiguration,
+int deviceWidth, int deviceHeight, double scale)
+{
+BufferedImage ret = graphicsConfiguration.createCompatibleImage(
+deviceWidth, deviceHeight, Transparency.TRANSLUCENT);
+Graphics2D g = ret.createGraphics();
+try {
+g.clip(new Rectangle(0, 0, deviceWidth, deviceHeight));
+g.scale(scale, scale);
+icon1.paintIcon(c, g, 0, 0);
+icon2.paintIcon(c, g, x, y);
+} finally {
+g.dispose();
+}
+return ret;
+}
+}
+
/** Creates BufferedImage with Transparency.TRANSLUCENT */
static final java.awt.image.BufferedImage createBufferedImage(int width,
int height) {
if (Utilities.isMac()) {
-
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
[netbeans] 09/10: Don't have CachedHiDPIIcon extend from ImageIcon.
This is an automated email from the ASF dual-hosted git repository.
ebakke pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/netbeans.git
commit 5f828b3eb302124ba438c235053f7863417e8d30
Author: Eirik Bakke
AuthorDate: Sun Jun 2 14:31:59 2019 -0400
Don't have CachedHiDPIIcon extend from ImageIcon.
This was left over from a previous experiment. Also fix a case where
ImageUtilities.icon2Image could return null even when the icon is not null.
(Include this fix in this PR rather than in the SVG support PR, to
ensure I don't commit bugs if this one is merged before the other.)
---
platform/openide.util.ui/src/org/openide/util/CachedHiDPIIcon.java | 3 +--
platform/openide.util.ui/src/org/openide/util/ImageUtilities.java | 7 ---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/platform/openide.util.ui/src/org/openide/util/CachedHiDPIIcon.java
b/platform/openide.util.ui/src/org/openide/util/CachedHiDPIIcon.java
index 107469c..b0bcffe 100644
--- a/platform/openide.util.ui/src/org/openide/util/CachedHiDPIIcon.java
+++ b/platform/openide.util.ui/src/org/openide/util/CachedHiDPIIcon.java
@@ -29,14 +29,13 @@ import java.util.LinkedHashMap;
import java.util.Map;
import java.util.Objects;
import javax.swing.Icon;
-import javax.swing.ImageIcon;
/**
* Abstract base class for {@link javax.swing.Icon} implementations that need
to cache scaled bitmap
* representations for HiDPI displays. Bitmaps for multiple HiDPI scaling
factors can be cached at
* the same time, e.g. for multi-monitor setups. Thread-safe.
*/
-abstract class CachedHiDPIIcon extends ImageIcon {
+abstract class CachedHiDPIIcon implements Icon {
/**
* The maximum size of the cache, as a multiple of the size of the icon at
100% scaling. For
* example, storing three images at 100%, 150%, and 200% scaling,
respectively, yields a total
diff --git a/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
b/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
index e7f8121..b133ad9 100644
--- a/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
+++ b/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
@@ -303,10 +303,11 @@ public final class ImageUtilities {
} else if (icon instanceof IconImageIcon) {
return icon2Image(((IconImageIcon) icon).getDelegateIcon());
} else if (icon instanceof ImageIcon) {
-return ((ImageIcon) icon).getImage();
-} else {
-return icon2ToolTipImage(icon);
+Image ret = ((ImageIcon) icon).getImage();
+if (ret != null)
+return ret;
}
+return icon2ToolTipImage(icon);
}
private static ToolTipImage icon2ToolTipImage(Icon icon) {
-
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
[netbeans] 03/10: [NETBEANS-1586] Make ImageUtilities.createDisabledIcon work with HiDPI icons
This is an automated email from the ASF dual-hosted git repository.
ebakke pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/netbeans.git
commit d305cd16e9a4ab88a71ced7e7b8622d26542b2f1
Author: Eirik Bakke
AuthorDate: Wed May 29 16:13:30 2019 -0400
[NETBEANS-1586] Make ImageUtilities.createDisabledIcon work with HiDPI icons
Introduced a FilteredIcon class which extends from a new CachedHiDPIIcon
class.
The CachedHiDPIIcon class will be used again in the future; it was
originally
designed for an SVG-based Icon implementation, which will be contributed
separately in the future. It is generic enough to work with any kind of
custom
Icon implementation that needs caching.
Also make color filtering of icons for dark themes work with HiDPI icons,
using
the same FilteredIcon class.
Also improved a null handling case in ImageUtilities.loadImage. Passing a
null
resource used to be valid before (yielding a null return value), but caused
a
NPE on dark LAFs. Since it worked in the common non-dark case, it should
arguably work in the dark case as well. This might fix NETBEANS-2401, or it
might just lead to an NPE elsewhere in that case.
---
.../src/org/openide/util/CachedHiDPIIcon.java | 211 +
.../src/org/openide/util/FilteredIcon.java | 79
.../src/org/openide/util/ImageUtilities.java | 62 ++
3 files changed, 308 insertions(+), 44 deletions(-)
diff --git a/platform/openide.util.ui/src/org/openide/util/CachedHiDPIIcon.java
b/platform/openide.util.ui/src/org/openide/util/CachedHiDPIIcon.java
new file mode 100644
index 000..ecce663
--- /dev/null
+++ b/platform/openide.util.ui/src/org/openide/util/CachedHiDPIIcon.java
@@ -0,0 +1,211 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.openide.util;
+
+import java.awt.Component;
+import java.awt.Graphics;
+import java.awt.Graphics2D;
+import java.awt.GraphicsConfiguration;
+import java.awt.Image;
+import java.awt.geom.AffineTransform;
+import java.util.Iterator;
+import java.util.LinkedHashMap;
+import java.util.Map;
+import java.util.Objects;
+import javax.swing.Icon;
+import javax.swing.ImageIcon;
+
+/**
+ * Abstract base class for {@link javax.swing.Icon} implementations that need
to cache scaled bitmap
+ * representations for HiDPI displays. Bitmaps for multiple HiDPI scaling
factors can be cached at
+ * the same time, e.g. for multi-monitor setups.
+ */
+abstract class CachedHiDPIIcon extends ImageIcon {
+/**
+ * The maximum size of the cache, as a multiple of the size of the icon at
100% scaling. For
+ * example, storing three images at 100%, 150%, and 200% scaling,
respectively, yields a total
+ * cache size of 1.0^2 + 1.5^2 + 2^2 = 7.2.
+ */
+private static final double MAX_CACHE_SIZE = 10.0;
+private final int width;
+private final int height;
+/**
+ * Cache map with least-recently-used iteration order.
+ */
+private final Map cache =
+new LinkedHashMap(16, 0.75f, true);
+/**
+ * Total size of the images currently in the cache, in the same units as
+ * {@link #MAX_CACHE_SIZE}.
+ */
+private double cacheSize = 0.0;
+
+/**
+ * Constructor to be used by subclasses.
+ */
+protected CachedHiDPIIcon(int width, int height) {
+if (width < 0) {
+throw new IllegalArgumentException();
+}
+if (height < 0) {
+throw new IllegalArgumentException();
+}
+this.width = width;
+this.height = height;
+}
+
+private synchronized Image getScaledImageCached(Component c,
CachedImageKey key) {
+Image ret = cache.get(key);
+if (ret != null) {
+return ret;
+}
+final double scale = key.getScale();
+final int deviceWidth = (int) Math.ceil(getIconWidth() * scale);
+final int deviceHeight = (int) Math.ceil(getIconHeight() * scale);
+final Image img =
+createImage(c, key.getGraphicsConfiguration(), deviceWidth,
deviceHeight, scale);
+final double imgSize = key.getSize();
+if
[netbeans] 06/10: Improve rendering quality of scaled bitmap icons on HiDPI displays.
This is an automated email from the ASF dual-hosted git repository.
ebakke pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/netbeans.git
commit 894376f42517da2dd028852fcb3bb0d1e4b10609
Author: Eirik Bakke
AuthorDate: Thu May 30 13:52:57 2019 -0400
Improve rendering quality of scaled bitmap icons on HiDPI displays.
Having centralized icon painting into ImageUtilities.ToolTipImage.paintIcon
in
the previous commits, we can now add a few painting tweaks to improve the
appearance of low-resolution bitmap icons that must be scaled up for HiDPI
displays. See the before/after screenshots that are attached to JIRA ticket
NETBEANS-2614.
---
.../src/org/openide/util/ImageUtilities.java | 50 +++---
1 file changed, 45 insertions(+), 5 deletions(-)
diff --git a/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
b/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
index 8783424..e39a306 100644
--- a/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
+++ b/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
@@ -21,11 +21,14 @@ package org.openide.util;
import java.awt.Component;
import java.awt.Graphics;
+import java.awt.Graphics2D;
import java.awt.HeadlessException;
import java.awt.Image;
import java.awt.MediaTracker;
+import java.awt.RenderingHints;
import java.awt.Toolkit;
import java.awt.Transparency;
+import java.awt.geom.AffineTransform;
import java.awt.image.BufferedImage;
import java.awt.image.ColorModel;
import java.awt.image.ImageObserver;
@@ -160,7 +163,8 @@ public final class ImageUtilities {
return loadImageInternal(resource, localized);
}
-// Private version with more specific return type.
+/* Private version of the method showing the more specific return type. We
always return a
+ToolTipImage, to take advantage of its rendering tweaks for HiDPI screens.
*/
private static ToolTipImage loadImageInternal(String resource, boolean
localized) {
// Avoid a NPE that could previously occur in the isDarkLaF case only.
See NETBEANS-2401.
if (resource == null) {
@@ -177,9 +181,6 @@ public final class ImageUtilities {
// only non _dark images need filtering
RGBImageFilter imageFilter = getImageIconFilter();
if (null != image && null != imageFilter) {
-/* Make sure that every Image loaded by this class is a
ToolTipImage, whether or not
-a filter is applied. That way we're less likely to introduce
bugs that only occur on
-certain LAFs. */
image = icon2ToolTipImage(FilteredIcon.create(imageFilter,
image));
}
}
@@ -276,6 +277,8 @@ public final class ImageUtilities {
* @return icon corresponding icon
*/
public static final Icon image2Icon(Image image) {
+/* Make sure to always return a ToolTipImage, to take advantage of its
rendering tweaks for
+HiDPI screens. */
return (image instanceof ToolTipImage)
? (ToolTipImage) image : assignToolTipToImageInternal(image,
"");
}
@@ -954,7 +957,44 @@ public final class ImageUtilities {
if (delegateIcon != null) {
delegateIcon.paintIcon(c, g, x, y);
} else {
-g.drawImage(this, x, y, null);
+/* There is no scalable delegate icon available. On HiDPI
displays, this means that
+original low-resolution icons will need to be scaled up to a
higher resolution. Do a
+few tricks here to improve the quality of the scaling. See
NETBEANS-2614 and the
+before/after screenshots that are attached to said JIRA
ticket. */
+Graphics2D g2 = (Graphics2D) g.create();
+try {
+final AffineTransform tx = g2.getTransform();
+final int txType = tx.getType();
+final double scale;
+if (txType == AffineTransform.TYPE_UNIFORM_SCALE ||
+txType == (AffineTransform.TYPE_UNIFORM_SCALE |
AffineTransform.TYPE_TRANSLATION))
+{
+ scale = tx.getScaleX();
+} else {
+ scale = 1.0;
+}
+if (scale != 1.0) {
+/* The default interpolation mode is nearest neighbor.
Use bicubic
+interpolation instead, which looks better, especially
with non-integral
+HiDPI scaling factors (e.g. 150%). Even for an
integral 2x scaling factor
+(used by all Retina displays on MacOS), the blurred
appearance of bicubic
+scaling ends up looking better on HiDPI displays than
the blocky appearance
+of nearest neighbor. */
+
[netbeans] 02/10: Use Icon.paintIcon instead of Graphics.drawImage (one example).
This is an automated email from the ASF dual-hosted git repository.
ebakke pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/netbeans.git
commit d7d467c342a7ab4d0759f67c276d4d75ef8fb275
Author: Eirik Bakke
AuthorDate: Wed May 29 15:36:42 2019 -0400
Use Icon.paintIcon instead of Graphics.drawImage (one example).
Most of the icons that are seen in the IDE during a standard Java editing
session are already painted via a call to Icon.paintIcon. One exception is
the
separator icon that is used in the breadcrumb component under the code
editor,
which is painted via Graphics.drawImage. Migrate this one to Icon.paintIcon
to
make the icon look better on HiDPI displays (taking advantage of the HiDPI
scaling hints that were recently implemented in ImageUtilities).
This also serves as an example of how to fix other similar cases in the
future.
---
.../modules/editor/breadcrumbs/BreadCrumbComponent.java | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git
a/ide/editor.breadcrumbs/src/org/netbeans/modules/editor/breadcrumbs/BreadCrumbComponent.java
b/ide/editor.breadcrumbs/src/org/netbeans/modules/editor/breadcrumbs/BreadCrumbComponent.java
index 3a5ad9d..3d60c65 100644
---
a/ide/editor.breadcrumbs/src/org/netbeans/modules/editor/breadcrumbs/BreadCrumbComponent.java
+++
b/ide/editor.breadcrumbs/src/org/netbeans/modules/editor/breadcrumbs/BreadCrumbComponent.java
@@ -64,7 +64,8 @@ import org.openide.util.WeakListeners;
*/
public class BreadCrumbComponent extends JComponent
implements PropertyChangeListener {
-private final Image SEPARATOR =
ImageUtilities.loadImage("org/netbeans/modules/editor/breadcrumbs/resources/separator.png");
+private final Icon SEPARATOR =
+
ImageUtilities.image2Icon(ImageUtilities.loadImage("org/netbeans/modules/editor/breadcrumbs/resources/separator.png"));
public BreadCrumbComponent() {
setPreferredSize(new Dimension(0, COMPONENT_HEIGHT));
@@ -119,7 +120,7 @@ public class BreadCrumbComponent
extends JComponent i
int height = getHeight();
if (nodes.length == 0) {
-g.drawImage(SEPARATOR, START_INSET, (height -
SEPARATOR.getHeight(null)) / 2, null);
+SEPARATOR.paintIcon(this, g, START_INSET, (height -
SEPARATOR.getIconHeight()) / 2);
return ;
}
@@ -135,10 +136,10 @@ public class BreadCrumbComponent extends JComponent i
g.translate(-x, -labelY);
x += sizes[i];
-
-g.drawImage(SEPARATOR, x + LEFT_SEPARATOR_INSET, (height -
SEPARATOR.getHeight(null)) / 2, null);
-x += LEFT_SEPARATOR_INSET + SEPARATOR.getWidth(null) +
RIGHT_SEPARATOR_INSET;
+SEPARATOR.paintIcon(this, g, x + LEFT_SEPARATOR_INSET, (height -
SEPARATOR.getIconHeight()) / 2);
+
+x += LEFT_SEPARATOR_INSET + SEPARATOR.getIconWidth() +
RIGHT_SEPARATOR_INSET;
}
}
@@ -169,7 +170,7 @@ public class BreadCrumbComponent
extends JComponent i
i++;
}
-setPreferredSize(new Dimension((int) (xTotal + (nodes.length - 1) *
(LEFT_SEPARATOR_INSET + SEPARATOR.getWidth(null) + RIGHT_SEPARATOR_INSET) +
START_INSET), USABLE_HEIGHT/*(int) (height + 2 * INSET_HEIGHT)*/));
+setPreferredSize(new Dimension((int) (xTotal + (nodes.length - 1) *
(LEFT_SEPARATOR_INSET + SEPARATOR.getIconWidth() + RIGHT_SEPARATOR_INSET) +
START_INSET), USABLE_HEIGHT/*(int) (height + 2 * INSET_HEIGHT)*/));
}
@Override
@@ -206,7 +207,7 @@ public class BreadCrumbComponent
extends JComponent i
}
startX = elemX;
-elemX += SEPARATOR.getWidth(null);
+elemX += SEPARATOR.getIconWidth();
if (clickX <= elemX) {
//found:
-
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
[netbeans] branch master updated (6417f2f -> 5f78200)
This is an automated email from the ASF dual-hosted git repository. ebakke pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/netbeans.git. from 6417f2f Merge pull request #1281 from jglick/NbEventSpy-NETBEANS-2639 new b8312bd Replace 'new ImageIcon' with image2Icon for commonly visible icons. new d7d467c Use Icon.paintIcon instead of Graphics.drawImage (one example). new d305cd1 [NETBEANS-1586] Make ImageUtilities.createDisabledIcon work with HiDPI icons new 44822cd Adjust data types in ImageUtilities to make it easier to see where ToolTipImage is being passed around. new 0f61cd9 Make ImageUtilities handle scalable Icon implementations. new 894376f Improve rendering quality of scaled bitmap icons on HiDPI displays. new c6bf0a5 Support HiDPI icons from ImageUtilities.mergeImages. new 73a3f68 Fix a few comment typos. new 5f828b3 Don't have CachedHiDPIIcon extend from ImageIcon. new 5f78200 Add more tests for ImageUtilities, and fix some broken ones. The 10 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../editor/breadcrumbs/BreadCrumbComponent.java| 15 +- .../src/org/netbeans/modules/java/ui/Icons.java| 4 +- .../jshell/editor/CommandCompletionProvider.java | 2 +- .../org/netbeans/core/windows/view/EditorView.java | 2 +- .../core/windows/view/ui/TabbedHandler.java| 5 +- .../windows/view/ui/slides/TabbedSlideAdapter.java | 4 +- .../view/ui/tabcontrol/AbstractTabbedImpl.java | 3 +- .../core/windows/view/ui/toolbars/DnDSupport.java | 2 +- .../core/windows/view/ui/toolbars/ToolbarRow.java | 4 +- .../explorer/view/NodeRenderDataProvider.java | 4 +- .../src/org/openide/util/CachedHiDPIIcon.java | 210 + .../src/org/openide/util/FilteredIcon.java | 79 + .../src/org/openide/util/ImageUtilities.java | 342 +++-- .../src/org/openide/util/VectorIcon.java | 2 +- .../src/org/openide/util/ImageUtilitiesTest.java | 234 +- 15 files changed, 786 insertions(+), 126 deletions(-) create mode 100644 platform/openide.util.ui/src/org/openide/util/CachedHiDPIIcon.java create mode 100644 platform/openide.util.ui/src/org/openide/util/FilteredIcon.java - 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
[netbeans] 04/10: Adjust data types in ImageUtilities to make it easier to see where ToolTipImage is being passed around.
This is an automated email from the ASF dual-hosted git repository.
ebakke pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/netbeans.git
commit 44822cdcb0e2c6d174f0eeb260395d4696b2ab69
Author: Eirik Bakke
AuthorDate: Wed May 29 17:22:16 2019 -0400
Adjust data types in ImageUtilities to make it easier to see where
ToolTipImage is being passed around.
No public APIs are affected.
---
.../src/org/openide/util/ImageUtilities.java | 31 +-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
b/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
index 4a46b6a..7a3c73a 100644
--- a/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
+++ b/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
@@ -224,7 +224,7 @@ public final class ImageUtilities {
}
CompositeImageKey k = new CompositeImageKey(image1, image2, x, y);
-Image cached;
+ToolTipImage cached;
synchronized (compositeCache) {
ActiveRef r = compositeCache.get(k);
@@ -282,10 +282,15 @@ public final class ImageUtilities {
* @return Image with attached tool tip
*/
public static final Image assignToolTipToImage(Image image, String text) {
+return assignToolTipToImageInternal(image, text);
+}
+
+// Private version with more specific return type.
+private static ToolTipImage assignToolTipToImageInternal(Image image,
String text) {
Parameters.notNull("image", image);
Parameters.notNull("text", text);
ToolTipImageKey key = new ToolTipImageKey(image, text);
-Image cached;
+ToolTipImage cached;
synchronized (imageToolTipCache) {
ActiveRef r = imageToolTipCache.get(key);
if (r != null) {
@@ -411,14 +416,14 @@ public final class ImageUtilities {
}
}
-static Image getIcon(String resource, boolean localized) {
+static ToolTipImage getIcon(String resource, boolean localized) {
if (localized) {
if (resource == null) {
return null;
}
synchronized (localizedCache) {
ActiveRef ref = localizedCache.get(resource);
-Image img = null;
+ToolTipImage img = null;
// no icon for this name (already tested)
if (ref == NO_ICON) {
@@ -460,7 +465,7 @@ public final class ImageUtilities {
while (it.hasNext()) {
String suffix = it.next();
-Image i;
+ToolTipImage i;
if (suffix.length() == 0) {
i = getIcon(resource, loader, false);
@@ -487,12 +492,12 @@ public final class ImageUtilities {
* @param localizedQuery whether the name contains some localization suffix
* and is not optimized/interned
*/
-private static Image getIcon(String name, ClassLoader loader, boolean
localizedQuery) {
+private static ToolTipImage getIcon(String name, ClassLoader loader,
boolean localizedQuery) {
if (name == null) {
return null;
}
ActiveRef ref = cache.get(name);
-Image img = null;
+ToolTipImage img = null;
// no icon for this name (already tested)
if (ref == NO_ICON) {
@@ -596,9 +601,9 @@ public final class ImageUtilities {
ERR.log(Level.FINE, "loading icon {0} = {1}", new Object[]
{n, result});
}
name = new String(name).intern(); // NOPMD
-result = ToolTipImage.createNew("", result, url);
-cache.put(name, new ActiveRef(result, cache, name));
-return result;
+ToolTipImage toolTipImage = ToolTipImage.createNew("", result,
url);
+cache.put(name, new ActiveRef(toolTipImage, cache,
name));
+return toolTipImage;
} else { // no icon found
if (!localizedQuery) {
cache.put(name, NO_ICON);
@@ -651,7 +656,7 @@ public final class ImageUtilities {
}
}
-private static final Image doMergeImages(Image image1, Image image2, int
x, int y) {
+private static final ToolTipImage doMergeImages(Image image1, Image
image2, int x, int y) {
ensureLoaded(image1);
ensureLoaded(image2);
@@ -788,11 +793,11 @@ public final class ImageUtilities {
}
/** Cleaning reference. */
-private static final class ActiveRef extends SoftReference
implements Runnable {
+private static final class ActiveRef extends
SoftReference implements Runnable {
private final Map> holder;
private final T key;
-public ActiveRef(Image o, Map> holder, T key) {
+public
[netbeans] 05/10: Make ImageUtilities handle scalable Icon implementations.
This is an automated email from the ASF dual-hosted git repository.
ebakke pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/netbeans.git
commit 0f61cd9928841a065a4ec18b0bb808e154a9632b
Author: Eirik Bakke
AuthorDate: Thu May 30 00:20:20 2019 -0400
Make ImageUtilities handle scalable Icon implementations.
This commit prepares ImageUtilities to work with scalable Icon
implementations,
such as a future SVGIcon class. Conversions such
image2icon(icon2Image(icon))
are now lossless with respect to scalable Icon implementations. This allows
HiDPI support to be implemented via custom Icon classes while keeping
existing
Image-based APIs (such as org.openide.nodes.Node.getIcon) unchanged.
The internal ImageUtilities.ToolTipImage class, which also implements the
Icon
interface, is now used in most cases for ImageUtilities methods that return
an
Image. Modifying ToolTipImage's paint() method to paint an extra debugging
stroke yields a quick confirmation that most of the icons visible in the IDE
now successfully have their painting delegated through this method. This
will
come in handy in a subsequent commit, when we try to do some centralized
scaling
improvements for HiDPI displays.
It is no longer safe to assume that ImageUtilities.image2Icon returns an
ImageIcon. Grepped the entire codebase for such casts (searched for cast to
ImageIcon within 3 lines of 'image2Icon'), and found only one, which was
fixed.
Manually tested, including for the case where
ImageUtilities.getImageIconFilter() returns a non-null filter. Fixed a
deadlock
bug that was unearthed in the latter case.
---
.../jshell/editor/CommandCompletionProvider.java | 2 +-
.../src/org/openide/util/ImageUtilities.java | 166 +++--
2 files changed, 125 insertions(+), 43 deletions(-)
diff --git
a/java/jshell.support/src/org/netbeans/modules/jshell/editor/CommandCompletionProvider.java
b/java/jshell.support/src/org/netbeans/modules/jshell/editor/CommandCompletionProvider.java
index fbb8fd9..697970d 100644
---
a/java/jshell.support/src/org/netbeans/modules/jshell/editor/CommandCompletionProvider.java
+++
b/java/jshell.support/src/org/netbeans/modules/jshell/editor/CommandCompletionProvider.java
@@ -337,7 +337,7 @@ public class CommandCompletionProvider implements
CompletionProvider{
n = f.getLookup().lookup(Node.class);
}
if (n != null) {
-return
(ImageIcon)ImageUtilities.image2Icon(n.getIcon(BeanInfo.ICON_COLOR_16x16));
+return new
ImageIcon(n.getIcon(BeanInfo.ICON_COLOR_16x16));
}
}
}
diff --git a/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
b/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
index 7a3c73a..8783424 100644
--- a/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
+++ b/platform/openide.util.ui/src/org/openide/util/ImageUtilities.java
@@ -28,7 +28,6 @@ import java.awt.Toolkit;
import java.awt.Transparency;
import java.awt.image.BufferedImage;
import java.awt.image.ColorModel;
-import java.awt.image.FilteredImageSource;
import java.awt.image.ImageObserver;
import java.awt.image.RGBImageFilter;
import java.awt.image.WritableRaster;
@@ -54,6 +53,13 @@ import javax.swing.UIManager;
/**
* Useful static methods for manipulation with images/icons, results are
cached.
+ *
+ * Images can be represented as instances of either {@link Image} or {@link
Icon}. For best
+ * results on HiDPI displays, clients should use the {@link
#image2Icon(Image)} method provided by
+ * this class when converting an {@code Image} to an {@code Icon}, rather than
constructing
+ * {@link ImageIcon} instances themselves. When doing manual painting, clients
should use
+ * {@link Icon#paintIcon(Component, Graphics, int, int)} rather than
+ * {@link Graphics#drawImage(Image, int, int, ImageObserver)}.
*
* @author Jaroslav Tulach, Tomas Holy
* @since 7.15
@@ -93,6 +99,22 @@ public final class ImageUtilities {
private static final Logger ERR =
Logger.getLogger(ImageUtilities.class.getName());
private static final String DARK_LAF_SUFFIX = "_dark"; //NOI18N
+
+/**
+ * Dummy component to be passed to the first parameter of
+ * {@link Icon#paintIcon(Component, Graphics, int, int)} when converting
an {@code Icon} to an
+ * {@code Image}. See comment in {@link #icon2ToolTipImage(Icon)}.
+ */
+private static volatile Component dummyIconComponent;
+
+static {
+Mutex.EVENT.writeAccess(new Runnable() {
+@Override
+public void run() {
+dummyIconComponent = new JLabel();
+}
+});
+}
private ImageUtilities() {
}
@@
[jira] [Updated] (NETBEANS-2457) Error hint to fix the '--enable-preview' features in java project
[
https://issues.apache.org/jira/browse/NETBEANS-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated NETBEANS-2457:
-
Labels: pull-request-available (was: )
> Error hint to fix the '--enable-preview' features in java project
> -
>
> Key: NETBEANS-2457
> URL: https://issues.apache.org/jira/browse/NETBEANS-2457
> Project: NetBeans
> Issue Type: Improvement
>Reporter: ARUNAVA SINHA
>Assignee: ARUNAVA SINHA
>Priority: Major
> Labels: pull-request-available
> Fix For: 12.0
>
>
> Suppose we had used switch-expression in a Java Project (JDK-12)
> e.g.,
> int a = switch (num)
> { case 1 ->1; default->2; }
> ;
> It will show the below error:
> switch expressions are a preview feature and are disabled by default.
> (use --enable-preview to enable switch expressions)
>
> NetBeans doesn't provide the fix.
> Currently manually need to add '--enable-preview" in build configuration file.
--
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-467) maven artifacts for Apache NetBeans Platform need to be created and hosted
[ https://issues.apache.org/jira/browse/NETBEANS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858150#comment-16858150 ] Salvatore Cardinale commented on NETBEANS-467: -- [~skygo]- As [~GeertjanWielenga] pointed out- Apache should own the domain now. But political/infrastructure blockers aside there are still some issues with the maven setups: * The default "create maven netbeans platform" wizard still points to the bits.netbeans.org/nexus repo (I just confirmed this on NB10). Anyone comparing RCP platforms will be limited to an older version of Netbeans unless they take the time to scan through forums to find out that they need to manually update the pom file to point to a different repo. * All versions should be available from one repo. Since the last developer published repo was netbeans "RELEASE82". It would be nice to be able to easily jump back and forth between say 82 and 10 without swapping repos. Yes, I understand a local nexus/maven repo will solve this. > maven artifacts for Apache NetBeans Platform need to be created and hosted > --- > > Key: NETBEANS-467 > URL: https://issues.apache.org/jira/browse/NETBEANS-467 > Project: NetBeans > Issue Type: Task > Components: website >Affects Versions: 9.0 >Reporter: Eric Barboni >Assignee: Eric Barboni >Priority: Critical > Labels: NETBEANS-9 > > Hi (hope I did not miss mails on this topic), > During test on maven NetCAT, testers are told to create and generate > mavenized NetBeans Platform Module and Suite. > Maven archetype for Netbeans platform module [1] are linked to artefacts > stored in [2] (RELEASE 6 to 8.2) and it is also possible to use snapshot > versions from [3] > Artifacts are generated from Oracle NetBeans sources at the moment, RELEASE* > artifact were built from a specific build, SNAPSHOT artifact are refreshed > every day with no history (I suppose for space reason). > > It would be nice to recreate a workflow to regenerate maven artefacts for > the Apache NetBeans Platform from Apache NetBeans sources. > > [1][https://github.com/mojohaus/nbm-archetype/] > [2][https://bits.netbeans.org/nexus] > [3][https://bits.netbeans.org/dev/maven-snapshot/|http://bits.netbeans.org/dev/maven-snapshot/] > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Created] (NETBEANS-2647) Incorrect JSP taglib dependency resolution
Jan Tošovský created NETBEANS-2647:
--
Summary: Incorrect JSP taglib dependency resolution
Key: NETBEANS-2647
URL: https://issues.apache.org/jira/browse/NETBEANS-2647
Project: NetBeans
Issue Type: Bug
Components: javaee - JSP
Affects Versions: 11.0
Reporter: Jan Tošovský
In my project https://github.com/jan-tosovsky-cz/taglib-test I use specific
taglib which has dependency on another library. Both are specified as
dependencies in my pom.xml file. However, when inserting this taglib into JSP
page, NetBeans fails to resolve that dependency correctly. It is logged in the
Notification tab, see detailed stack trace:
{code:java}
java.lang.NoClassDefFoundError: com/liferay/portal/kernel/util/Validator
at
com.liferay.taglib.portlet.ActionURLTei.getVariableInfo(ActionURLTei.java:33)
at javax.servlet.jsp.tagext.TagInfo.getVariableInfo(TagInfo.java:280)
at
org.netbeans.modules.web.core.syntax.JSPProcessor.createBeanVarDeclarations(JSPProcessor.java:143)
at
org.netbeans.modules.web.core.syntax.SimplifiedJspServlet.renderProcess(SimplifiedJspServlet.java:237)
at
org.netbeans.modules.web.core.syntax.JSPProcessor$2.run(JSPProcessor.java:325)
at org.netbeans.editor.BaseDocument.render(BaseDocument.java:1402)
at
org.netbeans.modules.web.core.syntax.JSPProcessor.process(JSPProcessor.java:321)
at
org.netbeans.modules.web.core.syntax.EmbeddingProviderImpl.getEmbeddings(EmbeddingProviderImpl.java:52)
at
org.netbeans.modules.parsing.impl.TaskProcessor.callEmbeddingProvider(TaskProcessor.java:576)
at
org.netbeans.modules.parsing.impl.SourceCache.getAllEmbeddings(SourceCache.java:299)
at
org.netbeans.modules.parsing.api.ResultIterator.getEmbeddings(ResultIterator.java:140)
at
org.netbeans.modules.parsing.api.ResultIterator.getParserResult(ResultIterator.java:126)
at
org.netbeans.modules.csl.hints.infrastructure.SuggestionsTask$1.run(SuggestionsTask.java:99)
at
org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586)
at
org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:130)
at
org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:114)
at
org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181)
at
org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178)
at
org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
at
org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
at
org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
at
org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
at
org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178)
at
org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:81)
at
org.netbeans.modules.csl.hints.infrastructure.SuggestionsTask.run(SuggestionsTask.java:97)
at
org.netbeans.modules.csl.hints.infrastructure.SuggestionsTask.run(SuggestionsTask.java:54)
at
org.netbeans.modules.parsing.impl.TaskProcessor.callParserResultTask(TaskProcessor.java:561)
at
org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.run(TaskProcessor.java:786)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279)
at
org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.execute(TaskProcessor.java:702)
[catch] at
org.netbeans.modules.parsing.impl.TaskProcessor$CompilationJob.run(TaskProcessor.java:663)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at
org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-2646) Improve border appearances with fractional HiDPI scaling factors (Windows LAF)
[
https://issues.apache.org/jira/browse/NETBEANS-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated NETBEANS-2646:
-
Labels: HiDPI pull-request-available (was: HiDPI)
> Improve border appearances with fractional HiDPI scaling factors (Windows LAF)
> --
>
> Key: NETBEANS-2646
> URL: https://issues.apache.org/jira/browse/NETBEANS-2646
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Window System
>Affects Versions: 11.0
> Environment: Windows 10 with HiDPI monitor in fractional scaling mode
> (e.g. 150%), Java 9 and above
>Reporter: Eirik Bakke
>Assignee: Eirik Bakke
>Priority: Major
> Labels: HiDPI, pull-request-available
> Attachments: BordersAfterPatch.png, BordersBeforePatch.png
>
>
> On Windows 10 systems with HiDPI monitors, it is possible to specify
> fractional DPI scaling factors, such as 150%. Some of the borders around
> components visible in the main NetBeans window end up looking ugly on this
> setting, because of rounding errors that cause a border 1 logical pixels wide
> to be painted as either 1 or 2 device pixels wide, depending on exactly where
> on the screen the border is drawn. This can be seen on Windows 10 with a 150%
> DPI scaling factor, by dragging the split pane between the "Projects" tab and
> the source code editor back and forth, and observing spurious changes in the
> surrounding borders. See the attached screenshots (be sure to view at 100%
> scaling).
> I'll add a pull request to fix this in the most visible places, which is
> borders used in the NetBeans tab control. There are similar problems in other
> Swing components, e.g. JTextField, but that would have to be reported as a
> bug against the JDK's Windows LAF.
> This issue/PR relates only to the Windows LAF. On MacOS, the problem does not
> appear, since only an integral scaling factor (2x) is used for HiDPI
> ("retina") screens, which avoids the underlying rounding errors.
> A similar problem may also appear on Linux; if this is the case, feel free to
> open a new ticket. I did not have a Linux machine to test on, so I prepared
> this patch for the Windows LAF only.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-2646) Improve border appearances with fractional HiDPI scaling factors (Windows LAF)
[
https://issues.apache.org/jira/browse/NETBEANS-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke updated NETBEANS-2646:
--
Description:
On Windows 10 systems with HiDPI monitors, it is possible to specify fractional
DPI scaling factors, such as 150%. Some of the borders around components
visible in the main NetBeans window end up looking ugly on this setting,
because of rounding errors that cause a border 1 logical pixels wide to be
painted as either 1 or 2 device pixels wide, depending on exactly where on the
screen the border is drawn. This can be seen on Windows 10 with a 150% DPI
scaling factor, by dragging the split pane between the "Projects" tab and the
source code editor back and forth, and observing spurious changes in the
surrounding borders. See the attached screenshots (be sure to view at 100%
scaling).
I'll add a pull request to fix this in the most visible places, which is
borders used in the NetBeans tab control. There are similar problems in other
Swing components, e.g. JTextField, but that would have to be reported as a bug
against the JDK's Windows LAF.
This issue/PR relates only to the Windows LAF. On MacOS, the problem does not
appear, since only an integral scaling factor (2x) is used for HiDPI ("retina")
screens, which avoids the underlying rounding errors.
A similar problem may also appear on Linux; if this is the case, feel free to
open a new ticket. I did not have a Linux machine to test on, so I prepared
this patch for the Windows LAF only.
was:
On Windows 10 systems with HiDPI monitors, it is possible to specify fractional
DPI scaling factors, such as 150%. Some of the borders around components
visible in the main NetBeans window end up looking ugly on this setting,
because of rounding errors that cause a border 1 logical pixels wide to be
painted as either 1 or 2 device pixels wide, depending on exactly where on the
screen the border is drawn. This can be seen on Windows 10 with a 150% DPI
scaling factor, by dragging the split pane between the "Projects" tab and the
source code editor back and forth, and observing spurious changes in the
surrounding borders. See the attached screenshots (be sure to view at 100%
scaling).
I'll add a pull request to fix this in the most visible places, which is
borders used in the NetBeans tab control. There are similar problems in other
Swing components, e.g. JTextField, but that would have to be reported as a bug
against the JDK's Windows LAF.
> Improve border appearances with fractional HiDPI scaling factors (Windows LAF)
> --
>
> Key: NETBEANS-2646
> URL: https://issues.apache.org/jira/browse/NETBEANS-2646
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Window System
>Affects Versions: 11.0
> Environment: Windows 10 with HiDPI monitor in fractional scaling mode
> (e.g. 150%), Java 9 and above
>Reporter: Eirik Bakke
>Assignee: Eirik Bakke
>Priority: Major
> Labels: HiDPI
> Attachments: BordersAfterPatch.png, BordersBeforePatch.png
>
>
> On Windows 10 systems with HiDPI monitors, it is possible to specify
> fractional DPI scaling factors, such as 150%. Some of the borders around
> components visible in the main NetBeans window end up looking ugly on this
> setting, because of rounding errors that cause a border 1 logical pixels wide
> to be painted as either 1 or 2 device pixels wide, depending on exactly where
> on the screen the border is drawn. This can be seen on Windows 10 with a 150%
> DPI scaling factor, by dragging the split pane between the "Projects" tab and
> the source code editor back and forth, and observing spurious changes in the
> surrounding borders. See the attached screenshots (be sure to view at 100%
> scaling).
> I'll add a pull request to fix this in the most visible places, which is
> borders used in the NetBeans tab control. There are similar problems in other
> Swing components, e.g. JTextField, but that would have to be reported as a
> bug against the JDK's Windows LAF.
> This issue/PR relates only to the Windows LAF. On MacOS, the problem does not
> appear, since only an integral scaling factor (2x) is used for HiDPI
> ("retina") screens, which avoids the underlying rounding errors.
> A similar problem may also appear on Linux; if this is the case, feel free to
> open a new ticket. I did not have a Linux machine to test on, so I prepared
> this patch for the Windows LAF only.
--
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
[jira] [Updated] (NETBEANS-2646) Improve border appearances with fractional HiDPI scaling factors (Windows LAF)
[ https://issues.apache.org/jira/browse/NETBEANS-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-2646: -- Summary: Improve border appearances with fractional HiDPI scaling factors (Windows LAF) (was: Improve border appearances with fractional HiDPI scaling factors) > Improve border appearances with fractional HiDPI scaling factors (Windows LAF) > -- > > Key: NETBEANS-2646 > URL: https://issues.apache.org/jira/browse/NETBEANS-2646 > Project: NetBeans > Issue Type: Improvement > Components: platform - Window System >Affects Versions: 11.0 > Environment: Windows 10 with HiDPI monitor in fractional scaling mode > (e.g. 150%), Java 9 and above >Reporter: Eirik Bakke >Assignee: Eirik Bakke >Priority: Major > Labels: HiDPI > Attachments: BordersAfterPatch.png, BordersBeforePatch.png > > > On Windows 10 systems with HiDPI monitors, it is possible to specify > fractional DPI scaling factors, such as 150%. Some of the borders around > components visible in the main NetBeans window end up looking ugly on this > setting, because of rounding errors that cause a border 1 logical pixels wide > to be painted as either 1 or 2 device pixels wide, depending on exactly where > on the screen the border is drawn. This can be seen on Windows 10 with a 150% > DPI scaling factor, by dragging the split pane between the "Projects" tab and > the source code editor back and forth, and observing spurious changes in the > surrounding borders. See the attached screenshots (be sure to view at 100% > scaling). > I'll add a pull request to fix this in the most visible places, which is > borders used in the NetBeans tab control. There are similar problems in other > Swing components, e.g. JTextField, but that would have to be reported as a > bug against the JDK's Windows LAF. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-2646) Improve border appearances with fractional HiDPI scaling factors
[ https://issues.apache.org/jira/browse/NETBEANS-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-2646: -- Attachment: BordersBeforePatch.png > Improve border appearances with fractional HiDPI scaling factors > > > Key: NETBEANS-2646 > URL: https://issues.apache.org/jira/browse/NETBEANS-2646 > Project: NetBeans > Issue Type: Improvement > Components: platform - Window System >Affects Versions: 11.0 > Environment: Windows 10 with HiDPI monitor in fractional scaling mode > (e.g. 150%), Java 9 and above >Reporter: Eirik Bakke >Assignee: Eirik Bakke >Priority: Major > Labels: HiDPI > Attachments: BordersAfterPatch.png, BordersBeforePatch.png > > > On Windows 10 systems with HiDPI monitors, it is possible to specify > fractional DPI scaling factors, such as 150%. Some of the borders around > components visible in the main NetBeans window end up looking ugly on this > setting, because of rounding errors that cause a border 1 logical pixels wide > to be painted as either 1 or 2 device pixels wide, depending on exactly where > on the screen the border is drawn. This can be seen on Windows 10 with a 150% > DPI scaling factor, by dragging the split pane between the "Projects" tab and > the source code editor back and forth, and observing spurious changes in the > surrounding borders. See the attached screenshot. > I'll add a pull request to fix this in the most visible places, which is > borders used in the NetBeans tab control. There are similar problems in other > Swing components, e.g. JTextField, but that would have to be reported as a > bug against the JDK's Windows LAF. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-2646) Improve border appearances with fractional HiDPI scaling factors
[ https://issues.apache.org/jira/browse/NETBEANS-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-2646: -- Attachment: BordersAfterPatch.png > Improve border appearances with fractional HiDPI scaling factors > > > Key: NETBEANS-2646 > URL: https://issues.apache.org/jira/browse/NETBEANS-2646 > Project: NetBeans > Issue Type: Improvement > Components: platform - Window System >Affects Versions: 11.0 > Environment: Windows 10 with HiDPI monitor in fractional scaling mode > (e.g. 150%), Java 9 and above >Reporter: Eirik Bakke >Assignee: Eirik Bakke >Priority: Major > Labels: HiDPI > Attachments: BordersAfterPatch.png, BordersBeforePatch.png > > > On Windows 10 systems with HiDPI monitors, it is possible to specify > fractional DPI scaling factors, such as 150%. Some of the borders around > components visible in the main NetBeans window end up looking ugly on this > setting, because of rounding errors that cause a border 1 logical pixels wide > to be painted as either 1 or 2 device pixels wide, depending on exactly where > on the screen the border is drawn. This can be seen on Windows 10 with a 150% > DPI scaling factor, by dragging the split pane between the "Projects" tab and > the source code editor back and forth, and observing spurious changes in the > surrounding borders. See the attached screenshot. > I'll add a pull request to fix this in the most visible places, which is > borders used in the NetBeans tab control. There are similar problems in other > Swing components, e.g. JTextField, but that would have to be reported as a > bug against the JDK's Windows LAF. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-2646) Improve border appearances with fractional HiDPI scaling factors
[ https://issues.apache.org/jira/browse/NETBEANS-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-2646: -- Description: On Windows 10 systems with HiDPI monitors, it is possible to specify fractional DPI scaling factors, such as 150%. Some of the borders around components visible in the main NetBeans window end up looking ugly on this setting, because of rounding errors that cause a border 1 logical pixels wide to be painted as either 1 or 2 device pixels wide, depending on exactly where on the screen the border is drawn. This can be seen on Windows 10 with a 150% DPI scaling factor, by dragging the split pane between the "Projects" tab and the source code editor back and forth, and observing spurious changes in the surrounding borders. See the attached screenshots (be sure to view at 100% scaling). I'll add a pull request to fix this in the most visible places, which is borders used in the NetBeans tab control. There are similar problems in other Swing components, e.g. JTextField, but that would have to be reported as a bug against the JDK's Windows LAF. was: On Windows 10 systems with HiDPI monitors, it is possible to specify fractional DPI scaling factors, such as 150%. Some of the borders around components visible in the main NetBeans window end up looking ugly on this setting, because of rounding errors that cause a border 1 logical pixels wide to be painted as either 1 or 2 device pixels wide, depending on exactly where on the screen the border is drawn. This can be seen on Windows 10 with a 150% DPI scaling factor, by dragging the split pane between the "Projects" tab and the source code editor back and forth, and observing spurious changes in the surrounding borders. See the attached screenshot. I'll add a pull request to fix this in the most visible places, which is borders used in the NetBeans tab control. There are similar problems in other Swing components, e.g. JTextField, but that would have to be reported as a bug against the JDK's Windows LAF. > Improve border appearances with fractional HiDPI scaling factors > > > Key: NETBEANS-2646 > URL: https://issues.apache.org/jira/browse/NETBEANS-2646 > Project: NetBeans > Issue Type: Improvement > Components: platform - Window System >Affects Versions: 11.0 > Environment: Windows 10 with HiDPI monitor in fractional scaling mode > (e.g. 150%), Java 9 and above >Reporter: Eirik Bakke >Assignee: Eirik Bakke >Priority: Major > Labels: HiDPI > Attachments: BordersAfterPatch.png, BordersBeforePatch.png > > > On Windows 10 systems with HiDPI monitors, it is possible to specify > fractional DPI scaling factors, such as 150%. Some of the borders around > components visible in the main NetBeans window end up looking ugly on this > setting, because of rounding errors that cause a border 1 logical pixels wide > to be painted as either 1 or 2 device pixels wide, depending on exactly where > on the screen the border is drawn. This can be seen on Windows 10 with a 150% > DPI scaling factor, by dragging the split pane between the "Projects" tab and > the source code editor back and forth, and observing spurious changes in the > surrounding borders. See the attached screenshots (be sure to view at 100% > scaling). > I'll add a pull request to fix this in the most visible places, which is > borders used in the NetBeans tab control. There are similar problems in other > Swing components, e.g. JTextField, but that would have to be reported as a > bug against the JDK's Windows LAF. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Created] (NETBEANS-2646) Improve border appearances with fractional HiDPI scaling factors
Eirik Bakke created NETBEANS-2646: - Summary: Improve border appearances with fractional HiDPI scaling factors Key: NETBEANS-2646 URL: https://issues.apache.org/jira/browse/NETBEANS-2646 Project: NetBeans Issue Type: Improvement Components: platform - Window System Affects Versions: 11.0 Environment: Windows 10 with HiDPI monitor in fractional scaling mode (e.g. 150%), Java 9 and above Reporter: Eirik Bakke Assignee: Eirik Bakke On Windows 10 systems with HiDPI monitors, it is possible to specify fractional DPI scaling factors, such as 150%. Some of the borders around components visible in the main NetBeans window end up looking ugly on this setting, because of rounding errors that cause a border 1 logical pixels wide to be painted as either 1 or 2 device pixels wide, depending on exactly where on the screen the border is drawn. This can be seen on Windows 10 with a 150% DPI scaling factor, by dragging the split pane between the "Projects" tab and the source code editor back and forth, and observing spurious changes in the surrounding borders. See the attached screenshot. I'll add a pull request to fix this in the most visible places, which is borders used in the NetBeans tab control. There are similar problems in other Swing components, e.g. JTextField, but that would have to be reported as a bug against the JDK's Windows LAF. -- 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-2617) Redraw common icons in SVG
[ https://issues.apache.org/jira/browse/NETBEANS-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857757#comment-16857757 ] Eirik Bakke commented on NETBEANS-2617: --- Coordination note: nicktail is working on some of these icons (see https://twitter.com/nicktail/status/1136000863489495040 ). > Redraw common icons in SVG > -- > > Key: NETBEANS-2617 > URL: https://issues.apache.org/jira/browse/NETBEANS-2617 > Project: NetBeans > Issue Type: Improvement > Components: platform - Other >Affects Versions: 11.0 > Environment: Windows, Linux, and MacOS >Reporter: Eirik Bakke >Priority: Major > Labels: HiDPI > Attachments: netbeans_icons_illustrator_template.ai, style example.png > > > Once NETBEANS-2604 is done, we should start replacing commonly seen NetBeans > icons with SVG versions, for improved appearance on Retina/HiDPI displays. > With some practice, it takes on average 30 minutes to create an SVG version > of a typical icon in Adobe Illustrator. See the attached illustration and > Illustrator template. The Illustrator template includes a few icons which > have already been converted. > In NETBEANS-2605, the following prioritized list of icons to convert was > produced: > https://people.csail.mit.edu/ebakke/misc/netbeans-icons/prioritized.html > By redrawing the most commonly seen icons first, we can get the greatest > "bang for the buck" in terms of improving NetBeans' appearance on HiDPI > displays. Note that in cases where an icon file has been copied around to > various places in the NetBeans codebase, only one of the paths is shown in > the list above. > See also the overview page for HiDPI improvements on > https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements > . > h2. Proposed Style Guide for Vectorized Icons > * Vector icons should be drawn in Adobe Illustrator. Each icon should be one > named artboard, sized to the correct size in pixels. See the attached > Illustrator template. (Adobe Illustrator comes with a free 7-day trial, after > which it's $35/month. If cost is a problem but you want to contribute your > time to draw icons, ask Eirik...) > * For each icon to be vectorized, place the old bitmap version of the icon in > the "Old Bitmap Icons" layer in Illustrator. You can then draw the vectorized > version on top. > * Since most of the existing NetBeans icons follow a quite consistent visual > style, and to simplify the job of creating new icons, it is best to keep the > shape of the new vectorized icons the same as in the old bitmap icons. For > instance, a rectangle of size 5x4px in the bitmap icon should probably become > a rectangle of 5x4px in the vector version. > * Keep the same general colors in vectorized icons as in the corresponding > old bitmap icons. (The color scheme is not too hard to change later, but we > should do this only once most of the IDE icons have been vectorized.) > * If the old bitmap icon is complex, it is fine to simplify it a bit when > drawing vectorized versions. > * Omit gradients, bevels, and unnecessary drop shadows. They take more time > to draw, and with "flat design", they are now out of fashion in any case. > * Use a stroke width of 1px around the main shapes in the icon, like in the > existing bitmap icons. The new icons should look consistent with the existing > bitmap icons, especially since we may see bitmap icons and vector icons > side-by-side for a long time. Within shapes, 0.5px strokes can be used for > finer details. > * The 1px strokes that outline the icon's shapes should typically be 33% > transparent black on top of the shape's background color, or of similar > darkness. See the examples in the attached "style example.png" file. > * Horizontal and vertical strokes must be aligned to the pixel grid. > * While it may sometimes be necessary to "outline" strokes for the purposes > of applying boolean operations (e.g. subtracting another shape from the > stroke only), strokes should be left as strokes whenever possible, as this > leads to smaller SVG files, and makes shapes within the icon easier to modify. > * For toolbar icons, which exist in both 16x16 and 24x24 sizes, base the > vector version on the smaller 16x16 one, which is sometimes simpler. (This is > already done in the prioritized icon list above.) > If you wish to contribute to this effort, comment here; Eirik will coordinate > to make sure multiple people are not working on the same icons. -- 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
[jira] [Commented] (NETBEANS-2629) "Error Node" shown when using relative path in srcDir parameter
[
https://issues.apache.org/jira/browse/NETBEANS-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857744#comment-16857744
]
Laszlo Kishalmi commented on NETBEANS-2629:
---
However the proposed patch resolves the issue, it opens the gate for a series
of mishaps. This kind of project open the possibility to share java sourcefiles
between projects, which contradicts the NetBeans one source file, one project
paradigm. So NetBeans would be in trouble which classpath shall it associate
with the file when it is loaded into the editor.
So generally these kind of projects are bad practice.
> "Error Node" shown when using relative path in srcDir parameter
> ---
>
> Key: NETBEANS-2629
> URL: https://issues.apache.org/jira/browse/NETBEANS-2629
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Gradle
>Reporter: Lou Hamersly
>Assignee: Laszlo Kishalmi
>Priority: Major
> Labels: pull-request-available
> Attachments: Screenshot from 2019-06-02 14-18-24.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Error Node is displayed in Projects tab when using a relative path to a src
> folder. An absolute path doesn't work either.
> {code:java}
> sourceSets {
> main {
> java {
> srcDir 'src/main/java'
> srcDir '../jme3-bullet/src/common/java'
> }
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [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=16857594#comment-16857594
]
jmborer edited comment on NETBEANS-58 at 6/6/19 12:27 PM:
--
@phansson: do you plan to recompile your plugins for NB 11 and release them on
the plugin center?
The 8.2 plugins could have been compatible if they haven't been linked to
implementation version of certain modules. phansson had probably to do it to
get access to classes that are not publicly accessible otherwise.
I ran several times into similar issues with our NB platform based application.
I often regret that the exposure policy in NB is often more closed than open.
IMHO this over protects NB "internals" a little too much. I would have
preferred a policy based on greater openness and trust. This would have
greatly facilitate my life.
was (Author: jmborer):
@phansson: do you plan to recompile your plugins for NB 11 and release them on
the plugin center?
The 8.2 plugins could have been compatible if they haven't been linked to
implementation version of certain modules. phansson had probably to do it to
get access to classes that are not publicly accessible otherwise.
I ran several times into similar issues with our NB platform based application.
I often regret that the exposure policy is NB is more often closed than public.
IMHO this over protect NB "internals" a little too much. I would have preferred
a policy based on greater openness and trust. This would have greatly
facilitate my life.
> 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.
[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=16857594#comment-16857594
]
jmborer commented on NETBEANS-58:
-
@phansson: do you plan to recompile your plugins for NB 11 and release them on
the plugin center?
The 8.2 plugins could have been compatible if they haven't been linked to
implementation version of certain modules. phansson had probably to do it to
get access to classes that are not publicly accessible otherwise.
I ran several times into similar issues with our NB platform based application.
I often regret that the exposure policy is NB is more often closed than public.
IMHO this over protect NB "internals" a little too much. I would have preferred
a policy based on greater openness and trust.
> 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
>
[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=16857590#comment-16857590
]
Geertjan Wielenga commented on NETBEANS-58:
---
Well, there's no surprise about that -- the plugins you're using need to be
opened (i.e., the sources) in Apache NetBeans 11 and recompiled there. Then
you're able to install them.
> 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 actually virtually impossible to design an
> Authenticator which doesn't trigger this problem. You cannot predict when
> classloading is needed. In fact it is very likely to be needed when
> application is still not
[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=16857588#comment-16857588
]
Tilman Hausherr commented on NETBEANS-58:
-
I took the settings from my NB8 installation, so the start page wasn't shown.
But it frozed later, e.g. when searching for the latest plugins. Today I
managed to get it to work by using a local proxy that chains to my actual
proxy. That local proxy is a tool I've had for over a decade and I don't know
if I can install it on my next corporate pc.
So I tried again to install the two plugins but I can't, NB 11 still pops up a
dialog that requires "plugin Core" and "plugin JNA" and the "Next" button is
grey.
> 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
>
[jira] [Comment Edited] (NETBEANS-771) Support for SubVersion CLI client version 1.10
[
https://issues.apache.org/jira/browse/NETBEANS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857532#comment-16857532
]
Tilman Hausherr edited comment on NETBEANS-771 at 6/6/19 11:03 AM:
---
I see that bug (failing to parse "0-SlikSvn") was likely fixed in NETBEANS-1936
one month ago.
was (Author: tilman):
I see that bug (failing to parse "0-SlikSvn") was likely fixed in NETBEANS-1936
one months ago.
> Support for SubVersion CLI client version 1.10
> --
>
> Key: NETBEANS-771
> URL: https://issues.apache.org/jira/browse/NETBEANS-771
> Project: NetBeans
> Issue Type: Bug
> Components: versioncontrol - Subversion
>Affects Versions: 8.2, 9.0
>Reporter: Petr Hadraba
>Priority: Major
> Fix For: 9.0
>
> Attachments: org-netbeans-modules-subversion.jar,
> org-netbeans-modules-subversion.jar
>
>
> SubVersion CLI client version 1.10 does not work in NetBeans 9.0.
> The following message appears in NetBeans log when invoking refresh in
> SubVersion panel:
> {{ INFO [org.netbeans.modules.subversion]: Commandline client version: 1.10.0
> (r1827917)}}
> {{ WARNING [org.netbeans.modules.subversion]: Unsupported svn version. You
> need >= 1.5}}
> {{ WARNING [org.netbeans.modules.subversion.client.SvnClientFactory]:
> executable binary path set to /opt/local/bin yet client not available.}}
> The dialog box appears and says:
>
> {{1. Download and Install Subversion 1.8 or later
> ([http://subversion.apache.org/packages.html]). }}
> \{{ 2. Add it to PATH. }}
> \{{ Test the installation by running 'svn --version' from a command line }}
> \{{ 3. Restart the IDE.}}
> My SubVersion is the latest version:
> {\{ localhost:~ petr$ which svn}}
> \{{ /opt/local/bin/svn}}
> \{{ localhost:~ petr$ svn --version}}
> \{{ svn, version 1.10.0 (r1827917)}}
> \{{ compiled Apr 18 2018, 01:35:41 on x86_64-apple-darwin17.4.0}}
> \{{ }}
> \{{ Copyright (C) 2018 The Apache Software Foundation.}}
> \{{ This software consists of contributions made by many people;}}
> \{{ see the NOTICE file for more information.}}
> {{ Subversion is open source software, see [http://subversion.apache.org/]}}
> \{{ }}
> \{{ The following repository access (RA) modules are available:}}
> \{{ }}
> * {{ra_svn : Module for accessing a repository using the svn network
> protocol.}}{\{ - with Cyrus SASL authentication}}\{{ - handles 'svn'
> scheme}}
> * {{ra_local : Module for accessing a repository on local disk.}}{\{ -
> handles 'file' scheme}}
> * {{ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.}}{\{ - using serf 1.3.9 (compiled with 1.3.8)}}\{{ - handles 'http'
> scheme}}\{{ - handles 'https' scheme}}\{{ }}\{{ The following
> authentication credential caches are available:}}\{{ }}
> * {{Plaintext cache in /Users/petr/.subversion}}
> * {{GPG-Agent}}
> * {{Mac OS X Keychain}}
--
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-771) Support for SubVersion CLI client version 1.10
[
https://issues.apache.org/jira/browse/NETBEANS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857532#comment-16857532
]
Tilman Hausherr commented on NETBEANS-771:
--
I see that bug (failing to parse "0-SlikSvn") was likely fixed in NETBEANS-1936.
> Support for SubVersion CLI client version 1.10
> --
>
> Key: NETBEANS-771
> URL: https://issues.apache.org/jira/browse/NETBEANS-771
> Project: NetBeans
> Issue Type: Bug
> Components: versioncontrol - Subversion
>Affects Versions: 8.2, 9.0
>Reporter: Petr Hadraba
>Priority: Major
> Fix For: 9.0
>
> Attachments: org-netbeans-modules-subversion.jar,
> org-netbeans-modules-subversion.jar
>
>
> SubVersion CLI client version 1.10 does not work in NetBeans 9.0.
> The following message appears in NetBeans log when invoking refresh in
> SubVersion panel:
> {{ INFO [org.netbeans.modules.subversion]: Commandline client version: 1.10.0
> (r1827917)}}
> {{ WARNING [org.netbeans.modules.subversion]: Unsupported svn version. You
> need >= 1.5}}
> {{ WARNING [org.netbeans.modules.subversion.client.SvnClientFactory]:
> executable binary path set to /opt/local/bin yet client not available.}}
> The dialog box appears and says:
>
> {{1. Download and Install Subversion 1.8 or later
> ([http://subversion.apache.org/packages.html]). }}
> \{{ 2. Add it to PATH. }}
> \{{ Test the installation by running 'svn --version' from a command line }}
> \{{ 3. Restart the IDE.}}
> My SubVersion is the latest version:
> {\{ localhost:~ petr$ which svn}}
> \{{ /opt/local/bin/svn}}
> \{{ localhost:~ petr$ svn --version}}
> \{{ svn, version 1.10.0 (r1827917)}}
> \{{ compiled Apr 18 2018, 01:35:41 on x86_64-apple-darwin17.4.0}}
> \{{ }}
> \{{ Copyright (C) 2018 The Apache Software Foundation.}}
> \{{ This software consists of contributions made by many people;}}
> \{{ see the NOTICE file for more information.}}
> {{ Subversion is open source software, see [http://subversion.apache.org/]}}
> \{{ }}
> \{{ The following repository access (RA) modules are available:}}
> \{{ }}
> * {{ra_svn : Module for accessing a repository using the svn network
> protocol.}}{\{ - with Cyrus SASL authentication}}\{{ - handles 'svn'
> scheme}}
> * {{ra_local : Module for accessing a repository on local disk.}}{\{ -
> handles 'file' scheme}}
> * {{ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.}}{\{ - using serf 1.3.9 (compiled with 1.3.8)}}\{{ - handles 'http'
> scheme}}\{{ - handles 'https' scheme}}\{{ }}\{{ The following
> authentication credential caches are available:}}\{{ }}
> * {{Plaintext cache in /Users/petr/.subversion}}
> * {{GPG-Agent}}
> * {{Mac OS X Keychain}}
--
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-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=16857508#comment-16857508
]
jmborer edited comment on NETBEANS-58 at 6/6/19 10:54 AM:
--
Not sure to understand how the PR is solving the issue. First, it seems to
partly solve it by providing SPI for custom Authenticator and secondly I don't
understand in which state the PR currently is.
was (Author: jmborer):
Not sure to understand how the PR is solving the issue. Fist, it seems to
partly solve it by providing SPI for custom Authenticator and secondly I don't
understand in which state the PR currently is.
> 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
[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=16857509#comment-16857509
]
Geertjan Wielenga commented on NETBEANS-58:
---
I know, it's become quite confusing. :-)
> 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 actually virtually impossible to design an
> Authenticator which doesn't trigger this problem. You cannot predict when
> classloading is needed. In fact it is very likely to be needed when
> application is still not "warm", i.e. during startup.
> h3. WORKAROUNDS
> *#1*
> If on Windows: Setting the following registry key:
>
[jira] [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=16857508#comment-16857508
]
jmborer commented on NETBEANS-58:
-
Not sure to understand how the PR is solving the issue. Fist, it seems to
partly solve it by providing SPI for custom Authenticator and secondly I don't
understand in which state the PR currently is.
> 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 actually virtually impossible to design an
> Authenticator which doesn't trigger this problem. You cannot predict when
> classloading is needed. In fact it is very likely to be needed when
> application is still not
[jira] [Updated] (NETBEANS-2645) Getting a NPE when pasting code (which needs new imports) from one class to another
[ https://issues.apache.org/jira/browse/NETBEANS-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihai Sandu updated NETBEANS-2645: -- Environment: Netbeans 11.0 running on openjdk 10, all running in Ubuntu Linux 18.04.2 LTS (Bionic Beaver) x86-64 $ java -version openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime Environment 18.3 (build 10.0.2+13) OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) was: Netbeans 11.0 running on openjdk 10 $ java -version openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime Environment 18.3 (build 10.0.2+13) OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) > Getting a NPE when pasting code (which needs new imports) from one class to > another > --- > > Key: NETBEANS-2645 > URL: https://issues.apache.org/jira/browse/NETBEANS-2645 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.0 > Environment: Netbeans 11.0 running on openjdk 10, all running in > Ubuntu Linux 18.04.2 LTS (Bionic Beaver) x86-64 > $ java -version > openjdk version "10.0.2" 2018-07-17 > OpenJDK Runtime Environment 18.3 (build 10.0.2+13) > OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) >Reporter: Mihai Sandu >Priority: Major > Attachments: Screenshot_20190606_122239.png, messages.log > > > When doing copy/paste of code from one class to another, then the automatic > importing (of needed classes/methods) don't work and a NPE occurs. > The import dialog remains in a stale state and has to be closed manually. > Please see the attached screenshot and the message log. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-2645) Getting a NPE when pasting code (which needs new imports) from one class to another
[ https://issues.apache.org/jira/browse/NETBEANS-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihai Sandu updated NETBEANS-2645: -- Environment: Netbeans 11.0 running on openjdk 10.0.2, all running in Ubuntu Linux 18.04.2 LTS (Bionic Beaver) x86-64 $ java -version openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime Environment 18.3 (build 10.0.2+13) OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) was: Netbeans 11.0 running on openjdk 10, all running in Ubuntu Linux 18.04.2 LTS (Bionic Beaver) x86-64 $ java -version openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime Environment 18.3 (build 10.0.2+13) OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) > Getting a NPE when pasting code (which needs new imports) from one class to > another > --- > > Key: NETBEANS-2645 > URL: https://issues.apache.org/jira/browse/NETBEANS-2645 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.0 > Environment: Netbeans 11.0 running on openjdk 10.0.2, all running in > Ubuntu Linux 18.04.2 LTS (Bionic Beaver) x86-64 > $ java -version > openjdk version "10.0.2" 2018-07-17 > OpenJDK Runtime Environment 18.3 (build 10.0.2+13) > OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) >Reporter: Mihai Sandu >Priority: Major > Attachments: Screenshot_20190606_122239.png, messages.log > > > When doing copy/paste of code from one class to another, then the automatic > importing (of needed classes/methods) don't work and a NPE occurs. > The import dialog remains in a stale state and has to be closed manually. > Please see the attached screenshot and the message log. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Created] (NETBEANS-2645) Getting a NPE when pasting code (which needs new imports) from one class to another
Mihai Sandu created NETBEANS-2645: - Summary: Getting a NPE when pasting code (which needs new imports) from one class to another Key: NETBEANS-2645 URL: https://issues.apache.org/jira/browse/NETBEANS-2645 Project: NetBeans Issue Type: Bug Affects Versions: 11.0 Environment: Netbeans 11.0 running on openjdk 10 $ java -version openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime Environment 18.3 (build 10.0.2+13) OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) Reporter: Mihai Sandu Attachments: Screenshot_20190606_122239.png, messages.log When doing copy/paste of code from one class to another, then the automatic importing (of needed classes/methods) don't work and a NPE occurs. The import dialog remains in a stale state and has to be closed manually. Please see the attached screenshot and the message log. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857444#comment-16857444
]
Geertjan Wielenga commented on NETBEANS-58:
---
Seems to be connected to this, i.e., would this solve it for you:
https://github.com/apache/netbeans/pull/2
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 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 actually virtually impossible to design an
> Authenticator which doesn't trigger this problem. You cannot predict when
> classloading is needed. In fact it is very likely to be needed when
> application is still not "warm", i.e. during startup.
> h3. WORKAROUNDS
> *#1*
> If on Windows: Setting
[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=16857441#comment-16857441
]
jmborer commented on NETBEANS-58:
-
It seems there is some left over and cleanup to do in the start page, but if we
get back to our freeze issue, I wonder why requests from the start page and
requests to the plugin center(s) are made even thought the start page is not
shown.
The IDE freeze is really occurring for any network request that is made no
matter which module is triggering it.
> 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 actually virtually impossible to design an
> Authenticator which
[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=16857437#comment-16857437
]
jmborer edited comment on NETBEANS-58 at 6/6/19 8:48 AM:
-
May be it is a left over when I migrated my preferences from 8.2 to 11.0
I disabled the 8.2 plugins portal as well now.
I opened up again the start page and can observe queries to
[http://www.netbeans.org/news.xml]
Isn't it the RSS feed?
When you navigate the start page it triggers as well GET to
http://netbeans.org/demos.xml
was (Author: jmborer):
May be it is a left over when I migrated my preferences from 8.2 to 11.0
I disabled the 8.2 plugins portal as well now.
I opened up again the start page and can observe queries to
[http://www.netbeans.org/news.xml]
Isn't it the RSS feed?
> 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
[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=16857438#comment-16857438
]
Geertjan Wielenga commented on NETBEANS-58:
---
Yes, but it shouldn't be needed anymore, just point here instead, i.e., at
netbeans.apache.org:
https://blogs.apache.org/netbeans/
> 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 actually virtually impossible to design an
> Authenticator which doesn't trigger this problem. You cannot predict when
> classloading is needed. In fact it is very likely to be needed when
> application is still not "warm", i.e. during startup.
> h3. WORKAROUNDS
> *#1*
[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=16857437#comment-16857437
]
jmborer commented on NETBEANS-58:
-
May be it is a left over when I migrated my preferences from 8.2 to 11.0
I disabled the 8.2 plugins portal as well now.
I opened up again the start page and can observe queries to
[http://www.netbeans.org/news.xml]
Isn't it the RSS feed?
> 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 actually virtually impossible to design an
> Authenticator which doesn't trigger this problem. You cannot predict when
> classloading is needed. In fact it is very likely to be
[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=16857436#comment-16857436
]
Geertjan Wielenga commented on NETBEANS-58:
---
Well, those two links are not relevant in any way in the context of Apache, if
you can find where they are in the Apache NetBeans GitHub, provide a pull
request replacing those links with something on netbeans.apache.org.
> 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 actually virtually impossible to design an
> Authenticator which doesn't trigger this problem. You cannot predict when
> classloading is needed. In fact it is very likely to be
[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=16857431#comment-16857431 ] jmborer edited comment on NETBEANS-58 at 6/6/19 8:40 AM: - Hmm. That is a very good question. I don't know if Tilman Hausherr is running into this issue because of the start page or if it is related to other network requests. The start page is just another trigger for network requests. For example, when I start my IDE where the start page is already disabled (unchecked "show on startup") and no projects open, NB still triggers network requests to: [http://www.netbeans.org/news.xml] [http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a] These request can lead to the deadlock of the IDE. When I open some of my projects the IDE triggers calls to: [ http://netbeans-vm.apache.org/uc/11.0/updates.xml.gz?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a_90e7342f-955b-4cc6-8e15-39e4810b37c2|http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml.gz] [http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml.gz] [https://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz] Not sure why opening projects trigger check of update center. What is particularly annoying with this issue is its unpredictability. It can bite you or not. For example our new very faster PCs with SSDs are more likely (not to say systematically) to run into this issue where my older machine seems not to be affected. This is pure luck. was (Author: jmborer): Hmm. That is a very good question. I don't know if Tilman Hausherr is running into this issue because of the start page or if it is related to other network requests. The start page is just another trigger for network requests. For example, when I start my IDE where the start page is already disabled (unchecked "show on startup") and no projects open, NB still triggers network requests to: [http://www.netbeans.org/news.xml] [http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a] These request can lead to the deadlock of the IDE. When I open some of my projects the IDE triggers calls to: [http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml.gz] https://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz Not sure why opening projects trigger check of update center. What is particularly annoying with this issue is its unpredictability. It can bite you or not. For example our new very faster PCs with SSDs are more likely (not to say systematically) to run into this issue where my older machine seems not to be affected. This is pure luck. > 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
[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=16857431#comment-16857431 ] jmborer edited comment on NETBEANS-58 at 6/6/19 8:38 AM: - Hmm. That is a very good question. I don't know if Tilman Hausherr is running into this issue because of the start page or if it is related to other network requests. The start page is just another trigger for network requests. For example, when I start my IDE where the start page is already disabled (unchecked "show on startup") and no projects open, NB still triggers network requests to: [http://www.netbeans.org/news.xml] [http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a] These request can lead to the deadlock of the IDE. When I open some of my projects the IDE triggers calls to: [http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml.gz] https://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz Not sure why opening projects trigger check of update center. What is particularly annoying with this issue is its unpredictability. It can bite you or not. For example our new very faster PCs with SSDs are more likely (not to say systematically) to run into this issue where my older machine seems not to be affected. This is pure luck. was (Author: jmborer): Hmm. That is a very good question. I don't know if Tilman Hausherr is running into this issue because of the start page or if it is related to other network requests. The start page is just another trigger for network requests. For example, when I start my IDE where the start page is already disabled (unchecked "show on startup") and no projects open, NB still triggers network requests to: http://www.netbeans.org/news.xml [http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a] These request can lead to the deadlock of the IDE. What is particularly annoying with this issue is its unpredictability. It can bite you or not. For example our new very faster PCs with SSDs are more likely (not to say systematically) to run into this issue where my older machine seems not to be affected. This is pure luck. > 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.
[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=16857431#comment-16857431
]
jmborer commented on NETBEANS-58:
-
Hmm. That is a very good question. I don't know if Tilman Hausherr is running
into this issue because of the start page or if it is related to other network
requests.
The start page is just another trigger for network requests.
For example, when I start my IDE where the start page is already disabled
(unchecked "show on startup") and no projects open, NB still triggers network
requests to:
http://www.netbeans.org/news.xml
[http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a]
These request can lead to the deadlock of the IDE.
What is particularly annoying with this issue is its unpredictability. It can
bite you or not. For example our new very faster PCs with SSDs are more likely
(not to say systematically) to run into this issue where my older machine seems
not to be affected. This is pure luck.
> 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)
[jira] [Comment Edited] (NETBEANS-1428) Fatal error when profiling
[
https://issues.apache.org/jira/browse/NETBEANS-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857417#comment-16857417
]
Yaytay edited comment on NETBEANS-1428 at 6/6/19 8:24 AM:
--
Also tested with DLL from
[https://github.com/pedro-w/incubator-netbeans/releases/tag/v0.1-alpha] and it
works for:
* Oracle JDK 12
* Azul Zulu JDK 12
Please get this fixed in the next netbeans release.
And thank you [~peterhull90]
was (Author: yaytay):
Also tested with DLL from
[https://github.com/pedro-w/incubator-netbeans/releases/tag/v0.1-alpha] and it
works for:
* Oracle JDK 12
* Azul Zulu JDK 12
Please get this fixed in the next netbeans release.
> Fatal error when profiling
> --
>
> Key: NETBEANS-1428
> URL: https://issues.apache.org/jira/browse/NETBEANS-1428
> Project: NetBeans
> Issue Type: Bug
> Components: profiler - Base
>Affects Versions: 9.0, 10.0
> Environment: Windows 10, JDK11 (OpenJDK 11.0+28)
>Reporter: Peter Hull
>Priority: Major
> Labels: netcat
> Attachments: hs_err_pid38528.log
>
>
> Attempting to profile a Java freeform project (Netcat 10, Profiling FreeForm,
> Step 2)
> I get the following error
> {{#}}
> {{# A fatal error has been detected by the Java Runtime Environment:}}
> {{#}}
> {{# EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7ff8e831c775,
> pid=38528, tid=38596}}
> {{#}}
> {{# JRE version: OpenJDK Runtime Environment (11.0+28) (build 11+28)}}
> {{# Java VM: OpenJDK 64-Bit Server VM (11+28, mixed mode, tiered, compressed
> oops, g1 gc, windows-amd64)}}
> {{# Problematic frame:}}
> {{# V [jvm.dll+0x5ec775]}}
> {{#}}
> {{# No core dump will be written. Minidumps are not enabled by default on
> client versions of Windows}}
> {{#}}
> {{# An error report file with more information is saved as:}}
> {{# D:\Libraries\Downloads\TS_Profiler_freeform\freeform\hs_err_pid38528.log}}
> {{#}}
> {{# If you would like to submit a bug report, please visit:}}
> {{# http://bugreport.java.com/bugreport/crash.jsp}}
> {{#}}
> Seems reproducible, I have attached the crash log.
--
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-1428) Fatal error when profiling
[
https://issues.apache.org/jira/browse/NETBEANS-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857417#comment-16857417
]
Yaytay commented on NETBEANS-1428:
--
Also tested with DLL from
[https://github.com/pedro-w/incubator-netbeans/releases/tag/v0.1-alpha] and it
works for:
* Oracle JDK 12
* Azul Zulu JDK 12
Please get this fixed in the next netbeans release.
> Fatal error when profiling
> --
>
> Key: NETBEANS-1428
> URL: https://issues.apache.org/jira/browse/NETBEANS-1428
> Project: NetBeans
> Issue Type: Bug
> Components: profiler - Base
>Affects Versions: 9.0, 10.0
> Environment: Windows 10, JDK11 (OpenJDK 11.0+28)
>Reporter: Peter Hull
>Priority: Major
> Labels: netcat
> Attachments: hs_err_pid38528.log
>
>
> Attempting to profile a Java freeform project (Netcat 10, Profiling FreeForm,
> Step 2)
> I get the following error
> {{#}}
> {{# A fatal error has been detected by the Java Runtime Environment:}}
> {{#}}
> {{# EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7ff8e831c775,
> pid=38528, tid=38596}}
> {{#}}
> {{# JRE version: OpenJDK Runtime Environment (11.0+28) (build 11+28)}}
> {{# Java VM: OpenJDK 64-Bit Server VM (11+28, mixed mode, tiered, compressed
> oops, g1 gc, windows-amd64)}}
> {{# Problematic frame:}}
> {{# V [jvm.dll+0x5ec775]}}
> {{#}}
> {{# No core dump will be written. Minidumps are not enabled by default on
> client versions of Windows}}
> {{#}}
> {{# An error report file with more information is saved as:}}
> {{# D:\Libraries\Downloads\TS_Profiler_freeform\freeform\hs_err_pid38528.log}}
> {{#}}
> {{# If you would like to submit a bug report, please visit:}}
> {{# http://bugreport.java.com/bugreport/crash.jsp}}
> {{#}}
> Seems reproducible, I have attached the crash log.
--
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-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=16857412#comment-16857412
]
Geertjan Wielenga edited comment on NETBEANS-58 at 6/6/19 8:20 AM:
---
So, if there was a switch to cause the Welcome screen not to be shown at
startup or the module providing the Welcome screen to be disabled at startup,
that would solve this?
was (Author: geertjanwielenga):
So, if there was a switch to cause the Welcome screen not to be shown or the
module providing the Welcome screen to be disabled, that would solve this?
> 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.
[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=16857412#comment-16857412
]
Geertjan Wielenga commented on NETBEANS-58:
---
So, if there was a switch to cause the Welcome screen not to be shown or the
module providing the Welcome screen to be disabled, that would solve this?
> 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 actually virtually impossible to design an
> Authenticator which doesn't trigger this problem. You cannot predict when
> classloading is needed. In fact it is very likely to be needed when
> application is still not "warm", i.e. during startup.
>
[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=16857390#comment-16857390
]
jmborer edited comment on NETBEANS-58 at 6/6/19 8:11 AM:
-
I confirm that this still happens with NB 11.
As I said before, not the best advertisement for NB when you try to convince
people to adopt it.
When you install NB, it will by default open the welcome "start" page which
triggers network requests.
was (Author: jmborer):
I confirm that this still happens with NB 11.
I find this really an important issue. When it bites you (my colleagues for
example), it is not the best user experience you can expect from such an
amazing IDE. My colleagues were quite upset and immediately thought to change
their IDE for an alternative. Hopefully this only happens in specific working
environment, but still, not the best promotion for NB...
When you install NB, it will by default open the welcome "start" page which
triggers network requests. I still don't understand why this issue can't be
fixed in NB. If I remember well when I hunted down the issue, it is the
asynchronous request to the Keyring with another thread that deadlock each
other...
> 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
[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=16857390#comment-16857390
]
jmborer commented on NETBEANS-58:
-
I confirme that this still happens with NB 11.
I find this really an important issue. When it bites you (my colleagues for
example), it is not the best user experience you can expect from such an
amazing IDE. My colleagues were quite upset and immediately thought to change
their IDE for an alternative. Hopefully this only happens in specific working
environment, but still, not the best promotion for NB...
When you install NB, it will by default open the welcome "start" page which
triggers network requests. I still don't understand why this issue can't be
fixed in NB. If I remember well when I hunted down the issue, it is the
asynchronous request to the Keyring with another thread that deadlock each
other...
> 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,
[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=16857390#comment-16857390
]
jmborer edited comment on NETBEANS-58 at 6/6/19 7:58 AM:
-
I confirm that this still happens with NB 11.
I find this really an important issue. When it bites you (my colleagues for
example), it is not the best user experience you can expect from such an
amazing IDE. My colleagues were quite upset and immediately thought to change
their IDE for an alternative. Hopefully this only happens in specific working
environment, but still, not the best promotion for NB...
When you install NB, it will by default open the welcome "start" page which
triggers network requests. I still don't understand why this issue can't be
fixed in NB. If I remember well when I hunted down the issue, it is the
asynchronous request to the Keyring with another thread that deadlock each
other...
was (Author: jmborer):
I confirme that this still happens with NB 11.
I find this really an important issue. When it bites you (my colleagues for
example), it is not the best user experience you can expect from such an
amazing IDE. My colleagues were quite upset and immediately thought to change
their IDE for an alternative. Hopefully this only happens in specific working
environment, but still, not the best promotion for NB...
When you install NB, it will by default open the welcome "start" page which
triggers network requests. I still don't understand why this issue can't be
fixed in NB. If I remember well when I hunted down the issue, it is the
asynchronous request to the Keyring with another thread that deadlock each
other...
> 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] [Assigned] (NETBEANS-2637) IllegalStateException in RequestProcessor after duplicate install attempt of nbjavac Library [1.6] on message request
[ https://issues.apache.org/jira/browse/NETBEANS-2637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul deauna reassigned NETBEANS-2637: - Assignee: paul deauna (was: Jan Lahoda) > IllegalStateException in RequestProcessor after duplicate install attempt of > nbjavac Library [1.6] on message request > - > > Key: NETBEANS-2637 > URL: https://issues.apache.org/jira/browse/NETBEANS-2637 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.0 >Reporter: Bernard >Assignee: paul deauna >Priority: Blocker > Attachments: messages.log, messages.log, uigestures > > > As part of the discovery of NETBEANS-1824, I gradually built up the IDE > state, adding project after project (14) with some re-starts in between to > get clean log files for inspection. I selected the projects to be simple, and > I verified before with the maven graph viewer that they did not contain the > problematic lombok dependency. In the latest iteration, at a new re-start, > without me doing anything, a NullPointerException occurred (also logged as > message but later disappeared from the message queue) and a message prompt to > install nbjavac Library. I first saved the log to get the NPE and then I > followed the prompt. "The following plugins will be installed: > nbjavac Library [1.6]." This failed with the latest exception which makes > sense because it would have been already installed by the initial > installation and updates. So the 2nd question is what lets the IDE decide to > make this wrong decision? And the 1st question is what is this > NullPointerException that occurs at this iteration where the number of > projects is less than in a different installation of the same version with > the lombok bug present. -- 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
