Re: Request for comment: merging the openjdk client groups ?

Am Mittwoch, den 18.02.2015 um 16:06 -0800 schrieb Phil Race: > There have been brief internal exchanges every now and again for some > substantial period > of time (18 months at least) as to whether we should consolidate the > various JDK client groups > in openjdk. The client groups are conside

Re: Is the following code supposed to leak?

Speaking of boundaries, 2 points I would like to add: - We don't bend the Java specs to prevent System.exit() from exiting, we only install a SecurityManager. That is natural, because I don't want users of the demos to mess with my server. For example, if you open a file dialog in the demo, withou

Re: Is the following code supposed to leak?

Hi all, > > The vm doesn't terminate. > > > > One VM to rule them all: the instances are separated via the > > appcontext, but there is just one server vm running. > I'm not sure that's correct behavior. According to javadoc of > java.lang.System#exit: "Terminates the currently running Java Virtu

Re: Is the following code supposed to leak?

Hi Clemens, Am Samstag, den 20.08.2011, 11:54 +0200 schrieb Clemens Eisserer: > Hi Roman, > > You keep creating and adding new listeners without ever > removing them. > Of course this is going to leak. > > What makes me wonder, I add the listeners to an Action from a new

Re: Is the following code supposed to leak?

Hi Clemens, > When running the Notepad-Demo shipped with the JDK on > caciocavallo-web, I noticed memory leaks caused by > PropertyChangeListeners added to Actions defined in DefaultEditorKit. > Those actions are referenced by a static field (defaultActions). > > I was able to distill the problem

Re: Ways to cancel SwingWorker running task

Hi Xmly, > After running some tests with JDK6.0, I find Thread.stop can terminate > the thread even if it's uninterruptible(ThreadDeath exception on the > running thread stack). Seems some statements in the article are > obsolete now? No they're not. There are very good reasons to try and avoid T

Re: Ways to cancel SwingWorker running task

Hi, > Can I use Thread.stop() to cancel a SwingWorker running task forcely? > Though the stop method is documented as deprecated in JDK doc. My > thought is, first store the thread in doInBackground, then force stop > the thread by invoking thread.stop() later. > > The purpose is to guarantee t

Re: CSS$LengthUnit not found when running with my own AWT implementation

Hi Clemens, > I am working on a Caciocavallo-based AWT implementation which > (hopefully) will allow to run Swing-Applications server-side but > re-direct rendering/events to a Canvas5 capable browser. > > However I have troubles with Swing elements which contain HTML, > initiating those widgets

Re: Text rendering/layout problem in Swing

> For multiline text components this needs to be fm.getAscent() + numLines > * fm.getHeight() + fm.getDescent(). That should have been fm.getAscent() + (numLines - 1) * fm.getHeight() + fm.getDescent() instead. /Roman

Text rendering/layout problem in Swing

While hunting a bug in the Freetype Fontscaler, I came over an issue in the way Swing lays out and renders text. In many (if not all) cases in Swing, FontMetrics.getHeight() is used to lay out text inside a text component or label. For example, in PlainView, we use numberOfLines * fm.getHeight() t

Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional

Hi, > and don't like the idea of being able to disable Nimbus > because of this dependency. Too many negations and ablebables for my parser... Oops. ;-) /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated S

Re: Swing Group Status?

e > with the community or just as needed and time allows? > > It would be great if we could speed up things a bit! > > -Florian > -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-S

Re: [PATCH] DefaultDesktopPane fix

d to check if the window is obscured and take action if it is (or if it cannot be determined) - just like we do in JViewport. > any other tests are also welcome > > It is always better to have a clear test case before fixing a problem Sure. Let's hope you can reproduce the problem wi

Re: [PATCH] DefaultDesktopPane fix

rg). But this behaviour is actually specified: <> This means we cannot rely on copyArea to copy pixels that are obscured by some other window, even if it works (more or less by good luck) on some system. And I think we do something similar already in JViewport. So it only makes sense to do

