From james.graham at oracle.com Sat Feb 1 01:35:26 2014 From: james.graham at oracle.com (Jim Graham) Date: Fri, 31 Jan 2014 17:35:26 -0800 Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting In-Reply-To: <52EBB516.70906@oracle.com> References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com> <52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com> <52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com> <52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com> <52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com> <52B0F447.2020207@oracle.com> <52DE761E.2000201@oracle.com> <52E192F0.7010107@oracle.com> <52E27CDA.40703@oracle.com> <52E31866.3010508@oracle.com> <52E7CE5B.4070101@oracle.com> <52EAD304.2090809@oracle.com> <52EBB516.70906@oracle.com> Message-ID: <52EC4F5E.7060906@oracle.com> Hi Anton, On 1/31/14 6:37 AM, Anton V. Tarasov wrote: > My understanding is that, unless the fix is absolutely irrelevant (whic > I hope it isn't), we should integrate it into 9/8u20 to support > SwingNode in its current implementation on Retina displays. > > What do you think? I agree with this sentiment. My suggestion for reducing its footprint aside (which it looks like you are investigating), the main thing I will be looking for is whether or not we return an object to a developer (i.e. it isn't just managed internally to our own code) where they can do "instanceof BufferedImage" and then see something odd coming from its width/height. It looks like if we simply use getLayoutWH() internally then they would never ever see anything odd from getWidthHeight() anyway. The only additional "gotcha" would be if they grab the image and render it directly and it comes out an unexpected size to them (because, for instance, they didn't check the layout dims like we do internally). That's a pretty minor issue, though, and I think we could live with it. For 9.0 perhaps we could add the LayoutWH() as new API on BufferedImage and then most of this would be public? I'd have to mull over if that makes sense and I'm not entirely sure of the naming yet... ...jim From Alan.Bateman at oracle.com Sun Feb 2 11:51:46 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 02 Feb 2014 11:51:46 +0000 Subject: [OpenJDK 2D-Dev] Should changes to client libraries be pushed to jdk9/dev instead of jdk9/client In-Reply-To: <52EC35BF.60505@oracle.com> References: <52E40C2C.8070503@oracle.com> <52E4D5A4.4040104@oracle.com> <52EB67F2.7030800@oracle.com> <52EB754C.6040904@oracle.com> <52EC35BF.60505@oracle.com> Message-ID: <52EE3152.6020006@oracle.com> On 31/01/2014 23:46, Joseph Darcy wrote: > : > > Discussions are on going as to which forest client libraries fixes > should go into, the client forest (where closed-source deployment > changes happen to be going) or to the dev forest where all the other > libraries work is going; FWIW, I favor the latter. I would too but I assume it depends on whether the changes require any special pre-integration testing that would prohibit weekly or more frequent integrations into master. > > In any case, for all the forests which will be integrating into dev, > including the client and hotspot forests, the maintainers of those > forests are responsible for regularly pulling down changes from dev > and merging them in. In my estimation, unless there is a reason for > temporary isolation, the frequency of syncing with dev should be > closer to daily than weekly or monthly. The dev forest was open for > business on Dec. 13, 2013, and fixes started going into it that day. > From my reading of the JDK 9 master > (http://hg.openjdk.java.net/jdk9/jdk9/jdk/), the tag for jdk9-b01 was > added about three weeks ago. So if the first sync from dev into client > has only done in the last day or two, that would seem to be tardy to me. I assume that since this is a new structure that it will take time to get used to. While I'm not too concerned about jdk9/client being behind for a bit, I do wonder about the changes backing up in jdk9/client. I don't think there has been any client->dev push yet and some of the changes in jdk9/client were pushed in December. Hopefully that will be sorted out soon. > > The goal for dev is to have integrations into master no less than > weekly, but I'd like us to transition to having smaller and more > frequent integrations. We are laying the foundational work, cleaning > up intermittent test failures, etc. to allow that to happen. Indeed, and I expect that the test work will continue for a long time. -Alan. From suenaga.yasumasa at lab.ntt.co.jp Mon Feb 3 06:12:12 2014 From: suenaga.yasumasa at lab.ntt.co.jp (Yasumasa Suenaga) Date: Mon, 03 Feb 2014 15:12:12 +0900 Subject: [OpenJDK 2D-Dev] JDK-8017773: OpenJDK7 returns incorrect TrueType font metrics Message-ID: <52EF333C.2030208@lab.ntt.co.jp> Hi all, My customer encountered this issue. I think this issue is caused by Bug 1435 [1] and 1659 [2] in IcedTea. I read source code of "freetype-2.5.0-4.fc20" . Bold style should affect Font Glyph only. However, current implementation of OpenJDK affects Font Face. Thus value of Ascent/Descent is incorrect. OracleJDK seems to use sun.font.T2KFontScaler to calculate these values. So this issue occurs in OpenJDK only. I think we need to merge patches of Bug 1435 and 1659 in IcedTea to fix JDK-8017773 . Could you merge these patches ? Please cooperate. Thanks, Yasumasa [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1435 [2] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1659 ------ D E T A I L S ------ I've created testcase as "JavaApplication1.java" . Result as: OracleJDK 6 Update 31 ---------------- [root at RHEL6-5 font]# /usr/local/jdk1.6.0_31/bin/java JavaApplication1 JDK: 1.6.0_31 VM: Java HotSpot(TM) 64-Bit Server VM java.awt.Font[family=IPAMincho,name=IPAMincho,style=plain,size=50] Ascent: 43.99414 Descent: 6.0058594 java.awt.Font[family=IPAMincho,name=IPAMincho,style=bold,size=50] Ascent: 43.99414 Descent: 6.0058594 ---------------- OpenJDK7 (in RHEL6.5) ---------------- [root at RHEL6-5 font]# java JavaApplication1 JDK: 1.7.0_45 VM: OpenJDK 64-Bit Server VM java.awt.Font[family=IPAMincho,name=IPAMincho,style=plain,size=50] Ascent: 43.99414 Descent: 6.0058594 java.awt.Font[family=IPAMincho,name=IPAMincho,style=bold,size=50] Ascent: 45.60547 Descent: 4.3945312 ---------------- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: JavaApplication1.java URL: From anton.tarasov at oracle.com Mon Feb 3 14:36:48 2014 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Mon, 03 Feb 2014 18:36:48 +0400 Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting In-Reply-To: <52EC4F5E.7060906@oracle.com> References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com> <52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com> <52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com> <52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com> <52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com> <52B0F447.2020207@oracle.com> <52DE761E.2000201@oracle.com> <52E192F0.7010107@oracle.com> <52E27CDA.40703@oracle.com> <52E31866.3010508@oracle.com> <52E7CE5B.4070101@oracle.com> <52EAD304.2090809@oracle.com> <52EBB516.70906@oracle.com> <52EC4F5E.7060906@oracle.com> Message-ID: <52EFA980.6000404@oracle.com> Hi Jim, Please look at the updated version: http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.4 On 01.02.2014 5:35, Jim Graham wrote: > Hi Anton, > > On 1/31/14 6:37 AM, Anton V. Tarasov wrote: >> My understanding is that, unless the fix is absolutely irrelevant (whic >> I hope it isn't), we should integrate it into 9/8u20 to support >> SwingNode in its current implementation on Retina displays. >> >> What do you think? > > I agree with this sentiment. My suggestion for reducing its footprint aside (which it looks like > you are investigating), the main thing I will be looking for is whether or not we return an object > to a developer (i.e. it isn't just managed internally to our own code) where they can do > "instanceof BufferedImage" and then see something odd coming from its width/height. > > It looks like if we simply use getLayoutWH() internally then they would never ever see anything > odd from getWidthHeight() anyway. The only additional "gotcha" would be if they grab the image and > render it directly and it comes out an unexpected size to them (because, for instance, they didn't > check the layout dims like we do internally). That's a pretty minor issue, though, and I think we > could live with it. I've refactored the fix with this concern in mind. Here is what I've done: - eliminated the new OffscreenHiDPIImage class (as you suggested) and put all of its "scale" logic into the OffscreenImage. - made the scaled OffscreenImage return the physical size (like an ordinary BufferredImage does) by default . - renamed the "set/isHiDPIEnabled" method to "set/isReturnLayoutSize". - made the setReturnLayoutSize(true) be called internally (where we don't leak the OffscreenImage). In SG2D, the drawHiDPIImage, for instance, makes a call to op.filter(img, null); where the img is expected to return its layout size. That's why I still prefer to use the setReturnLayoutSize "switcher", in order not to go deep into the 2D rendering code, casting here and there to OffscreenImage and calling getLayoutWidth/Height. > > For 9.0 perhaps we could add the LayoutWH() as new API on BufferedImage and then most of this > would be public? I'd have to mull over if that makes sense and I'm not entirely sure of the > naming yet... That's a good idea, however we need a 8u working solution as well... As to the naming, I'm ready for any suggestions. Thanks, Anton. > > ...jim From ag at 4js.com Tue Feb 4 11:12:55 2014 From: ag at 4js.com (Alex Geller) Date: Tue, 04 Feb 2014 12:12:55 +0100 Subject: [OpenJDK 2D-Dev] [PATCH] JDK-4627340 : RFE: A way to improve text printing performance for postscript devices (Improved proposal) Message-ID: <52F0CB37.4000902@4js.com> Hi, my OCA submitted on January 10 didn't make its appearance and I am guessing it is because I checked the "Vice president" option by mistake. I have submitted a corrected version and I hope it is OK to continue posting on this topic in spite of that. After some minor adjustments to the patch I improved the test program so that instead of printing a static test document it now reads external files containing arbitrary attributed text. Based on the new version I have created a couple of test documents, compared the output under various settings and performed some benchmarks. The changes to the patch are: - For testing purposes the patch can be activated/deactivated by the temporary system property "PSRenderType3" - I removed the code that allowed to choose different byte encodings for the purpose of yielding a more compact Postscript representation mainly because text extraction via tools like "pstotext" or "ps2pdf" can't work correctly with anything else then Latin1 encoding anyway (Disregarding the option to use CID-Keyed fonts). - I spotted "Font.deriveFont(1000f)" as a source of slowness and replaced it with code that scales the glyphs of the original font instead. The test program can now be invoked with some command line options as list below: $java PSTest -help Usage: java PSTest -help|[-inputFileName file name ("example.xml")] [-latinFontName font name ("SansSerif")] [-asianFontName font name ("WenQuanYi Zen Hei")] [-renderingMethod DrawString|DrawGlyphVector|DrawTextLayout (DrawString)] [-renderIntoBufferedImage true|false (false)] [-useFractionalMetricsForLayoutComputation true|false (true)] [-useFractionalMetricsForPainting true|false (true)] [-useAntiAliasingForLayoutComputation true|false (false)] [-useAntiAliasingForPainting true|false (false)] [-numberOfPrintIterations number (3)] [-paintExpectedStringSizeMarkers number (false)] [-bufferedImageDPI number (300.0)] I created the following test documents: -oracle.xml: This is conversion of the Oracle terms and conditions page (http://www.oracle.com/us/legal/terms/index.html). The document has about 20,000 characters printed on two pages. About 1% of the characters are rendered using the default rendering due to text colorization (FOREGROUND attribute). -t-mobile.xml: This is conversion of the T-Mobile terms and conditions page (http://www.t-mobile.com/Templates/Popup.aspx?PAsset=Ftr_Ftr_TermsAndConditions&print=true). The document has about 56,000 characters printed on eight pages. About 0.1% of the characters are rendered using the default rendering due to underlining (UNDERLINE attribute). -baidu.xml: This is conversion of the Chinese Baidu terms and conditions page (http://adm.baidu.com/contract.html). The document has about 4,000 characters printed on three pages. There are 536 distinct characters in the text. All characters can be rendered using Type-3 fonts. -benchmark1.xml: A document containing a page with 64 lines of 100 'a' characters. This represents the "best case" for the font embedding strategy. -benchmark2.xml: A document containing 64 lines of 100 characters with 10 different characters -benchmark2.xml: A document containing 64 lines of 100 characters with 82 different characters -benchmark4.xml: A document containing a page with 64 lines of 99 'a' characters and one asian character. This is to test the bit set and to force the usage of "glyphshow" instead of the more compact "show" string representation -benchmark5.xml: A document containing a page with 12 lines of unique characters where each line uses an entirely different font. This represents the "worst case" for the font embedding strategy. -benchmark6.xml: Same as benchmark5.xml but just enough non unique characters are added so that size and performance exceed outline drawing. -example.xml: A two paged document that replaces the static document from the previous version. Other files: - results.html: Test results. The results include Java execution time, resulting Postscript file size and the time Ghostscript needed to rasterize the result. - results.txt: Detailed test results - condense.awk: A script that condenses the data in "results.txt" producing "results.html" - runtests.sh: A shellscript that produces "results.txt" and "results.html" - Makefile: A makefile with the targets "run" and "clean" Running the tests: The test are run via "make run" which compiles PSTest.java and then runs the shell script "runtests.sh" which in turn creates the HTML result file "results.html". Two of the tests requires a list of fonts. This list is located in "runtests.sh" and should be adjusted before running. Measuring rasterization time with Ghostscript: If "gs" is installed then the script will measure the time Ghostscript takes to render the document to a 600 DPI raster. As far as I can tell there is no option to perform rasterization only. Instead one has to select an output format where image encoding and file IO does not dominate the results. After some tests I decided to use the "pngmono" option with a scaledown of 3. Regarding the Java performance measurements: The values "Time for first run" and "Time for second run" are obtained by calls to "System.nanoTime()" immediately before and after the code that sets up and executes the print job. The JVM startup, the loading of the document and the computation of the layout are not included in this measure. Each print job is executed twice from the same JVM hence the differentiation between the values "first run" and "second run". The values "Performance for first/second in characters/s" are computed from those time measurements and the document size. Summary of results: The rendering seems to be accurate and the fallback to outline rendering when required works for all tested cases. Suggestions for additional tests are very much appreciated since I have only superficial knowledge in this area. Rendering speed using Ghostview: Font embedding is always faster including in the "worst case" scenario "benchmark5.xml" where there is absolutely no character reuse. Type 3 font embedding is more than 20 times faster on the Latin documents "t-mobile.xml" and "oracle.xml" and even with the Chinese document "baidu.xml" the gain is more than factor 6. In absolute numbers this means that the 8 page document "t-mobile.xml" is rendered in under 2 seconds while it takes about 40 seconds using the current method. Printing that document on my local DELL 2330dn takes 2 minutes using embedded fonts while it takes over 40 minutes using the current method. Rendering speed in Java: There is a large improvement in speed between the first run and consecutive runs using the new font embedding strategy for which I have not yet found an explanation while the effect is not observable when using outline drawing. However, even regarding the slower run only, the new method outperforms the existing method but for the "worst case" scenario where it reaches only about 80 % of the current performance. In all other case the improvement is at least factor 3 and gets better with growing document sizes. For the largest document "t-mobile.xml" the gain is factor 16 so that it is rendered in less then 300 ms while the current method takes over 4 seconds. On a "long running" JVM the gain nearly reached factor 40 so that the performance went from about 18 thousand characters per second to about 700 thousand characters per second. Postscript file size: The examples show an average of about 600 to 700 bytes per character using outlines for Latin text and 1.5 KB per Chinese glyph. Using font embedding the initial character definition has the same size as a outline character but any subsequent character usage requires about 5 bytes for Latin and 20 bytes for Asian text (For non fractional metrics the values roughly double). The values could be further reduced a little by using single character shortcuts for the "show", "glyphshow" and "rmoveto" commands. The files size varies between factor 400 ("best case" document "benchmark1.xml") and a 20 % increase of size ("worst case" document benchmark5.xml). For the two paged latin document "oracle.xml" the gain is more than factor 40 and for the longer document "t-mobile.xml" the gain is more than factor 120 so that the document is 300 KB instead of 35 MB. The Chinese document "baidu.xml" is reduced to about 20 % of the original size. The size difference increases after conversion to PDF so that for example the "t-mobile" document shrinks from 22 MB to less than 100KB. Thanks, Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: PSTest.zip Type: application/zip Size: 65412 bytes Desc: not available URL: From anthony.petrov at oracle.com Tue Feb 4 18:55:23 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 04 Feb 2014 22:55:23 +0400 Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting In-Reply-To: <52EFA980.6000404@oracle.com> References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com> <52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com> <52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com> <52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com> <52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com> <52B0F447.2020207@oracle.com> <52DE761E.2000201@oracle.com> <52E192F0.7010107@oracle.com> <52E27CDA.40703@oracle.com> <52E31866.3010508@oracle.com> <52E7CE5B.4070101@oracle.com> <52EAD304.2090809@oracle.com> <52EBB516.70906@oracle.com> <52EC4F5E.7060906@oracle.com> <52EFA980.6000404@oracle.com> Message-ID: <52F1379B.7000004@oracle.com> Hi Anton, I skimmed through the code that I'm familiar with, and the changes look good to me. Someone from Swing and 2D should review their parts, too. -- best regards, Anthony On 2/3/2014 6:36 PM, Anton V. Tarasov wrote: > Hi Jim, > > Please look at the updated version: > > http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.4 > > On 01.02.2014 5:35, Jim Graham wrote: >> Hi Anton, >> >> On 1/31/14 6:37 AM, Anton V. Tarasov wrote: >>> My understanding is that, unless the fix is absolutely irrelevant (whic >>> I hope it isn't), we should integrate it into 9/8u20 to support >>> SwingNode in its current implementation on Retina displays. >>> >>> What do you think? >> >> I agree with this sentiment. My suggestion for reducing its footprint >> aside (which it looks like you are investigating), the main thing I >> will be looking for is whether or not we return an object to a >> developer (i.e. it isn't just managed internally to our own code) >> where they can do "instanceof BufferedImage" and then see something >> odd coming from its width/height. >> >> It looks like if we simply use getLayoutWH() internally then they >> would never ever see anything odd from getWidthHeight() anyway. The >> only additional "gotcha" would be if they grab the image and render it >> directly and it comes out an unexpected size to them (because, for >> instance, they didn't check the layout dims like we do internally). >> That's a pretty minor issue, though, and I think we could live with it. > > I've refactored the fix with this concern in mind. Here is what I've done: > > - eliminated the new OffscreenHiDPIImage class (as you suggested) and > put all of its "scale" logic into the OffscreenImage. > - made the scaled OffscreenImage return the physical size (like an > ordinary BufferredImage does) by default . > - renamed the "set/isHiDPIEnabled" method to "set/isReturnLayoutSize". > - made the setReturnLayoutSize(true) be called internally (where we > don't leak the OffscreenImage). > > In SG2D, the drawHiDPIImage, for instance, makes a call to > op.filter(img, null); where the img is expected to return its layout > size. That's why I still prefer to use the setReturnLayoutSize > "switcher", in order not to go deep into the 2D rendering code, casting > here and there to OffscreenImage and calling getLayoutWidth/Height. > >> >> For 9.0 perhaps we could add the LayoutWH() as new API on >> BufferedImage and then most of this would be public? I'd have to mull >> over if that makes sense and I'm not entirely sure of the naming yet... > > That's a good idea, however we need a 8u working solution as well... As > to the naming, I'm ready for any suggestions. > > Thanks, > Anton. > >> >> ...jim > From joe.darcy at oracle.com Wed Feb 5 00:30:10 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 04 Feb 2014 16:30:10 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033616 : Fix serial lint warnings in javax.imageio.* Message-ID: <52F18612.9080904@oracle.com> Hello, Please review this simple patch to add serialVersionUID fields to several serializable types in javax.imageio. JDK-8033616 : Fix serial lint warnings in javax.imageio.* http://cr.openjdk.java.net/~darcy/8033616.0/ I've verified the serialVersionUID values have been stable across JDK 6 and JDK 8. Full patch below. Thanks, -Joe --- old/src/share/classes/javax/imageio/IIOException.java 2014-02-04 16:24:18.000000000 -0800 +++ new/src/share/classes/javax/imageio/IIOException.java 2014-02-04 16:24:18.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -40,6 +40,7 @@ * */ public class IIOException extends IOException { + private static final long serialVersionUID = -3216210718638985251L; /** * Constructs an IIOException with a given message --- old/src/share/classes/javax/imageio/metadata/IIOInvalidTreeException.java 2014-02-04 16:24:19.000000000 -0800 +++ new/src/share/classes/javax/imageio/metadata/IIOInvalidTreeException.java 2014-02-04 16:24:19.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, 2001, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -44,6 +44,7 @@ * */ public class IIOInvalidTreeException extends IIOException { + private static final long serialVersionUID = -1314083172544132777L; /** * The Node that led to the parsing error, or --- old/src/share/classes/javax/imageio/metadata/IIOMetadataNode.java 2014-02-04 16:24:19.000000000 -0800 +++ new/src/share/classes/javax/imageio/metadata/IIOMetadataNode.java 2014-02-04 16:24:19.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -41,6 +41,7 @@ class IIODOMException extends DOMException { + private static final long serialVersionUID = -4369510142067447468L; public IIODOMException(short code, String message) { super(code, message); --- old/src/share/classes/javax/imageio/spi/DigraphNode.java 2014-02-04 16:24:20.000000000 -0800 +++ new/src/share/classes/javax/imageio/spi/DigraphNode.java 2014-02-04 16:24:20.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -40,6 +40,7 @@ * */ class DigraphNode implements Cloneable, Serializable { + private static final long serialVersionUID = 5308261378582246841L; /** The data associated with this node. */ protected Object data; From joe.darcy at oracle.com Wed Feb 5 07:41:28 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 04 Feb 2014 23:41:28 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font Message-ID: <52F1EB28.8090002@oracle.com> Hello, Please review this change which resolves ~200 raw and unchecked warnings in sun.font. (Afterward, the code is also free the of the "cast" warning.) JDK-8033624 : Fix raw and unchecked lint warnings in sun.font http://cr.openjdk.java.net/~darcy/8033624.0/ Thanks, -Joe From Alan.Bateman at oracle.com Wed Feb 5 08:32:32 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 05 Feb 2014 08:32:32 +0000 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033616 : Fix serial lint warnings in javax.imageio.* In-Reply-To: <52F18612.9080904@oracle.com> References: <52F18612.9080904@oracle.com> Message-ID: <52F1F720.4060007@oracle.com> On 05/02/2014 00:30, Joe Darcy wrote: > Hello, > > Please review this simple patch to add serialVersionUID fields to > several serializable types in javax.imageio. > > JDK-8033616 : Fix serial lint warnings in javax.imageio.* > http://cr.openjdk.java.net/~darcy/8033616.0/ > > I've verified the serialVersionUID values have been stable across JDK > 6 and JDK 8. Looks good to me. -Alan. From Alan.Bateman at oracle.com Wed Feb 5 09:51:10 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 05 Feb 2014 09:51:10 +0000 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font In-Reply-To: <52F1EB28.8090002@oracle.com> References: <52F1EB28.8090002@oracle.com> Message-ID: <52F2098E.8060300@oracle.com> On 05/02/2014 07:41, Joe Darcy wrote: > Hello, > > Please review this change which resolves ~200 raw and unchecked > warnings in sun.font. (Afterward, the code is also free the of the > "cast" warning.) > > JDK-8033624 : Fix raw and unchecked lint warnings in sun.font > http://cr.openjdk.java.net/~darcy/8033624.0/ I've skimmed through this and I don't see anything obviously wrong. There are a @SuppressWarnings("unchecked") on methods where I wonder if the scope could be reduced but this requires deeper knowledge of this area. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.tarasov at oracle.com Wed Feb 5 16:07:55 2014 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 05 Feb 2014 20:07:55 +0400 Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting In-Reply-To: <52F1379B.7000004@oracle.com> References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com> <52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com> <52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com> <52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com> <52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com> <52B0F447.2020207@oracle.com> <52DE761E.2000201@oracle.com> <52E192F0.7010107@oracle.com> <52E27CDA.40703@oracle.com> <52E31866.3010508@oracle.com> <52E7CE5B.4070101@oracle.com> <52EAD304.2090809@oracle.com> <52EBB516.70906@oracle.com> <52EC4F5E.7060906@oracle.com> <52EFA980.6000404@oracle.com> <52F1379B.7000004@oracle.com> Message-ID: <52F261DB.3000806@oracle.com> Thanks for the review, Anthony! Regards, Anton. On 04.02.2014 22:55, Anthony Petrov wrote: > Hi Anton, > > I skimmed through the code that I'm familiar with, and the changes look good to me. Someone from > Swing and 2D should review their parts, too. > > -- > best regards, > Anthony > > On 2/3/2014 6:36 PM, Anton V. Tarasov wrote: >> Hi Jim, >> >> Please look at the updated version: >> >> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.4 >> >> On 01.02.2014 5:35, Jim Graham wrote: >>> Hi Anton, >>> >>> On 1/31/14 6:37 AM, Anton V. Tarasov wrote: >>>> My understanding is that, unless the fix is absolutely irrelevant (whic >>>> I hope it isn't), we should integrate it into 9/8u20 to support >>>> SwingNode in its current implementation on Retina displays. >>>> >>>> What do you think? >>> >>> I agree with this sentiment. My suggestion for reducing its footprint >>> aside (which it looks like you are investigating), the main thing I >>> will be looking for is whether or not we return an object to a >>> developer (i.e. it isn't just managed internally to our own code) >>> where they can do "instanceof BufferedImage" and then see something >>> odd coming from its width/height. >>> >>> It looks like if we simply use getLayoutWH() internally then they >>> would never ever see anything odd from getWidthHeight() anyway. The >>> only additional "gotcha" would be if they grab the image and render it >>> directly and it comes out an unexpected size to them (because, for >>> instance, they didn't check the layout dims like we do internally). >>> That's a pretty minor issue, though, and I think we could live with it. >> >> I've refactored the fix with this concern in mind. Here is what I've done: >> >> - eliminated the new OffscreenHiDPIImage class (as you suggested) and >> put all of its "scale" logic into the OffscreenImage. >> - made the scaled OffscreenImage return the physical size (like an >> ordinary BufferredImage does) by default . >> - renamed the "set/isHiDPIEnabled" method to "set/isReturnLayoutSize". >> - made the setReturnLayoutSize(true) be called internally (where we >> don't leak the OffscreenImage). >> >> In SG2D, the drawHiDPIImage, for instance, makes a call to >> op.filter(img, null); where the img is expected to return its layout >> size. That's why I still prefer to use the setReturnLayoutSize >> "switcher", in order not to go deep into the 2D rendering code, casting >> here and there to OffscreenImage and calling getLayoutWidth/Height. >> >>> >>> For 9.0 perhaps we could add the LayoutWH() as new API on >>> BufferedImage and then most of this would be public? I'd have to mull >>> over if that makes sense and I'm not entirely sure of the naming yet... >> >> That's a good idea, however we need a 8u working solution as well... As >> to the naming, I'm ready for any suggestions. >> >> Thanks, >> Anton. >> >>> >>> ...jim >> From philip.race at oracle.com Wed Feb 5 17:53:28 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 05 Feb 2014 09:53:28 -0800 Subject: [OpenJDK 2D-Dev] [PATCH] Re: JDK-8012351 In-Reply-To: <52DEAFB1.2020907@sd63.bc.ca> References: <52CB49CF.7050807@sd63.bc.ca> <52DEAFB1.2020907@sd63.bc.ca> Message-ID: <52F27A98.4010400@oracle.com> So that patch wasn't the right thing but as a result of off-list discussion its become clearer how the problem might occur I've updated https://bugs.openjdk.java.net/browse/JDK-8012351 with the evaluation. And I think this is the right fix for it: http://cr.openjdk.java.net/~prr/8012351/ Please review. Randy says it works for him. If anyone else is seeing this problem it would be nice to know if this fixes it for them too - or not ! I never reproduced the problem myself except by 'forcing' Ubuntu Regular to be ignored in fontconfiguration. -phil. On 01/21/2014 09:34 AM, Ryan Tandy wrote: > Dear JDK team, > > Further to my earlier message, please find attached the patch that I > think solves JDK-8012351. I applied this change to the Ubuntu JDK7 > package and made it available at the Launchpad bug for testing; so far > one other user commented that it works for them. > > Can JDK-8012351 be re-opened and this change considered as part of a > possible fix? > From henry.jen at oracle.com Wed Feb 5 20:19:38 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 05 Feb 2014 12:19:38 -0800 Subject: [OpenJDK 2D-Dev] JDK 9: RFR: 8033716: Fix raw and unchecked lint warnings in com.sun.imageio Message-ID: <52F29CDA.9010705@oracle.com> Hi, Please review the webrev to clean up raw and unchecked warnings in com.sun.imageio packag at, http://cr.openjdk.java.net/~henryjen/jdk9/8033716/0/webrev/ The more significant change in this webrev is that I have changed the clone() method of MarkerSegment-derived classes to return exact type rather than Object. Otherwise, it's basically add type information and eliminate cast no longer needed. Cheers, Henry From philip.race at oracle.com Wed Feb 5 23:55:20 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 05 Feb 2014 15:55:20 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font In-Reply-To: <52F1EB28.8090002@oracle.com> References: <52F1EB28.8090002@oracle.com> Message-ID: <52F2CF68.9080308@oracle.com> Joe, This help is very much appreciated but can you please re-generate your webrev against jdk9/client and I'll review it then. If this is a problem for you then instead I can take your final patch and commit into the client forest on your behalf. Let me know which you prefer. -phil. On 02/04/2014 11:41 PM, Joe Darcy wrote: > Hello, > > Please review this change which resolves ~200 raw and unchecked > warnings in sun.font. (Afterward, the code is also free the of the > "cast" warning.) > > JDK-8033624 : Fix raw and unchecked lint warnings in sun.font > http://cr.openjdk.java.net/~darcy/8033624.0/ > > Thanks, > > -Joe > From joe.darcy at oracle.com Thu Feb 6 02:01:12 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 05 Feb 2014 18:01:12 -0800 Subject: [OpenJDK 2D-Dev] JDK 9: RFR: 8033716: Fix raw and unchecked lint warnings in com.sun.imageio In-Reply-To: <52F29CDA.9010705@oracle.com> References: <52F29CDA.9010705@oracle.com> Message-ID: <52F2ECE8.5020000@oracle.com> Hi Henry, On 02/05/2014 12:19 PM, Henry Jen wrote: > Hi, > > Please review the webrev to clean up raw and unchecked warnings in > com.sun.imageio packag at, > > http://cr.openjdk.java.net/~henryjen/jdk9/8033716/0/webrev/ > > The more significant change in this webrev is that I have changed the > clone() method of MarkerSegment-derived classes to return exact type > rather than Object. Otherwise, it's basically add type information and > eliminate cast no longer needed. > > Cheers, > Henry I looked over the changes and they generally look good. I've taken a closer look at the clone-related changes. The types SOSMarkerSegment, SOFMarkerSegment, MarkerSegment, etc. are call package-private and all have had their Object-returning clone methods replaced with a self-type returning clone method, a covariant override. Since there are no other potential subclasses of these com.sun.* type that would already have had a covariant override of clone, I believe the changes to clone on these three methods is fine. (This avoid the hazards outlined in JDK-7140820: (coll) Add covariant overrides to Collections clone methods.) Thanks, -Joe From joe.darcy at oracle.com Thu Feb 6 07:44:43 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 05 Feb 2014 23:44:43 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font In-Reply-To: <52F2098E.8060300@oracle.com> References: <52F1EB28.8090002@oracle.com> <52F2098E.8060300@oracle.com> Message-ID: <52F33D6B.70403@oracle.com> On 02/05/2014 01:51 AM, Alan Bateman wrote: > On 05/02/2014 07:41, Joe Darcy wrote: >> Hello, >> >> Please review this change which resolves ~200 raw and unchecked >> warnings in sun.font. (Afterward, the code is also free the of the >> "cast" warning.) >> >> JDK-8033624 : Fix raw and unchecked lint warnings in sun.font >> http://cr.openjdk.java.net/~darcy/8033624.0/ > I've skimmed through this and I don't see anything obviously wrong. > There are a @SuppressWarnings("unchecked") on methods where I wonder > if the scope could be reduced but this requires deeper knowledge of > this area. > > -Alan. For the range of @SuppressWarnings("unchecked"), if there was already a declaration handy, I put the annotation on the declaration (minimal scope). If there wasn't a declaration handy and the method was short, say less than 10 lines, I put the annotation on the method. Otherwise, I introduced a new declaration to host the annotation, roughly @SuppressWarnings("unchecked") Foo tmp = .... // generate the value with the unchecked condition existingVariable = tmp; // types match so no warning here -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Feb 6 08:43:58 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 06 Feb 2014 08:43:58 +0000 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font In-Reply-To: <52F33D6B.70403@oracle.com> References: <52F1EB28.8090002@oracle.com> <52F2098E.8060300@oracle.com> <52F33D6B.70403@oracle.com> Message-ID: <52F34B4E.5000703@oracle.com> On 06/02/2014 07:44, Joe Darcy wrote: > > For the range of @SuppressWarnings("unchecked"), if there was already > a declaration handy, I put the annotation on the declaration (minimal > scope). If there wasn't a declaration handy and the method was short, > say less than 10 lines, I put the annotation on the method. Otherwise, > I introduced a new declaration to host the annotation, roughly > > @SuppressWarnings("unchecked") > Foo tmp = .... // generate the value with the unchecked condition > existingVariable = tmp; // types match so no warning here Okay, it looks like you've done as much as possible so thumbs up from me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Feb 6 08:48:01 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 06 Feb 2014 08:48:01 +0000 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font In-Reply-To: <52F2CF68.9080308@oracle.com> References: <52F1EB28.8090002@oracle.com> <52F2CF68.9080308@oracle.com> Message-ID: <52F34C41.8060909@oracle.com> On 05/02/2014 23:55, Phil Race wrote: > Joe, > > This help is very much appreciated but can you please re-generate > your webrev against jdk9/client and I'll review it then. > If this is a problem for you then instead I can take your final patch and > commit into the client forest on your behalf. > Let me know which you prefer. All of these cleanups have (so far anyway) been pushed to jdk9/dev but there is clearly confusion as to where changes to AWT/Swing/2D/other code should be pushed. I hijacked one of Joe's recent reviews to restart that discussion: http://mail.openjdk.java.net/pipermail/2d-dev/2014-January/004181.html but I didn't see any replies except from Joe. -Alan. From joe.darcy at oracle.com Thu Feb 6 17:54:53 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 06 Feb 2014 09:54:53 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font In-Reply-To: <52F34C41.8060909@oracle.com> References: <52F1EB28.8090002@oracle.com> <52F2CF68.9080308@oracle.com> <52F34C41.8060909@oracle.com> Message-ID: <52F3CC6D.3070402@oracle.com> On 02/06/2014 12:48 AM, Alan Bateman wrote: > On 05/02/2014 23:55, Phil Race wrote: >> Joe, >> >> This help is very much appreciated but can you please re-generate >> your webrev against jdk9/client and I'll review it then. >> If this is a problem for you then instead I can take your final patch >> and >> commit into the client forest on your behalf. >> Let me know which you prefer. > All of these cleanups have (so far anyway) been pushed to jdk9/dev but > there is clearly confusion as to where changes to AWT/Swing/2D/other > code should be pushed. I hijacked one of Joe's recent reviews to > restart that discussion: > > http://mail.openjdk.java.net/pipermail/2d-dev/2014-January/004181.html > > but I didn't see any replies except from Joe. > > -Alan. For the files involved in this review, when I checked late last night, the unmodified versions of the files were identical in the dev and client forests. I've been using the results of an (unfortunately Oracle-internal only) CI job run against the dev forest to track how we are doing on warnings. Since December 2013, progress has been steady, with ~800 warnings being removed from client code. My preference is to push this fix into dev and the for the maintainers of the client forest to sync it down. Unless there is a prompt and regular integration of client into dev, I don't want to first push these cleanup fixes to the client forest since there won't be prompt registration of the reduced warnings and because it would complicate efforts to fix all the warnings in a category and then enable checks in the build. The goal here is not just to eliminate the warnings, but to eliminate them and make sure they cannot come back :-) -Joe From philip.race at oracle.com Thu Feb 6 19:01:32 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 06 Feb 2014 11:01:32 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font In-Reply-To: <52F3CC6D.3070402@oracle.com> References: <52F1EB28.8090002@oracle.com> <52F2CF68.9080308@oracle.com> <52F34C41.8060909@oracle.com> <52F3CC6D.3070402@oracle.com> Message-ID: <52F3DC0C.5020202@oracle.com> Joe, We will get an integration going soon, so you won't have to wait too long. Its more important to be consistent in that we get the client code in the client forest. We already had to deal with a merge problem due to changes to client code made in dev. So from now on if you have changes to client code, the client team's polite request is you make them in the client forest after appropriate review. -phil. On 2/6/2014 9:54 AM, Joe Darcy wrote: > On 02/06/2014 12:48 AM, Alan Bateman wrote: >> On 05/02/2014 23:55, Phil Race wrote: >>> Joe, >>> >>> This help is very much appreciated but can you please re-generate >>> your webrev against jdk9/client and I'll review it then. >>> If this is a problem for you then instead I can take your final >>> patch and >>> commit into the client forest on your behalf. >>> Let me know which you prefer. >> All of these cleanups have (so far anyway) been pushed to jdk9/dev >> but there is clearly confusion as to where changes to >> AWT/Swing/2D/other code should be pushed. I hijacked one of Joe's >> recent reviews to restart that discussion: >> >> http://mail.openjdk.java.net/pipermail/2d-dev/2014-January/004181.html >> >> but I didn't see any replies except from Joe. >> >> -Alan. > > For the files involved in this review, when I checked late last night, > the unmodified versions of the files were identical in the dev and > client forests. > > I've been using the results of an (unfortunately Oracle-internal only) > CI job run against the dev forest to track how we are doing on > warnings. Since December 2013, progress has been steady, with ~800 > warnings being removed from client code. > > My preference is to push this fix into dev and the for the maintainers > of the client forest to sync it down. Unless there is a prompt and > regular integration of client into dev, I don't want to first push > these cleanup fixes to the client forest since there won't be prompt > registration of the reduced warnings and because it would complicate > efforts to fix all the warnings in a category and then enable checks > in the build. > > The goal here is not just to eliminate the warnings, but to eliminate > them and make sure they cannot come back :-) > > -Joe From Alan.Bateman at oracle.com Thu Feb 6 19:12:53 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 06 Feb 2014 19:12:53 +0000 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font In-Reply-To: <52F3DC0C.5020202@oracle.com> References: <52F1EB28.8090002@oracle.com> <52F2CF68.9080308@oracle.com> <52F34C41.8060909@oracle.com> <52F3CC6D.3070402@oracle.com> <52F3DC0C.5020202@oracle.com> Message-ID: <52F3DEB5.9040401@oracle.com> On 06/02/2014 19:01, Phil Race wrote: > Joe, > > We will get an integration going soon, so you won't have to wait too > long. > Its more important to be consistent in that we get the client code in > the client forest. > We already had to deal with a merge problem due to changes to client > code made in dev. Assuming this was the SecurityManager change then this involved changes to both core and client libraries and we pushed it to jdk9/dev in mid-December. It's not too often that there are changes like this but in this case then it was important to get into jdk9/dev. It was very unfortunate that it wasn't pulled in jdk9/client for several weeks. Hopefully jdk9/client will be kept up to date going forward, also that it will push to jdk9/dev on a regular basis. -Alan From joe.darcy at oracle.com Thu Feb 6 19:15:56 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 06 Feb 2014 11:15:56 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font In-Reply-To: <52F3DEB5.9040401@oracle.com> References: <52F1EB28.8090002@oracle.com> <52F2CF68.9080308@oracle.com> <52F34C41.8060909@oracle.com> <52F3CC6D.3070402@oracle.com> <52F3DC0C.5020202@oracle.com> <52F3DEB5.9040401@oracle.com> Message-ID: <52F3DF6C.6050706@oracle.com> On 02/06/2014 11:12 AM, Alan Bateman wrote: > On 06/02/2014 19:01, Phil Race wrote: >> Joe, >> >> We will get an integration going soon, so you won't have to wait too >> long. >> Its more important to be consistent in that we get the client code in >> the client forest. >> We already had to deal with a merge problem due to changes to client >> code made in dev. > Assuming this was the SecurityManager change then this involved > changes to both core and client libraries and we pushed it to jdk9/dev > in mid-December. It's not too often that there are changes like this > but in this case then it was important to get into jdk9/dev. It was > very unfortunate that it wasn't pulled in jdk9/client for several > weeks. Hopefully jdk9/client will be kept up to date going forward, > also that it will push to jdk9/dev on a regular basis. > Yes, with the current model, unless there are changes in the client repo that need to be isolated while being stabilized, the client forest should be sync'ed with dev regularly, closer to daily rather than weekly or monthly. -Joe From philip.race at oracle.com Thu Feb 6 19:12:38 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 06 Feb 2014 11:12:38 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font In-Reply-To: <52F3DEB5.9040401@oracle.com> References: <52F1EB28.8090002@oracle.com> <52F2CF68.9080308@oracle.com> <52F34C41.8060909@oracle.com> <52F3CC6D.3070402@oracle.com> <52F3DC0C.5020202@oracle.com> <52F3DEB5.9040401@oracle.com> Message-ID: <52F3DEA6.5070906@oracle.com> There will be cases where its not practical or possible to separate changes. The other example I can cite is the AIX port changes which are coming in all together. But they should be considered the exception rather than the rule. In those cases you will want to consider which is the overall most appropriate location to push them. -phil. On 02/06/2014 11:12 AM, Alan Bateman wrote: > On 06/02/2014 19:01, Phil Race wrote: >> Joe, >> >> We will get an integration going soon, so you won't have to wait too >> long. >> Its more important to be consistent in that we get the client code in >> the client forest. >> We already had to deal with a merge problem due to changes to client >> code made in dev. > Assuming this was the SecurityManager change then this involved > changes to both core and client libraries and we pushed it to jdk9/dev > in mid-December. It's not too often that there are changes like this > but in this case then it was important to get into jdk9/dev. It was > very unfortunate that it wasn't pulled in jdk9/client for several > weeks. Hopefully jdk9/client will be kept up to date going forward, > also that it will push to jdk9/dev on a regular basis. > > -Alan From joe.darcy at oracle.com Thu Feb 6 19:20:31 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 06 Feb 2014 11:20:31 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font In-Reply-To: <52F3DC0C.5020202@oracle.com> References: <52F1EB28.8090002@oracle.com> <52F2CF68.9080308@oracle.com> <52F34C41.8060909@oracle.com> <52F3CC6D.3070402@oracle.com> <52F3DC0C.5020202@oracle.com> Message-ID: <52F3E07F.9010507@oracle.com> On 02/06/2014 11:01 AM, Phil Race wrote: > Joe, > > We will get an integration going soon, so you won't have to wait too > long. > Its more important to be consistent in that we get the client code in > the client forest. > We already had to deal with a merge problem due to changes to client > code made in dev. > So from now on if you have changes to client code, the client team's > polite request is > you make them in the client forest after appropriate review. Well, if all the client library (2D, awt, swing) changes went the dev forest directly, that would be another way to get consistency ;-) As many of the files I'm changing as part of the warnings cleanup have been untouched for five, ten, or in sometimes fifteen years, I would appreciate prompt reviews, especially when the changes are broken into small, easy to review portions: http://mail.openjdk.java.net/pipermail/awt-dev/2014-February/006934.html -Joe > > -phil. > > On 2/6/2014 9:54 AM, Joe Darcy wrote: >> On 02/06/2014 12:48 AM, Alan Bateman wrote: >>> On 05/02/2014 23:55, Phil Race wrote: >>>> Joe, >>>> >>>> This help is very much appreciated but can you please re-generate >>>> your webrev against jdk9/client and I'll review it then. >>>> If this is a problem for you then instead I can take your final >>>> patch and >>>> commit into the client forest on your behalf. >>>> Let me know which you prefer. >>> All of these cleanups have (so far anyway) been pushed to jdk9/dev >>> but there is clearly confusion as to where changes to >>> AWT/Swing/2D/other code should be pushed. I hijacked one of Joe's >>> recent reviews to restart that discussion: >>> >>> http://mail.openjdk.java.net/pipermail/2d-dev/2014-January/004181.html >>> >>> but I didn't see any replies except from Joe. >>> >>> -Alan. >> >> For the files involved in this review, when I checked late last >> night, the unmodified versions of the files were identical in the >> dev and client forests. >> >> I've been using the results of an (unfortunately Oracle-internal >> only) CI job run against the dev forest to track how we are doing on >> warnings. Since December 2013, progress has been steady, with ~800 >> warnings being removed from client code. >> >> My preference is to push this fix into dev and the for the >> maintainers of the client forest to sync it down. Unless there is a >> prompt and regular integration of client into dev, I don't want to >> first push these cleanup fixes to the client forest since there won't >> be prompt registration of the reduced warnings and because it would >> complicate efforts to fix all the warnings in a category and then >> enable checks in the build. >> >> The goal here is not just to eliminate the warnings, but to eliminate >> them and make sure they cannot come back :-) >> >> -Joe > From philip.race at oracle.com Thu Feb 6 22:31:23 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 06 Feb 2014 14:31:23 -0800 Subject: [OpenJDK 2D-Dev] RFR: Fix for 8032693 : javax.print.PrintService does not find any CUPS-Printers on Linux Message-ID: <52F40D3B.9060602@oracle.com> http://cr.openjdk.java.net/~prr/8032693/ This is a fix for https://bugs.openjdk.java.net/browse/JDK-8032693 It was introduced by the JDK 8 b115 fix for https://bugs.openjdk.java.net/browse/JDK-8022536 The root of the issue is that if you do not have a default printer set in CUPS then we get an NPE at line 635 (original file) of UnixPrintServiceLookup.java de-referencing the array returned from CUPSPrinter.getDefaultPrinter(). This caused a failure not just locating the default but *any* printer because the NPE went all the way back up to javax.print implementation where it calls getPrintServices() Really preventing that NPE from happening is all there is to the fix But for good measure I 1) Catch such an exception inside refreshServices() so we can continue on 2) Fix the usage of device-uri (should be printer-uri-supported) 3) Add lots more debugging to make it easier to get to the bottom of future problems. I'm pretty confident in this fix since I was able to reproduce the problem by updating CUPS so I had no default and this cures it. I've added a regression test as best I can. Unless you have printers, but have also no default printer its going to pass regardless. -phil From philip.race at oracle.com Fri Feb 7 00:13:51 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 06 Feb 2014 16:13:51 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8033624: Fix raw and unchecked lint warnings in sun.font In-Reply-To: <52F2098E.8060300@oracle.com> References: <52F1EB28.8090002@oracle.com> <52F2098E.8060300@oracle.com> Message-ID: <52F4253F.6020706@oracle.com> Comments/questions on the changes :- Font2D.java 108 protected Reference lastFontStrike = new SoftReference<>(null); ... 320 lastFontStrike = new SoftReference<>(strike); So the diamond operator can be used in this 2nd case ? Apparently so. I vaguely remember that it used to only be able to infer the type in the first case ? Did it get updated or did I just not realise ?? There are a few places including these :- ----- AttributeValues.java Map imStyles = hl.getStyle(); FontResolver.java 226 public Font getFont(int index, 227 Map attributes) { ---- where its not obvious how you decided the type to use. I know a lot of this code and that they look reasonable but I wouldn't have been confident that there weren't places where we allowed some wider type to be used in these maps. How did you decide on the types and how did you verify it ? > @SuppressWarnings("unchecked") Can you show what thevarious warnings looked like and say why they needed to be suppressed rather than fixed ? Is it anywhere you found it to tricky/impossible to get rid of a cast ? FontScaler.java : Is the whole somewhat ugly re-writing of this so that you have a single expression to which to apply @SuppressWarnings ? If you are going to do that anyway was it worth it ? Can't it just be applied to the static initialiser block ? And at the very least there should be spaces before "?" and ":" to make it easier to read. StrikeCache.java: Disposer.addReference((Reference