Re: [PATCH] DefaultDesktopPane fix

Hi there, no opinions on that? Should I file a bugreport instead? /Roman Am Mittwoch, den 14.01.2009, 14:54 +0100 schrieb Roman Kennke: > I found a problem in DefaultDesktopPane. Dragging in fast mode does not > work correctly (at least not on all platforms) if the pane is obscured > b

[PATCH] DefaultDesktopPane fix

ed in OpenJDK? /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 1

Problem in Swing Timer

} }); } } What do you think? /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel:

Re: [PATCH] Make RepaintManager more portable

t: > > > > 6759311: RepaintManager casts Tookit to SunToolkit without instanceof > > check > > Summary: Check type of Toolkit before casting. > > Reviewed-by: alexp > > > > If this is ok, then I'll push it to the gate ASAP. > > It's ok &g

Re: [PATCH] Make RepaintManager more portable

ing. Reviewed-by: alexp If this is ok, then I'll push it to the gate ASAP. Thanks and cheers, Roman > > alexp > > > > > /Roman > > > > Am Dienstag, den 16.09.2008, 10:54 +0200 schrieb Roman Kennke: > >> Hello, > >> > >> The a

Re: [PATCH] Make RepaintManager more portable

Hi there, how can we go about getting this patch into OpenJDK mainline? /Roman Am Dienstag, den 16.09.2008, 10:54 +0200 schrieb Roman Kennke: > Hello, > > The attached patch fixes two problems in RepaintManager. The first one > is a direct cast from Toolkit to SunToolkit, without

Re: [PATCH] Make RepaintManager more portable

No opinions? /Roman Am Dienstag, den 16.09.2008, 10:54 +0200 schrieb Roman Kennke: > Hello, > > The attached patch fixes two problems in RepaintManager. The first one > is a direct cast from Toolkit to SunToolkit, without checking for the > actual type, the second is using a Su

[PATCH] Make RepaintManager more portable

merged it into mainline. What do you think? /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id

Re: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay()

Hi, > Yep, I see. I didn't look at the file itself, only at the >patch, and got confused. Ok, what's next? Will the patch be included? /Roman > >Thanks, > Dmitri > > > Roman Kennke wrote: > > Hi Dmitri, > > > >>>

Re: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay()

Hi Dmitri, > > I need to repost my original patch for two reasons: 1. it doesn't apply > > cleanly (only with some fuzz), 2. it also has this init-loop problem. > > Find attached the correct version. I'd be happy to see it committed > > ASAP. > >I have a question about the fix: > --- a/src/so

Re: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay()

I need to repost my original patch for two reasons: 1. it doesn't apply cleanly (only with some fuzz), 2. it also has this init-loop problem. Find attached the correct version. I'd be happy to see it committed ASAP. /Roman Am Mittwoch, den 10.09.2008, 21:04 +0200 schrieb Roman Ke

Re: [OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay()

g. But that seems a little over the top right now. I also suggest to get the original patch through. /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany h

Re: [PATCH] SwingUtilities2.isLocalDisplay()

Bah, forgot the actual patch. Here it comes now! /Roman Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke: > Hi Oleg and lists, > > > >> I'm not the person who is supposed to review this changes from > > >> technical point of view, > > >&g

Re: [PATCH] SwingUtilities2.isLocalDisplay()

DisplayLocal(). We call it on X11GraphicsEnvironment only. In my original patch I tried to be more portable by calling GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but this resulted in an initialization loop (this code is very sensible to this kind of problem). I left that out for now, bec

Re: [PATCH] SwingUtilities2.isLocalDisplay()

ed several times to me that I can't just send in patches to public API and hope that it will be accepted easily. I propose to get in this patch if possible first, then start a discussion about adding public API. /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aica

[PATCH] SwingUtilities2.isLocalDisplay()

stance method in SGE. What do you think? Is this reasonable to merge into mainline? /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com *

Re: [PATCH] GrayFilter cache

Hi, > > I'm not a swing developer, but I'd suggest to not use static field for > > cache, but have per-AppContext cache instead (due to security reasons) > > Whoops. I have to get used to that .. Improved patch attached. No more opinions on that? Cheers, Roman

Re: [PATCH] GrayFilter cache

Hi Oleg, > I'm not a swing developer, but I'd suggest to not use static field for > cache, but have per-AppContext cache instead (due to security reasons) Whoops. I have to get used to that .. Improved patch attached. Cheers, Roman -- Dipl.-Inform. (FH) Roman Kennke, S

[PATCH] GrayFilter cache

representation or so). I would guess that nobody really does this, but what do I know? In this case, he would get the old gray image in return. What do you think about that, could this be included in OpenJDK? Cheers, Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas

Portable GUI backends

or tomorrow (in reply to the proposal, not this email please). Thanks alot and cheers, Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.c

Re: [PATCH] 6179357-related: Working on warnings removal

Hi Ismael, > Roman Kennke <[EMAIL PROTECTED]> writes: > > This isn't exactly correct. The equivalent of a ReferenceQueue in > > generics notation is ReferenceQueue. See: > > I don't think there's an exact equivalent, but if you take a List as an >

Re: [PATCH] 6179357-related: Working on warnings removal

Hi there, > 1. DesktopProperty: > Can You change declaration into > private final static ReferenceQueue queue = new > ReferenceQueue(); > (note that I added final and replaced HashMap by Map) and remove a > static section? This isn't exactly correct. The equivalent of a ReferenceQueue in gener

Re: GapContent behaviour

Hi Phil, Am Donnerstag, den 11.10.2007, 11:37 -0700 schrieb Phil Race: > Not my area but it sounds like a bug and yes, I believe > David Gilbert submitted this bug : > > http://bugs.sun.com/view_bug.do?bug_id=6463646 Well yes, he even answered to my original post :-) The question here is, if it'

Re: GapContent behaviour

Ping! Any opinion on this one? /Roman Am Donnerstag, den 27.09.2007, 21:01 +0200 schrieb Roman Kennke: > Hello, > > while implementing GapContent back then in GNU Classpath, I noticed that > the JDK implementation does not exactly conform to the specs in > AbstractDocument.Cont

Re: JViewport fixlet

Ping! Any opinion on this? /Roman Am Montag, den 24.09.2007, 12:47 +0200 schrieb Roman Kennke: > I just stumbled over this code in JViewport.setViewPosition(): > >if (view instanceof JComponent) { >JComponent c = (JComponent)view; >

GapContent behaviour

Hello, while implementing GapContent back then in GNU Classpath, I noticed that the JDK implementation does not exactly conform to the specs in AbstractDocument.Content. There, all the methods are specified to throw a BadLocationException for invalid locations. However, the GapContent doesn't thro

JViewport fixlet

; oldY = r.y; } I think this special casing is not necessary anymore since JDK1.2. Attached is a patch to correct this. Cheers, Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße

Re: [PATCH] 6463712: JSpinner forwards events from old model

Hi, > So just to let you know what is going on, when the bugfix has been > applied to a local workspace, we generate a "webrev" which shows the > revisions between the old and new files (a kind of diff, but with a > lot more ways to view the changes). This then gets sent to two or > more r

Re: [OpenJDK 2D-Dev] pluggable AWT peers/graphicsenv

ecide for yes). I know it's > possible to do and I am going to do this anyway, the question is as > part > of OpenJDK or not. One more thing. In order to keep the discussion sanely on one thread, I propose everybody answers on one list only, say awt-dev. /Roman -- Dipl.-Inform. (

pluggable AWT peers/graphicsenv

50.html [3] http://mail.openjdk.java.net/pipermail/awt-dev/2007-June/40.html Cheers, Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com