From philip.race at oracle.com Tue Jan 3 21:38:17 2017 From: philip.race at oracle.com (Phil Race) Date: Tue, 3 Jan 2017 13:38:17 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8172153: Create workaround for failure to use ICC profile contained in a TIFF field In-Reply-To: <5E46096B-257D-4BC3-A9BC-074576717E96@oracle.com> References: <5E46096B-257D-4BC3-A9BC-074576717E96@oracle.com> Message-ID: +1 I made a note in the referenced bug about this change. -phil. On 12/30/2016 12:22 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8172153 > Patch: http://cr.openjdk.java.net/~bpb/8172153/webrev.00/ > > If there is an error creating an ICC_ColorSpace instance from the data in an ICC Profile field, or invoking the method ColorSpace.toRGB() with parameter float[] {1.0F, 1.0F, 1.0F} on the created ICC_ColorSpace instance throws an exception, then fall back to a standard ColorSpace in preference to not being able to read the image. > > Thanks, > > Brian From philip.race at oracle.com Wed Jan 4 23:55:56 2017 From: philip.race at oracle.com (Philip Race) Date: Wed, 04 Jan 2017 15:55:56 -0800 Subject: [OpenJDK 2D-Dev] RFR: 6232267: TrueType Fonts which have only Apple platform names cannot be loaded In-Reply-To: <375323cc-f9ad-28af-563d-880aa3d0008b@oracle.com> References: <375323cc-f9ad-28af-563d-880aa3d0008b@oracle.com> Message-ID: <586D8B8C.4010600@oracle.com> Bug : https://bugs.openjdk.java.net/browse/JDK-6232267 Webrev : http://cr.openjdk.java.net/~prr/6232267/ Fonts such as "Menlo" on OS X have no Microsoft names (see https://www.microsoft.com/typography/otspec/name.htm) so historically we rejected these. Now that we support OS X, this is more of an issue, and it is possible to run into a case where we fail to parse these fonts when they go through the Font.createFont() path, even on OS X. This adds that basic support for parsing Apple names so that we load the font. This support already exists on JavaFX. -phil. From prasanta.sadhukhan at oracle.com Fri Jan 6 08:33:39 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 6 Jan 2017 14:03:39 +0530 Subject: [OpenJDK 2D-Dev] RFR: 6232267: TrueType Fonts which have only Apple platform names cannot be loaded In-Reply-To: <586D8B8C.4010600@oracle.com> References: <375323cc-f9ad-28af-563d-880aa3d0008b@oracle.com> <586D8B8C.4010600@oracle.com> Message-ID: <6a8b0ad4-94ac-83a0-b3f4-569747dbb980@oracle.com> Hi Phil, Looks good to me . One thing is that, the check forplatformID != MAC_PLATFORM_ID shouldn't we do the same in initAllNames()? Also, in the test, I guess we do not need 33 import java.io.BufferedInputStream; 35 import java.io.FileInputStream; 36 import java.io.InputStream; 37 and copyright should be 2017. Regards Prasanta On 1/5/2017 5:25 AM, Philip Race wrote: > > Bug : https://bugs.openjdk.java.net/browse/JDK-6232267 > Webrev : http://cr.openjdk.java.net/~prr/6232267/ > > Fonts such as "Menlo" on OS X have no Microsoft names > (see https://www.microsoft.com/typography/otspec/name.htm) > so historically we rejected these. > > Now that we support OS X, this is more of an issue, and > it is possible to run into a case where we fail to parse these fonts > when they go through the Font.createFont() path, even on OS X. > > This adds that basic support for parsing Apple names so that > we load the font. This support already exists on JavaFX. > > -phil. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Jan 10 09:13:13 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 10 Jan 2017 14:43:13 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8170578: The Pages Range From in print dialog is disabled In-Reply-To: <90c7f438-27ee-3334-d91a-5b1aff84e025@oracle.com> References: <39f21e6d-78fb-6486-0260-620f42a63ccb@oracle.com> <90c7f438-27ee-3334-d91a-5b1aff84e025@oracle.com> Message-ID: <224e283e-47c5-f254-bafd-de5beccf1584@oracle.com> Actually, in ubuntu16.10 attribute map did not have "page-ranges-supported" attribute because 2 attribute hashmap is created in IPPPrintService#readIPPResponse() and most of the supported attributes are part of the 2nd hashmap (responseMap[1]) whereas only the 1st hashmap is utilised through responseMap[0] [http://hg.openjdk.java.net/jdk9/client/jdk/file/8be0bb1aa238/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1760] As to why 2 hashmaps are created in ubuntu16.10, it is because readIPPResponse() checks if key is already present in existing map, then create a new hashmap through this code and in ubuntu16.10, some attributes (like pwg-raster-document-type-supported which is not there in ubuntu 14.04] are duplicated. Proposed fix is to check if there are more than 1 hashmaps, if it is, get the entries from those maps, remove duplicate entries and append to existing hashmap to get a consolidated map having all the IPP attributes. Regards Prasanta On 12/21/2016 11:28 PM, Phil Race wrote: > So now I am very suspicious. > First (previous fix I reviewed) Job Sheets weren't supported on 16.10, > now its PageRanges. > > I think this merits investigation of what is going on before we commit > this fix. > Why are attributes that have always been supported by CUPS suddenly > unavailable ? > > And for the cases we image the pages ourselves, we can implement > PageRanges > internally, so for a normal PrinterJob it always can be supported .. > regardless of > what the printer says. > > -phil. > > > On 12/14/2016 09:50 PM, Prasanta Sadhukhan wrote: >> >> Hi All, >> >> Please review a testbug fix for jdk9 for an issue where it it seen >> that PageRanges option is disabled in printer dialog in ubuntu16.10. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170578 >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8170578/webrev.00/ >> >> Issue was, in ubuntu16.10 the attribute map [obtained here >> http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1767] >> does not have >> "pageranges-supported" attribute returned by CUPS >> so this category is not added to supported categories >> [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1030] >> so isAttributeCategorySupported() called by ServiceDialog returns false >> [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1141] >> resulting in PageRanges option getting disabled. >> >> Fix is to check if PageRanges category is supported in underlying >> platform, only then proceed with the test. >> >> Regards >> Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Jan 10 09:14:28 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 10 Jan 2017 14:44:28 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8170578: The Pages Range From in print dialog is disabled In-Reply-To: <224e283e-47c5-f254-bafd-de5beccf1584@oracle.com> References: <39f21e6d-78fb-6486-0260-620f42a63ccb@oracle.com> <90c7f438-27ee-3334-d91a-5b1aff84e025@oracle.com> <224e283e-47c5-f254-bafd-de5beccf1584@oracle.com> Message-ID: <68d7b1d5-40f9-0841-0d6c-328861391f33@oracle.com> On 1/10/2017 2:43 PM, Prasanta Sadhukhan wrote: > Actually, in ubuntu16.10 attribute map did not have > "page-ranges-supported" attribute because 2 attribute hashmap is > created in IPPPrintService#readIPPResponse() and most of the supported > attributes are part of the 2nd hashmap (responseMap[1]) > whereas only the 1st hashmap is utilised through responseMap[0] > [http://hg.openjdk.java.net/jdk9/client/jdk/file/8be0bb1aa238/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1760] > > As to why 2 hashmaps are created in ubuntu16.10, it is because > readIPPResponse() checks if key is already present in existing map, > then create a new hashmap through this code > > and in ubuntu16.10, some attributes (like > pwg-raster-document-type-supported which is not there in ubuntu 14.04] > are duplicated. > > Proposed fix is to check if there are more than 1 hashmaps, if it is, > get the entries from those maps, remove duplicate entries and append > to existing hashmap to get a consolidated map having all the IPP > attributes. > Missing webrev link: http://cr.openjdk.java.net/~psadhukhan/8170578/webrev.01/ > Regards > Prasanta > On 12/21/2016 11:28 PM, Phil Race wrote: >> So now I am very suspicious. >> First (previous fix I reviewed) Job Sheets weren't supported on >> 16.10, now its PageRanges. >> >> I think this merits investigation of what is going on before we >> commit this fix. >> Why are attributes that have always been supported by CUPS suddenly >> unavailable ? >> >> And for the cases we image the pages ourselves, we can implement >> PageRanges >> internally, so for a normal PrinterJob it always can be supported .. >> regardless of >> what the printer says. >> >> -phil. >> >> >> On 12/14/2016 09:50 PM, Prasanta Sadhukhan wrote: >>> >>> Hi All, >>> >>> Please review a testbug fix for jdk9 for an issue where it it seen >>> that PageRanges option is disabled in printer dialog in ubuntu16.10. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170578 >>> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8170578/webrev.00/ >>> >>> Issue was, in ubuntu16.10 the attribute map [obtained here >>> http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1767] >>> does not have >>> "pageranges-supported" attribute returned by CUPS >>> so this category is not added to supported categories >>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1030] >>> so isAttributeCategorySupported() called by ServiceDialog returns false >>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1141] >>> resulting in PageRanges option getting disabled. >>> >>> Fix is to check if PageRanges category is supported in underlying >>> platform, only then proceed with the test. >>> >>> Regards >>> Prasanta >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Tue Jan 10 20:42:40 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Jan 2017 23:42:40 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] Deadlock in CGLGraphicsConfig.getCGLConfigInfo In-Reply-To: References: Message-ID: <18AD0EF9-82B2-4BD6-904A-EF1B0F72E7EA@oracle.com> Hi, Karl. The correct alias to discuss this issue is 2d-dev. Looks like this bug was reported before. https://bugs.openjdk.java.net/browse/JDK-8152683 Your evaluation and the fix seems reasonable. If you already signed the OCA[1] then you can send an official review request to 2d-dev. An example: http://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html [1] http://www.oracle.com/technetwork/community/oca-486395.html > > I have encountered a deadlock in Java 1.8.0_112 when changing between discrete and integrated GPU on a retina MacBook Pro. The deadlock is between: > > CGLGraphicsConfig.getCGLConfigInfo, running on AWT.EventQueue, trying to call [GraphicsConfigUtil _getCGLConfigInfo:] on > the main thread (AppKit thread) while it holds the AWT lock and is synchronized on CGraphicsEnvironment. > > and > > A) the AppKit main thread trying to call CGraphicsEnvironment._displayReconfiguration (via displaycb_handle in CGraphicsEnv.m) > and synchronizing on CGraphicsEnvironment?deadlock. > > or > > B) the AppKit main thread trying to render, and trying to acquire the OGLRenderQueue lock (which is the the AWT lock) > > > SUPPORTING STACK DUMPS > > - SCENARIO A > > CGraphicsEnvironment._displayReconfiguration is called on the main thread since > 8041900: [macosx] Java forces the use of discrete GPU (https://bugs.openjdk.java.net/browse/JDK-8041900 ) which appears as changeset 11227. > In the native thread dump below you can see the frame for displaycb_handle which is the block dispatched to the main thread to call > CGraphicsEnvironment._displayReconfiguration. > > Java stacks > > "AWT-EventQueue-0" #16 prio=6 os_prio=31 tid=0x00007fbc72a0a800 nid=0x1251f runnable [0x000070000e443000] > java.lang.Thread.State: RUNNABLE > at sun.java2d.opengl.CGLGraphicsConfig.getCGLConfigInfo(Native Method) > at sun.java2d.opengl.CGLGraphicsConfig.getConfig(CGLGraphicsConfig.java:147) > at sun.awt.CGraphicsDevice.(CGraphicsDevice.java:64) > at sun.awt.CGraphicsEnvironment.initDevices(CGraphicsEnvironment.java:163) > - locked <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) > at sun.awt.CGraphicsEnvironment.getDefaultScreenDevice(CGraphicsEnvironment.java:181) > - locked <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) > at sun.lwawt.macosx.LWCToolkit.getScreenResolution(LWCToolkit.java:415) > at net.miginfocom.swing.SwingComponentWrapper.getHorizontalScreenDPI(SwingComponentWrapper.java:260) > at net.miginfocom.swing.SwingComponentWrapper.getPixelUnitFactor(SwingComponentWrapper.java:119) > [SNIP] > at java.awt.Container.layout(Container.java:1510) > at java.awt.Container.doLayout(Container.java:1499) > at java.awt.Container.validateTree(Container.java:1695) > [SNIP] > at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1750) > [SNIP] > at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > > "AppKit Thread" #11 daemon prio=5 os_prio=31 tid=0x00007fbc75046800 nid=0x307 waiting for monitor entry [0x00007fff5b579000] > java.lang.Thread.State: BLOCKED (on object monitor) > at sun.awt.CGraphicsEnvironment._displayReconfiguration(CGraphicsEnvironment.java:129) > - waiting to lock <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) > > Native stacks > > Thread 0x6828c3 DispatchQueue 1 Thread name "AppKit Thread" 1000 samples (1-1000) priority 46 (base 46) cpu time <0.001 > 1000 start + 52 (Charles + 5156) [0x104682424] > 1000 main + 153 (Charles + 5321) [0x1046824c9] > 1000 launch + 10872 (Charles + 16520) [0x104685088] > 1000 JLI_Launch + 1952 (libjli.dylib + 5668) [0x104702624] > 1000 CreateExecutionEnvironment + 871 (libjli.dylib + 22781) [0x1047068fd] > 1000 CFRunLoopRunSpecific + 420 (CoreFoundation + 555380) [0x7fff97665974] > 1000 __CFRunLoopRun + 934 (CoreFoundation + 556918) [0x7fff97665f76] > 1000 __CFRunLoopDoSources0 + 557 (CoreFoundation + 559741) [0x7fff97666a7d] > 1000 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 (CoreFoundation + 686465) [0x7fff97685981] > 1000 __NSThreadPerformPerform + 326 (Foundation + 465034) [0x7fff990c988a] > 1000 -[AWTStarter starter:] + 905 (libawt_lwawt.dylib + 286207) [0x113081dff] > 1000 +[NSApplicationAWT runAWTLoopWithApp:] + 156 (libosxapp.dylib + 8525) [0x1130fa14d] > [SNIP] > 1000 +[JNFRunLoop _performCopiedBlock:] + 17 (JavaNativeFoundation + 28474) [0x112d0df3a] > 1000 __displaycb_handle_block_invoke_1 + 172 (libawt_lwawt.dylib + 119659) [0x11305936b] > 1000 JNFPerformEnvBlock + 87 (JavaNativeFoundation + 27229) [0x112d0da5d] > 1000 __displaycb_handle_block_invoke_2 + 80 (libawt_lwawt.dylib + 119988) [0x1130594b4] > 1000 JNFCallVoidMethod + 187 (JavaNativeFoundation + 13743) [0x112d0a5af] > 1000 jni_CallVoidMethodV + 248 (libjvm.dylib + 3069241) [0x106301539] > 1000 jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 748 (libjvm.dylib + 3124227) [0x10630ec03] > 1000 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 (libjvm.dylib + 3015574) [0x1062f4396] > 1000 ??? [0x113db94e7] > 1000 ??? [0x113dde021] > 1000 InterpreterRuntime::monitorenter(JavaThread*, BasicObjectLock*) + 165 (libjvm.dylib + 2995347) [0x1062ef493] > 1000 ObjectMonitor::enter(Thread*) + 472 (libjvm.dylib + 4524724) [0x106464ab4] > 1000 ObjectMonitor::EnterI(Thread*) + 532 (libjvm.dylib + 4521584) [0x106463e70] > 1000 os::PlatformEvent::park(long) + 404 (libjvm.dylib + 4561328) [0x10646d9b0] > 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] > *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] > > Thread 0x68292c Thread name "Java: AWT-EventQueue-0" 1000 samples (1-1000) priority 31 (base 31) > 1000 thread_start + 13 (libsystem_pthread.dylib + 12797) [0x7fffacdd51fd] > 1000 _pthread_start + 286 (libsystem_pthread.dylib + 14839) [0x7fffacdd59f7] > 1000 _pthread_body + 180 (libsystem_pthread.dylib + 15019) [0x7fffacdd5aab] > 1000 java_start(Thread*) + 246 (libjvm.dylib + 4574506) [0x106470d2a] > 1000 JavaThread::run() + 448 (libjvm.dylib + 5486408) [0x10654f748] > 1000 JavaThread::thread_main_inner() + 155 (libjvm.dylib + 5480593) [0x10654e091] > 1000 thread_entry(JavaThread*, Thread*) + 124 (libjvm.dylib + 3270354) [0x1063326d2] > 1000 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 (libjvm.dylib + 3017936) [0x1062f4cd0] > 1000 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 356 (libjvm.dylib + 3017508) [0x1062f4b24] > 1000 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 (libjvm.dylib + 3015574) [0x1062f4396] > [SNIP] > 1000 Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo + 279 (libawt_lwawt.dylib + 107562) [0x11305642a] > 1000 -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] + 131 (Foundation + 203394) [0x7fff99089a82] > 1000 -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] + 904 (Foundation + 204424) [0x7fff99089e88] > 1000 -[NSCondition wait] + 240 (Foundation + 208331) [0x7fff9908adcb] > 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] > *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] > > > > > > > - Scenario B > > Java stacks > > "AWT-EventQueue-0" #15 prio=6 os_prio=31 tid=0x00007fba611d2000 nid=0x1260f runnable [0x0000700005365000] > java.lang.Thread.State: RUNNABLE > at sun.java2d.opengl.CGLGraphicsConfig.getCGLConfigInfo(Native Method) > at sun.java2d.opengl.CGLGraphicsConfig.getConfig(CGLGraphicsConfig.java:147) > at sun.awt.CGraphicsDevice.(CGraphicsDevice.java:64) > at sun.awt.CGraphicsEnvironment.initDevices(CGraphicsEnvironment.java:163) > - locked <0x00000006c0df8c18> (a sun.awt.CGraphicsEnvironment) > at sun.awt.CGraphicsEnvironment.getDefaultScreenDevice(CGraphicsEnvironment.java:181) > - locked <0x00000006c0df8c18> (a sun.awt.CGraphicsEnvironment) > at sun.lwawt.macosx.LWCToolkit.getScreenResolution(LWCToolkit.java:415) > at net.miginfocom.swing.SwingComponentWrapper.getHorizontalScreenDPI(SwingComponentWrapper.java:260) > at net.miginfocom.swing.SwingComponentWrapper.getPixelUnitFactor(SwingComponentWrapper.java:119) > at net.miginfocom.layout.UnitValue.getPixelsExact(UnitValue.java:305) > at net.miginfocom.layout.UnitValue.getPixels(UnitValue.java:281) > [SNIP] > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > > "AppKit Thread" #11 daemon prio=5 os_prio=31 tid=0x00007fba59869800 nid=0x307 waiting on condition [0x00007fff52ac2000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000006c053b688> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) > at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) > at sun.awt.SunToolkit.awtLock(SunToolkit.java:253) > at sun.java2d.pipe.RenderQueue.lock(RenderQueue.java:112) > at sun.java2d.opengl.CGLLayer.drawInCGLContext(CGLLayer.java:139) > > Native stacks > > Thread 0x6764ca DispatchQueue 1 Thread name "AppKit Thread" 1000 samples (1-1000) priority 46 (base 46) > 1000 start + 52 (Charles + 5156) [0x10d139424] > 1000 main + 153 (Charles + 5321) [0x10d1394c9] > 1000 launch + 10872 (Charles + 16520) [0x10d13c088] > 1000 JLI_Launch + 1952 (libjli.dylib + 5668) [0x10d1b9624] > 1000 CreateExecutionEnvironment + 871 (libjli.dylib + 22781) [0x10d1bd8fd] > 1000 CFRunLoopRunSpecific + 420 (CoreFoundation + 555380) [0x7fff97665974] > 1000 __CFRunLoopRun + 934 (CoreFoundation + 556918) [0x7fff97665f76] > 1000 __CFRunLoopDoSources0 + 557 (CoreFoundation + 559741) [0x7fff97666a7d] > 1000 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 (CoreFoundation + 686465) [0x7fff97685981] > 1000 __NSThreadPerformPerform + 326 (Foundation + 465034) [0x7fff990c988a] > 1000 -[AWTStarter starter:] + 905 (libawt_lwawt.dylib + 286207) [0x12abc3dff] > 1000 +[NSApplicationAWT runAWTLoopWithApp:] + 156 (libosxapp.dylib + 8525) [0x12ac3c14d] > [SNIP] > 1000 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 108 (QuartzCore + 69522) [0x7fff9d393f92] > 1000 CA::Transaction::commit() + 475 (QuartzCore + 67121) [0x7fff9d393631] > 1000 CA::Context::commit_transaction(CA::Transaction*) + 280 (QuartzCore + 1153144) [0x7fff9d49c878] > 1000 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 35 (QuartzCore + 1196185) [0x7fff9d4a7099] > 1000 CA::Layer::display_if_needed(CA::Transaction*) + 572 (QuartzCore + 1195886) [0x7fff9d4a6f6e] > 1000 -[CAOpenGLLayer _display] + 351 (QuartzCore + 1117583) [0x7fff9d493d8f] > 1000 CAOpenGLLayerDraw(CAOpenGLLayer*, double, CVTimeStamp const*, unsigned int) + 873 (QuartzCore + 1118737) [0x7fff9d494211] > 1000 -[CGLLayer drawInCGLContext:pixelFormat:forLayerTime:displayTime:] + 287 (libawt_lwawt.dylib + 109022) [0x12ab989de] > 1000 JNFCallVoidMethod + 187 (JavaNativeFoundation + 13743) [0x12a84f5af] > 1000 jni_CallVoidMethodV + 248 (libjvm.dylib + 3069241) [0x10edb8539] > 1000 jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 748 (libjvm.dylib + 3124227) [0x10edc5c03] > 1000 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 (libjvm.dylib + 3015574) [0x10edab396] > 1000 ??? [0x10ffa0854] > 1000 ??? [0x11027642a] > 1000 Unsafe_Park + 126 (libjvm.dylib + 5571927) [0x10f01b557] > 1000 Parker::park(bool, long) + 495 (libjvm.dylib + 4560765) [0x10ef2477d] > 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] > *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] > > Thread 0x67652b Thread name "Java: AWT-EventQueue-0" 1000 samples (1-1000) priority 31 (base 31) > 1000 thread_start + 13 (libsystem_pthread.dylib + 12797) [0x7fffacdd51fd] > 1000 _pthread_start + 286 (libsystem_pthread.dylib + 14839) [0x7fffacdd59f7] > 1000 _pthread_body + 180 (libsystem_pthread.dylib + 15019) [0x7fffacdd5aab] > 1000 java_start(Thread*) + 246 (libjvm.dylib + 4574506) [0x10ef27d2a] > 1000 JavaThread::run() + 448 (libjvm.dylib + 5486408) [0x10f006748] > 1000 JavaThread::thread_main_inner() + 155 (libjvm.dylib + 5480593) [0x10f005091] > 1000 thread_entry(JavaThread*, Thread*) + 124 (libjvm.dylib + 3270354) [0x10ede96d2] > [SNIP] > 1000 ??? [0x10f7a0734] > 1000 Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo + 279 (libawt_lwawt.dylib + 107562) [0x12ab9842a] > 1000 -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] + 131 (Foundation + 203394) [0x7fff99089a82] > 1000 -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] + 904 (Foundation + 204424) [0x7fff99089e88] > 1000 -[NSCondition wait] + 240 (Foundation + 208331) [0x7fff9908adcb] > 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] > *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] > > > INTERPRETATION > > The deadlock is a race condition when macOS changes between the discrete and integrated GPU. > > When the GPU changes, the result of CGraphicsEnvironment.getMainDisplayID() changes immediately (There is a comment in CGraphicsEnvironment.m > that notes that the display ID changes in this case, and I have verified this) to return the new displayID, while the devices map is only built once initDevices() is called. > > CGLGraphicsConfig.getCGLConfigInfo (which is called as a consequence of initDevices, as per stack traces) calls out and waits on the AppKit main thread. I think this is > always dangerous due to the locks that the code calling it holds. I think we should avoid getCGLConfigInfo being called on anything but the AppKit main thread. I believe > this was the intention of 8041900: [macosx] Java forces the use of discrete GPU (https://bugs.openjdk.java.net/browse/JDK-8041900 ). > > CGraphicsEnvironment.getDefaultScreenDevice() is called from AWT layout code (as per the stacks) and it calls CGraphicsEnvironment.getMainDisplayID() each time. > If CGraphicsEnvironment.getDefaultScreenDevice() is called _after_ the GPU change, but _before_ CGraphicsEnvironment._displayReconfiguration() has been called, > the CGraphicsDevice for the new display ID cannot be found in the devices Map, so initDevices() is called from CGraphicsEnvironment.getDefaultScreenDevice() > on the AWT-EventQueue thread. > > There is a note in getDefaultScreenDevice() for this case: > we do not expect that this may happen, the only response is to re-initialize the list of devices > > Calling initDevices() here results in a call to CGLGraphicsConfig.getCGLConfigInfo, which then calls > [GraphicsConfigUtil _getCGLConfigInfo:] on the AppKit main thread and waits for the result. > > As the current thread (AWT Event queue) is holding the AWT lock, and is synchronized on CGraphicsEnvironment, the two deadlock > conditions described above can occur. > > > REPRODUCABILITY > > This happens quite regularly on my machine, and for my users. To reproduce it I have launched my app while the integrated GPU is active, then launched and quit an app that requires the discrete GPU. One to five repetitions are required to create the hanging condition. > > I believe the issue is triggered by my use of MigLayout, which results in the call to CGraphicsEnvironment as per this excerpt from the stack traces above: > > at sun.awt.CGraphicsEnvironment.getDefaultScreenDevice(CGraphicsEnvironment.java:181) > - locked <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) > at sun.lwawt.macosx.LWCToolkit.getScreenResolution(LWCToolkit.java:415) > at net.miginfocom.swing.SwingComponentWrapper.getHorizontalScreenDPI(SwingComponentWrapper.java:260) > at net.miginfocom.swing.SwingComponentWrapper.getPixelUnitFactor(SwingComponentWrapper.java:119) > > > PATCH > > I believe the solution is to remember the main display ID along with the devices Map, and to change the main display ID when initDevices is called. > This appears to work in my setup. There is however _sometimes_ a flash of half-size rendering, presumably while the rendering is working on the old device > before the reconfiguration / initDevices occurs. > > Below is a simple patch to demonstrate that approach. Generally I don?t think initDevices() should ever be called on the AWT-EventQueue, but in my tests (as per the comment) > that no longer happens with this patch. > > diff -r 5dd7e4bae5c2 src/macosx/classes/sun/awt/CGraphicsEnvironment.java > --- a/src/macosx/classes/sun/awt/CGraphicsEnvironment.java Thu Sep 22 13:17:42 2016 -0700 > +++ b/src/macosx/classes/sun/awt/CGraphicsEnvironment.java Sat Jan 07 20:49:39 2017 +1300 > @@ -95,6 +95,7 @@ > > /** Available CoreGraphics displays. */ > private final Map devices = new HashMap<>(5); > + private int inittedMainDisplayID; > > /** Reference to the display reconfiguration callback context. */ > private final long displayReconfigContext; > @@ -153,6 +154,7 @@ > devices.clear(); > > int mainID = getMainDisplayID(); > + inittedMainDisplayID = mainID; > > // initialization of the graphics device may change > // list of displays on hybrid systems via an activation > @@ -173,14 +175,13 @@ > > @Override > public synchronized GraphicsDevice getDefaultScreenDevice() throws HeadlessException { > - final int mainDisplayID = getMainDisplayID(); > - CGraphicsDevice d = devices.get(mainDisplayID); > + CGraphicsDevice d = devices.get(inittedMainDisplayID); > if (d == null) { > // we do not expect that this may happen, the only response > // is to re-initialize the list of devices > initDevices(); > > - d = devices.get(mainDisplayID); > + d = devices.get(inittedMainDisplayID); > if (d == null) { > throw new AWTError("no screen devices"); > } > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Jan 11 17:49:58 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 11 Jan 2017 09:49:58 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8152561: Is it allowed to have zero value for count in TIFFField.createArrayForType() for the rationals Message-ID: Hello All, Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8152561 Webrev : http://cr.openjdk.java.net/~jdv/8152561/webrev.00/ Issue : There is difference in how we interpret "count" variable passed to TIFFField.createArrayForType(int dataType, int count) and constructor TIFFField(TIFFTag tag, int type, int count, Object data). Root cause : There are certain limitation on what the "count" value should be based on dataType of TIFFTag. We check these conditions in TIFFField(TIFFTag tag, int type, int count, Object data) but we don't verify all the conditions in TIFFField.createArrayForType(int dataType, int count). Solution : Verify all the required conditions that has to be applied on "count" variable based on datatype of TIFFTag in TIFFField.createArrayForType(int dataType, int count). Also I have made specification changes for TIFFField(TIFFTag tag, int type, int count) which will elaborate on what exceptions will be thrown if we don't follow same "count" and "dataType" relationship. Note : Because of tighter conditions in TIFFField.createArrayForType(int dataType, int count) under the proposed fix 2 JCK tests are failing. 1) api/javax_imageio/plugins/tiff/TIFFField/index.html#TIFFFieldTest : CreateArrayForType_ValidScenario This is failing because they are passing count values of 0 for TIFFTag.TIFF_RATIONAL & TIFFTag.TIFF_SRATIONAL which will throw IAE. Also it will throw IAE if we pass count value 0 or 2 for TIFFTag.TIFF_IFD_POINTER. 2) api/javax_imageio/plugins/tiff/TIFFField/index.html#ConstructorTests : Constructor02_TagIsNull_ThrowNPE I think this scenario expects constructor to throw NPE when "tag" is null. But before it checks for "tag" value in TIFFField(TIFFTag tag, int type, int count, Object data) we call TIFFField.createArrayForType(int dataType, int count) to create needed data. So like mentioned in previous JCK test which is failing, we will be throwing IAE in all cases where as test expects us to throw NPE. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Jan 12 02:34:56 2017 From: philip.race at oracle.com (Philip Race) Date: Wed, 11 Jan 2017 18:34:56 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8170578: The Pages Range From in print dialog is disabled In-Reply-To: <68d7b1d5-40f9-0841-0d6c-328861391f33@oracle.com> References: <39f21e6d-78fb-6486-0260-620f42a63ccb@oracle.com> <90c7f438-27ee-3334-d91a-5b1aff84e025@oracle.com> <224e283e-47c5-f254-bafd-de5beccf1584@oracle.com> <68d7b1d5-40f9-0841-0d6c-328861391f33@oracle.com> Message-ID: <5876EB50.2010305@oracle.com> I am looking at this and the hold up is I can't remember the protocol readIPPResponse() is trying to follow. Without that understanding it is hard to say much .. so I need to go read up and remember .. Two comments : There is an extra space in if (responseMap.length> 1) { The test update is bogus in referring to this bug. The change is nothing to do with the bug. And I actually prefer printer tests to throw nasty exceptions when there are no printers and they need one ... else SQE just don't configure printers on test systems and the tests all wrongly pass. Would you run Linux UI tests on a blade with no X-server running ? -phil. On 1/10/17, 1:14 AM, Prasanta Sadhukhan wrote: > > > > On 1/10/2017 2:43 PM, Prasanta Sadhukhan wrote: >> Actually, in ubuntu16.10 attribute map did not have >> "page-ranges-supported" attribute because 2 attribute hashmap is >> created in IPPPrintService#readIPPResponse() and most of the >> supported attributes are part of the 2nd hashmap (responseMap[1]) >> whereas only the 1st hashmap is utilised through responseMap[0] >> [http://hg.openjdk.java.net/jdk9/client/jdk/file/8be0bb1aa238/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1760] >> >> As to why 2 hashmaps are created in ubuntu16.10, it is because >> readIPPResponse() checks if key is already present in existing map, >> then create a new hashmap through this code >> >> and in ubuntu16.10, some attributes (like >> pwg-raster-document-type-supported which is not there in ubuntu >> 14.04] are duplicated. >> >> Proposed fix is to check if there are more than 1 hashmaps, if it is, >> get the entries from those maps, remove duplicate entries and append >> to existing hashmap to get a consolidated map having all the IPP >> attributes. >> > Missing webrev link: > http://cr.openjdk.java.net/~psadhukhan/8170578/webrev.01/ >> Regards >> Prasanta >> On 12/21/2016 11:28 PM, Phil Race wrote: >>> So now I am very suspicious. >>> First (previous fix I reviewed) Job Sheets weren't supported on >>> 16.10, now its PageRanges. >>> >>> I think this merits investigation of what is going on before we >>> commit this fix. >>> Why are attributes that have always been supported by CUPS suddenly >>> unavailable ? >>> >>> And for the cases we image the pages ourselves, we can implement >>> PageRanges >>> internally, so for a normal PrinterJob it always can be supported .. >>> regardless of >>> what the printer says. >>> >>> -phil. >>> >>> >>> On 12/14/2016 09:50 PM, Prasanta Sadhukhan wrote: >>>> >>>> Hi All, >>>> >>>> Please review a testbug fix for jdk9 for an issue where it it seen >>>> that PageRanges option is disabled in printer dialog in ubuntu16.10. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170578 >>>> >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8170578/webrev.00/ >>>> >>>> Issue was, in ubuntu16.10 the attribute map [obtained here >>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1767] >>>> does not have >>>> "pageranges-supported" attribute returned by CUPS >>>> so this category is not added to supported categories >>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1030] >>>> so isAttributeCategorySupported() called by ServiceDialog returns false >>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1141] >>>> resulting in PageRanges option getting disabled. >>>> >>>> Fix is to check if PageRanges category is supported in underlying >>>> platform, only then proceed with the test. >>>> >>>> Regards >>>> Prasanta >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at xk72.com Thu Jan 12 03:22:28 2017 From: karl at xk72.com (Karl von Randow) Date: Thu, 12 Jan 2017 16:22:28 +1300 Subject: [OpenJDK 2D-Dev] [PATCH] Deadlock in CGLGraphicsConfig.getCGLConfigInfo In-Reply-To: <18AD0EF9-82B2-4BD6-904A-EF1B0F72E7EA@oracle.com> References: <18AD0EF9-82B2-4BD6-904A-EF1B0F72E7EA@oracle.com> Message-ID: <21F7FC1E-B806-4DDF-AC92-AE8C0A85BF0E@xk72.com> Thanks Sergey, I?m sorry I didn?t discover this bug somehow! Yes, this bug appears to be the exactly same fault: We can see the Java2D Disposer thread blocked in the same spot as the AWT Event Queue thread was blocked in my examples, and for the same reason: "Java2D Disposer" #1366 daemon prio=10 os_prio=31 tid=0x000000016859b800 nid=0xefeb runnable [0x000070000635a000] java.lang.Thread.State: RUNNABLE at sun.java2d.opengl.CGLGraphicsConfig.getCGLConfigInfo(Native Method) at sun.java2d.opengl.CGLGraphicsConfig.getConfig(CGLGraphicsConfig.java:147) at sun.awt.CGraphicsDevice.(CGraphicsDevice.java:64) at sun.awt.CGraphicsEnvironment.initDevices(CGraphicsEnvironment.java:167) - locked <0x000000044cbdce00> (a sun.awt.CGraphicsEnvironment) at sun.awt.CGraphicsEnvironment.getDefaultScreenDevice(CGraphicsEnvironment.java:181) We can then see the main thread blocked trying to do the graphics device reconfiguration: "main" #1 prio=6 os_prio=31 tid=0x0000000105811800 nid=0x160b waiting for monitor entry [0x00007fff5fbfb000] java.lang.Thread.State: BLOCKED (on object monitor) at sun.awt.CGraphicsEnvironment._displayReconfiguration(CGraphicsEnvironment.java:129) - waiting to lock <0x000000044cbdce00> (a sun.awt.CGraphicsEnvironment) at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method) at org.eclipse.swt.widgets.Display.applicationNextEventMatchingMask(Display.java:5000) at org.eclipse.swt.widgets.Display.applicationProc(Display.java:5378) I believe my proposed patch will correct this issue as well, although I have not specifically reproduced this issue and tested the correction. I don?t think I can comment on bug report itself (I don?t have a login). I have submitted an OCA and I am just waiting on that at the moment. Once my OCA is confirmed I will send through the official review request. Thank you very much for the links to examples and information. Best regards, Karl > On 11/01/2017, at 9:42 AM, Sergey Bylokhov wrote: > > Hi, Karl. > > The correct alias to discuss this issue is 2d-dev. > > Looks like this bug was reported before. > https://bugs.openjdk.java.net/browse/JDK-8152683 > > Your evaluation and the fix seems reasonable. > If you already signed the OCA[1] then you can send an official review request to 2d-dev. An example: > http://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html > > [1] http://www.oracle.com/technetwork/community/oca-486395.html > > >> >> I have encountered a deadlock in Java 1.8.0_112 when changing between discrete and integrated GPU on a retina MacBook Pro. The deadlock is between: >> >> CGLGraphicsConfig.getCGLConfigInfo, running on AWT.EventQueue, trying to call [GraphicsConfigUtil _getCGLConfigInfo:] on >> the main thread (AppKit thread) while it holds the AWT lock and is synchronized on CGraphicsEnvironment. >> >> and >> >> A) the AppKit main thread trying to call CGraphicsEnvironment._displayReconfiguration (via displaycb_handle in CGraphicsEnv.m) >> and synchronizing on CGraphicsEnvironment?deadlock. >> >> or >> >> B) the AppKit main thread trying to render, and trying to acquire the OGLRenderQueue lock (which is the the AWT lock) >> >> >> SUPPORTING STACK DUMPS >> >> - SCENARIO A >> >> CGraphicsEnvironment._displayReconfiguration is called on the main thread since >> 8041900: [macosx] Java forces the use of discrete GPU (https://bugs.openjdk.java.net/browse/JDK-8041900 >) which appears as changeset 11227. >> In the native thread dump below you can see the frame for displaycb_handle which is the block dispatched to the main thread to call >> CGraphicsEnvironment._displayReconfiguration. >> >> Java stacks >> >> "AWT-EventQueue-0" #16 prio=6 os_prio=31 tid=0x00007fbc72a0a800 nid=0x1251f runnable [0x000070000e443000] >> java.lang.Thread.State: RUNNABLE >> at sun.java2d.opengl.CGLGraphicsConfig.getCGLConfigInfo(Native Method) >> at sun.java2d.opengl.CGLGraphicsConfig.getConfig(CGLGraphicsConfig.java:147) >> at sun.awt.CGraphicsDevice.(CGraphicsDevice.java:64) >> at sun.awt.CGraphicsEnvironment.initDevices(CGraphicsEnvironment.java:163) >> - locked <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) >> at sun.awt.CGraphicsEnvironment.getDefaultScreenDevice(CGraphicsEnvironment.java:181) >> - locked <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) >> at sun.lwawt.macosx.LWCToolkit.getScreenResolution(LWCToolkit.java:415) >> at net.miginfocom.swing.SwingComponentWrapper.getHorizontalScreenDPI(SwingComponentWrapper.java:260) >> at net.miginfocom.swing.SwingComponentWrapper.getPixelUnitFactor(SwingComponentWrapper.java:119) >> [SNIP] >> at java.awt.Container.layout(Container.java:1510) >> at java.awt.Container.doLayout(Container.java:1499) >> at java.awt.Container.validateTree(Container.java:1695) >> [SNIP] >> at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1750) >> [SNIP] >> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) >> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) >> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) >> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) >> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) >> >> "AppKit Thread" #11 daemon prio=5 os_prio=31 tid=0x00007fbc75046800 nid=0x307 waiting for monitor entry [0x00007fff5b579000] >> java.lang.Thread.State: BLOCKED (on object monitor) >> at sun.awt.CGraphicsEnvironment._displayReconfiguration(CGraphicsEnvironment.java:129) >> - waiting to lock <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) >> >> Native stacks >> >> Thread 0x6828c3 DispatchQueue 1 Thread name "AppKit Thread" 1000 samples (1-1000) priority 46 (base 46) cpu time <0.001 >> 1000 start + 52 (Charles + 5156) [0x104682424] >> 1000 main + 153 (Charles + 5321) [0x1046824c9] >> 1000 launch + 10872 (Charles + 16520) [0x104685088] >> 1000 JLI_Launch + 1952 (libjli.dylib + 5668) [0x104702624] >> 1000 CreateExecutionEnvironment + 871 (libjli.dylib + 22781) [0x1047068fd] >> 1000 CFRunLoopRunSpecific + 420 (CoreFoundation + 555380) [0x7fff97665974] >> 1000 __CFRunLoopRun + 934 (CoreFoundation + 556918) [0x7fff97665f76] >> 1000 __CFRunLoopDoSources0 + 557 (CoreFoundation + 559741) [0x7fff97666a7d] >> 1000 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 (CoreFoundation + 686465) [0x7fff97685981] >> 1000 __NSThreadPerformPerform + 326 (Foundation + 465034) [0x7fff990c988a] >> 1000 -[AWTStarter starter:] + 905 (libawt_lwawt.dylib + 286207) [0x113081dff] >> 1000 +[NSApplicationAWT runAWTLoopWithApp:] + 156 (libosxapp.dylib + 8525) [0x1130fa14d] >> [SNIP] >> 1000 +[JNFRunLoop _performCopiedBlock:] + 17 (JavaNativeFoundation + 28474) [0x112d0df3a] >> 1000 __displaycb_handle_block_invoke_1 + 172 (libawt_lwawt.dylib + 119659) [0x11305936b] >> 1000 JNFPerformEnvBlock + 87 (JavaNativeFoundation + 27229) [0x112d0da5d] >> 1000 __displaycb_handle_block_invoke_2 + 80 (libawt_lwawt.dylib + 119988) [0x1130594b4] >> 1000 JNFCallVoidMethod + 187 (JavaNativeFoundation + 13743) [0x112d0a5af] >> 1000 jni_CallVoidMethodV + 248 (libjvm.dylib + 3069241) [0x106301539] >> 1000 jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 748 (libjvm.dylib + 3124227) [0x10630ec03] >> 1000 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 (libjvm.dylib + 3015574) [0x1062f4396] >> 1000 ??? [0x113db94e7] >> 1000 ??? [0x113dde021] >> 1000 InterpreterRuntime::monitorenter(JavaThread*, BasicObjectLock*) + 165 (libjvm.dylib + 2995347) [0x1062ef493] >> 1000 ObjectMonitor::enter(Thread*) + 472 (libjvm.dylib + 4524724) [0x106464ab4] >> 1000 ObjectMonitor::EnterI(Thread*) + 532 (libjvm.dylib + 4521584) [0x106463e70] >> 1000 os::PlatformEvent::park(long) + 404 (libjvm.dylib + 4561328) [0x10646d9b0] >> 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] >> *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] >> >> Thread 0x68292c Thread name "Java: AWT-EventQueue-0" 1000 samples (1-1000) priority 31 (base 31) >> 1000 thread_start + 13 (libsystem_pthread.dylib + 12797) [0x7fffacdd51fd] >> 1000 _pthread_start + 286 (libsystem_pthread.dylib + 14839) [0x7fffacdd59f7] >> 1000 _pthread_body + 180 (libsystem_pthread.dylib + 15019) [0x7fffacdd5aab] >> 1000 java_start(Thread*) + 246 (libjvm.dylib + 4574506) [0x106470d2a] >> 1000 JavaThread::run() + 448 (libjvm.dylib + 5486408) [0x10654f748] >> 1000 JavaThread::thread_main_inner() + 155 (libjvm.dylib + 5480593) [0x10654e091] >> 1000 thread_entry(JavaThread*, Thread*) + 124 (libjvm.dylib + 3270354) [0x1063326d2] >> 1000 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 (libjvm.dylib + 3017936) [0x1062f4cd0] >> 1000 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 356 (libjvm.dylib + 3017508) [0x1062f4b24] >> 1000 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 (libjvm.dylib + 3015574) [0x1062f4396] >> [SNIP] >> 1000 Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo + 279 (libawt_lwawt.dylib + 107562) [0x11305642a] >> 1000 -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] + 131 (Foundation + 203394) [0x7fff99089a82] >> 1000 -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] + 904 (Foundation + 204424) [0x7fff99089e88] >> 1000 -[NSCondition wait] + 240 (Foundation + 208331) [0x7fff9908adcb] >> 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] >> *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] >> >> >> >> >> >> >> - Scenario B >> >> Java stacks >> >> "AWT-EventQueue-0" #15 prio=6 os_prio=31 tid=0x00007fba611d2000 nid=0x1260f runnable [0x0000700005365000] >> java.lang.Thread.State: RUNNABLE >> at sun.java2d.opengl.CGLGraphicsConfig.getCGLConfigInfo(Native Method) >> at sun.java2d.opengl.CGLGraphicsConfig.getConfig(CGLGraphicsConfig.java:147) >> at sun.awt.CGraphicsDevice.(CGraphicsDevice.java:64) >> at sun.awt.CGraphicsEnvironment.initDevices(CGraphicsEnvironment.java:163) >> - locked <0x00000006c0df8c18> (a sun.awt.CGraphicsEnvironment) >> at sun.awt.CGraphicsEnvironment.getDefaultScreenDevice(CGraphicsEnvironment.java:181) >> - locked <0x00000006c0df8c18> (a sun.awt.CGraphicsEnvironment) >> at sun.lwawt.macosx.LWCToolkit.getScreenResolution(LWCToolkit.java:415) >> at net.miginfocom.swing.SwingComponentWrapper.getHorizontalScreenDPI(SwingComponentWrapper.java:260) >> at net.miginfocom.swing.SwingComponentWrapper.getPixelUnitFactor(SwingComponentWrapper.java:119) >> at net.miginfocom.layout.UnitValue.getPixelsExact(UnitValue.java:305) >> at net.miginfocom.layout.UnitValue.getPixels(UnitValue.java:281) >> [SNIP] >> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) >> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) >> >> "AppKit Thread" #11 daemon prio=5 os_prio=31 tid=0x00007fba59869800 nid=0x307 waiting on condition [0x00007fff52ac2000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000006c053b688> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) >> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) >> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) >> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) >> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) >> at sun.awt.SunToolkit.awtLock(SunToolkit.java:253) >> at sun.java2d.pipe.RenderQueue.lock(RenderQueue.java:112) >> at sun.java2d.opengl.CGLLayer.drawInCGLContext(CGLLayer.java:139) >> >> Native stacks >> >> Thread 0x6764ca DispatchQueue 1 Thread name "AppKit Thread" 1000 samples (1-1000) priority 46 (base 46) >> 1000 start + 52 (Charles + 5156) [0x10d139424] >> 1000 main + 153 (Charles + 5321) [0x10d1394c9] >> 1000 launch + 10872 (Charles + 16520) [0x10d13c088] >> 1000 JLI_Launch + 1952 (libjli.dylib + 5668) [0x10d1b9624] >> 1000 CreateExecutionEnvironment + 871 (libjli.dylib + 22781) [0x10d1bd8fd] >> 1000 CFRunLoopRunSpecific + 420 (CoreFoundation + 555380) [0x7fff97665974] >> 1000 __CFRunLoopRun + 934 (CoreFoundation + 556918) [0x7fff97665f76] >> 1000 __CFRunLoopDoSources0 + 557 (CoreFoundation + 559741) [0x7fff97666a7d] >> 1000 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 (CoreFoundation + 686465) [0x7fff97685981] >> 1000 __NSThreadPerformPerform + 326 (Foundation + 465034) [0x7fff990c988a] >> 1000 -[AWTStarter starter:] + 905 (libawt_lwawt.dylib + 286207) [0x12abc3dff] >> 1000 +[NSApplicationAWT runAWTLoopWithApp:] + 156 (libosxapp.dylib + 8525) [0x12ac3c14d] >> [SNIP] >> 1000 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 108 (QuartzCore + 69522) [0x7fff9d393f92] >> 1000 CA::Transaction::commit() + 475 (QuartzCore + 67121) [0x7fff9d393631] >> 1000 CA::Context::commit_transaction(CA::Transaction*) + 280 (QuartzCore + 1153144) [0x7fff9d49c878] >> 1000 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 35 (QuartzCore + 1196185) [0x7fff9d4a7099] >> 1000 CA::Layer::display_if_needed(CA::Transaction*) + 572 (QuartzCore + 1195886) [0x7fff9d4a6f6e] >> 1000 -[CAOpenGLLayer _display] + 351 (QuartzCore + 1117583) [0x7fff9d493d8f] >> 1000 CAOpenGLLayerDraw(CAOpenGLLayer*, double, CVTimeStamp const*, unsigned int) + 873 (QuartzCore + 1118737) [0x7fff9d494211] >> 1000 -[CGLLayer drawInCGLContext:pixelFormat:forLayerTime:displayTime:] + 287 (libawt_lwawt.dylib + 109022) [0x12ab989de] >> 1000 JNFCallVoidMethod + 187 (JavaNativeFoundation + 13743) [0x12a84f5af] >> 1000 jni_CallVoidMethodV + 248 (libjvm.dylib + 3069241) [0x10edb8539] >> 1000 jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 748 (libjvm.dylib + 3124227) [0x10edc5c03] >> 1000 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 (libjvm.dylib + 3015574) [0x10edab396] >> 1000 ??? [0x10ffa0854] >> 1000 ??? [0x11027642a] >> 1000 Unsafe_Park + 126 (libjvm.dylib + 5571927) [0x10f01b557] >> 1000 Parker::park(bool, long) + 495 (libjvm.dylib + 4560765) [0x10ef2477d] >> 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] >> *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] >> >> Thread 0x67652b Thread name "Java: AWT-EventQueue-0" 1000 samples (1-1000) priority 31 (base 31) >> 1000 thread_start + 13 (libsystem_pthread.dylib + 12797) [0x7fffacdd51fd] >> 1000 _pthread_start + 286 (libsystem_pthread.dylib + 14839) [0x7fffacdd59f7] >> 1000 _pthread_body + 180 (libsystem_pthread.dylib + 15019) [0x7fffacdd5aab] >> 1000 java_start(Thread*) + 246 (libjvm.dylib + 4574506) [0x10ef27d2a] >> 1000 JavaThread::run() + 448 (libjvm.dylib + 5486408) [0x10f006748] >> 1000 JavaThread::thread_main_inner() + 155 (libjvm.dylib + 5480593) [0x10f005091] >> 1000 thread_entry(JavaThread*, Thread*) + 124 (libjvm.dylib + 3270354) [0x10ede96d2] >> [SNIP] >> 1000 ??? [0x10f7a0734] >> 1000 Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo + 279 (libawt_lwawt.dylib + 107562) [0x12ab9842a] >> 1000 -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] + 131 (Foundation + 203394) [0x7fff99089a82] >> 1000 -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] + 904 (Foundation + 204424) [0x7fff99089e88] >> 1000 -[NSCondition wait] + 240 (Foundation + 208331) [0x7fff9908adcb] >> 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] >> *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] >> >> >> INTERPRETATION >> >> The deadlock is a race condition when macOS changes between the discrete and integrated GPU. >> >> When the GPU changes, the result of CGraphicsEnvironment.getMainDisplayID() changes immediately (There is a comment in CGraphicsEnvironment.m >> that notes that the display ID changes in this case, and I have verified this) to return the new displayID, while the devices map is only built once initDevices() is called. >> >> CGLGraphicsConfig.getCGLConfigInfo (which is called as a consequence of initDevices, as per stack traces) calls out and waits on the AppKit main thread. I think this is >> always dangerous due to the locks that the code calling it holds. I think we should avoid getCGLConfigInfo being called on anything but the AppKit main thread. I believe >> this was the intention of 8041900: [macosx] Java forces the use of discrete GPU (https://bugs.openjdk.java.net/browse/JDK-8041900 >). >> >> CGraphicsEnvironment.getDefaultScreenDevice() is called from AWT layout code (as per the stacks) and it calls CGraphicsEnvironment.getMainDisplayID() each time. >> If CGraphicsEnvironment.getDefaultScreenDevice() is called _after_ the GPU change, but _before_ CGraphicsEnvironment._displayReconfiguration() has been called, >> the CGraphicsDevice for the new display ID cannot be found in the devices Map, so initDevices() is called from CGraphicsEnvironment.getDefaultScreenDevice() >> on the AWT-EventQueue thread. >> >> There is a note in getDefaultScreenDevice() for this case: >> we do not expect that this may happen, the only response is to re-initialize the list of devices >> >> Calling initDevices() here results in a call to CGLGraphicsConfig.getCGLConfigInfo, which then calls >> [GraphicsConfigUtil _getCGLConfigInfo:] on the AppKit main thread and waits for the result. >> >> As the current thread (AWT Event queue) is holding the AWT lock, and is synchronized on CGraphicsEnvironment, the two deadlock >> conditions described above can occur. >> >> >> REPRODUCABILITY >> >> This happens quite regularly on my machine, and for my users. To reproduce it I have launched my app while the integrated GPU is active, then launched and quit an app that requires the discrete GPU. One to five repetitions are required to create the hanging condition. >> >> I believe the issue is triggered by my use of MigLayout, which results in the call to CGraphicsEnvironment as per this excerpt from the stack traces above: >> >> at sun.awt.CGraphicsEnvironment.getDefaultScreenDevice(CGraphicsEnvironment.java:181) >> - locked <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) >> at sun.lwawt.macosx.LWCToolkit.getScreenResolution(LWCToolkit.java:415) >> at net.miginfocom.swing.SwingComponentWrapper.getHorizontalScreenDPI(SwingComponentWrapper.java:260) >> at net.miginfocom.swing.SwingComponentWrapper.getPixelUnitFactor(SwingComponentWrapper.java:119) >> >> >> PATCH >> >> I believe the solution is to remember the main display ID along with the devices Map, and to change the main display ID when initDevices is called. >> This appears to work in my setup. There is however _sometimes_ a flash of half-size rendering, presumably while the rendering is working on the old device >> before the reconfiguration / initDevices occurs. >> >> Below is a simple patch to demonstrate that approach. Generally I don?t think initDevices() should ever be called on the AWT-EventQueue, but in my tests (as per the comment) >> that no longer happens with this patch. >> >> diff -r 5dd7e4bae5c2 src/macosx/classes/sun/awt/CGraphicsEnvironment.java >> --- a/src/macosx/classes/sun/awt/CGraphicsEnvironment.java Thu Sep 22 13:17:42 2016 -0700 >> +++ b/src/macosx/classes/sun/awt/CGraphicsEnvironment.java Sat Jan 07 20:49:39 2017 +1300 >> @@ -95,6 +95,7 @@ >> >> /** Available CoreGraphics displays. */ >> private final Map devices = new HashMap<>(5); >> + private int inittedMainDisplayID; >> >> /** Reference to the display reconfiguration callback context. */ >> private final long displayReconfigContext; >> @@ -153,6 +154,7 @@ >> devices.clear(); >> >> int mainID = getMainDisplayID(); >> + inittedMainDisplayID = mainID; >> >> // initialization of the graphics device may change >> // list of displays on hybrid systems via an activation >> @@ -173,14 +175,13 @@ >> >> @Override >> public synchronized GraphicsDevice getDefaultScreenDevice() throws HeadlessException { >> - final int mainDisplayID = getMainDisplayID(); >> - CGraphicsDevice d = devices.get(mainDisplayID); >> + CGraphicsDevice d = devices.get(inittedMainDisplayID); >> if (d == null) { >> // we do not expect that this may happen, the only response >> // is to re-initialize the list of devices >> initDevices(); >> >> - d = devices.get(mainDisplayID); >> + d = devices.get(inittedMainDisplayID); >> if (d == null) { >> throw new AWTError("no screen devices"); >> } >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prem.balakrishnan at oracle.com Thu Jan 12 06:04:29 2017 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Wed, 11 Jan 2017 22:04:29 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request JDK-8172559 [PIT][TEST_BUG] Move @test to be 1st annotation in java/awt/image/Raster/TestChildRasterOp.java Message-ID: <5a79ee37-ba48-4cb3-ae9f-deaa442f6a4e@default> Hi, Please review fix for JDK 9, Bug: https://bugs.openjdk.java.net/browse/JDK-8172559 Webrev: http://cr.openjdk.java.net/~pkbalakr/8172559/webrev.00/ Jtreg Error: Not a test or directory containing tests: java/awt/image/Raster/TestChildRasterOp.java Cause: Wrong order of tag tokens , @test tag token should be the topmost tag. Regards, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Thu Jan 12 06:13:41 2017 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 11 Jan 2017 22:13:41 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request JDK-8172559 [PIT][TEST_BUG] Move @test to be 1st annotation in java/awt/image/Raster/TestChildRasterOp.java In-Reply-To: <5a79ee37-ba48-4cb3-ae9f-deaa442f6a4e@default> References: <5a79ee37-ba48-4cb3-ae9f-deaa442f6a4e@default> Message-ID: <0f6f32d3-13e0-4fc8-8168-373aabf72a78@default> Looks fine. Regards, Ajit From: Prem Balakrishnan Sent: Thursday, January 12, 2017 11:34 AM To: Ajit Ghaisas; Prasanta Sadhukhan; 2d-dev at openjdk.java.net Subject: Review Request JDK-8172559 [PIT][TEST_BUG] Move @test to be 1st annotation in java/awt/image/Raster/TestChildRasterOp.java Hi, Please review fix for JDK 9, Bug: https://bugs.openjdk.java.net/browse/JDK-8172559 Webrev: http://cr.openjdk.java.net/~pkbalakr/8172559/webrev.00/ Jtreg Error: Not a test or directory containing tests: java/awt/image/Raster/TestChildRasterOp.java Cause: Wrong order of tag tokens , @test tag token should be the topmost tag. Regards, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Jan 12 06:14:09 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 12 Jan 2017 11:44:09 +0530 Subject: [OpenJDK 2D-Dev] Review Request JDK-8172559 [PIT][TEST_BUG] Move @test to be 1st annotation in java/awt/image/Raster/TestChildRasterOp.java In-Reply-To: <5a79ee37-ba48-4cb3-ae9f-deaa442f6a4e@default> References: <5a79ee37-ba48-4cb3-ae9f-deaa442f6a4e@default> Message-ID: +1. BTW, append 2017 to copyright year, before pushing. Regards Prasanta On 1/12/2017 11:34 AM, Prem Balakrishnan wrote: > > Hi, > > Please review fix for JDK 9, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172559 > > Webrev: http://cr.openjdk.java.net/~pkbalakr/8172559/webrev.00/ > > > Jtreg Error: Not a test or directory containing tests: > java/awt/image/Raster/TestChildRasterOp.java > > Cause: Wrong order of tag tokens , @test tag token should be the > topmost tag. > > Regards, > > Prem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Jan 12 06:39:07 2017 From: philip.race at oracle.com (Philip Race) Date: Wed, 11 Jan 2017 22:39:07 -0800 Subject: [OpenJDK 2D-Dev] Review Request JDK-8172559 [PIT][TEST_BUG] Move @test to be 1st annotation in java/awt/image/Raster/TestChildRasterOp.java In-Reply-To: <5a79ee37-ba48-4cb3-ae9f-deaa442f6a4e@default> References: <5a79ee37-ba48-4cb3-ae9f-deaa442f6a4e@default> Message-ID: <5877248B.60809@oracle.com> This sounds like a jtreg bug since I don't see this specified. http://openjdk.java.net/jtreg/tag-spec.html -phil On 1/11/17, 10:04 PM, Prem Balakrishnan wrote: > > Hi, > > Please review fix for JDK 9, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172559 > > Webrev: http://cr.openjdk.java.net/~pkbalakr/8172559/webrev.00/ > > > Jtreg Error: Not a test or directory containing tests: > java/awt/image/Raster/TestChildRasterOp.java > > Cause: Wrong order of tag tokens , @test tag token should be the > topmost tag. > > Regards, > > Prem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hs at tagtraum.com Thu Jan 12 07:58:01 2017 From: hs at tagtraum.com (Hendrik Schreiber) Date: Thu, 12 Jan 2017 08:58:01 +0100 Subject: [OpenJDK 2D-Dev] [PATCH] Deadlock in CGLGraphicsConfig.getCGLConfigInfo In-Reply-To: <21F7FC1E-B806-4DDF-AC92-AE8C0A85BF0E@xk72.com> References: <18AD0EF9-82B2-4BD6-904A-EF1B0F72E7EA@oracle.com> <21F7FC1E-B806-4DDF-AC92-AE8C0A85BF0E@xk72.com> Message-ID: > On Jan 12, 2017, at 04:22, Karl von Randow wrote: > > I?m sorry I didn?t discover this bug somehow! Who cares??I really appreciate that you provide a fix after no progress has been made for more than half a year! That?s awesome. -hendrik From prem.balakrishnan at oracle.com Thu Jan 12 08:34:41 2017 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Thu, 12 Jan 2017 00:34:41 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request JDK-8172559 [PIT][TEST_BUG] Move @test to be 1st annotation in java/awt/image/Raster/TestChildRasterOp.java In-Reply-To: <5877248B.60809@oracle.com> References: <5a79ee37-ba48-4cb3-ae9f-deaa442f6a4e@default> <5877248B.60809@oracle.com> Message-ID: <28ec8383-043f-4607-a9c6-ecdb44bbe953@default> Hi Phil Agree with you. As it's a PIT bug with a simple fix - on Ajit and Prasanta's review, I have already pushed the fix. Regards, Prem From: Philip Race Sent: Thursday, January 12, 2017 12:09 PM To: Prem Balakrishnan; Jonathan Gibbons Cc: Ajit Ghaisas; Prasanta Sadhukhan; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request JDK-8172559 [PIT][TEST_BUG] Move @test to be 1st annotation in java/awt/image/Raster/TestChildRasterOp.java This sounds like a jtreg bug since I don't see this specified. http://openjdk.java.net/jtreg/tag-spec.html -phil On 1/11/17, 10:04 PM, Prem Balakrishnan wrote: Hi, Please review fix for JDK 9, Bug: https://bugs.openjdk.java.net/browse/JDK-8172559 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8172559/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8172559/webrev.00/ Jtreg Error: Not a test or directory containing tests: java/awt/image/Raster/TestChildRasterOp.java Cause: Wrong order of tag tokens , @test tag token should be the topmost tag. Regards, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From yuri.nesterenko at oracle.com Thu Jan 12 09:03:50 2017 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 12 Jan 2017 12:03:50 +0300 Subject: [OpenJDK 2D-Dev] Review Request JDK-8172559 [PIT][TEST_BUG] Move @test to be 1st annotation in java/awt/image/Raster/TestChildRasterOp.java In-Reply-To: <28ec8383-043f-4607-a9c6-ecdb44bbe953@default> References: <5a79ee37-ba48-4cb3-ae9f-deaa442f6a4e@default> <5877248B.60809@oracle.com> <28ec8383-043f-4607-a9c6-ecdb44bbe953@default> Message-ID: <066c7f7c-cc97-906f-8ed0-634cf0a65dba@oracle.com> On 01/12/2017 11:34 AM, Prem Balakrishnan wrote: > Hi Phil > > > > Agree with you. > > As it?s a PIT bug with a simple fix ? on Ajit and Prasanta?s review, I > have already pushed the fix. And I'm sorry about that. There will be merge :-(. We cannot push this buggy test to master: jtreg may stop the whole run. -yan > > > > Regards, > > Prem > > > > > > *From:*Philip Race > *Sent:* Thursday, January 12, 2017 12:09 PM > *To:* Prem Balakrishnan; Jonathan Gibbons > *Cc:* Ajit Ghaisas; Prasanta Sadhukhan; 2d-dev at openjdk.java.net > *Subject:* Re: [OpenJDK 2D-Dev] Review Request JDK-8172559 > [PIT][TEST_BUG] Move @test to be 1st annotation in > java/awt/image/Raster/TestChildRasterOp.java > > > > This sounds like a jtreg bug since I don't see this specified. > > http://openjdk.java.net/jtreg/tag-spec.html > > -phil > > On 1/11/17, 10:04 PM, Prem Balakrishnan wrote: > > Hi, > > Please review fix for JDK 9, > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172559 > > Webrev: http://cr.openjdk.java.net/~pkbalakr/8172559/webrev.00/ > > > > > Jtreg Error: Not a test or directory containing tests: > java/awt/image/Raster/TestChildRasterOp.java > > Cause: Wrong order of tag tokens , @test tag token should be the topmost > tag. > > > > Regards, > > Prem > From philip.race at oracle.com Thu Jan 12 13:48:58 2017 From: philip.race at oracle.com (Philip Race) Date: Thu, 12 Jan 2017 05:48:58 -0800 Subject: [OpenJDK 2D-Dev] Review Request JDK-8172559 [PIT][TEST_BUG] Move @test to be 1st annotation in java/awt/image/Raster/TestChildRasterOp.java In-Reply-To: <066c7f7c-cc97-906f-8ed0-634cf0a65dba@oracle.com> References: <5a79ee37-ba48-4cb3-ae9f-deaa442f6a4e@default> <5877248B.60809@oracle.com> <28ec8383-043f-4607-a9c6-ecdb44bbe953@default> <066c7f7c-cc97-906f-8ed0-634cf0a65dba@oracle.com> Message-ID: <5877894A.2020103@oracle.com> So I will need to fix this in PIT under a different bug ID. -phil. On 1/12/17, 1:03 AM, Yuri Nesterenko wrote: > On 01/12/2017 11:34 AM, Prem Balakrishnan wrote: >> Hi Phil >> >> >> >> Agree with you. >> >> As it?s a PIT bug with a simple fix ? on Ajit and Prasanta?s review, I >> have already pushed the fix. > > And I'm sorry about that. There will be merge :-(. > We cannot push this buggy test to master: jtreg may stop the whole run. > > -yan > >> >> >> >> Regards, >> >> Prem >> >> >> >> >> >> *From:*Philip Race >> *Sent:* Thursday, January 12, 2017 12:09 PM >> *To:* Prem Balakrishnan; Jonathan Gibbons >> *Cc:* Ajit Ghaisas; Prasanta Sadhukhan; 2d-dev at openjdk.java.net >> *Subject:* Re: [OpenJDK 2D-Dev] Review Request JDK-8172559 >> [PIT][TEST_BUG] Move @test to be 1st annotation in >> java/awt/image/Raster/TestChildRasterOp.java >> >> >> >> This sounds like a jtreg bug since I don't see this specified. >> >> http://openjdk.java.net/jtreg/tag-spec.html >> >> -phil >> >> On 1/11/17, 10:04 PM, Prem Balakrishnan wrote: >> >> Hi, >> >> Please review fix for JDK 9, >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8172559 >> >> Webrev: http://cr.openjdk.java.net/~pkbalakr/8172559/webrev.00/ >> >> >> >> >> Jtreg Error: Not a test or directory containing tests: >> java/awt/image/Raster/TestChildRasterOp.java >> >> Cause: Wrong order of tag tokens , @test tag token should be the topmost >> tag. >> >> >> >> Regards, >> >> Prem >> > From prahalad.kumar.narayanan at oracle.com Fri Jan 13 09:24:06 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Fri, 13 Jan 2017 01:24:06 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP Message-ID: <3bb30333-41ef-4ad3-99c1-71388097e5dc@default> Hello Everyone Good day to you. Request your time in reviewing the fix for bug . [JDK-8167278] : ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP Root Cause . The issue seems to stem from a mal-formed RLE4 Encoded Bitmap Image . Specifically - the width as mentioned in header and encoded image data do not match. . Unfortunately, the decoder logic doesn't contain guard checks to prevent out of bounds array access. Fix Details: . Necessary guard conditions have been put to the RLE4 bitmap decoding logic. . Besides, two new issues were observed in same function block. They have been addressed as well. i. The last scanline of decoded image is missed in destination image (when EoF sequence arrives without EoL) . This was observed with a sample image created with gimp tool. ii. Handling of Delta encoding (0x00 0x02 xOffset yOffset) . The scanline of decoded image should be copied to destination if yOff shifts next pixel's location to other line . Secondly, the scanline index should be limited by boundary value after x and y offsets are added. . Note: I couldn't create a suitable image with Delta encoding in image buffer. Hence this small change could not be tested. Other Details: . The fix was run through both Jtreg and JCK test suites. No regressions were seen. The changes are available for your review under: Link: http://cr.openjdk.java.net/~pnarayanan/8167278/webrev.00/ Kindly review the changes at your convenience and share your feedback. Thank you for your time in review Have a good day Prahalad N. From philip.race at oracle.com Fri Jan 13 21:06:44 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 13 Jan 2017 13:06:44 -0800 Subject: [OpenJDK 2D-Dev] RFR 8171456: Upgrade harfbuzz in JDK 9 to v1.4.1 Message-ID: <4e3e2147-b6f4-306d-8791-3b58ec105a43@oracle.com> JDK9 currently has Harfbuzz v 1.3 from July 2016. The latest is HB 1.4.1 (Jan 6th 2017) and this change updates JDK 9 to that version Bug: https://bugs.openjdk.java.net/browse/JDK-8171456 Webrev: http://cr.openjdk.java.net/~prr/8171456 There are a lot of files changed, but nothing radical. JPRT builds it on all platforms, layout tests still work/pass. About 15 files are whitespace only changes so don't be surprised by apparently empty diffs. -phil. From philip.race at oracle.com Fri Jan 13 23:11:49 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 13 Jan 2017 15:11:49 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8172813 test/java/awt/font/JNICheck/JNICheck.sh fails on Linux Message-ID: <95994233-3c90-4569-a67d-9327cda46b0f@oracle.com> Bug : https://bugs.openjdk.java.net/browse/JDK-8172813 Webrev : http://cr.openjdk.java.net/~prr/8172813/ - Clear local refs once we are done with them. - Use grep to filter out from the log unrelated warnings as separately reported here : https://bugs.openjdk.java.net/browse/JDK-8131136 -phil. From dmitry.markov at oracle.com Sat Jan 14 14:52:09 2017 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Sat, 14 Jan 2017 17:52:09 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163889: [macosx] Can't print from browser on Mac OS X Message-ID: <00DB423C-EF8C-44DE-93E6-8071256D98D4@oracle.com> Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8163889 webrev: http://cr.openjdk.java.net/~dmarkov/8163889/webrev.00/ Problem description: Several functions inside ImageSurfaceData.m, (e.g. customPixelsFromJava(), customPixelsToJava(), etc.) invoke getJNIEnv() from ThreadUtilities instead of usage corresponding input parameter. According to the design - getJNIEnv() should be executed on AppKit thread, but all code related to printing should NOT run on AppKit thread. So we get the following assert here - ?CocoaAWT: Not running on AppKit thread 0 when expected.? Also customPixelsFromJava() and customPixelsToJava() call OSXOffScreenSurfaceData.syncFromCustom() and OSXOffScreenSurfaceData.syncToCustom(), but these methods are absent at Java layer. So when we try to perform such JNI invocation we experience the crash. Fix: It is necessary to eliminate negative effects such as crashes, native exceptions and assert errors during printing. Change summary: - Replaced invocation of getJNIEnv() with usage of corresponding input parameter. - Added method stubs to OSXOffScreenSurfaceData. Thanks, Dmitry From prasanta.sadhukhan at oracle.com Mon Jan 16 06:14:07 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 16 Jan 2017 11:44:07 +0530 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163889: [macosx] Can't print from browser on Mac OS X In-Reply-To: <00DB423C-EF8C-44DE-93E6-8071256D98D4@oracle.com> References: <00DB423C-EF8C-44DE-93E6-8071256D98D4@oracle.com> Message-ID: Hi Dmitri, Don't you need to implement syncFromCustom() and syncToCustom()? If not, then it seems you do not need to call this functions from customPixelsFromJava() and customPixelsToJava() in which case, then env change/fix will not be needed. Also, is it not possible to create a regression testcase? Regards Prasanta On 1/14/2017 8:22 PM, Dmitry Markov wrote: > Hello, > > Could you review a fix for jdk9, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8163889 > webrev: http://cr.openjdk.java.net/~dmarkov/8163889/webrev.00/ > > Problem description: > Several functions inside ImageSurfaceData.m, (e.g. customPixelsFromJava(), customPixelsToJava(), etc.) invoke getJNIEnv() from ThreadUtilities instead of usage corresponding input parameter. According to the design - getJNIEnv() should be executed on AppKit thread, but all code related to printing should NOT run on AppKit thread. So we get the following assert here - ?CocoaAWT: Not running on AppKit thread 0 when expected.? > > Also customPixelsFromJava() and customPixelsToJava() call OSXOffScreenSurfaceData.syncFromCustom() and OSXOffScreenSurfaceData.syncToCustom(), but these methods are absent at Java layer. So when we try to perform such JNI invocation we experience the crash. > > Fix: > It is necessary to eliminate negative effects such as crashes, native exceptions and assert errors during printing. > > Change summary: > - Replaced invocation of getJNIEnv() with usage of corresponding input parameter. > - Added method stubs to OSXOffScreenSurfaceData. > > Thanks, > Dmitry From prasanta.sadhukhan at oracle.com Mon Jan 16 06:57:38 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 16 Jan 2017 12:27:38 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8172813 test/java/awt/font/JNICheck/JNICheck.sh fails on Linux In-Reply-To: <95994233-3c90-4569-a67d-9327cda46b0f@oracle.com> References: <95994233-3c90-4569-a67d-9327cda46b0f@oracle.com> Message-ID: <2fe6d24a-fdd6-681a-fe71-5fb1d7c6d6e1@oracle.com> looks good to me. Regards Prasanta On 1/14/2017 4:41 AM, Phil Race wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8172813 > Webrev : http://cr.openjdk.java.net/~prr/8172813/ > > - Clear local refs once we are done with them. > - Use grep to filter out from the log unrelated warnings as separately > reported here : > > https://bugs.openjdk.java.net/browse/JDK-8131136 > > -phil. From vadim.pakhnushev at oracle.com Mon Jan 16 09:50:55 2017 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 16 Jan 2017 12:50:55 +0300 Subject: [OpenJDK 2D-Dev] RFR 8171456: Upgrade harfbuzz in JDK 9 to v1.4.1 In-Reply-To: <4e3e2147-b6f4-306d-8791-3b58ec105a43@oracle.com> References: <4e3e2147-b6f4-306d-8791-3b58ec105a43@oracle.com> Message-ID: <3df4d8bc-1b6b-5d61-de56-4fbe1cf65385@oracle.com> Looks good. Vadim On 14.01.2017 0:06, Phil Race wrote: > JDK9 currently has Harfbuzz v 1.3 from July 2016. > The latest is HB 1.4.1 (Jan 6th 2017) and this change updates JDK 9 to > that version > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171456 > > Webrev: http://cr.openjdk.java.net/~prr/8171456 > > There are a lot of files changed, but nothing radical. > JPRT builds it on all platforms, layout tests still work/pass. > > About 15 files are whitespace only changes so don't be surprised by > apparently empty diffs. > > -phil. > > > > From sergey.bylokhov at oracle.com Mon Jan 16 17:07:26 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 16 Jan 2017 20:07:26 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8172813 test/java/awt/font/JNICheck/JNICheck.sh fails on Linux In-Reply-To: <95994233-3c90-4569-a67d-9327cda46b0f@oracle.com> References: <95994233-3c90-4569-a67d-9327cda46b0f@oracle.com> Message-ID: <413DBFBC-EF85-450C-BB96-018312D0EA70@oracle.com> Hi, Phil. Should we add DeleteLocalRef in fontpath.c at lines 1140 and 1166, or both were skipped intentionally? > > Bug : https://bugs.openjdk.java.net/browse/JDK-8172813 > Webrev : http://cr.openjdk.java.net/~prr/8172813/ > > - Clear local refs once we are done with them. > - Use grep to filter out from the log unrelated warnings as separately reported here : > > https://bugs.openjdk.java.net/browse/JDK-8131136 > > -phil. From sergey.bylokhov at oracle.com Mon Jan 16 17:18:51 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 16 Jan 2017 20:18:51 +0300 Subject: [OpenJDK 2D-Dev] RFR 8171456: Upgrade harfbuzz in JDK 9 to v1.4.1 In-Reply-To: <3df4d8bc-1b6b-5d61-de56-4fbe1cf65385@oracle.com> References: <4e3e2147-b6f4-306d-8791-3b58ec105a43@oracle.com> <3df4d8bc-1b6b-5d61-de56-4fbe1cf65385@oracle.com> Message-ID: <9BE7B298-1641-4075-BC26-83FBCD95957D@oracle.com> Looks fine, I assume that there are no changes in hb-atomic-private.hh and the fix for JDK-8145077 was not purged [1] [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4d367c763183 > > Looks good. > > Vadim > > On 14.01.2017 0:06, Phil Race wrote: >> JDK9 currently has Harfbuzz v 1.3 from July 2016. >> The latest is HB 1.4.1 (Jan 6th 2017) and this change updates JDK 9 to that version >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8171456 >> >> Webrev: http://cr.openjdk.java.net/~prr/8171456 >> >> There are a lot of files changed, but nothing radical. >> JPRT builds it on all platforms, layout tests still work/pass. >> >> About 15 files are whitespace only changes so don't be surprised by apparently empty diffs. >> >> -phil. >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Jan 17 07:17:42 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 17 Jan 2017 12:47:42 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8152561: Is it allowed to have zero value for count in TIFFField.createArrayForType() for the rationals In-Reply-To: References: Message-ID: <11ec13a4-cae7-ecac-2fc5-1f4431f3cceb@oracle.com> Looks good to me. Only thing is that in the test, if one test fails it will not proceed to the next test. I think we should test all combinations and fail at last with the informations of all failed combinations. Regards Prasanta On 1/11/2017 11:19 PM, Jayathirth D V wrote: > > Hello All, > > Please review the following fix in JDK9: > > Bug : https://bugs.openjdk.java.net/browse/JDK-8152561 > > Webrev : http://cr.openjdk.java.net/~jdv/8152561/webrev.00/ > > > Issue : There is difference in how we interpret ?count? variable > passed to TIFFField.createArrayForType(int dataType, int count) and > constructor TIFFField(TIFFTag tag, int type, int count, Object data). > > Root cause : There are certain limitation on what the ?count? value > should be based on dataType of TIFFTag. We check these conditions in > TIFFField(TIFFTag tag, int type, int count, Object data) but we don?t > verify all the conditions in TIFFField.createArrayForType(int > dataType, int count). > > Solution : Verify all the required conditions that has to be applied > on ?count? variable based on datatype of TIFFTag in > TIFFField.createArrayForType(int dataType, int count). Also I have > made specification changes for TIFFField(TIFFTag tag, int type, int > count) which will elaborate on what exceptions will be thrown if we > don?t follow same ?count? and ?dataType? relationship. > > Note : Because of tighter conditions in > TIFFField.createArrayForType(int dataType, int count) under the > proposed fix 2 JCK tests are failing. > > 1)_api/javax_imageio/plugins/tiff/TIFFField/index.html#TIFFFieldTest : > /CreateArrayForType_ValidScenario/_ > > This is failing because they are passing count values of 0 for > TIFFTag.TIFF_RATIONAL & TIFFTag.TIFF_SRATIONAL which will throw IAE. > Also it will throw IAE if we pass count value 0 or 2 for > TIFFTag.TIFF_IFD_POINTER. > > 2)_api/javax_imageio/plugins/tiff/TIFFField/index.html#ConstructorTests > : /Constructor02_TagIsNull_ThrowNPE/_ > > I think this scenario expects constructor to throw NPE when ?tag? is > null. But before it checks for ?tag? value in TIFFField(TIFFTag tag, > int type, int count, Object data) we call > TIFFField.createArrayForType(int dataType, int count) to create needed > data. So like mentioned in previous JCK test which is failing, we will > be throwing IAE in all cases where as test expects us to throw NPE. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Tue Jan 17 13:42:20 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 17 Jan 2017 14:42:20 +0100 Subject: [OpenJDK 2D-Dev] RFR 8171456: Upgrade harfbuzz in JDK 9 to v1.4.1 In-Reply-To: <9BE7B298-1641-4075-BC26-83FBCD95957D@oracle.com> References: <4e3e2147-b6f4-306d-8791-3b58ec105a43@oracle.com> <3df4d8bc-1b6b-5d61-de56-4fbe1cf65385@oracle.com> <9BE7B298-1641-4075-BC26-83FBCD95957D@oracle.com> Message-ID: Hi Sergey, thanks for caring for our AIX changes :) They've been committed up-stream in December 2015 already so that shouldn't be a problem any more. I've also checked that the changes for JDK-8171248 which we've done directly up-stream are present in this upgrade. So thumbs up from me! Volker [1] https://bugs.openjdk.java.net/browse/JDK-8171248 On Mon, Jan 16, 2017 at 6:18 PM, Sergey Bylokhov wrote: > Looks fine, I assume that there are no changes in hb-atomic-private.hh and > the fix for JDK-8145077 was not purged [1] > > [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4d367c763183 > > > > Looks good. > > Vadim > > On 14.01.2017 0:06, Phil Race wrote: > > JDK9 currently has Harfbuzz v 1.3 from July 2016. > The latest is HB 1.4.1 (Jan 6th 2017) and this change updates JDK 9 to that > version > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171456 > > Webrev: http://cr.openjdk.java.net/~prr/8171456 > > There are a lot of files changed, but nothing radical. > JPRT builds it on all platforms, layout tests still work/pass. > > About 15 files are whitespace only changes so don't be surprised by > apparently empty diffs. > > -phil. > > > > > > From philip.race at oracle.com Tue Jan 17 19:44:47 2017 From: philip.race at oracle.com (Phil Race) Date: Tue, 17 Jan 2017 11:44:47 -0800 Subject: [OpenJDK 2D-Dev] RFR 8171456: Upgrade harfbuzz in JDK 9 to v1.4.1 In-Reply-To: References: <4e3e2147-b6f4-306d-8791-3b58ec105a43@oracle.com> <3df4d8bc-1b6b-5d61-de56-4fbe1cf65385@oracle.com> <9BE7B298-1641-4075-BC26-83FBCD95957D@oracle.com> Message-ID: <6f84dd37-303b-ed8f-390e-add5af31c538@oracle.com> As Volker notes, the identical change was committed upstream and so 1.3 also showed "no changes" since they were there then, and no changes to hb-atomic-private.hh this time round either. -phil. On 01/17/2017 05:42 AM, Volker Simonis wrote: > Hi Sergey, > > thanks for caring for our AIX changes :) > They've been committed up-stream in December 2015 already so that > shouldn't be a problem any more. > > I've also checked that the changes for JDK-8171248 which we've done > directly up-stream are present in this upgrade. > > So thumbs up from me! > Volker > > [1] https://bugs.openjdk.java.net/browse/JDK-8171248 > > On Mon, Jan 16, 2017 at 6:18 PM, Sergey Bylokhov > wrote: >> Looks fine, I assume that there are no changes in hb-atomic-private.hh and >> the fix for JDK-8145077 was not purged [1] >> >> [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4d367c763183 >> >> >> >> Looks good. >> >> Vadim >> >> On 14.01.2017 0:06, Phil Race wrote: >> >> JDK9 currently has Harfbuzz v 1.3 from July 2016. >> The latest is HB 1.4.1 (Jan 6th 2017) and this change updates JDK 9 to that >> version >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8171456 >> >> Webrev: http://cr.openjdk.java.net/~prr/8171456 >> >> There are a lot of files changed, but nothing radical. >> JPRT builds it on all platforms, layout tests still work/pass. >> >> About 15 files are whitespace only changes so don't be surprised by >> apparently empty diffs. >> >> -phil. >> >> >> >> >> >> From philip.race at oracle.com Tue Jan 17 20:29:24 2017 From: philip.race at oracle.com (Phil Race) Date: Tue, 17 Jan 2017 12:29:24 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8172813 test/java/awt/font/JNICheck/JNICheck.sh fails on Linux In-Reply-To: <413DBFBC-EF85-450C-BB96-018312D0EA70@oracle.com> References: <95994233-3c90-4569-a67d-9327cda46b0f@oracle.com> <413DBFBC-EF85-450C-BB96-018312D0EA70@oracle.com> Message-ID: <65d232e2-47e4-2a78-c454-c144876af564@oracle.com> Both yes and no :-), although I think it is fine to add both. 1140 .. there are no more than 2 cachedirs (1 user + 1 system) so I didn't examine JNI refs in this loop 1166 .. I was not realistically expecting a "NULL" here so ignored it. Unlike some of the JNI bugs "call while pending exception" type bugs we've fixed these were actual, not hypothetical. Updated webrev: http://cr.openjdk.java.net/~prr/8172813.1 -phil. On 01/16/2017 09:07 AM, Sergey Bylokhov wrote: > Hi, Phil. > Should we add DeleteLocalRef in fontpath.c at lines 1140 and 1166, or both were skipped intentionally? > >> Bug : https://bugs.openjdk.java.net/browse/JDK-8172813 >> Webrev : http://cr.openjdk.java.net/~prr/8172813/ >> >> - Clear local refs once we are done with them. >> - Use grep to filter out from the log unrelated warnings as separately reported here : >> >> https://bugs.openjdk.java.net/browse/JDK-8131136 >> >> -phil. From jayathirth.d.v at oracle.com Wed Jan 18 09:03:10 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 18 Jan 2017 01:03:10 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8152561: Is it allowed to have zero value for count in TIFFField.createArrayForType() for the rationals In-Reply-To: <11ec13a4-cae7-ecac-2fc5-1f4431f3cceb@oracle.com> References: <11ec13a4-cae7-ecac-2fc5-1f4431f3cceb@oracle.com> Message-ID: <1dca39d1-82dd-45a4-a918-d0cb53257f70@default> Hi Prasanta, Thanks for your review. Now I am forcing all testcases to run even if any initial testcase fails. I have divided all 4 test cases into different functions and I am throwing proper RuntimeException based on what test case is failing. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/8152561/webrev.01/ Thanks, Jay From: Prasanta Sadhukhan Sent: Tuesday, January 17, 2017 12:48 PM To: Jayathirth D V; Philip Race; Brian Burkhalter; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8152561: Is it allowed to have zero value for count in TIFFField.createArrayForType() for the rationals Looks good to me. Only thing is that in the test, if one test fails it will not proceed to the next test. I think we should test all combinations and fail at last with the informations of all failed combinations. Regards Prasanta On 1/11/2017 11:19 PM, Jayathirth D V wrote: Hello All, Please review the following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8152561 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8152561/webrev.00/"http://cr.openjdk.java.net/~jdv/8152561/webrev.00/ Issue : There is difference in how we interpret "count" variable passed to TIFFField.createArrayForType(int dataType, int count) and constructor TIFFField(TIFFTag tag, int type, int count, Object data). Root cause : There are certain limitation on what the "count" value should be based on dataType of TIFFTag. We check these conditions in TIFFField(TIFFTag tag, int type, int count, Object data) but we don't verify all the conditions in TIFFField.createArrayForType(int dataType, int count). Solution : Verify all the required conditions that has to be applied on "count" variable based on datatype of TIFFTag in TIFFField.createArrayForType(int dataType, int count). Also I have made specification changes for TIFFField(TIFFTag tag, int type, int count) which will elaborate on what exceptions will be thrown if we don't follow same "count" and "dataType" relationship. Note : Because of tighter conditions in TIFFField.createArrayForType(int dataType, int count) under the proposed fix 2 JCK tests are failing. 1) api/javax_imageio/plugins/tiff/TIFFField/index.html#TIFFFieldTest : CreateArrayForType_ValidScenario This is failing because they are passing count values of 0 for TIFFTag.TIFF_RATIONAL & TIFFTag.TIFF_SRATIONAL which will throw IAE. Also it will throw IAE if we pass count value 0 or 2 for TIFFTag.TIFF_IFD_POINTER. 2) api/javax_imageio/plugins/tiff/TIFFField/index.html#ConstructorTests : Constructor02_TagIsNull_ThrowNPE I think this scenario expects constructor to throw NPE when "tag" is null. But before it checks for "tag" value in TIFFField(TIFFTag tag, int type, int count, Object data) we call TIFFField.createArrayForType(int dataType, int count) to create needed data. So like mentioned in previous JCK test which is failing, we will be throwing IAE in all cases where as test expects us to throw NPE. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Jan 18 09:11:47 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 18 Jan 2017 14:41:47 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8152561: Is it allowed to have zero value for count in TIFFField.createArrayForType() for the rationals In-Reply-To: <1dca39d1-82dd-45a4-a918-d0cb53257f70@default> References: <11ec13a4-cae7-ecac-2fc5-1f4431f3cceb@oracle.com> <1dca39d1-82dd-45a4-a918-d0cb53257f70@default> Message-ID: <51bbe3bd-a3fa-51fd-4c7a-9b45e9b064d9@oracle.com> Looks good to me. Regards Prasanta On 1/18/2017 2:33 PM, Jayathirth D V wrote: > > Hi Prasanta, > > Thanks for your review. > > Now I am forcing all testcases to run even if any initial testcase fails. > > I have divided all 4 test cases into different functions and I am > throwing proper RuntimeException based on what test case is failing. > > Please find updated webrev for review : > > http://cr.openjdk.java.net/~jdv/8152561/webrev.01/ > > > Thanks, > > Jay > > *From:*Prasanta Sadhukhan > *Sent:* Tuesday, January 17, 2017 12:48 PM > *To:* Jayathirth D V; Philip Race; Brian Burkhalter; 2d-dev > *Subject:* Re: [OpenJDK 2D-Dev] [9] RFR JDK-8152561: Is it allowed to > have zero value for count in TIFFField.createArrayForType() for the > rationals > > Looks good to me. > > Only thing is that in the test, if one test fails it will not proceed > to the next test. I think we should test all combinations and fail at > last with the informations of all failed combinations. > > Regards > Prasanta > > On 1/11/2017 11:19 PM, Jayathirth D V wrote: > > Hello All, > > Please review the following fix in JDK9: > > Bug : https://bugs.openjdk.java.net/browse/JDK-8152561 > > Webrev : http://cr.openjdk.java.net/~jdv/8152561/webrev.00/ > > > Issue : There is difference in how we interpret ?count? variable > passed to TIFFField.createArrayForType(int dataType, int count) > and constructor TIFFField(TIFFTag tag, int type, int count, Object > data). > > Root cause : There are certain limitation on what the ?count? > value should be based on dataType of TIFFTag. We check these > conditions in TIFFField(TIFFTag tag, int type, int count, Object > data) but we don?t verify all the conditions in > TIFFField.createArrayForType(int dataType, int count). > > Solution : Verify all the required conditions that has to be > applied on ?count? variable based on datatype of TIFFTag in > TIFFField.createArrayForType(int dataType, int count). Also I have > made specification changes for TIFFField(TIFFTag tag, int type, > int count) which will elaborate on what exceptions will be thrown > if we don?t follow same ?count? and ?dataType? relationship. > > Note : Because of tighter conditions in > TIFFField.createArrayForType(int dataType, int count) under the > proposed fix 2 JCK tests are failing. > > 1)_api/javax_imageio/plugins/tiff/TIFFField/index.html#TIFFFieldTest > : /CreateArrayForType_ValidScenario/_ > > This is failing because they are passing count values of 0 for > TIFFTag.TIFF_RATIONAL & TIFFTag.TIFF_SRATIONAL which will throw > IAE. Also it will throw IAE if we pass count value 0 or 2 for > TIFFTag.TIFF_IFD_POINTER. > > 2)_api/javax_imageio/plugins/tiff/TIFFField/index.html#ConstructorTests > : /Constructor02_TagIsNull_ThrowNPE/_ > > I think this scenario expects constructor to throw NPE when ?tag? > is null. But before it checks for ?tag? value in TIFFField(TIFFTag > tag, int type, int count, Object data) we call > TIFFField.createArrayForType(int dataType, int count) to create > needed data. So like mentioned in previous JCK test which is > failing, we will be throwing IAE in all cases where as test > expects us to throw NPE. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Jan 18 11:11:56 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 18 Jan 2017 16:41:56 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8170578: The Pages Range From in print dialog is disabled In-Reply-To: <5876EB50.2010305@oracle.com> References: <39f21e6d-78fb-6486-0260-620f42a63ccb@oracle.com> <90c7f438-27ee-3334-d91a-5b1aff84e025@oracle.com> <224e283e-47c5-f254-bafd-de5beccf1584@oracle.com> <68d7b1d5-40f9-0841-0d6c-328861391f33@oracle.com> <5876EB50.2010305@oracle.com> Message-ID: <65c06ba2-0e8e-3219-76bd-220fe15bb973@oracle.com> Ok. Updated webrev just in case we are not reading the protocol wrongly. http://cr.openjdk.java.net/~psadhukhan/8170578/webrev.02/ Regards Prasanta On 1/12/2017 8:04 AM, Philip Race wrote: > I am looking at this and the hold up is I can't remember the protocol > readIPPResponse() is > trying to follow. Without that understanding it is hard to say much .. > so I need to go read > up and remember .. > > Two comments : There is an extra space in > if (responseMap.length > 1) { > The test update is bogus in referring to this bug. The change is > nothing to do with the bug. > And I actually prefer printer tests to throw nasty exceptions when > there are no printers > and they need one ... else SQE just don't configure printers on test > systems and the tests all wrongly pass. > Would you run Linux UI tests on a blade with no X-server running ? > > -phil. > > On 1/10/17, 1:14 AM, Prasanta Sadhukhan wrote: >> >> >> >> On 1/10/2017 2:43 PM, Prasanta Sadhukhan wrote: >>> Actually, in ubuntu16.10 attribute map did not have >>> "page-ranges-supported" attribute because 2 attribute hashmap is >>> created in IPPPrintService#readIPPResponse() and most of the >>> supported attributes are part of the 2nd hashmap (responseMap[1]) >>> whereas only the 1st hashmap is utilised through responseMap[0] >>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/8be0bb1aa238/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1760] >>> >>> As to why 2 hashmaps are created in ubuntu16.10, it is because >>> readIPPResponse() checks if key is already present in existing map, >>> then create a new hashmap through this code >>> >>> and in ubuntu16.10, some attributes (like >>> pwg-raster-document-type-supported which is not there in ubuntu >>> 14.04] are duplicated. >>> >>> Proposed fix is to check if there are more than 1 hashmaps, if it >>> is, get the entries from those maps, remove duplicate entries and >>> append to existing hashmap to get a consolidated map having all the >>> IPP attributes. >>> >> Missing webrev link: >> http://cr.openjdk.java.net/~psadhukhan/8170578/webrev.01/ >>> Regards >>> Prasanta >>> On 12/21/2016 11:28 PM, Phil Race wrote: >>>> So now I am very suspicious. >>>> First (previous fix I reviewed) Job Sheets weren't supported on >>>> 16.10, now its PageRanges. >>>> >>>> I think this merits investigation of what is going on before we >>>> commit this fix. >>>> Why are attributes that have always been supported by CUPS suddenly >>>> unavailable ? >>>> >>>> And for the cases we image the pages ourselves, we can implement >>>> PageRanges >>>> internally, so for a normal PrinterJob it always can be supported >>>> .. regardless of >>>> what the printer says. >>>> >>>> -phil. >>>> >>>> >>>> On 12/14/2016 09:50 PM, Prasanta Sadhukhan wrote: >>>>> >>>>> Hi All, >>>>> >>>>> Please review a testbug fix for jdk9 for an issue where it it seen >>>>> that PageRanges option is disabled in printer dialog in ubuntu16.10. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170578 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8170578/webrev.00/ >>>>> >>>>> Issue was, in ubuntu16.10 the attribute map [obtained here >>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1767] >>>>> does not have >>>>> "pageranges-supported" attribute returned by CUPS >>>>> so this category is not added to supported categories >>>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1030] >>>>> so isAttributeCategorySupported() called by ServiceDialog returns >>>>> false >>>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1141] >>>>> resulting in PageRanges option getting disabled. >>>>> >>>>> Fix is to check if PageRanges category is supported in underlying >>>>> platform, only then proceed with the test. >>>>> >>>>> Regards >>>>> Prasanta >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Wed Jan 18 16:18:00 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 18 Jan 2017 19:18:00 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8172813 test/java/awt/font/JNICheck/JNICheck.sh fails on Linux In-Reply-To: <65d232e2-47e4-2a78-c454-c144876af564@oracle.com> References: <95994233-3c90-4569-a67d-9327cda46b0f@oracle.com> <413DBFBC-EF85-450C-BB96-018312D0EA70@oracle.com> <65d232e2-47e4-2a78-c454-c144876af564@oracle.com> Message-ID: <67A85F24-CC41-4A45-B227-5E3D2DE3527F@oracle.com> Looks fine. > > Both yes and no :-), although I think it is fine to add both. > > 1140 .. there are no more than 2 cachedirs (1 user + 1 system) so I didn't examine JNI refs in this loop > > 1166 .. I was not realistically expecting a "NULL" here so ignored it. > > Unlike some of the JNI bugs "call while pending exception" type bugs we've fixed > these were actual, not hypothetical. > > Updated webrev: > > http://cr.openjdk.java.net/~prr/8172813.1 > > > -phil. > > > On 01/16/2017 09:07 AM, Sergey Bylokhov wrote: >> Hi, Phil. >> Should we add DeleteLocalRef in fontpath.c at lines 1140 and 1166, or both were skipped intentionally? >> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8172813 >>> Webrev : http://cr.openjdk.java.net/~prr/8172813/ >>> >>> - Clear local refs once we are done with them. >>> - Use grep to filter out from the log unrelated warnings as separately reported here : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8131136 >>> >>> -phil. > From prahalad.kumar.narayanan at oracle.com Wed Jan 18 17:51:31 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Wed, 18 Jan 2017 09:51:31 -0800 (PST) Subject: [OpenJDK 2D-Dev] RFR: 8172813 test/java/awt/font/JNICheck/JNICheck.sh fails on Linux Message-ID: Hello Phil The change looks good - Reduces the number of local references held by the JNI function. Here are some findings : 1. I found additional references that could be released. You can check the severity of the problem and decide to release or skip. Line: 1129 Concerned Object: cacheDirArray. I believe the existing code may not create trouble as reference to object is outside the loop. Line: 1168 and Line: 1175 Concerned Object: fcCompFontObj Both these lines, either terminate /or continue the loop without releasing the reference. Line: 1330 Concerned Object: fcFont When jstr becomes NULL, for loop is exited with break without releasing the reference Line: 1364 Concerned Object: fcFontArr fcFontArr (new object array ) is created in every iteration of the loop. This could be released in this line alongside release of fcCompFontObj 2. Copyright notice to have 2017 instead of 2016 3. Question: Should we mask the other warning messages with 'grep -v' in JNICheck.sh ? Thanks Have a good day Prahalad N. ------------------------------ Message: 2 Date: Tue, 17 Jan 2017 12:29:24 -0800 From: Phil Race To: Sergey Bylokhov Cc: 2d-dev <2d-dev at openjdk.java.net> Subject: Re: [OpenJDK 2D-Dev] RFR: 8172813 test/java/awt/font/JNICheck/JNICheck.sh fails on Linux Message-ID: <65d232e2-47e4-2a78-c454-c144876af564 at oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Both yes and no :-), although I think it is fine to add both. 1140 .. there are no more than 2 cachedirs (1 user + 1 system) so I didn't examine JNI refs in this loop 1166 .. I was not realistically expecting a "NULL" here so ignored it. Unlike some of the JNI bugs "call while pending exception" type bugs we've fixed these were actual, not hypothetical. Updated webrev: http://cr.openjdk.java.net/~prr/8172813.1 -phil. On 01/16/2017 09:07 AM, Sergey Bylokhov wrote: > Hi, Phil. > Should we add DeleteLocalRef in fontpath.c at lines 1140 and 1166, or both were skipped intentionally? > >> Bug : https://bugs.openjdk.java.net/browse/JDK-8172813 >> Webrev : http://cr.openjdk.java.net/~prr/8172813/ >> >> - Clear local refs once we are done with them. >> - Use grep to filter out from the log unrelated warnings as separately reported here : >> >> https://bugs.openjdk.java.net/browse/JDK-8131136 >> >> -phil. From brian.burkhalter at oracle.com Wed Jan 18 18:34:18 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 18 Jan 2017 10:34:18 -0800 Subject: [OpenJDK 2D-Dev] JDK-7132728: is a patch welcome? In-Reply-To: References: Message-ID: Hello Sebastian, CCing the 2d-dev mailing list which is the apt forum for this topic. Patches are most welcome but need to be contributed according to the protocol delineated in [1]. Regards, Brian [1] http://openjdk.java.net/contribute/ On Jan 18, 2017, at 9:11 AM, Sebastian Bathke wrote: > Hi, > > I hope this is the correct mailing list for this imageIO issue. > > https://bugs.openjdk.java.net/browse/JDK-7132728 > > I found several workarounds for this by patched ImageReaders but would > rather see it get fixed in the JDK. > I wonder whether a path addressing the issue would be welcome as ? > > Regards > Sebastian From philip.race at oracle.com Wed Jan 18 23:08:18 2017 From: philip.race at oracle.com (Phil Race) Date: Wed, 18 Jan 2017 15:08:18 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8172999: Crash on Windows getting FontMetrics since JDK 9 b96 Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8172999 Webrev: http://cr.openjdk.java.net/~prr/8172999/ fix for a crash on windows. -phil. From philip.race at oracle.com Thu Jan 19 00:05:58 2017 From: philip.race at oracle.com (Phil Race) Date: Wed, 18 Jan 2017 16:05:58 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8172813 test/java/awt/font/JNICheck/JNICheck.sh fails on Linux In-Reply-To: References: Message-ID: <38850f8b-83e2-98e4-e8d2-e66bf8a9bf22@oracle.com> A couple of updates made : http://cr.openjdk.java.net/~prr/8172813,2 Comments in-line below -phil. On 01/18/2017 09:51 AM, Prahalad Kumar Narayanan wrote: > Hello Phil > > The change looks good - Reduces the number of local references held by the JNI function. > Here are some findings : > > 1. I found additional references that could be released. You can check the severity of the problem and decide to release or skip. > Line: 1129 Concerned Object: cacheDirArray. > I believe the existing code may not create trouble as reference to object is outside the loop. This is not really any different than the hundreds of other JNI methods that use some small number of local refs. It is indeed the ones in a loop that matter here. > > Line: 1168 and > Line: 1175 Concerned Object: fcCompFontObj > Both these lines, either terminate /or continue the loop without releasing the reference. 1168 I updated but 1175 causes a return to Java so freeing happens then automatically. > > Line: 1330 Concerned Object: fcFont > When jstr becomes NULL, for loop is exited with break without releasing the reference I looked at these before the first webrev and decided they weren't a problem in practice since this really should never happen. > > Line: 1364 Concerned Object: fcFontArr > fcFontArr (new object array ) is created in every iteration of the loop. > This could be released in this line alongside release of fcCompFontObj I added a Delete here - line 1368 in the new version. > > 2. Copyright notice to have 2017 instead of 2016 I rarely-to-never bother to update these. A script will be run at some point. > > 3. Question: Should we mask the other warning messages with 'grep -v' in JNICheck.sh ? I am not sure what you are asking here. I am masking the other warnings with grep -v .. and since I added doing that obviously I think we should :-) -phil. > > Thanks > Have a good day > > Prahalad N. > > ------------------------------ > > Message: 2 > Date: Tue, 17 Jan 2017 12:29:24 -0800 > From: Phil Race > To: Sergey Bylokhov > Cc: 2d-dev <2d-dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] RFR: 8172813 > test/java/awt/font/JNICheck/JNICheck.sh fails on Linux > Message-ID: <65d232e2-47e4-2a78-c454-c144876af564 at oracle.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Both yes and no :-), although I think it is fine to add both. > > 1140 .. there are no more than 2 cachedirs (1 user + 1 system) so I didn't examine JNI refs in this loop > > 1166 .. I was not realistically expecting a "NULL" here so ignored it. > > Unlike some of the JNI bugs "call while pending exception" type bugs we've fixed these were actual, not hypothetical. > > Updated webrev: > > http://cr.openjdk.java.net/~prr/8172813.1 > > > -phil. > > > On 01/16/2017 09:07 AM, Sergey Bylokhov wrote: >> Hi, Phil. >> Should we add DeleteLocalRef in fontpath.c at lines 1140 and 1166, or both were skipped intentionally? >> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8172813 >>> Webrev : http://cr.openjdk.java.net/~prr/8172813/ >>> >>> - Clear local refs once we are done with them. >>> - Use grep to filter out from the log unrelated warnings as separately reported here : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8131136 >>> >>> -phil. From philip.race at oracle.com Thu Jan 19 00:25:30 2017 From: philip.race at oracle.com (Phil Race) Date: Wed, 18 Jan 2017 16:25:30 -0800 Subject: [OpenJDK 2D-Dev] RFR: 6232267: TrueType Fonts which have only Apple platform names cannot be loaded In-Reply-To: <6a8b0ad4-94ac-83a0-b3f4-569747dbb980@oracle.com> References: <375323cc-f9ad-28af-563d-880aa3d0008b@oracle.com> <586D8B8C.4010600@oracle.com> <6a8b0ad4-94ac-83a0-b3f4-569747dbb980@oracle.com> Message-ID: <7ee1f63e-3782-b521-ccc2-e5aa32910dda@oracle.com> On 01/06/2017 12:33 AM, Prasanta Sadhukhan wrote: > > Hi Phil, > > Looks good to me . One thing is that, the check forplatformID != > MAC_PLATFORM_ID > shouldn't we do the same in initAllNames()? No, I don't think so. initAllNames() is specifically looking for all the Windows localised names and in this change the idea is just to find an English name on Mac .. not to look for others. > > Also, in the test, I guess we do not need > 33 import java.io.BufferedInputStream; > 35 import java.io.FileInputStream; > 36 import java.io.InputStream; > 37 > and copyright should be 2017. > Well, I wrote it in 2016 :-) .. I only posted it in 2017. Anyway I will make those changes before I push. -phil. > Regards > Prasanta > On 1/5/2017 5:25 AM, Philip Race wrote: >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-6232267 >> Webrev : http://cr.openjdk.java.net/~prr/6232267/ >> >> Fonts such as "Menlo" on OS X have no Microsoft names >> (see https://www.microsoft.com/typography/otspec/name.htm) >> so historically we rejected these. >> >> Now that we support OS X, this is more of an issue, and >> it is possible to run into a case where we fail to parse these fonts >> when they go through the Font.createFont() path, even on OS X. >> >> This adds that basic support for parsing Apple names so that >> we load the font. This support already exists on JavaFX. >> >> -phil. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Thu Jan 19 02:36:58 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Wed, 18 Jan 2017 18:36:58 -0800 (PST) Subject: [OpenJDK 2D-Dev] RFR: 8172813 test/java/awt/font/JNICheck/JNICheck.sh fails on Linux In-Reply-To: <38850f8b-83e2-98e4-e8d2-e66bf8a9bf22@oracle.com> References: <38850f8b-83e2-98e4-e8d2-e66bf8a9bf22@oracle.com> Message-ID: <56ef3390-831e-4183-a7ea-3370cd644f80@default> Hello Phil Thanks for the detailed follow-up. The change looks good. Btw, a small correction in the webrev link. ( , has been replaced with . ) http://cr.openjdk.java.net/~prr/8172813.2 Thanks Have a good day Prahalad N. -----Original Message----- From: Phil Race Sent: Thursday, January 19, 2017 5:36 AM To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] RFR: 8172813 test/java/awt/font/JNICheck/JNICheck.sh fails on Linux A couple of updates made : http://cr.openjdk.java.net/~prr/8172813,2 Comments in-line below -phil. On 01/18/2017 09:51 AM, Prahalad Kumar Narayanan wrote: > Hello Phil > > The change looks good - Reduces the number of local references held by the JNI function. > Here are some findings : > > 1. I found additional references that could be released. You can check the severity of the problem and decide to release or skip. > Line: 1129 Concerned Object: cacheDirArray. > I believe the existing code may not create trouble as reference to object is outside the loop. This is not really any different than the hundreds of other JNI methods that use some small number of local refs. It is indeed the ones in a loop that matter here. > > Line: 1168 and > Line: 1175 Concerned Object: fcCompFontObj > Both these lines, either terminate /or continue the loop without releasing the reference. 1168 I updated but 1175 causes a return to Java so freeing happens then automatically. > > Line: 1330 Concerned Object: fcFont > When jstr becomes NULL, for loop is exited > with break without releasing the reference I looked at these before the first webrev and decided they weren't a problem in practice since this really should never happen. > > Line: 1364 Concerned Object: fcFontArr > fcFontArr (new object array ) is created in every iteration of the loop. > This could be released in this line alongside > release of fcCompFontObj I added a Delete here - line 1368 in the new version. > > 2. Copyright notice to have 2017 instead of 2016 I rarely-to-never bother to update these. A script will be run at some point. > > 3. Question: Should we mask the other warning messages with 'grep -v' in JNICheck.sh ? I am not sure what you are asking here. I am masking the other warnings with grep -v .. and since I added doing that obviously I think we should :-) -phil. > > Thanks > Have a good day > > Prahalad N. > > ------------------------------ > > Message: 2 > Date: Tue, 17 Jan 2017 12:29:24 -0800 > From: Phil Race > To: Sergey Bylokhov > Cc: 2d-dev <2d-dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] RFR: 8172813 > test/java/awt/font/JNICheck/JNICheck.sh fails on Linux > Message-ID: <65d232e2-47e4-2a78-c454-c144876af564 at oracle.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Both yes and no :-), although I think it is fine to add both. > > 1140 .. there are no more than 2 cachedirs (1 user + 1 system) so I > didn't examine JNI refs in this loop > > 1166 .. I was not realistically expecting a "NULL" here so ignored it. > > Unlike some of the JNI bugs "call while pending exception" type bugs we've fixed these were actual, not hypothetical. > > Updated webrev: > > http://cr.openjdk.java.net/~prr/8172813.1 > > > -phil. > > > On 01/16/2017 09:07 AM, Sergey Bylokhov wrote: >> Hi, Phil. >> Should we add DeleteLocalRef in fontpath.c at lines 1140 and 1166, or both were skipped intentionally? >> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8172813 >>> Webrev : http://cr.openjdk.java.net/~prr/8172813/ >>> >>> - Clear local refs once we are done with them. >>> - Use grep to filter out from the log unrelated warnings as separately reported here : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8131136 >>> >>> -phil. From jayathirth.d.v at oracle.com Thu Jan 19 07:05:38 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 18 Jan 2017 23:05:38 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP In-Reply-To: <3bb30333-41ef-4ad3-99c1-71388097e5dc@default> References: <3bb30333-41ef-4ad3-99c1-71388097e5dc@default> Message-ID: Hi Prahalad, Please find my observations : 1) Since you have moved calculation of "lineStride" to different function I think we can optimize it more by moving the calculation of lineStride inside the "else if ((lineNo - sourceRegion.y) % scaleY == 0)" because it is not used in "if (noTransform)" case. 2) Also there is small typo at line 1670 "// REL4 decoding" and please remove trailing spaces in test case before pushing. Apart from these things changes are working fine. Also I noted that we are not using "padding" parameter passed to decodeRLE4() function. Not using this padding parameter will cause any problems while decoding? If it is not needed we can remove "padding" parameter in decodeRLE4() and its calculation in readRLE4().If it is not under the scope of this bug you can raise a new bug for the same. Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Friday, January 13, 2017 2:54 PM To: 2d-dev at openjdk.java.net Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP Hello Everyone Good day to you. Request your time in reviewing the fix for bug . [JDK-8167278] : ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP Root Cause . The issue seems to stem from a mal-formed RLE4 Encoded Bitmap Image . Specifically - the width as mentioned in header and encoded image data do not match. . Unfortunately, the decoder logic doesn't contain guard checks to prevent out of bounds array access. Fix Details: . Necessary guard conditions have been put to the RLE4 bitmap decoding logic. . Besides, two new issues were observed in same function block. They have been addressed as well. i. The last scanline of decoded image is missed in destination image (when EoF sequence arrives without EoL) . This was observed with a sample image created with gimp tool. ii. Handling of Delta encoding (0x00 0x02 xOffset yOffset) . The scanline of decoded image should be copied to destination if yOff shifts next pixel's location to other line . Secondly, the scanline index should be limited by boundary value after x and y offsets are added. . Note: I couldn't create a suitable image with Delta encoding in image buffer. Hence this small change could not be tested. Other Details: . The fix was run through both Jtreg and JCK test suites. No regressions were seen. The changes are available for your review under: Link: http://cr.openjdk.java.net/~pnarayanan/8167278/webrev.00/ Kindly review the changes at your convenience and share your feedback. Thank you for your time in review Have a good day Prahalad N. From jayathirth.d.v at oracle.com Thu Jan 19 10:17:20 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 19 Jan 2017 02:17:20 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <24ca2994-aa27-4a70-8cf9-0bda35664f3f@default> <574809B2.5040901@oracle.com> <9f641938-f979-4021-9e94-bde47e1d3c67@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> <57744D0D.9080809@oracle.com> <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> Message-ID: <3aefa53e-dd6f-46ba-9345-4f78e76c23d6@default> Hello All, After getting feedback from Joe in CCC I have made changes to the code to reflect Joe's suggestions. For ColorModel class I have just added identity-is-equality equals(). For its subclasses like IndexColorModel, PackedColorModel & ComponentColorModel, I have added instanceOf checks and checking all fields for equality. Since we are not checking any fields in ColorModel, in subclasses there will be redundant checks. DirectColorModel has no unique properties to check so it will be using PackedColorModel equals() and hashCode(). Please review the updated code at your convenience: http://cr.openjdk.java.net/~jdv/7107905/webrev.14/ Thanks, Jay -----Original Message----- From: Jim Graham Sent: Friday, July 22, 2016 3:15 AM To: Jayathirth D V; Philip Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods Looks good to me... ...jim On 07/20/2016 09:53 AM, Jayathirth D V wrote: > Hi Jim, > > Thanks for your input. > I have updated specification of ColorModel and its subclasses. > Please find new webrev for review: > http://cr.openjdk.java.net/~jdv/7107905/webrev.13/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Tuesday, July 12, 2016 7:41 PM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: > ColorModel subclasses are missing hashCode() or equals() or both > methods > > Hi Jay, > > When I write javadoc suggestions I sometimes use the short-hand "{some text}" to indicate that it should be formatted using javadoc protocols, typically that expands to "{@code some text}", but sometimes a link may be appropriate. It looks like you copied and pasted a number of places where I wrote "{foo}" in email and just left the bare braces there, please adjust those (most of them should probably just have "@code" inserted. > > In ColorModel.equals(), I'd replace the entire "following properties" sentence with: > > * Subclasses may check additional properties, but this method > * will check the following basic properties for equivalence to > * determine if the target object equals this object: > > The text for IndexColorModel is also a little odd. I'd change it to something like: > > * The target object and this object will be equal iff > * {@link ColorModel#equals()} returns true and the following > * properties are also the same: > > For Packed: > > * The target object and this object will be equal iff > * {@link ColorModel#equals()} returns true and the masks > * of the color and alpha samples are the same. > > In terms of Joe's request, I'd add the following text to ColorModel.equals() right after we talk about all of the properties that it checks: > > *

> * Subclasses should override this method if they have any additional > * properties to compare and should use the following implementation. > * Note that the base {@code ColorModel} class already ensures that > * the target object is the same class as this object so the cast to > * the subclass type can be assumed if {@code super.equals(obj)} > returns > * true. > * 

> *     public boolean equals(Object obj) {
> *         if (!super.equals(obj)) {
> *             return false;
> *         }
> *         MyCMClass cm = (MyCMClass) obj;
> *         // test additional properties on "cm" and "this"
> *     }
> *
> > > On 7/1/16 3:31 AM, Jayathirth D V wrote: >> Hi Jim, >> >> Thanks for your inputs. >> I have discussed with Phil also regarding the same issue offline. >> I have collated all the changes mentioned by you and Phil in the latest webrev: >> http://cr.openjdk.java.net/~jdv/7107905/webrev.12/ >> >> But I was not able to understand your statement - "Arguably, we could omit the class comparison text from the subclasses as well by using a reference like that, but I think that the class equivalence test is enough out of the ordinary that it does bear reiterating it in every subclass as you already do now even though we only reference the specific other properties tested by a reference.", please clarify. >> >> Also I am not able find a way to describe Joe's concern of "The ColorModel equals and hashCode methods should spell out the protocol subclasses need to follow to obey the respective contracts of methods.", I have discussed with Phil also regarding the same offline. Any inputs on this also would be helpful. >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Thursday, June 30, 2016 4:05 AM >> To: Jayathirth D V; Philip Race; 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >> ColorModel subclasses are missing hashCode() or equals() or both >> methods >> >> Hi Jay, >> >> We need to reference the properties from the base class in the subclasses. We don't need to list them every time, but we could introduce the "additional properties" using something like: >> >> "... we check all of the properties checked by the {equals} method of {ColorModel}, and the following additional properties:" >> >> Arguably, we could omit the class comparison text from the subclasses as well by using a reference like that, but I think that the class equivalence test is enough out of the ordinary that it does bear reiterating it in every subclass as you already do now even though we only reference the specific other properties tested by a reference. >> >> A few grammar fixes: >> >> In all of the classes, insert a space before any parentheses in >> comment text as in "the same class (and not a subclass)". (That >> wouldn't apply if the text in the comment is referring to code - then >> space it as you would actual code.) >> >> In CM, insert the word "the" as in "also check the following ..." >> >> In ICM I would refer to the "Valid bits of" instead as "The list of valid pixel indices in". >> >> In PCM I would change "check maskArray of ..." to "check the masks of the ..." and pluralize the word "samples". >> >> ...jim >> >> On 06/29/2016 04:13 AM, Jayathirth D V wrote: >>> Hi, >>> >>> Since Joe mentioned to add information related to what fields we are using to calculate equals() method in ColorModel and its subclasses I have updated the spec for the same. >>> >>> Please find updated webrev for review: >>> http://cr.openjdk.java.net/~jdv/7107905/webrev.11/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Saturday, June 04, 2016 4:52 AM >>> To: Jayathirth D V; Philip Race >>> Cc: 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >>> ColorModel subclasses are missing hashCode() or equals() or both >>> methods >>> >>> That looks good to me. Has the CCC cleared yet? >>> >>> ...jim >>> >>> On 6/3/16 2:49 AM, Jayathirth D V wrote: >>>> Hi Jim, >>>> >>>> Oh that's an important change. >>>> Thanks for your review. >>>> >>>> I have updated ColorModel constructor to copy nBIts only of numOfComponents length and I have removed validBits check in hashCode() of ICM. >>>> Please find updated webrev for review: >>>> http://cr.openjdk.java.net/~jdv/7107905/webrev.10/ >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Friday, June 03, 2016 2:25 AM >>>> To: Jayathirth D V; Philip Race >>>> Cc: 2d-dev at openjdk.java.net >>>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>>> are missing hashCode() or equals() or both methods >>>> >>>> I just noticed a hashCode/equals violation that we created a few revisions ago. We compute the hash of the validBits in ICM, but we only compare validBits up to the number of colors in the colormap. One could construct two ICMs that have different validBits that are identical in the first N bits (N = number of colors), but have different bits beyond that, and those 2 ICMs would evaluate as equals(), but their hashcodes would be different. >>>> >>>> Possible solutions: >>>> >>>> - Truncate validBits when it is accepted in the constructor >>>> (validBits.and(...)) >>>> - Manually compute the hash of the first N bits of validBits >>>> - Not use validBits in the hash code since it is allowed to omit >>>> significant data from the hash >>>> >>>> (Note that everything in hashcode must participate in equals(), but >>>> not vice versa) >>>> >>>> The same is true of nBits in ColorModel. (nBits can be copied and >>>> truncated with Arrays.copyOf) >>>> >>>> The same is *not* true of maskBits in PCM since the constructor creates an array of the precise length it needs... >>>> >>>> ...jim >>>> >>>> On 6/2/16 7:07 AM, Jayathirth D V wrote: >>>>> Hi Phil, >>>>> >>>>> I have updated the code with all the changes I mentioned previously. I am caching hashCode when first time hashCode() is called. >>>>> Please find the updated webrev for review: >>>>> http://cr.openjdk.java.net/~jdv/7107905/webrev.09/ >>>>> >>>>> Thanks, >>>>> Jay >>>>> >>>>> -----Original Message----- >>>>> From: Philip Race >>>>> Sent: Wednesday, June 01, 2016 10:06 PM >>>>> To: Jayathirth D V >>>>> Cc: Jim Graham; 2d-dev at openjdk.java.net >>>>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>>>> are missing hashCode() or equals() or both methods >>>>> >>>>> Please post the updated webrev. >>>>> >>>>> -phil. >>>>> >>>>> On 6/1/16, 12:02 AM, Jayathirth D V wrote: >>>>>> Hi Phil& Jim, >>>>>> >>>>>> Collating all the changes needed: >>>>>> 1) I have removed both equals()& hashCode() in CCM but forgot to add the file while creating webrev. I will include changes in CCM in updated webrev. >>>>>> 2) Caching of hashCode value in IndexColorModel& PackedColorModel : >>>>>> We can cache hashCode value when constructor is called or when hashCode() is called for first time. What approach we have to follow? >>>>>> 3) Comment section of equals() method, I will update it to : >>>>>> 1449 * the target object must be the same class (and not a subclass) as this >>>>>> 4) I will use .equals() to compare colorSpace values in CM.equals() so it will be like we are not intending ColorSpace class to never override equals() method. >>>>>> >>>>>> Please let me know your inputs. >>>>>> >>>>>> Thanks, >>>>>> Jay >>>>>> >>>>>> -----Original Message----- >>>>>> From: Jim Graham >>>>>> Sent: Wednesday, June 01, 2016 4:14 AM >>>>>> To: Phil Race >>>>>> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >>>>>> Subject: Re: Review Request for JDK-7107905: ColorModel >>>>>> subclasses are missing hashCode() or equals() or both methods >>>>>> >>>>>> I think we should use .equals() here, otherwise it looks like a recommendation that the intent is for those classes to never implement it... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 05/31/2016 03:31 PM, Phil Race wrote: >>>>>>> I don't know of any design intent, so yes, I meant more as a >>>>>>> practical matter. >>>>>>> Unless they subclass then using equals() which I thought >>>>>>> unlikely it makes no difference here. >>>>>>> But it would be proof against that to use equals, unlikely to >>>>>>> matter as it might be .. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 05/31/2016 03:19 PM, Jim Graham wrote: >>>>>>>> >>>>>>>> On 05/31/2016 02:50 PM, Phil Race wrote: >>>>>>>>> On 05/31/2016 12:20 PM, Jim Graham wrote: >>>>>>>>>> Hi Jay, >>>>>>>>>> >>>>>>>>>> You were going to remove hashCode/equals from CCM, but >>>>>>>>>> instead you simply removed it from the patch. You still need >>>>>>>>>> to edit it to remove the existing methods. >>>>>>>>> Oh yeah ! CCM is gone from the latest webrev. I expect that >>>>>>>>> was not intentional. >>>>>>>>> >>>>>>>>>> Also, I'm not sure == is a good way to compare ColorSpace >>>>>>>>>> instances >>>>>>>>>> - Phil? >>>>>>>>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or >>>>>>>>> hashCode and all the predefined ones are constructed as >>>>>>>>> singletons so it seems unlikely to cause problems >>>>>>>> Should it use .equals() on principle, though? Otherwise we are >>>>>>>> baking in the assumption that it doesn't implement equals() >>>>>>>> into our implementation of the CM.equals() method. Might it >>>>>>>> some day implement equals (perhaps it isn't a practical issue >>>>>>>> today, but it might be in the future when we forget that it was >>>>>>>> omitted in this usage we create today). >>>>>>>> >>>>>>>> I guess what I'm asking is if it is a design feature that >>>>>>>> different objects are considered non-equal (such as an object >>>>>>>> that, for instance, has only predetermined instances that are >>>>>>>> shared by reference and reused). I think color spaces are sort >>>>>>>> of in-between in that we define a few constants that simply get >>>>>>>> used by reference in 99% of cases, but that isn't a design >>>>>>>> feature, more like a practical issue... >>>>>>>> >>>>>>>> ...jim From vadim.pakhnushev at oracle.com Thu Jan 19 10:51:35 2017 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Thu, 19 Jan 2017 13:51:35 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8172999: Crash on Windows getting FontMetrics since JDK 9 b96 In-Reply-To: References: Message-ID: <9c36b1f0-7d74-d65a-55a6-8be40ae7f0d8@oracle.com> Looks good. On 19.01.2017 2:08, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8172999 > Webrev: http://cr.openjdk.java.net/~prr/8172999/ > > fix for a crash on windows. > > -phil. From dmitry.markov at oracle.com Thu Jan 19 12:28:17 2017 From: dmitry.markov at oracle.com (dmitry markov) Date: Thu, 19 Jan 2017 15:28:17 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163889: [macosx] Can't print from browser on Mac OS X In-Reply-To: References: <00DB423C-EF8C-44DE-93E6-8071256D98D4@oracle.com> Message-ID: <5880B0E1.8090704@oracle.com> Hi Prasanta, Thank you for your feedback. Actually there are two problems here: JDK-8163889 is devoted to the crash/assert error and JDK-8173050 which is about possible lack of support for the images with 'custom' type. Currently I am trying to address the first problem, (i.e. eliminate crash and assert errors which take place during printing). So possible implementations of syncFromCustom(), syncToCustom(), etc. are out of scope for this fix. They will be investigated under JDK-8173050 . It is possible to create manual regression test for this problem. Also the test will require some additional set up steps such as printer installation and so on. It seems to me that is overhead for person who runs it. However if you insist on test creation, I will add it. Thanks, Dmitry On 16/01/2017 09:14, Prasanta Sadhukhan wrote: > Hi Dmitri, > > Don't you need to implement syncFromCustom() and syncToCustom()? > If not, then it seems you do not need to call this functions from > customPixelsFromJava() and customPixelsToJava() in which case, then > env change/fix will not be needed. > Also, is it not possible to create a regression testcase? > > Regards > Prasanta > On 1/14/2017 8:22 PM, Dmitry Markov wrote: >> Hello, >> >> Could you review a fix for jdk9, please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8163889 >> webrev: http://cr.openjdk.java.net/~dmarkov/8163889/webrev.00/ >> >> Problem description: >> Several functions inside ImageSurfaceData.m, (e.g. >> customPixelsFromJava(), customPixelsToJava(), etc.) invoke >> getJNIEnv() from ThreadUtilities instead of usage corresponding input >> parameter. According to the design - getJNIEnv() should be executed >> on AppKit thread, but all code related to printing should NOT run on >> AppKit thread. So we get the following assert here - ?CocoaAWT: Not >> running on AppKit thread 0 when expected.? >> >> Also customPixelsFromJava() and customPixelsToJava() call >> OSXOffScreenSurfaceData.syncFromCustom() and >> OSXOffScreenSurfaceData.syncToCustom(), but these methods are absent >> at Java layer. So when we try to perform such JNI invocation we >> experience the crash. >> >> Fix: >> It is necessary to eliminate negative effects such as crashes, native >> exceptions and assert errors during printing. >> >> Change summary: >> - Replaced invocation of getJNIEnv() with usage of corresponding >> input parameter. >> - Added method stubs to OSXOffScreenSurfaceData. >> >> Thanks, >> Dmitry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Fri Jan 20 07:03:17 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 19 Jan 2017 23:03:17 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8173064: Unexpected tag in javax/imageio/plugins/tiff/package.html Message-ID: <9e90d194-0095-4005-aa92-73af981484ec@default> Hello All, Please review the following fix in JDK9 : Bug : https://bugs.openjdk.java.net/browse/JDK-8173064 Webrev : http://cr.openjdk.java.net/~jdv/8173064/webrev.00/ Html : http://cr.openjdk.java.net/~jdv/8173064/package.html Issue : There was extra tag present in package.html which will cause problems in html documentation. Solution : Removed the extra tag. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From ambarish.rapte at oracle.com Fri Jan 20 07:17:37 2017 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Thu, 19 Jan 2017 23:17:37 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8173064: Unexpected tag in javax/imageio/plugins/tiff/package.html In-Reply-To: <9e90d194-0095-4005-aa92-73af981484ec@default> References: <9e90d194-0095-4005-aa92-73af981484ec@default> Message-ID: <93144881-7410-49c8-9984-25ac6c2cfe62@default> Hi Jay, The change looks good to me. Regards, Ambarish From: Jayathirth D V Sent: Friday, January 20, 2017 12:33 PM To: 2d-dev at openjdk.java.net Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8173064: Unexpected tag in javax/imageio/plugins/tiff/package.html Hello All, Please review the following fix in JDK9 : Bug : https://bugs.openjdk.java.net/browse/JDK-8173064 Webrev : http://cr.openjdk.java.net/~jdv/8173064/webrev.00/ Html : http://cr.openjdk.java.net/~jdv/8173064/package.html Issue : There was extra tag present in package.html which will cause problems in html documentation. Solution : Removed the extra tag. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Jan 20 07:19:22 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 20 Jan 2017 12:49:22 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8173064: Unexpected tag in javax/imageio/plugins/tiff/package.html In-Reply-To: <9e90d194-0095-4005-aa92-73af981484ec@default> References: <9e90d194-0095-4005-aa92-73af981484ec@default> Message-ID: <07d196dc-6339-6f7a-ee37-7e34e8892870@oracle.com> +1 Regards Prasanta On 1/20/2017 12:33 PM, Jayathirth D V wrote: > > Hello All, > > Please review the following fix in JDK9 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-8173064 > > Webrev : http://cr.openjdk.java.net/~jdv/8173064/webrev.00/ > > > Html : http://cr.openjdk.java.net/~jdv/8173064/package.html > > > Issue : There was extra tag present in package.html which will > cause problems in html documentation. > > Solution : Removed the extra tag. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Fri Jan 20 08:34:27 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 20 Jan 2017 11:34:27 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8172999: Crash on Windows getting FontMetrics since JDK 9 b96 In-Reply-To: <9c36b1f0-7d74-d65a-55a6-8be40ae7f0d8@oracle.com> References: <9c36b1f0-7d74-d65a-55a6-8be40ae7f0d8@oracle.com> Message-ID: +1 > > > Looks good. > > On 19.01.2017 2:08, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8172999 >> Webrev: http://cr.openjdk.java.net/~prr/8172999/ >> >> fix for a crash on windows. >> >> -phil. > From prahalad.kumar.narayanan at oracle.com Fri Jan 20 09:09:03 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Fri, 20 Jan 2017 01:09:03 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP In-Reply-To: References: <3bb30333-41ef-4ad3-99c1-71388097e5dc@default> Message-ID: Hello Jay Thank you for your time in review. I 've incorporated review suggestions and the modified code is available for review under: Link: http://cr.openjdk.java.net/~pnarayanan/8167278/webrev.01/ Quick info on the changes from previous revision: 1. Line stride calculation: This has been moved into the 'else if' section as suggested.. 2. Typo error: At Line 1670 has been corrected 3. Un-used argument value- 'padding', in decodeRLE4 function() > Not using this padding parameter will cause any problems while decoding? Line 1547: mentions - If width is not 32bit aligned then while un-compressing each scanline will have padding bytes. The above comment (and thus padding value) is not applicable to ' current ' RLE4 decoding logic because, . The logic creates an intermediate scanline array exactly of size -width. . Besides, when the intermediate scanline is flushed to the destination, the logic assumes the destination is also of type- MultiPixelPackedSampleModel. > If it is not needed we can remove "padding" parameter in decodeRLE4() and its calculation in readRLE4(). > If it is not under the scope of this bug you can raise a new bug for the same. Yes - The padding is not applicable for current logic, it could be removed. I have not removed the variable because it could help in fixing this bug- JDK-8172696 in future [JDK-8172696] ClassCastException is thrown while decoding RLE4 Bitmap with a destination BufferedImage set in ImageReadParams Kindly review the new changes at your convenience. Thank you for your time in review Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Thursday, January 19, 2017 12:36 PM To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP Hi Prahalad, Please find my observations : 1) Since you have moved calculation of "lineStride" to different function I think we can optimize it more by moving the calculation of lineStride inside the "else if ((lineNo - sourceRegion.y) % scaleY == 0)" because it is not used in "if (noTransform)" case. 2) Also there is small typo at line 1670 "// REL4 decoding" and please remove trailing spaces in test case before pushing. Apart from these things changes are working fine. Also I noted that we are not using "padding" parameter passed to decodeRLE4() function. Not using this padding parameter will cause any problems while decoding? If it is not needed we can remove "padding" parameter in decodeRLE4() and its calculation in readRLE4().If it is not under the scope of this bug you can raise a new bug for the same. Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Friday, January 13, 2017 2:54 PM To: 2d-dev at openjdk.java.net Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP Hello Everyone Good day to you. Request your time in reviewing the fix for bug . [JDK-8167278] : ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP Root Cause . The issue seems to stem from a mal-formed RLE4 Encoded Bitmap Image . Specifically - the width as mentioned in header and encoded image data do not match. . Unfortunately, the decoder logic doesn't contain guard checks to prevent out of bounds array access. Fix Details: . Necessary guard conditions have been put to the RLE4 bitmap decoding logic. . Besides, two new issues were observed in same function block. They have been addressed as well. i. The last scanline of decoded image is missed in destination image (when EoF sequence arrives without EoL) . This was observed with a sample image created with gimp tool. ii. Handling of Delta encoding (0x00 0x02 xOffset yOffset) . The scanline of decoded image should be copied to destination if yOff shifts next pixel's location to other line . Secondly, the scanline index should be limited by boundary value after x and y offsets are added. . Note: I couldn't create a suitable image with Delta encoding in image buffer. Hence this small change could not be tested. Other Details: . The fix was run through both Jtreg and JCK test suites. No regressions were seen. The changes are available for your review under: Link: http://cr.openjdk.java.net/~pnarayanan/8167278/webrev.00/ Kindly review the changes at your convenience and share your feedback. Thank you for your time in review Have a good day Prahalad N. From jayathirth.d.v at oracle.com Fri Jan 20 09:37:13 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 20 Jan 2017 01:37:13 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP In-Reply-To: References: <3bb30333-41ef-4ad3-99c1-71388097e5dc@default> Message-ID: <806a836b-af16-4090-9ff1-db248d5648c6@default> Hi Prahalad, Changes are fine. Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Friday, January 20, 2017 2:39 PM To: Jayathirth D V; 2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP Hello Jay Thank you for your time in review. I 've incorporated review suggestions and the modified code is available for review under: Link: http://cr.openjdk.java.net/~pnarayanan/8167278/webrev.01/ Quick info on the changes from previous revision: 1. Line stride calculation: This has been moved into the 'else if' section as suggested.. 2. Typo error: At Line 1670 has been corrected 3. Un-used argument value- 'padding', in decodeRLE4 function() > Not using this padding parameter will cause any problems while decoding? Line 1547: mentions - If width is not 32bit aligned then while un-compressing each scanline will have padding bytes. The above comment (and thus padding value) is not applicable to ' current ' RLE4 decoding logic because, . The logic creates an intermediate scanline array exactly of size -width. . Besides, when the intermediate scanline is flushed to the destination, the logic assumes the destination is also of type- MultiPixelPackedSampleModel. > If it is not needed we can remove "padding" parameter in decodeRLE4() and its calculation in readRLE4(). > If it is not under the scope of this bug you can raise a new bug for the same. Yes - The padding is not applicable for current logic, it could be removed. I have not removed the variable because it could help in fixing this bug- JDK-8172696 in future [JDK-8172696] ClassCastException is thrown while decoding RLE4 Bitmap with a destination BufferedImage set in ImageReadParams Kindly review the new changes at your convenience. Thank you for your time in review Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Thursday, January 19, 2017 12:36 PM To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net Subject: RE: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP Hi Prahalad, Please find my observations : 1) Since you have moved calculation of "lineStride" to different function I think we can optimize it more by moving the calculation of lineStride inside the "else if ((lineNo - sourceRegion.y) % scaleY == 0)" because it is not used in "if (noTransform)" case. 2) Also there is small typo at line 1670 "// REL4 decoding" and please remove trailing spaces in test case before pushing. Apart from these things changes are working fine. Also I noted that we are not using "padding" parameter passed to decodeRLE4() function. Not using this padding parameter will cause any problems while decoding? If it is not needed we can remove "padding" parameter in decodeRLE4() and its calculation in readRLE4().If it is not under the scope of this bug you can raise a new bug for the same. Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Friday, January 13, 2017 2:54 PM To: 2d-dev at openjdk.java.net Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP Hello Everyone Good day to you. Request your time in reviewing the fix for bug . [JDK-8167278] : ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP Root Cause . The issue seems to stem from a mal-formed RLE4 Encoded Bitmap Image . Specifically - the width as mentioned in header and encoded image data do not match. . Unfortunately, the decoder logic doesn't contain guard checks to prevent out of bounds array access. Fix Details: . Necessary guard conditions have been put to the RLE4 bitmap decoding logic. . Besides, two new issues were observed in same function block. They have been addressed as well. i. The last scanline of decoded image is missed in destination image (when EoF sequence arrives without EoL) . This was observed with a sample image created with gimp tool. ii. Handling of Delta encoding (0x00 0x02 xOffset yOffset) . The scanline of decoded image should be copied to destination if yOff shifts next pixel's location to other line . Secondly, the scanline index should be limited by boundary value after x and y offsets are added. . Note: I couldn't create a suitable image with Delta encoding in image buffer. Hence this small change could not be tested. Other Details: . The fix was run through both Jtreg and JCK test suites. No regressions were seen. The changes are available for your review under: Link: http://cr.openjdk.java.net/~pnarayanan/8167278/webrev.00/ Kindly review the changes at your convenience and share your feedback. Thank you for your time in review Have a good day Prahalad N. From prasanta.sadhukhan at oracle.com Fri Jan 20 12:04:48 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 20 Jan 2017 17:34:48 +0530 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163889: [macosx] Can't print from browser on Mac OS X In-Reply-To: <5880B0E1.8090704@oracle.com> References: <00DB423C-EF8C-44DE-93E6-8071256D98D4@oracle.com> <5880B0E1.8090704@oracle.com> Message-ID: <9852e243-2f44-05a1-7978-d32cbd91da46@oracle.com> Hi Dmitri, Ok. I think it will be good to add a testcase (since bug already has a reproducible test) and since its a print problem, anyone who runs it has to install printer to verify so no excuse there :-) or if you can find any other existing testcase which showcase this crash problem, you can append this bugid to that testcase. Regards Prasanta On 1/19/2017 5:58 PM, dmitry markov wrote: > Hi Prasanta, > Thank you for your feedback. > > Actually there are two problems here: JDK-8163889 > is devoted to the > crash/assert error and JDK-8173050 > which is about > possible lack of support for the images with 'custom' type. > Currently I am trying to address the first problem, (i.e. eliminate > crash and assert errors which take place during printing). So possible > implementations of syncFromCustom(), syncToCustom(), etc. are out of > scope for this fix. They will be investigated under JDK-8173050 > . > > It is possible to create manual regression test for this problem. Also > the test will require some additional set up steps such as printer > installation and so on. It seems to me that is overhead for person who > runs it. However if you insist on test creation, I will add it. > > Thanks, > Dmitry > On 16/01/2017 09:14, Prasanta Sadhukhan wrote: >> Hi Dmitri, >> >> Don't you need to implement syncFromCustom() and syncToCustom()? >> If not, then it seems you do not need to call this functions from >> customPixelsFromJava() and customPixelsToJava() in which case, then >> env change/fix will not be needed. >> Also, is it not possible to create a regression testcase? >> >> Regards >> Prasanta >> On 1/14/2017 8:22 PM, Dmitry Markov wrote: >>> Hello, >>> >>> Could you review a fix for jdk9, please? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8163889 >>> webrev: http://cr.openjdk.java.net/~dmarkov/8163889/webrev.00/ >>> >>> Problem description: >>> Several functions inside ImageSurfaceData.m, (e.g. >>> customPixelsFromJava(), customPixelsToJava(), etc.) invoke >>> getJNIEnv() from ThreadUtilities instead of usage corresponding >>> input parameter. According to the design - getJNIEnv() should be >>> executed on AppKit thread, but all code related to printing should >>> NOT run on AppKit thread. So we get the following assert here - >>> ?CocoaAWT: Not running on AppKit thread 0 when expected.? >>> >>> Also customPixelsFromJava() and customPixelsToJava() call >>> OSXOffScreenSurfaceData.syncFromCustom() and >>> OSXOffScreenSurfaceData.syncToCustom(), but these methods are absent >>> at Java layer. So when we try to perform such JNI invocation we >>> experience the crash. >>> >>> Fix: >>> It is necessary to eliminate negative effects such as crashes, >>> native exceptions and assert errors during printing. >>> >>> Change summary: >>> - Replaced invocation of getJNIEnv() with usage of corresponding >>> input parameter. >>> - Added method stubs to OSXOffScreenSurfaceData. >>> >>> Thanks, >>> Dmitry >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jan 20 16:50:51 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 20 Jan 2017 08:50:51 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163889: [macosx] Can't print from browser on Mac OS X In-Reply-To: <9852e243-2f44-05a1-7978-d32cbd91da46@oracle.com> References: <00DB423C-EF8C-44DE-93E6-8071256D98D4@oracle.com> <5880B0E1.8090704@oracle.com> <9852e243-2f44-05a1-7978-d32cbd91da46@oracle.com> Message-ID: I haven't looked at the fix (yet) but I definitely agree that a manual regression test for this is better than none. What else should we do ? Just not test printing ? In my view which I've expressed to SQE for a really long time, if you aren't testing with printers installed you aren't testing the whole platform. Whilst it may be convenient that tests (silently) don't complain when there are no printers, it is a slippery slope .. -phil. On 01/20/2017 04:04 AM, Prasanta Sadhukhan wrote: > > It is possible to create manual regression test for this problem. Also > the test will require some additional set up steps such as printer > installation and so on. It seems to me that is overhead for person who > runs it. However if you insist on test creation, I will add it. From dmitry.markov at oracle.com Fri Jan 20 17:36:21 2017 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Fri, 20 Jan 2017 20:36:21 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163889: [macosx] Can't print from browser on Mac OS X In-Reply-To: References: <00DB423C-EF8C-44DE-93E6-8071256D98D4@oracle.com> <5880B0E1.8090704@oracle.com> <9852e243-2f44-05a1-7978-d32cbd91da46@oracle.com> Message-ID: Hi Phil, Prasanta, I have updated the fix as you suggested, (i.e. added the regression test). The new webrev is located at http://cr.openjdk.java.net/~dmarkov/8163889/webrev.01/ Could you review the new version, please? Thanks, Dmitry > On 20 Jan 2017, at 19:50, Phil Race wrote: > > I haven't looked at the fix (yet) but I definitely agree that a manual regression test > for this is better than none. What else should we do ? Just not test printing ? > > In my view which I've expressed to SQE for a really long time, if you aren't testing with > printers installed you aren't testing the whole platform. Whilst it may be convenient > that tests (silently) don't complain when there are no printers, it is a slippery slope .. > > -phil. > > On 01/20/2017 04:04 AM, Prasanta Sadhukhan wrote: >> >> It is possible to create manual regression test for this problem. Also the test will require some additional set up steps such as printer installation and so on. It seems to me that is overhead for person who runs it. However if you insist on test creation, I will add it. > From philip.race at oracle.com Fri Jan 20 21:00:50 2017 From: philip.race at oracle.com (Philip Race) Date: Fri, 20 Jan 2017 13:00:50 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8145019: Exceptions from TIFFImageReader.read() when loading bit depth test images In-Reply-To: <307E88A7-42F4-452A-B331-642AAF5A7537@oracle.com> References: <307E88A7-42F4-452A-B331-642AAF5A7537@oracle.com> Message-ID: <58827A82.1050001@oracle.com> What's with the empty loop ? 2851 for (int band = 0; band < numBands; band++) { 2852 2853 } -phil. On 12/28/16, 2:17 PM, Brian Burkhalter wrote: > The problems were that in some cases an incorrect ImageTypeSpecifier was being created for the layout of the image, that odd bit-depth data, e.g., 6 bits per sample, were not being expanded into, e.g., 8-bit components, and that the data expansion for planar (banded) images was using sizes appropriate to all bands as opposed to single bands. With this change, all the ?flower? images in the ?depth? subdirectory of the ?libtiffpic? test image set are able to be displayed without exceptions. From philip.race at oracle.com Fri Jan 20 21:13:58 2017 From: philip.race at oracle.com (Philip Race) Date: Fri, 20 Jan 2017 13:13:58 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8154228: [TIFF] IIOException: "Insufficient data offsets or byte counts" when loading test image In-Reply-To: <64BCE41A-617D-4874-B049-F75FA1DAD4C0@oracle.com> References: <64BCE41A-617D-4874-B049-F75FA1DAD4C0@oracle.com> Message-ID: <58827D96.9060407@oracle.com> 612 } else { 613 614 } ? -phil On 12/29/16, 2:25 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8154228 > Patch: http://cr.openjdk.java.net/~bpb/8154228/webrev.00/ > > The problem is that the test image XING_T24.TIF is missing the StripByteCounts field which is required by the TIFF specification. The solution for the case where the image data are uncompressed and the offsets to the data packets (strips or tiles) are known, is to compute the number of bytes in each packet provided the information needed to do so is present in the image. > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jan 20 21:24:53 2017 From: philip.race at oracle.com (Philip Race) Date: Fri, 20 Jan 2017 13:24:53 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163889: [macosx] Can't print from browser on Mac OS X In-Reply-To: References: <00DB423C-EF8C-44DE-93E6-8071256D98D4@oracle.com> <5880B0E1.8090704@oracle.com> <9852e243-2f44-05a1-7978-d32cbd91da46@oracle.com> Message-ID: <58828025.9050500@oracle.com> Hi Dmitry, > 29 * @run main/othervm PrintCrashTest why othervm ? I don't think that is strictly necessary just because you are using deleteOnExit. And FWIW I think the test could "more promptly" delete the file anyway after print returns. -phil. On 1/20/17, 9:36 AM, Dmitry Markov wrote: > Hi Phil, Prasanta, > > I have updated the fix as you suggested, (i.e. added the regression test). The new webrev is located at http://cr.openjdk.java.net/~dmarkov/8163889/webrev.01/ > Could you review the new version, please? > > Thanks, > Dmitry >> On 20 Jan 2017, at 19:50, Phil Race wrote: >> >> I haven't looked at the fix (yet) but I definitely agree that a manual regression test >> for this is better than none. What else should we do ? Just not test printing ? >> >> In my view which I've expressed to SQE for a really long time, if you aren't testing with >> printers installed you aren't testing the whole platform. Whilst it may be convenient >> that tests (silently) don't complain when there are no printers, it is a slippery slope .. >> >> -phil. >> >> On 01/20/2017 04:04 AM, Prasanta Sadhukhan wrote: >>> It is possible to create manual regression test for this problem. Also the test will require some additional set up steps such as printer installation and so on. It seems to me that is overhead for person who runs it. However if you insist on test creation, I will add it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Jan 20 22:07:28 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 20 Jan 2017 14:07:28 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8154228: [TIFF] IIOException: "Insufficient data offsets or byte counts" when loading test image In-Reply-To: <58827D96.9060407@oracle.com> References: <64BCE41A-617D-4874-B049-F75FA1DAD4C0@oracle.com> <58827D96.9060407@oracle.com> Message-ID: Clearly lines 612-613 need to go. http://cr.openjdk.java.net/~bpb/8154228/webrev.01/ Thanks, Brian On Jan 20, 2017, at 1:13 PM, Philip Race wrote: > 612 } else { > 613 > 614 } -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Jan 20 22:11:42 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 20 Jan 2017 14:11:42 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8145019: Exceptions from TIFFImageReader.read() when loading bit depth test images In-Reply-To: <58827A82.1050001@oracle.com> References: <307E88A7-42F4-452A-B331-642AAF5A7537@oracle.com> <58827A82.1050001@oracle.com> Message-ID: <689A7AEC-8BD8-4AB4-A60F-8E8417E2AFA3@oracle.com> An inadvertent deletion. http://cr.openjdk.java.net/~bpb/8145019/webrev.01/ Thanks, Brian On Jan 20, 2017, at 1:00 PM, Philip Race wrote: > What's with the empty loop ? > > 2851 for (int band = 0; band < numBands; band++) { > 2852 > 2853 } -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jan 20 22:28:01 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 20 Jan 2017 14:28:01 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8145019: Exceptions from TIFFImageReader.read() when loading bit depth test images In-Reply-To: <689A7AEC-8BD8-4AB4-A60F-8E8417E2AFA3@oracle.com> References: <307E88A7-42F4-452A-B331-642AAF5A7537@oracle.com> <58827A82.1050001@oracle.com> <689A7AEC-8BD8-4AB4-A60F-8E8417E2AFA3@oracle.com> Message-ID: That's what I was supposing .. +1 -phil. On 01/20/2017 02:11 PM, Brian Burkhalter wrote: > An inadvertent deletion. > > http://cr.openjdk.java.net/~bpb/8145019/webrev.01/ > > > Thanks, > > Brian > > On Jan 20, 2017, at 1:00 PM, Philip Race > wrote: > >> What's with the empty loop ? >> >> 2851 for (int band = 0; band < numBands; >> band++) { >> 2852 >> 2853 } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jan 20 22:28:13 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 20 Jan 2017 14:28:13 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8154228: [TIFF] IIOException: "Insufficient data offsets or byte counts" when loading test image In-Reply-To: References: <64BCE41A-617D-4874-B049-F75FA1DAD4C0@oracle.com> <58827D96.9060407@oracle.com> Message-ID: <29c00fff-2e51-0fcd-627a-108fa0b9cc10@oracle.com> +1 -phil. On 01/20/2017 02:07 PM, Brian Burkhalter wrote: > Clearly lines 612-613 need to go. > > http://cr.openjdk.java.net/~bpb/8154228/webrev.01/ > > > Thanks, > > Brian > > On Jan 20, 2017, at 1:13 PM, Philip Race > wrote: > >> 612 } else { >> 613 >> 614 } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jan 20 23:04:40 2017 From: philip.race at oracle.com (Philip Race) Date: Fri, 20 Jan 2017 15:04:40 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP In-Reply-To: References: <3bb30333-41ef-4ad3-99c1-71388097e5dc@default> Message-ID: <58829788.40509@oracle.com> ii. Handling of Delta encoding (0x00 0x02 xOffset yOffset) . The scanline of decoded image should be copied to destination if yOff shifts next pixel's location to other line . Secondly, the scanline index should be limited by boundary value after x and y offsets are added. . Note: I couldn't create a suitable image with Delta encoding in image buffer. Hence this small change could not be tested. That is worrying me since I don't follow these lines are part of that:- 1684 // Move to the position (xoff, yoff). Since l-is used 1685 // to index into the scanline buffer, the calculation 1686 // must be limited by the size 1687 l += xoff + yoff*width; 1688 l %= width; 1687 was already there but 1688 and the comment are new and 1688 looks wrong to me as it would seem to throw away the y it just added in ... Why "othervm" for the test ? I don't see anything the test does that requires this and it just slows down the test harness. -phil. On 1/20/17, 1:09 AM, Prahalad Kumar Narayanan wrote: > Hello Jay > > Thank you for your time in review. > > I 've incorporated review suggestions and the modified code is available for review under: > Link: http://cr.openjdk.java.net/~pnarayanan/8167278/webrev.01/ > > Quick info on the changes from previous revision: > 1. Line stride calculation: This has been moved into the 'else if' section as suggested.. > 2. Typo error: At Line 1670 has been corrected > 3. Un-used argument value- 'padding', in decodeRLE4 function() > >> Not using this padding parameter will cause any problems while decoding? > Line 1547: mentions - If width is not 32bit aligned then while un-compressing each scanline will have padding bytes. > The above comment (and thus padding value) is not applicable to ' current ' RLE4 decoding logic because, > . The logic creates an intermediate scanline array exactly of size -width. > . Besides, when the intermediate scanline is flushed to the destination, the logic assumes the destination is also of type- MultiPixelPackedSampleModel. > >> If it is not needed we can remove "padding" parameter in decodeRLE4() and its calculation in readRLE4(). >> If it is not under the scope of this bug you can raise a new bug for the same. > Yes - The padding is not applicable for current logic, it could be removed. > I have not removed the variable because it could help in fixing this bug- JDK-8172696 in future > [JDK-8172696] ClassCastException is thrown while decoding RLE4 Bitmap with a destination BufferedImage set in ImageReadParams > > Kindly review the new changes at your convenience. > > Thank you for your time in review > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Jayathirth D V > Sent: Thursday, January 19, 2017 12:36 PM > To: Prahalad Kumar Narayanan; 2d-dev at openjdk.java.net > Subject: RE: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP > > Hi Prahalad, > > Please find my observations : > > 1) Since you have moved calculation of "lineStride" to different function I think we can optimize it more by moving the calculation of lineStride inside the "else if ((lineNo - sourceRegion.y) % scaleY == 0)" because it is not used in "if (noTransform)" case. > > 2) Also there is small typo at line 1670 "// REL4 decoding" and please remove trailing spaces in test case before pushing. > > Apart from these things changes are working fine. > > Also I noted that we are not using "padding" parameter passed to decodeRLE4() function. > Not using this padding parameter will cause any problems while decoding? > > If it is not needed we can remove "padding" parameter in decodeRLE4() and its calculation in readRLE4().If it is not under the scope of this bug you can raise a new bug for the same. > > Thanks, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Friday, January 13, 2017 2:54 PM > To: 2d-dev at openjdk.java.net > Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP > > Hello Everyone > > Good day to you. > > Request your time in reviewing the fix for bug > . [JDK-8167278] : ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP > > Root Cause > . The issue seems to stem from a mal-formed RLE4 Encoded Bitmap Image > . Specifically - the width as mentioned in header and encoded image data do not match. > . Unfortunately, the decoder logic doesn't contain guard checks to prevent out of bounds array access. > > Fix Details: > . Necessary guard conditions have been put to the RLE4 bitmap decoding logic. > . Besides, two new issues were observed in same function block. They have been addressed as well. > i. The last scanline of decoded image is missed in destination image (when EoF sequence arrives without EoL) > . This was observed with a sample image created with gimp tool. > ii. Handling of Delta encoding (0x00 0x02 xOffset yOffset) > . The scanline of decoded image should be copied to destination if yOff shifts next pixel's location to other line > . Secondly, the scanline index should be limited by boundary value after x and y offsets are added. > . Note: I couldn't create a suitable image with Delta encoding in image buffer. Hence this small change could not be tested. > > Other Details: > . The fix was run through both Jtreg and JCK test suites. No regressions were seen. > > The changes are available for your review under: > Link: http://cr.openjdk.java.net/~pnarayanan/8167278/webrev.00/ > > Kindly review the changes at your convenience and share your feedback. > > Thank you for your time in review > Have a good day > > Prahalad N. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Sat Jan 21 00:30:23 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 20 Jan 2017 16:30:23 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP In-Reply-To: <58829788.40509@oracle.com> References: <3bb30333-41ef-4ad3-99c1-71388097e5dc@default> <58829788.40509@oracle.com> Message-ID: <94A4ABDA-52F1-4A0E-A5EB-465187442A87@oracle.com> On Jan 20, 2017, at 3:04 PM, Philip Race wrote: > . Note: I couldn't create a suitable image with Delta encoding in image buffer. Hence this small change could not be tested. Have you looked at image test suites such as http://bmptestsuite.sourceforge.net/? > That is worrying me since I don't follow these lines are part of that:- > 1684 // Move to the position (xoff, yoff). Since l-is used > 1685 // to index into the scanline buffer, the calculation > 1686 // must be limited by the size > 1687 l += xoff + yoff*width; > 1688 l %= width; > 1687 was already there but 1688 and the comment are new and 1688 looks wrong to me > as it would seem to throw away the y it just added in ... Indeed, if xoff is in the half-closed interval [0,width), then (xoff + yoff*width) % width == xoff. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Sat Jan 21 00:34:40 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 20 Jan 2017 16:34:40 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP In-Reply-To: <94A4ABDA-52F1-4A0E-A5EB-465187442A87@oracle.com> References: <3bb30333-41ef-4ad3-99c1-71388097e5dc@default> <58829788.40509@oracle.com> <94A4ABDA-52F1-4A0E-A5EB-465187442A87@oracle.com> Message-ID: <220D4634-7558-4D09-B98F-8984759CCF1F@oracle.com> On Jan 20, 2017, at 4:30 PM, Brian Burkhalter wrote: >> That is worrying me since I don't follow these lines are part of that:- >> 1684 // Move to the position (xoff, yoff). Since l-is used >> 1685 // to index into the scanline buffer, the calculation >> 1686 // must be limited by the size >> 1687 l += xoff + yoff*width; >> 1688 l %= width; >> 1687 was already there but 1688 and the comment are new and 1688 looks wrong to me >> as it would seem to throw away the y it just added in ... > > Indeed, if xoff is in the half-closed interval [0,width), then (xoff + yoff*width) % width == xoff. This does not however account for the accumulation into ?l? which might negate my observation. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.markov at oracle.com Sat Jan 21 19:05:49 2017 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Sat, 21 Jan 2017 22:05:49 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163889: [macosx] Can't print from browser on Mac OS X In-Reply-To: <58828025.9050500@oracle.com> References: <00DB423C-EF8C-44DE-93E6-8071256D98D4@oracle.com> <5880B0E1.8090704@oracle.com> <9852e243-2f44-05a1-7978-d32cbd91da46@oracle.com> <58828025.9050500@oracle.com> Message-ID: Hi Phil, I agree ?othervm? is not necessary here. That is ?copy-paste? error. Also I updated the part related to the file deletion based on your suggestion. Please find new webrev here: http://cr.openjdk.java.net/~dmarkov/8163889/webrev.02/ Thanks, Dmitry > On 21 Jan 2017, at 00:24, Philip Race wrote: > > Hi Dmitry, > > 29 * @run main/othervm PrintCrashTest > why othervm ? > > I don't think that is strictly necessary just because you are using deleteOnExit. > And FWIW I think the test could "more promptly" delete the file anyway after print returns. > > -phil. > > > On 1/20/17, 9:36 AM, Dmitry Markov wrote: >> >> Hi Phil, Prasanta, >> >> I have updated the fix as you suggested, (i.e. added the regression test). The new webrev is located at http://cr.openjdk.java.net/~dmarkov/8163889/webrev.01/ >> Could you review the new version, please? >> >> Thanks, >> Dmitry >>> On 20 Jan 2017, at 19:50, Phil Race wrote: >>> >>> I haven't looked at the fix (yet) but I definitely agree that a manual regression test >>> for this is better than none. What else should we do ? Just not test printing ? >>> >>> In my view which I've expressed to SQE for a really long time, if you aren't testing with >>> printers installed you aren't testing the whole platform. Whilst it may be convenient >>> that tests (silently) don't complain when there are no printers, it is a slippery slope .. >>> >>> -phil. >>> >>> On 01/20/2017 04:04 AM, Prasanta Sadhukhan wrote: >>>> It is possible to create manual regression test for this problem. Also the test will require some additional set up steps such as printer installation and so on. It seems to me that is overhead for person who runs it. However if you insist on test creation, I will add it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sat Jan 21 19:39:54 2017 From: philip.race at oracle.com (Philip Race) Date: Sat, 21 Jan 2017 11:39:54 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163889: [macosx] Can't print from browser on Mac OS X In-Reply-To: References: <00DB423C-EF8C-44DE-93E6-8071256D98D4@oracle.com> <5880B0E1.8090704@oracle.com> <9852e243-2f44-05a1-7978-d32cbd91da46@oracle.com> <58828025.9050500@oracle.com> Message-ID: <5883B90A.6010204@oracle.com> +1 -phil On 1/21/17, 11:05 AM, Dmitry Markov wrote: > Hi Phil, > > I agree ?othervm? is not necessary here. That is ?copy-paste? error. > Also I updated the part related to the file deletion based on your > suggestion. > Please find new webrev here: > http://cr.openjdk.java.net/~dmarkov/8163889/webrev.02/ > > > Thanks, > Dmitry >> On 21 Jan 2017, at 00:24, Philip Race > > wrote: >> >> Hi Dmitry, >> > 29 * @run main/othervm PrintCrashTest >> why othervm ? >> >> I don't think that is strictly necessary just because you are using deleteOnExit. >> And FWIW I think the test could "more promptly" delete the file anyway after print returns. >> >> -phil. >> >> >> On 1/20/17, 9:36 AM, Dmitry Markov wrote: >>> Hi Phil, Prasanta, >>> >>> I have updated the fix as you suggested, (i.e. added the regression test). The new webrev is located athttp://cr.openjdk.java.net/~dmarkov/8163889/webrev.01/ >>> Could you review the new version, please? >>> >>> Thanks, >>> Dmitry >>>> On 20 Jan 2017, at 19:50, Phil Race wrote: >>>> >>>> I haven't looked at the fix (yet) but I definitely agree that a manual regression test >>>> for this is better than none. What else should we do ? Just not test printing ? >>>> >>>> In my view which I've expressed to SQE for a really long time, if you aren't testing with >>>> printers installed you aren't testing the whole platform. Whilst it may be convenient >>>> that tests (silently) don't complain when there are no printers, it is a slippery slope .. >>>> >>>> -phil. >>>> >>>> On 01/20/2017 04:04 AM, Prasanta Sadhukhan wrote: >>>>> It is possible to create manual regression test for this problem. Also the test will require some additional set up steps such as printer installation and so on. It seems to me that is overhead for person who runs it. However if you insist on test creation, I will add it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.markov at oracle.com Sat Jan 21 20:14:20 2017 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Sat, 21 Jan 2017 23:14:20 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163889: [macosx] Can't print from browser on Mac OS X In-Reply-To: <5883B90A.6010204@oracle.com> References: <00DB423C-EF8C-44DE-93E6-8071256D98D4@oracle.com> <5880B0E1.8090704@oracle.com> <9852e243-2f44-05a1-7978-d32cbd91da46@oracle.com> <58828025.9050500@oracle.com> <5883B90A.6010204@oracle.com> Message-ID: Thank you very much, Phil! Looking for the second +1 from someone else. Dmitry > On 21 Jan 2017, at 22:39, Philip Race wrote: > > +1 > > -phil > > On 1/21/17, 11:05 AM, Dmitry Markov wrote: >> >> Hi Phil, >> >> I agree ?othervm? is not necessary here. That is ?copy-paste? error. >> Also I updated the part related to the file deletion based on your suggestion. >> Please find new webrev here: http://cr.openjdk.java.net/~dmarkov/8163889/webrev.02/ >> >> Thanks, >> Dmitry >>> On 21 Jan 2017, at 00:24, Philip Race > wrote: >>> >>> Hi Dmitry, >>> > 29 * @run main/othervm PrintCrashTest >>> why othervm ? >>> >>> I don't think that is strictly necessary just because you are using deleteOnExit. >>> And FWIW I think the test could "more promptly" delete the file anyway after print returns. >>> >>> -phil. >>> >>> >>> On 1/20/17, 9:36 AM, Dmitry Markov wrote: >>>> >>>> Hi Phil, Prasanta, >>>> >>>> I have updated the fix as you suggested, (i.e. added the regression test). The new webrev is located at http://cr.openjdk.java.net/~dmarkov/8163889/webrev.01/ >>>> Could you review the new version, please? >>>> >>>> Thanks, >>>> Dmitry >>>>> On 20 Jan 2017, at 19:50, Phil Race wrote: >>>>> >>>>> I haven't looked at the fix (yet) but I definitely agree that a manual regression test >>>>> for this is better than none. What else should we do ? Just not test printing ? >>>>> >>>>> In my view which I've expressed to SQE for a really long time, if you aren't testing with >>>>> printers installed you aren't testing the whole platform. Whilst it may be convenient >>>>> that tests (silently) don't complain when there are no printers, it is a slippery slope .. >>>>> >>>>> -phil. >>>>> >>>>> On 01/20/2017 04:04 AM, Prasanta Sadhukhan wrote: >>>>>> It is possible to create manual regression test for this problem. Also the test will require some additional set up steps such as printer installation and so on. It seems to me that is overhead for person who runs it. However if you insist on test creation, I will add it. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Jan 23 06:17:22 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 23 Jan 2017 11:47:22 +0530 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163889: [macosx] Can't print from browser on Mac OS X In-Reply-To: References: <00DB423C-EF8C-44DE-93E6-8071256D98D4@oracle.com> <5880B0E1.8090704@oracle.com> <9852e243-2f44-05a1-7978-d32cbd91da46@oracle.com> <58828025.9050500@oracle.com> Message-ID: <6ebefe9c-8d36-26e8-d590-be0c996058d9@oracle.com> Hi Dmitry, Any particular reason why in imageDataProvider_UnholdJavaPixels(), we are not doing isdo->pixels = null; which we do in unholdJavaPixels() since in holdJavaPixels() , we are doing 967 else if (isdo->pixels == NULL) 968 { 969 isdo->pixels = (Pixel8bit*)((*env)->GetDirectBufferAddress(env, isdo->array)); 970 } Also, in the test, I guess there's no point catching Exception and rethrowing RuntimeException since we are not doing any processing in catch block. We can just add throws Exception in main() without this catch block and have try-finally. Also, I guess we do not follow adding "author" in the new test anymore. Regards Prasanta On 1/22/2017 12:35 AM, Dmitry Markov wrote: > Hi Phil, > > I agree ?othervm? is not necessary here. That is ?copy-paste? error. > Also I updated the part related to the file deletion based on your > suggestion. > Please find new webrev here: > http://cr.openjdk.java.net/~dmarkov/8163889/webrev.02/ > > > Thanks, > Dmitry >> On 21 Jan 2017, at 00:24, Philip Race > > wrote: >> >> Hi Dmitry, >> > 29 * @run main/othervm PrintCrashTest >> why othervm ? >> >> I don't think that is strictly necessary just because you are using deleteOnExit. >> And FWIW I think the test could "more promptly" delete the file anyway after print returns. >> >> -phil. >> >> >> On 1/20/17, 9:36 AM, Dmitry Markov wrote: >>> Hi Phil, Prasanta, >>> >>> I have updated the fix as you suggested, (i.e. added the regression test). The new webrev is located athttp://cr.openjdk.java.net/~dmarkov/8163889/webrev.01/ >>> Could you review the new version, please? >>> >>> Thanks, >>> Dmitry >>>> On 20 Jan 2017, at 19:50, Phil Race wrote: >>>> >>>> I haven't looked at the fix (yet) but I definitely agree that a manual regression test >>>> for this is better than none. What else should we do ? Just not test printing ? >>>> >>>> In my view which I've expressed to SQE for a really long time, if you aren't testing with >>>> printers installed you aren't testing the whole platform. Whilst it may be convenient >>>> that tests (silently) don't complain when there are no printers, it is a slippery slope .. >>>> >>>> -phil. >>>> >>>> On 01/20/2017 04:04 AM, Prasanta Sadhukhan wrote: >>>>> It is possible to create manual regression test for this problem. Also the test will require some additional set up steps such as printer installation and so on. It seems to me that is overhead for person who runs it. However if you insist on test creation, I will add it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Mon Jan 23 14:24:21 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Mon, 23 Jan 2017 06:24:21 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP In-Reply-To: <220D4634-7558-4D09-B98F-8984759CCF1F@oracle.com> References: <3bb30333-41ef-4ad3-99c1-71388097e5dc@default> <58829788.40509@oracle.com> <94A4ABDA-52F1-4A0E-A5EB-465187442A87@oracle.com> <220D4634-7558-4D09-B98F-8984759CCF1F@oracle.com> Message-ID: Hello Phil & Brian Thank you for your time in review and feedback. . Testing with bmptestsuite . The test suite came handy to test the changes and confirm our approach. . The test suite has a collection of RLE4 compressed images that are- valid, questionable and corrupt. . The collection includes image with Delta sequence as well. . Handling of Delta sequence (0x00 0x02 xOffset yOffset) . The decodeRLE4(...) function deploys line-by-line decoding of compressed bitmap image. . Until decoding of one row (or line) of pixels is complete, the values are stored in intermediate scanline buffer : val. . Upon completion of decoding one row of pixels (ie., with EoL, EoF sequence ), contents of val are copied to destination image's buffer. . Declaration of val buffer is given as . Line 1619: byte[] val = new byte[width]; . As we see, the intermediate scanline array ' val ' is of size : width ( Not- height x width ) . Thus the offset addition to ' l ', in delta sequence will cause index out of bounds if accumulated offset goes beyond size of ' val ' buffer. . Hence the new expression at Line 1691 that limits the offset within the capacity of the buffer- val. . Line 1690: l += xoff + yoff*width; . Line 1691: l %= width; . If the yOffset shifts the decoding to another line, we should ensure to copy the decoded row to destination bitmap. . Failing to do so, will cause the current row to be missed on the destination image. . This is achieved with the new set of lines. . Line 1677: if (yoff != 0) { Line 1678: // Copy the decoded scanline to destination Line 1679: if (copyRLE4ScanlineToDst(lineNo, val, bdata)) { . When tested with bmptestsuite's rle4 images, Delta sequence handling required two additional changes (mentioned in 3.a and 3.b) 3. Changes from previous webrev 3.a. Proper update to the variable- lineNo . After handling a delta sequence (xOffset yOffsest), the variable- lineNo must be updated correspondingly . Reason: lineNo is used to locate exact row on Destination buffer to store intermediate scanline. . Line 1684: lineNo += isBottomUp ? -yOffset : yOffset; 3.b. Clearing of intermediate scanline buffer before starting to decode new row/line. . Ensures the previous row's decoded pixels do not appear on current row 3.c. Minor change to the condition in the while loop to ensure sufficient data is available before every iteration. 3.d. Removal of main/othervm from the jtreg comments in test file. 4. The build with changes was run through Jreg and JCK tests. No regressions were seen. . In addition, the build works well for all input RLE4 bitmap images from the test suite The changes are available for review in the link: http://cr.openjdk.java.net/~pnarayanan/8167278/webrev.02/ Kindly review the changes at your convenience & share your feedback. Thank you once again Have a good day Prahalad N. --- Original message --- From: Brian Burkhalter Sent: Saturday, January 21, 2017 6:05 AM To: Philip Race Cc: 2d-dev at openjdk.java.net; Prahalad Kumar Narayanan Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP On Jan 20, 2017, at 4:30 PM, Brian Burkhalter wrote: That is worrying me since I don't follow these lines are part of that:- 1684 // Move to the position (xoff, yoff). Since l-is used 1685 // to index into the scanline buffer, the calculation 1686 // must be limited by the size 1687 l += xoff + yoff*width; 1688 l %= width; 1687 was already there but 1688 and the comment are new and 1688 looks wrong to me as it would seem to throw away the y it just added in ... Indeed, if xoff is in the half-closed interval [0,width), then (xoff + yoff*width) % width == xoff. This does not however account for the accumulation into "l" which might negate my observation. Brian From dmitry.markov at oracle.com Mon Jan 23 18:22:04 2017 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Mon, 23 Jan 2017 21:22:04 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163889: [macosx] Can't print from browser on Mac OS X In-Reply-To: <6ebefe9c-8d36-26e8-d590-be0c996058d9@oracle.com> References: <00DB423C-EF8C-44DE-93E6-8071256D98D4@oracle.com> <5880B0E1.8090704@oracle.com> <9852e243-2f44-05a1-7978-d32cbd91da46@oracle.com> <58828025.9050500@oracle.com> <6ebefe9c-8d36-26e8-d590-be0c996058d9@oracle.com> Message-ID: Hi Prasanta, As far as I know imageDataProvider_UnholdJavaPixels() is only invoked for images with ?custom? type. We read the data directly from Java memory for such images. At the same time for other image types we use Get/ReleasePrimitiveArrayCritical() and copy the data from Java to native memory. I guess that?s the main reason why we don?t set isdo->pixels to null inside imageDataProvider_UnholdJavaPixels(). Also I updated the test based on your suggestions. Please find the new version here: http://cr.openjdk.java.net/~dmarkov/8163889/webrev.03/ Thanks, Dmitry > On 23 Jan 2017, at 09:17, Prasanta Sadhukhan wrote: > > Hi Dmitry, > Any particular reason why in imageDataProvider_UnholdJavaPixels(), we are not doing > isdo->pixels = null; which we do in unholdJavaPixels() > > since in holdJavaPixels() , we are doing > 967 else if (isdo->pixels == NULL) > 968 { > 969 isdo->pixels = (Pixel8bit*)((*env)->GetDirectBufferAddress(env, isdo->array)); > 970 } > > Also, in the test, I guess there's no point catching Exception and rethrowing RuntimeException since we are not doing any processing in catch block. We can just add throws Exception in main() without this catch block and have try-finally. > Also, I guess we do not follow adding "author" in the new test anymore. > > Regards > Prasanta > On 1/22/2017 12:35 AM, Dmitry Markov wrote: >> Hi Phil, >> >> I agree ?othervm? is not necessary here. That is ?copy-paste? error. >> Also I updated the part related to the file deletion based on your suggestion. >> Please find new webrev here: http://cr.openjdk.java.net/~dmarkov/8163889/webrev.02/ >> >> Thanks, >> Dmitry >>> On 21 Jan 2017, at 00:24, Philip Race > wrote: >>> >>> Hi Dmitry, >>> > 29 * @run main/othervm PrintCrashTest >>> why othervm ? >>> >>> I don't think that is strictly necessary just because you are using deleteOnExit. >>> And FWIW I think the test could "more promptly" delete the file anyway after print returns. >>> >>> -phil. >>> >>> >>> On 1/20/17, 9:36 AM, Dmitry Markov wrote: >>>> >>>> Hi Phil, Prasanta, >>>> >>>> I have updated the fix as you suggested, (i.e. added the regression test). The new webrev is located at http://cr.openjdk.java.net/~dmarkov/8163889/webrev.01/ >>>> Could you review the new version, please? >>>> >>>> Thanks, >>>> Dmitry >>>>> On 20 Jan 2017, at 19:50, Phil Race wrote: >>>>> >>>>> I haven't looked at the fix (yet) but I definitely agree that a manual regression test >>>>> for this is better than none. What else should we do ? Just not test printing ? >>>>> >>>>> In my view which I've expressed to SQE for a really long time, if you aren't testing with >>>>> printers installed you aren't testing the whole platform. Whilst it may be convenient >>>>> that tests (silently) don't complain when there are no printers, it is a slippery slope .. >>>>> >>>>> -phil. >>>>> >>>>> On 01/20/2017 04:04 AM, Prasanta Sadhukhan wrote: >>>>>> It is possible to create manual regression test for this problem. Also the test will require some additional set up steps such as printer installation and so on. It seems to me that is overhead for person who runs it. However if you insist on test creation, I will add it. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Jan 23 19:46:03 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 23 Jan 2017 11:46:03 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP In-Reply-To: References: <3bb30333-41ef-4ad3-99c1-71388097e5dc@default> <58829788.40509@oracle.com> <94A4ABDA-52F1-4A0E-A5EB-465187442A87@oracle.com> <220D4634-7558-4D09-B98F-8984759CCF1F@oracle.com> Message-ID: Hi Prahalad, Out of curiosity, did you test against all BMP images in the suite, or only the ones which are RLE4-compressed? Thanks, Brian On Jan 23, 2017, at 6:24 AM, Prahalad Kumar Narayanan wrote: > . Testing with bmptestsuite > . The test suite came handy to test the changes and confirm our approach. > . The test suite has a collection of RLE4 compressed images that are- valid, questionable and corrupt. > . The collection includes image with Delta sequence as w -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Jan 23 20:35:40 2017 From: philip.race at oracle.com (Phil Race) Date: Mon, 23 Jan 2017 12:35:40 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP In-Reply-To: References: <3bb30333-41ef-4ad3-99c1-71388097e5dc@default> <58829788.40509@oracle.com> <94A4ABDA-52F1-4A0E-A5EB-465187442A87@oracle.com> <220D4634-7558-4D09-B98F-8984759CCF1F@oracle.com> Message-ID: I just noticed something. The bug report says :- > However, I have a public web application that allows users to upload images, > and I was surprised to find a failure caused by an unexpected > ArrayIndexOutOfBoundsException when a user uploaded an apparently-valid RLE4 BMP file. > The attached code contains this BMP file, as a byte array. This means the submitter of this bug report almost certainly does not own this image ! So we cannot include it in the test to be checked in no matter how encoded. Thus you will need to create your own RLE4 encoded BMP. If you can't do that then we won't be able to check in a test. -phil. On 01/23/2017 06:24 AM, Prahalad Kumar Narayanan wrote: > Hello Phil & Brian > > Thank you for your time in review and feedback. > > . Testing with bmptestsuite > . The test suite came handy to test the changes and confirm our approach. > . The test suite has a collection of RLE4 compressed images that are- valid, questionable and corrupt. > . The collection includes image with Delta sequence as well. > > . Handling of Delta sequence (0x00 0x02 xOffset yOffset) > . The decodeRLE4(...) function deploys line-by-line decoding of compressed bitmap image. > . Until decoding of one row (or line) of pixels is complete, the values are stored in intermediate scanline buffer : val. > . Upon completion of decoding one row of pixels (ie., with EoL, EoF sequence ), contents of val are copied to destination image's buffer. > > . Declaration of val buffer is given as > . Line 1619: byte[] val = new byte[width]; > > . As we see, the intermediate scanline array ' val ' is of size : width ( Not- height x width ) > . Thus the offset addition to ' l ', in delta sequence will cause index out of bounds if accumulated offset goes beyond size of ' val ' buffer. > . Hence the new expression at Line 1691 that limits the offset within the capacity of the buffer- val. > . Line 1690: l += xoff + yoff*width; > . Line 1691: l %= width; > > . If the yOffset shifts the decoding to another line, we should ensure to copy the decoded row to destination bitmap. > . Failing to do so, will cause the current row to be missed on the destination image. > . This is achieved with the new set of lines. > . Line 1677: if (yoff != 0) { > Line 1678: // Copy the decoded scanline to destination > Line 1679: if (copyRLE4ScanlineToDst(lineNo, val, bdata)) { > > . When tested with bmptestsuite's rle4 images, Delta sequence handling required two additional changes (mentioned in 3.a and 3.b) > > 3. Changes from previous webrev > 3.a. Proper update to the variable- lineNo > . After handling a delta sequence (xOffset yOffsest), the variable- lineNo must be updated correspondingly > . Reason: lineNo is used to locate exact row on Destination buffer to store intermediate scanline. > . Line 1684: lineNo += isBottomUp ? -yOffset : yOffset; > > 3.b. Clearing of intermediate scanline buffer before starting to decode new row/line. > . Ensures the previous row's decoded pixels do not appear on current row > 3.c. Minor change to the condition in the while loop to ensure sufficient data is available before every iteration. > 3.d. Removal of main/othervm from the jtreg comments in test file. > > 4. The build with changes was run through Jreg and JCK tests. No regressions were seen. > . In addition, the build works well for all input RLE4 bitmap images from the test suite > > The changes are available for review in the link: > http://cr.openjdk.java.net/~pnarayanan/8167278/webrev.02/ > > Kindly review the changes at your convenience & share your feedback. > > Thank you once again > Have a good day > > Prahalad N. > > --- Original message --- > From: Brian Burkhalter > Sent: Saturday, January 21, 2017 6:05 AM > To: Philip Race > Cc: 2d-dev at openjdk.java.net; Prahalad Kumar Narayanan > Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP > > On Jan 20, 2017, at 4:30 PM, Brian Burkhalter wrote: > > > That is worrying me since I don't follow these lines are part of that:- > > 1684 // Move to the position (xoff, yoff). Since l-is used > 1685 // to index into the scanline buffer, the calculation > 1686 // must be limited by the size > 1687 l += xoff + yoff*width; > 1688 l %= width; > 1687 was already there but 1688 and the comment are new and 1688 looks wrong to me > as it would seem to throw away the y it just added in ... > > Indeed, if xoff is in the half-closed interval [0,width), then (xoff + yoff*width) % width == xoff. > > This does not however account for the accumulation into "l" which might negate my observation. > > Brian From prahalad.kumar.narayanan at oracle.com Tue Jan 24 02:54:10 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Mon, 23 Jan 2017 18:54:10 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP In-Reply-To: References: <3bb30333-41ef-4ad3-99c1-71388097e5dc@default> <58829788.40509@oracle.com> <94A4ABDA-52F1-4A0E-A5EB-465187442A87@oracle.com> <220D4634-7558-4D09-B98F-8984759CCF1F@oracle.com> Message-ID: <7424983c-bbc4-45e9-a72c-b8c2f03592bb@default> Hello Brian First, I should thank you for sharing the link. . Since the code changes pertain to one particular format of BMP, I ' did not ' use the entire BMP image set to test. . I used the 3 types of RLE4 compressed images present in the suite- valid, questionable & corrupt. . Having put through this test, I believe, the code is stable now Thank you Have a good day Prahalad N. --- Original Message --- From: Brian Burkhalter Sent: Tuesday, January 24, 2017 1:16 AM To: Prahalad Kumar Narayanan Cc: Philip Race; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP Hi?Prahalad, Out of curiosity, did you test against all BMP images in the suite, or only the ones which are RLE4-compressed? Thanks, Brian On Jan 23, 2017, at 6:24 AM, Prahalad Kumar Narayanan wrote: . Testing with bmptestsuite ?????. The test suite came handy to test the changes and confirm our approach. ?????. The test suite has a collection of RLE4 compressed images that are- valid, questionable and corrupt. ???????????????. The collection includes image with Delta sequence as w From prasanta.sadhukhan at oracle.com Tue Jan 24 05:29:09 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 24 Jan 2017 10:59:09 +0530 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163889: [macosx] Can't print from browser on Mac OS X In-Reply-To: References: <00DB423C-EF8C-44DE-93E6-8071256D98D4@oracle.com> <5880B0E1.8090704@oracle.com> <9852e243-2f44-05a1-7978-d32cbd91da46@oracle.com> <58828025.9050500@oracle.com> <6ebefe9c-8d36-26e8-d590-be0c996058d9@oracle.com> Message-ID: <68ccebf0-3619-7796-a791-05ebec257fd2@oracle.com> Hi Dmitri, On 1/23/2017 11:52 PM, Dmitry Markov wrote: > Hi Prasanta, > > As far as I know imageDataProvider_UnholdJavaPixels() is only invoked > for images with ?custom? type. We read the data directly from Java > memory for such images. I understand that but my question was coming from the fact that, if we are going to print more than 1 "custom" image, then isdo->pixels will point to the same "direct buffer address" (which we obtained for the first custom image) since isdo->pixels will not be NULL (so line 969 will not be executed), whereas ideally, isdo->pixels should obtain the data again. Am I misinterpreting something? > At the same time for other image types we use > Get/ReleasePrimitiveArrayCritical() and copy the data from Java to > native memory. > I guess that?s the main reason why we don?t set isdo->pixels to null > inside imageDataProvider_UnholdJavaPixels(). > > Also I updated the test based on your suggestions. Please find the new > version here: http://cr.openjdk.java.net/~dmarkov/8163889/webrev.03/ > test looks good. Regards Prasanta > > Thanks, > Dmitry > >> On 23 Jan 2017, at 09:17, Prasanta Sadhukhan >> > > wrote: >> >> Hi Dmitry, >> >> Any particular reason why in imageDataProvider_UnholdJavaPixels(), we >> are not doing >> >> isdo->pixels = null; which we do in unholdJavaPixels() >> >> since in holdJavaPixels() , we are doing >> 967 else if (isdo->pixels == NULL) >> 968 { >> 969 isdo->pixels = (Pixel8bit*)((*env)->GetDirectBufferAddress(env, isdo->array)); >> 970 } >> >> Also, in the test, I guess there's no point catching Exception and >> rethrowing RuntimeException since we are not doing any processing in >> catch block. We can just add throws Exception in main() without this >> catch block and have try-finally. >> Also, I guess we do not follow adding "author" in the new test anymore. >> >> Regards >> Prasanta >> On 1/22/2017 12:35 AM, Dmitry Markov wrote: >>> Hi Phil, >>> >>> I agree ?othervm? is not necessary here. That is ?copy-paste? error. >>> Also I updated the part related to the file deletion based on your >>> suggestion. >>> Please find new webrev here: >>> http://cr.openjdk.java.net/~dmarkov/8163889/webrev.02/ >>> >>> >>> Thanks, >>> Dmitry >>>> On 21 Jan 2017, at 00:24, Philip Race >>> > wrote: >>>> >>>> Hi Dmitry, >>>> > 29 * @run main/othervm PrintCrashTest >>>> why othervm ? >>>> >>>> I don't think that is strictly necessary just because you are using deleteOnExit. >>>> And FWIW I think the test could "more promptly" delete the file anyway after print returns. >>>> >>>> -phil. >>>> >>>> >>>> On 1/20/17, 9:36 AM, Dmitry Markov wrote: >>>>> Hi Phil, Prasanta, >>>>> >>>>> I have updated the fix as you suggested, (i.e. added the regression test). The new webrev is located athttp://cr.openjdk.java.net/~dmarkov/8163889/webrev.01/ >>>>> Could you review the new version, please? >>>>> >>>>> Thanks, >>>>> Dmitry >>>>>> On 20 Jan 2017, at 19:50, Phil Race wrote: >>>>>> >>>>>> I haven't looked at the fix (yet) but I definitely agree that a manual regression test >>>>>> for this is better than none. What else should we do ? Just not test printing ? >>>>>> >>>>>> In my view which I've expressed to SQE for a really long time, if you aren't testing with >>>>>> printers installed you aren't testing the whole platform. Whilst it may be convenient >>>>>> that tests (silently) don't complain when there are no printers, it is a slippery slope .. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 01/20/2017 04:04 AM, Prasanta Sadhukhan wrote: >>>>>>> It is possible to create manual regression test for this problem. Also the test will require some additional set up steps such as printer installation and so on. It seems to me that is overhead for person who runs it. However if you insist on test creation, I will add it. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.markov at oracle.com Tue Jan 24 06:34:37 2017 From: dmitry.markov at oracle.com (dmitry markov) Date: Tue, 24 Jan 2017 09:34:37 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163889: [macosx] Can't print from browser on Mac OS X In-Reply-To: <68ccebf0-3619-7796-a791-05ebec257fd2@oracle.com> References: <00DB423C-EF8C-44DE-93E6-8071256D98D4@oracle.com> <5880B0E1.8090704@oracle.com> <9852e243-2f44-05a1-7978-d32cbd91da46@oracle.com> <58828025.9050500@oracle.com> <6ebefe9c-8d36-26e8-d590-be0c996058d9@oracle.com> <68ccebf0-3619-7796-a791-05ebec257fd2@oracle.com> Message-ID: <5886F57D.4090601@oracle.com> Hi Prasanta, Please find my answer inline. Thanks, Dmitry On 24/01/2017 08:29, Prasanta Sadhukhan wrote: > > Hi Dmitri, > > > On 1/23/2017 11:52 PM, Dmitry Markov wrote: >> Hi Prasanta, >> >> As far as I know imageDataProvider_UnholdJavaPixels() is only invoked >> for images with ?custom? type. We read the data directly from Java >> memory for such images. > I understand that but my question was coming from the fact that, if we > are going to print more than 1 "custom" image, then isdo->pixels will > point to the same "direct buffer address" (which we obtained for the > first custom image) since isdo->pixels will not be NULL (so line 969 > will not be executed), whereas ideally, isdo->pixels should obtain the > data again. Am I misinterpreting something? Actually we initialize isdo structure based on data from Java layer anytime when an image is printed, see LockImage() function. So isdo->pixels will be correctly initialized inside holdJavaPixels() for every "custom" image. I am sorry, but the situation you described above is not possible here. >> At the same time for other image types we use >> Get/ReleasePrimitiveArrayCritical() and copy the data from Java to >> native memory. >> I guess that?s the main reason why we don?t set isdo->pixels to null >> inside imageDataProvider_UnholdJavaPixels(). >> >> Also I updated the test based on your suggestions. Please find the >> new version here: >> http://cr.openjdk.java.net/~dmarkov/8163889/webrev.03/ >> > test looks good. > > Regards > Prasanta >> >> Thanks, >> Dmitry >> >>> On 23 Jan 2017, at 09:17, Prasanta Sadhukhan >>> >> > wrote: >>> >>> Hi Dmitry, >>> >>> Any particular reason why in imageDataProvider_UnholdJavaPixels(), >>> we are not doing >>> >>> isdo->pixels = null; which we do in unholdJavaPixels() >>> >>> since in holdJavaPixels() , we are doing >>> 967 else if (isdo->pixels == NULL) >>> 968 { >>> 969 isdo->pixels = (Pixel8bit*)((*env)->GetDirectBufferAddress(env, isdo->array)); >>> 970 } >>> >>> Also, in the test, I guess there's no point catching Exception and >>> rethrowing RuntimeException since we are not doing any processing in >>> catch block. We can just add throws Exception in main() without this >>> catch block and have try-finally. >>> Also, I guess we do not follow adding "author" in the new test anymore. >>> >>> Regards >>> Prasanta >>> On 1/22/2017 12:35 AM, Dmitry Markov wrote: >>>> Hi Phil, >>>> >>>> I agree ?othervm? is not necessary here. That is ?copy-paste? error. >>>> Also I updated the part related to the file deletion based on your >>>> suggestion. >>>> Please find new webrev here: >>>> http://cr.openjdk.java.net/~dmarkov/8163889/webrev.02/ >>>> >>>> >>>> Thanks, >>>> Dmitry >>>>> On 21 Jan 2017, at 00:24, Philip Race >>>> > wrote: >>>>> >>>>> Hi Dmitry, >>>>> > 29 * @run main/othervm PrintCrashTest >>>>> why othervm ? >>>>> >>>>> I don't think that is strictly necessary just because you are using deleteOnExit. >>>>> And FWIW I think the test could "more promptly" delete the file anyway after print returns. >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 1/20/17, 9:36 AM, Dmitry Markov wrote: >>>>>> Hi Phil, Prasanta, >>>>>> >>>>>> I have updated the fix as you suggested, (i.e. added the regression test). The new webrev is located athttp://cr.openjdk.java.net/~dmarkov/8163889/webrev.01/ >>>>>> Could you review the new version, please? >>>>>> >>>>>> Thanks, >>>>>> Dmitry >>>>>>> On 20 Jan 2017, at 19:50, Phil Race wrote: >>>>>>> >>>>>>> I haven't looked at the fix (yet) but I definitely agree that a manual regression test >>>>>>> for this is better than none. What else should we do ? Just not test printing ? >>>>>>> >>>>>>> In my view which I've expressed to SQE for a really long time, if you aren't testing with >>>>>>> printers installed you aren't testing the whole platform. Whilst it may be convenient >>>>>>> that tests (silently) don't complain when there are no printers, it is a slippery slope .. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 01/20/2017 04:04 AM, Prasanta Sadhukhan wrote: >>>>>>>> It is possible to create manual regression test for this problem. Also the test will require some additional set up steps such as printer installation and so on. It seems to me that is overhead for person who runs it. However if you insist on test creation, I will add it. >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Jan 24 06:40:46 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 24 Jan 2017 12:10:46 +0530 Subject: [OpenJDK 2D-Dev] [9] Review request for 8163889: [macosx] Can't print from browser on Mac OS X In-Reply-To: <5886F57D.4090601@oracle.com> References: <00DB423C-EF8C-44DE-93E6-8071256D98D4@oracle.com> <5880B0E1.8090704@oracle.com> <9852e243-2f44-05a1-7978-d32cbd91da46@oracle.com> <58828025.9050500@oracle.com> <6ebefe9c-8d36-26e8-d590-be0c996058d9@oracle.com> <68ccebf0-3619-7796-a791-05ebec257fd2@oracle.com> <5886F57D.4090601@oracle.com> Message-ID: ok. +1 Regards Prasanta On 1/24/2017 12:04 PM, dmitry markov wrote: > Hi Prasanta, > > Please find my answer inline. > > Thanks, > Dmitry > On 24/01/2017 08:29, Prasanta Sadhukhan wrote: >> >> Hi Dmitri, >> >> >> On 1/23/2017 11:52 PM, Dmitry Markov wrote: >>> Hi Prasanta, >>> >>> As far as I know imageDataProvider_UnholdJavaPixels() is only >>> invoked for images with ?custom? type. We read the data directly >>> from Java memory for such images. >> I understand that but my question was coming from the fact that, if >> we are going to print more than 1 "custom" image, then isdo->pixels >> will point to the same "direct buffer address" (which we obtained for >> the first custom image) since isdo->pixels will not be NULL (so line >> 969 will not be executed), whereas ideally, isdo->pixels should >> obtain the data again. Am I misinterpreting something? > Actually we initialize isdo structure based on data from Java layer > anytime when an image is printed, see LockImage() function. So > isdo->pixels will be correctly initialized inside holdJavaPixels() for > every "custom" image. I am sorry, but the situation you described > above is not possible here. >>> At the same time for other image types we use >>> Get/ReleasePrimitiveArrayCritical() and copy the data from Java to >>> native memory. >>> I guess that?s the main reason why we don?t set isdo->pixels to null >>> inside imageDataProvider_UnholdJavaPixels(). >>> >>> Also I updated the test based on your suggestions. Please find the >>> new version here: >>> http://cr.openjdk.java.net/~dmarkov/8163889/webrev.03/ >>> >> test looks good. >> >> Regards >> Prasanta >>> >>> Thanks, >>> Dmitry >>> >>>> On 23 Jan 2017, at 09:17, Prasanta Sadhukhan >>>> >>> > wrote: >>>> >>>> Hi Dmitry, >>>> >>>> Any particular reason why in imageDataProvider_UnholdJavaPixels(), >>>> we are not doing >>>> >>>> isdo->pixels = null; which we do in unholdJavaPixels() >>>> >>>> since in holdJavaPixels() , we are doing >>>> 967 else if (isdo->pixels == NULL) >>>> 968 { >>>> 969 isdo->pixels = (Pixel8bit*)((*env)->GetDirectBufferAddress(env, isdo->array)); >>>> 970 } >>>> >>>> Also, in the test, I guess there's no point catching Exception and >>>> rethrowing RuntimeException since we are not doing any processing >>>> in catch block. We can just add throws Exception in main() without >>>> this catch block and have try-finally. >>>> Also, I guess we do not follow adding "author" in the new test >>>> anymore. >>>> >>>> Regards >>>> Prasanta >>>> On 1/22/2017 12:35 AM, Dmitry Markov wrote: >>>>> Hi Phil, >>>>> >>>>> I agree ?othervm? is not necessary here. That is ?copy-paste? error. >>>>> Also I updated the part related to the file deletion based on your >>>>> suggestion. >>>>> Please find new webrev here: >>>>> http://cr.openjdk.java.net/~dmarkov/8163889/webrev.02/ >>>>> >>>>> >>>>> Thanks, >>>>> Dmitry >>>>>> On 21 Jan 2017, at 00:24, Philip Race >>>>> > wrote: >>>>>> >>>>>> Hi Dmitry, >>>>>> > 29 * @run main/othervm PrintCrashTest >>>>>> why othervm ? >>>>>> >>>>>> I don't think that is strictly necessary just because you are using deleteOnExit. >>>>>> And FWIW I think the test could "more promptly" delete the file anyway after print returns. >>>>>> >>>>>> -phil. >>>>>> >>>>>> >>>>>> On 1/20/17, 9:36 AM, Dmitry Markov wrote: >>>>>>> Hi Phil, Prasanta, >>>>>>> >>>>>>> I have updated the fix as you suggested, (i.e. added the regression test). The new webrev is located athttp://cr.openjdk.java.net/~dmarkov/8163889/webrev.01/ >>>>>>> Could you review the new version, please? >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitry >>>>>>>> On 20 Jan 2017, at 19:50, Phil Race wrote: >>>>>>>> >>>>>>>> I haven't looked at the fix (yet) but I definitely agree that a manual regression test >>>>>>>> for this is better than none. What else should we do ? Just not test printing ? >>>>>>>> >>>>>>>> In my view which I've expressed to SQE for a really long time, if you aren't testing with >>>>>>>> printers installed you aren't testing the whole platform. Whilst it may be convenient >>>>>>>> that tests (silently) don't complain when there are no printers, it is a slippery slope .. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 01/20/2017 04:04 AM, Prasanta Sadhukhan wrote: >>>>>>>>> It is possible to create manual regression test for this problem. Also the test will require some additional set up steps such as printer installation and so on. It seems to me that is overhead for person who runs it. However if you insist on test creation, I will add it. >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Tue Jan 24 08:57:40 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Tue, 24 Jan 2017 00:57:40 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP In-Reply-To: References: <3bb30333-41ef-4ad3-99c1-71388097e5dc@default> <58829788.40509@oracle.com> <94A4ABDA-52F1-4A0E-A5EB-465187442A87@oracle.com> <220D4634-7558-4D09-B98F-8984759CCF1F@oracle.com> Message-ID: <8135383b-5ee6-4dc1-b748-077c010f166b@default> Hello Phil I agree with you in your observation. We cannot include the image in the test case. This morning, I created many RLE4 bitmap images using Gimp. But none of the created images contained Delta sequence /or corrupt image data to cause ArrayIndexOutOfBounds Exception. Henceforth, I 've removed the test case from the proposed fix. I 've also substantiated the reasons in JBS for not including a test case. The new webrev without test-case is available under Link: http://cr.openjdk.java.net/~pnarayanan/8167278/webrev.03/ Kindly review at your convenience and share the feedback. Thank you for your time Have a good day Prahalad N. -----Original Message----- From: Phil Race Sent: Tuesday, January 24, 2017 2:06 AM To: Prahalad Kumar Narayanan; Brian Burkhalter Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP I just noticed something. The bug report says :- > However, I have a public web application that allows users to upload images, > and I was surprised to find a failure caused by an unexpected > ArrayIndexOutOfBoundsException when a user uploaded an apparently-valid RLE4 BMP file. > The attached code contains this BMP file, as a byte array. This means the submitter of this bug report almost certainly does not own this image ! So we cannot include it in the test to be checked in no matter how encoded. Thus you will need to create your own RLE4 encoded BMP. If you can't do that then we won't be able to check in a test. -phil. On 01/23/2017 06:24 AM, Prahalad Kumar Narayanan wrote: > Hello Phil & Brian > > Thank you for your time in review and feedback. > > . Testing with bmptestsuite > . The test suite came handy to test the changes and confirm our approach. > . The test suite has a collection of RLE4 compressed images that are- valid, questionable and corrupt. > . The collection includes image with Delta sequence as well. > > . Handling of Delta sequence (0x00 0x02 xOffset yOffset) > . The decodeRLE4(...) function deploys line-by-line decoding of compressed bitmap image. > . Until decoding of one row (or line) of pixels is complete, the values are stored in intermediate scanline buffer : val. > . Upon completion of decoding one row of pixels (ie., with EoL, EoF sequence ), contents of val are copied to destination image's buffer. > > . Declaration of val buffer is given as > . Line 1619: byte[] val = new byte[width]; > > . As we see, the intermediate scanline array ' val ' is of size : width ( Not- height x width ) > . Thus the offset addition to ' l ', in delta sequence will cause index out of bounds if accumulated offset goes beyond size of ' val ' buffer. > . Hence the new expression at Line 1691 that limits the offset within the capacity of the buffer- val. > . Line 1690: l += xoff + yoff*width; > . Line 1691: l %= width; > > . If the yOffset shifts the decoding to another line, we should ensure to copy the decoded row to destination bitmap. > . Failing to do so, will cause the current row to be missed on the destination image. > . This is achieved with the new set of lines. > . Line 1677: if (yoff != 0) { > Line 1678: // Copy the decoded scanline to destination > Line 1679: if (copyRLE4ScanlineToDst(lineNo, val, bdata)) { > > . When tested with bmptestsuite's rle4 images, Delta sequence > handling required two additional changes (mentioned in 3.a and 3.b) > > 3. Changes from previous webrev > 3.a. Proper update to the variable- lineNo > . After handling a delta sequence (xOffset yOffsest), the variable- lineNo must be updated correspondingly > . Reason: lineNo is used to locate exact row on Destination buffer to store intermediate scanline. > . Line 1684: lineNo += isBottomUp ? -yOffset : yOffset; > > 3.b. Clearing of intermediate scanline buffer before starting to decode new row/line. > . Ensures the previous row's decoded pixels do not appear on current row > 3.c. Minor change to the condition in the while loop to ensure sufficient data is available before every iteration. > 3.d. Removal of main/othervm from the jtreg comments in test file. > > 4. The build with changes was run through Jreg and JCK tests. No regressions were seen. > . In addition, the build works well for all input RLE4 bitmap > images from the test suite > > The changes are available for review in the link: > http://cr.openjdk.java.net/~pnarayanan/8167278/webrev.02/ > > Kindly review the changes at your convenience & share your feedback. > > Thank you once again > Have a good day > > Prahalad N. > > --- Original message --- > From: Brian Burkhalter > Sent: Saturday, January 21, 2017 6:05 AM > To: Philip Race > Cc: 2d-dev at openjdk.java.net; Prahalad Kumar Narayanan > Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: > ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) > with RLE4 BMP > > On Jan 20, 2017, at 4:30 PM, Brian Burkhalter wrote: > > > That is worrying me since I don't follow these lines are part of > that:- > > 1684 // Move to the position (xoff, yoff). Since l-is used > 1685 // to index into the scanline buffer, the calculation > 1686 // must be limited by the size > 1687 l += xoff + yoff*width; > 1688 l %= width; > 1687 was already there but 1688 and the comment are new and 1688 looks > wrong to me as it would seem to throw away the y it just added in ... > > Indeed, if xoff is in the half-closed interval [0,width), then (xoff + yoff*width) % width == xoff. > > This does not however account for the accumulation into "l" which might negate my observation. > > Brian From brian.burkhalter at oracle.com Tue Jan 24 21:08:09 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 24 Jan 2017 13:08:09 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8152561: Is it allowed to have zero value for count in TIFFField.createArrayForType() for the rationals In-Reply-To: <1dca39d1-82dd-45a4-a918-d0cb53257f70@default> References: <11ec13a4-cae7-ecac-2fc5-1f4431f3cceb@oracle.com> <1dca39d1-82dd-45a4-a918-d0cb53257f70@default> Message-ID: <665EA001-9810-4961-BD57-E4C188641B58@oracle.com> Hi Jay, I think line 910 of TIFFField needs to state ?and count != 1?. Also the copyright year should now be 2017. OK to make these changes without another webrev: +1. Thanks, Brian On Jan 18, 2017, at 1:03 AM, Jayathirth D V wrote: > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/8152561/webrev.01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jan 25 01:18:28 2017 From: philip.race at oracle.com (Philip Race) Date: Tue, 24 Jan 2017 17:18:28 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP In-Reply-To: <8135383b-5ee6-4dc1-b748-077c010f166b@default> References: <3bb30333-41ef-4ad3-99c1-71388097e5dc@default> <58829788.40509@oracle.com> <94A4ABDA-52F1-4A0E-A5EB-465187442A87@oracle.com> <220D4634-7558-4D09-B98F-8984759CCF1F@oracle.com> <8135383b-5ee6-4dc1-b748-077c010f166b@default> Message-ID: <5887FCE4.4080200@oracle.com> OK .. +1 -phil. On 1/24/17, 12:57 AM, Prahalad Kumar Narayanan wrote: > Hello Phil > > I agree with you in your observation. We cannot include the image in the test case. > > This morning, I created many RLE4 bitmap images using Gimp. But none of the created images contained Delta sequence /or corrupt image data to cause ArrayIndexOutOfBounds Exception. Henceforth, I 've removed the test case from the proposed fix. I 've also substantiated the reasons in JBS for not including a test case. > > The new webrev without test-case is available under > Link: http://cr.openjdk.java.net/~pnarayanan/8167278/webrev.03/ > > Kindly review at your convenience and share the feedback. > > Thank you for your time > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Phil Race > Sent: Tuesday, January 24, 2017 2:06 AM > To: Prahalad Kumar Narayanan; Brian Burkhalter > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP > > I just noticed something. The bug report says :- > > > However, I have a public web application that allows users to upload images, > > and I was surprised to find a failure caused by an unexpected > > ArrayIndexOutOfBoundsException when a user uploaded an apparently-valid RLE4 BMP file. > > The attached code contains this BMP file, as a byte array. > > This means the submitter of this bug report almost certainly does not own this image ! > So we cannot include it in the test to be checked in no matter how encoded. > > Thus you will need to create your own RLE4 encoded BMP. > If you can't do that then we won't be able to check in a test. > > -phil. > > On 01/23/2017 06:24 AM, Prahalad Kumar Narayanan wrote: >> Hello Phil& Brian >> >> Thank you for your time in review and feedback. >> >> . Testing with bmptestsuite >> . The test suite came handy to test the changes and confirm our approach. >> . The test suite has a collection of RLE4 compressed images that are- valid, questionable and corrupt. >> . The collection includes image with Delta sequence as well. >> >> . Handling of Delta sequence (0x00 0x02 xOffset yOffset) >> . The decodeRLE4(...) function deploys line-by-line decoding of compressed bitmap image. >> . Until decoding of one row (or line) of pixels is complete, the values are stored in intermediate scanline buffer : val. >> . Upon completion of decoding one row of pixels (ie., with EoL, EoF sequence ), contents of val are copied to destination image's buffer. >> >> . Declaration of val buffer is given as >> . Line 1619: byte[] val = new byte[width]; >> >> . As we see, the intermediate scanline array ' val ' is of size : width ( Not- height x width ) >> . Thus the offset addition to ' l ', in delta sequence will cause index out of bounds if accumulated offset goes beyond size of ' val ' buffer. >> . Hence the new expression at Line 1691 that limits the offset within the capacity of the buffer- val. >> . Line 1690: l += xoff + yoff*width; >> . Line 1691: l %= width; >> >> . If the yOffset shifts the decoding to another line, we should ensure to copy the decoded row to destination bitmap. >> . Failing to do so, will cause the current row to be missed on the destination image. >> . This is achieved with the new set of lines. >> . Line 1677: if (yoff != 0) { >> Line 1678: // Copy the decoded scanline to destination >> Line 1679: if (copyRLE4ScanlineToDst(lineNo, val, bdata)) { >> >> . When tested with bmptestsuite's rle4 images, Delta sequence >> handling required two additional changes (mentioned in 3.a and 3.b) >> >> 3. Changes from previous webrev >> 3.a. Proper update to the variable- lineNo >> . After handling a delta sequence (xOffset yOffsest), the variable- lineNo must be updated correspondingly >> . Reason: lineNo is used to locate exact row on Destination buffer to store intermediate scanline. >> . Line 1684: lineNo += isBottomUp ? -yOffset : yOffset; >> >> 3.b. Clearing of intermediate scanline buffer before starting to decode new row/line. >> . Ensures the previous row's decoded pixels do not appear on current row >> 3.c. Minor change to the condition in the while loop to ensure sufficient data is available before every iteration. >> 3.d. Removal of main/othervm from the jtreg comments in test file. >> >> 4. The build with changes was run through Jreg and JCK tests. No regressions were seen. >> . In addition, the build works well for all input RLE4 bitmap >> images from the test suite >> >> The changes are available for review in the link: >> http://cr.openjdk.java.net/~pnarayanan/8167278/webrev.02/ >> >> Kindly review the changes at your convenience& share your feedback. >> >> Thank you once again >> Have a good day >> >> Prahalad N. >> >> --- Original message --- >> From: Brian Burkhalter >> Sent: Saturday, January 21, 2017 6:05 AM >> To: Philip Race >> Cc: 2d-dev at openjdk.java.net; Prahalad Kumar Narayanan >> Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: >> ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) >> with RLE4 BMP >> >> On Jan 20, 2017, at 4:30 PM, Brian Burkhalter wrote: >> >> >> That is worrying me since I don't follow these lines are part of >> that:- >> >> 1684 // Move to the position (xoff, yoff). Since l-is used >> 1685 // to index into the scanline buffer, the calculation >> 1686 // must be limited by the size >> 1687 l += xoff + yoff*width; >> 1688 l %= width; >> 1687 was already there but 1688 and the comment are new and 1688 looks >> wrong to me as it would seem to throw away the y it just added in ... >> >> Indeed, if xoff is in the half-closed interval [0,width), then (xoff + yoff*width) % width == xoff. >> >> This does not however account for the accumulation into "l" which might negate my observation. >> >> Brian From philip.race at oracle.com Wed Jan 25 05:31:15 2017 From: philip.race at oracle.com (Philip Race) Date: Tue, 24 Jan 2017 21:31:15 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8152561: Is it allowed to have zero value for count in TIFFField.createArrayForType() for the rationals In-Reply-To: <665EA001-9810-4961-BD57-E4C188641B58@oracle.com> References: <11ec13a4-cae7-ecac-2fc5-1f4431f3cceb@oracle.com> <1dca39d1-82dd-45a4-a918-d0cb53257f70@default> <665EA001-9810-4961-BD57-E4C188641B58@oracle.com> Message-ID: <58883823.2020702@oracle.com> } else if((dataType == TIFFTag.TIFF_RATIONAL I know that someone (ahem Brian ;-)) has a lot of "if(" code in here but please make any new ones "if (" Other than that, +1 -phil. On 1/24/17, 1:08 PM, Brian Burkhalter wrote: > Hi Jay, > > I think line 910 of TIFFField needs to state ?and count != 1?. Also > the copyright year should now be 2017. > > OK to make these changes without another webrev: +1. > > Thanks, > > Brian > > On Jan 18, 2017, at 1:03 AM, Jayathirth D V > wrote: > >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/8152561/webrev.01/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Jan 25 07:26:18 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 24 Jan 2017 23:26:18 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8152561: Is it allowed to have zero value for count in TIFFField.createArrayForType() for the rationals In-Reply-To: <58883823.2020702@oracle.com> References: <11ec13a4-cae7-ecac-2fc5-1f4431f3cceb@oracle.com> <1dca39d1-82dd-45a4-a918-d0cb53257f70@default> <665EA001-9810-4961-BD57-E4C188641B58@oracle.com> <58883823.2020702@oracle.com> Message-ID: Hi Phil & Brian, Thanks for your review. FYI, I have updated the webrev to include your suggestions : http://cr.openjdk.java.net/~jdv/8152561/webrev.02/ Regards, Jay From: Philip Race Sent: Wednesday, January 25, 2017 11:01 AM To: Brian Burkhalter Cc: Jayathirth D V; Prasanta Sadhukhan; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8152561: Is it allowed to have zero value for count in TIFFField.createArrayForType() for the rationals } else if((dataType == TIFFTag.TIFF_RATIONAL I know that someone (ahem Brian ;-)) has a lot of "if(" code in here but please make any new ones "if (" Other than that, +1 -phil. On 1/24/17, 1:08 PM, Brian Burkhalter wrote: Hi Jay, I think line 910 of TIFFField needs to state "and count != 1". Also the copyright year should now be 2017. OK to make these changes without another webrev: +1. Thanks, Brian On Jan 18, 2017, at 1:03 AM, Jayathirth D V wrote: Please find updated webrev for review : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8152561/webrev.01/"http://cr.openjdk.java.net/~jdv/8152561/webrev.01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Jan 25 15:33:22 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 25 Jan 2017 07:33:22 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8152561: Is it allowed to have zero value for count in TIFFField.createArrayForType() for the rationals In-Reply-To: References: <11ec13a4-cae7-ecac-2fc5-1f4431f3cceb@oracle.com> <1dca39d1-82dd-45a4-a918-d0cb53257f70@default> <665EA001-9810-4961-BD57-E4C188641B58@oracle.com> <58883823.2020702@oracle.com> Message-ID: Hi Jay, +1 Thanks, Brian On Jan 24, 2017, at 11:26 PM, Jayathirth D V wrote: > Thanks for your review. > FYI, I have updated the webrev to include your suggestions : > http://cr.openjdk.java.net/~jdv/8152561/webrev.02/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jan 27 16:41:42 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 27 Jan 2017 08:41:42 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <3aefa53e-dd6f-46ba-9345-4f78e76c23d6@default> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <24ca2994-aa27-4a70-8cf9-0bda35664f3f@default> <574809B2.5040901@oracle.com> <9f641938-f979-4021-9e94-bde47e1d3c67@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> <57744D0D.9080809@oracle.com> <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> <3aefa53e-dd6f-46ba-9345-4f78e76c23d6@default> Message-ID: Hi Jay, Joe had suggested >ColorModel is redefined to use identity-is-equality equals semantics, the default behavior from object. > This avoids the need to define a hashcode method in the base class. However you have restored the problem that started this. ColorModel now over-rides equals but not hashCode and it doesn't matter that it just delegates. Code that checks for this pattern can't tell that. I think Joe must have meant to *remove* the ColorModel.equals() method entirely. Other than that it looks fine to me. -phil. On 01/19/2017 02:17 AM, Jayathirth D V wrote: > Hello All, > > After getting feedback from Joe in CCC I have made changes to the code to reflect Joe's suggestions. > > For ColorModel class I have just added identity-is-equality equals(). > For its subclasses like IndexColorModel, PackedColorModel & ComponentColorModel, I have added instanceOf checks and checking all fields for equality. Since we are not checking any fields in ColorModel, in subclasses there will be redundant checks. > DirectColorModel has no unique properties to check so it will be using PackedColorModel equals() and hashCode(). > > Please review the updated code at your convenience: > http://cr.openjdk.java.net/~jdv/7107905/webrev.14/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Friday, July 22, 2016 3:15 AM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods > > Looks good to me... > > ...jim > > On 07/20/2016 09:53 AM, Jayathirth D V wrote: >> Hi Jim, >> >> Thanks for your input. >> I have updated specification of ColorModel and its subclasses. >> Please find new webrev for review: >> http://cr.openjdk.java.net/~jdv/7107905/webrev.13/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Tuesday, July 12, 2016 7:41 PM >> To: Jayathirth D V; Philip Race >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >> ColorModel subclasses are missing hashCode() or equals() or both >> methods >> >> Hi Jay, >> >> When I write javadoc suggestions I sometimes use the short-hand "{some text}" to indicate that it should be formatted using javadoc protocols, typically that expands to "{@code some text}", but sometimes a link may be appropriate. It looks like you copied and pasted a number of places where I wrote "{foo}" in email and just left the bare braces there, please adjust those (most of them should probably just have "@code" inserted. >> >> In ColorModel.equals(), I'd replace the entire "following properties" sentence with: >> >> * Subclasses may check additional properties, but this method >> * will check the following basic properties for equivalence to >> * determine if the target object equals this object: >> >> The text for IndexColorModel is also a little odd. I'd change it to something like: >> >> * The target object and this object will be equal iff >> * {@link ColorModel#equals()} returns true and the following >> * properties are also the same: >> >> For Packed: >> >> * The target object and this object will be equal iff >> * {@link ColorModel#equals()} returns true and the masks >> * of the color and alpha samples are the same. >> >> In terms of Joe's request, I'd add the following text to ColorModel.equals() right after we talk about all of the properties that it checks: >> >> *

>> * Subclasses should override this method if they have any additional >> * properties to compare and should use the following implementation. >> * Note that the base {@code ColorModel} class already ensures that >> * the target object is the same class as this object so the cast to >> * the subclass type can be assumed if {@code super.equals(obj)} >> returns >> * true. >> * 

>> *     public boolean equals(Object obj) {
>> *         if (!super.equals(obj)) {
>> *             return false;
>> *         }
>> *         MyCMClass cm = (MyCMClass) obj;
>> *         // test additional properties on "cm" and "this"
>> *     }
>> *
>> >> >> On 7/1/16 3:31 AM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> Thanks for your inputs. >>> I have discussed with Phil also regarding the same issue offline. >>> I have collated all the changes mentioned by you and Phil in the latest webrev: >>> http://cr.openjdk.java.net/~jdv/7107905/webrev.12/ >>> >>> But I was not able to understand your statement - "Arguably, we could omit the class comparison text from the subclasses as well by using a reference like that, but I think that the class equivalence test is enough out of the ordinary that it does bear reiterating it in every subclass as you already do now even though we only reference the specific other properties tested by a reference.", please clarify. >>> >>> Also I am not able find a way to describe Joe's concern of "The ColorModel equals and hashCode methods should spell out the protocol subclasses need to follow to obey the respective contracts of methods.", I have discussed with Phil also regarding the same offline. Any inputs on this also would be helpful. >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Thursday, June 30, 2016 4:05 AM >>> To: Jayathirth D V; Philip Race; 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >>> ColorModel subclasses are missing hashCode() or equals() or both >>> methods >>> >>> Hi Jay, >>> >>> We need to reference the properties from the base class in the subclasses. We don't need to list them every time, but we could introduce the "additional properties" using something like: >>> >>> "... we check all of the properties checked by the {equals} method of {ColorModel}, and the following additional properties:" >>> >>> Arguably, we could omit the class comparison text from the subclasses as well by using a reference like that, but I think that the class equivalence test is enough out of the ordinary that it does bear reiterating it in every subclass as you already do now even though we only reference the specific other properties tested by a reference. >>> >>> A few grammar fixes: >>> >>> In all of the classes, insert a space before any parentheses in >>> comment text as in "the same class (and not a subclass)". (That >>> wouldn't apply if the text in the comment is referring to code - then >>> space it as you would actual code.) >>> >>> In CM, insert the word "the" as in "also check the following ..." >>> >>> In ICM I would refer to the "Valid bits of" instead as "The list of valid pixel indices in". >>> >>> In PCM I would change "check maskArray of ..." to "check the masks of the ..." and pluralize the word "samples". >>> >>> ...jim >>> >>> On 06/29/2016 04:13 AM, Jayathirth D V wrote: >>>> Hi, >>>> >>>> Since Joe mentioned to add information related to what fields we are using to calculate equals() method in ColorModel and its subclasses I have updated the spec for the same. >>>> >>>> Please find updated webrev for review: >>>> http://cr.openjdk.java.net/~jdv/7107905/webrev.11/ >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Saturday, June 04, 2016 4:52 AM >>>> To: Jayathirth D V; Philip Race >>>> Cc: 2d-dev at openjdk.java.net >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >>>> ColorModel subclasses are missing hashCode() or equals() or both >>>> methods >>>> >>>> That looks good to me. Has the CCC cleared yet? >>>> >>>> ...jim >>>> >>>> On 6/3/16 2:49 AM, Jayathirth D V wrote: >>>>> Hi Jim, >>>>> >>>>> Oh that's an important change. >>>>> Thanks for your review. >>>>> >>>>> I have updated ColorModel constructor to copy nBIts only of numOfComponents length and I have removed validBits check in hashCode() of ICM. >>>>> Please find updated webrev for review: >>>>> http://cr.openjdk.java.net/~jdv/7107905/webrev.10/ >>>>> >>>>> Thanks, >>>>> Jay >>>>> >>>>> -----Original Message----- >>>>> From: Jim Graham >>>>> Sent: Friday, June 03, 2016 2:25 AM >>>>> To: Jayathirth D V; Philip Race >>>>> Cc: 2d-dev at openjdk.java.net >>>>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>>>> are missing hashCode() or equals() or both methods >>>>> >>>>> I just noticed a hashCode/equals violation that we created a few revisions ago. We compute the hash of the validBits in ICM, but we only compare validBits up to the number of colors in the colormap. One could construct two ICMs that have different validBits that are identical in the first N bits (N = number of colors), but have different bits beyond that, and those 2 ICMs would evaluate as equals(), but their hashcodes would be different. >>>>> >>>>> Possible solutions: >>>>> >>>>> - Truncate validBits when it is accepted in the constructor >>>>> (validBits.and(...)) >>>>> - Manually compute the hash of the first N bits of validBits >>>>> - Not use validBits in the hash code since it is allowed to omit >>>>> significant data from the hash >>>>> >>>>> (Note that everything in hashcode must participate in equals(), but >>>>> not vice versa) >>>>> >>>>> The same is true of nBits in ColorModel. (nBits can be copied and >>>>> truncated with Arrays.copyOf) >>>>> >>>>> The same is *not* true of maskBits in PCM since the constructor creates an array of the precise length it needs... >>>>> >>>>> ...jim >>>>> >>>>> On 6/2/16 7:07 AM, Jayathirth D V wrote: >>>>>> Hi Phil, >>>>>> >>>>>> I have updated the code with all the changes I mentioned previously. I am caching hashCode when first time hashCode() is called. >>>>>> Please find the updated webrev for review: >>>>>> http://cr.openjdk.java.net/~jdv/7107905/webrev.09/ >>>>>> >>>>>> Thanks, >>>>>> Jay >>>>>> >>>>>> -----Original Message----- >>>>>> From: Philip Race >>>>>> Sent: Wednesday, June 01, 2016 10:06 PM >>>>>> To: Jayathirth D V >>>>>> Cc: Jim Graham; 2d-dev at openjdk.java.net >>>>>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>>>>> are missing hashCode() or equals() or both methods >>>>>> >>>>>> Please post the updated webrev. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 6/1/16, 12:02 AM, Jayathirth D V wrote: >>>>>>> Hi Phil& Jim, >>>>>>> >>>>>>> Collating all the changes needed: >>>>>>> 1) I have removed both equals()& hashCode() in CCM but forgot to add the file while creating webrev. I will include changes in CCM in updated webrev. >>>>>>> 2) Caching of hashCode value in IndexColorModel& PackedColorModel : >>>>>>> We can cache hashCode value when constructor is called or when hashCode() is called for first time. What approach we have to follow? >>>>>>> 3) Comment section of equals() method, I will update it to : >>>>>>> 1449 * the target object must be the same class (and not a subclass) as this >>>>>>> 4) I will use .equals() to compare colorSpace values in CM.equals() so it will be like we are not intending ColorSpace class to never override equals() method. >>>>>>> >>>>>>> Please let me know your inputs. >>>>>>> >>>>>>> Thanks, >>>>>>> Jay >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Jim Graham >>>>>>> Sent: Wednesday, June 01, 2016 4:14 AM >>>>>>> To: Phil Race >>>>>>> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >>>>>>> Subject: Re: Review Request for JDK-7107905: ColorModel >>>>>>> subclasses are missing hashCode() or equals() or both methods >>>>>>> >>>>>>> I think we should use .equals() here, otherwise it looks like a recommendation that the intent is for those classes to never implement it... >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 05/31/2016 03:31 PM, Phil Race wrote: >>>>>>>> I don't know of any design intent, so yes, I meant more as a >>>>>>>> practical matter. >>>>>>>> Unless they subclass then using equals() which I thought >>>>>>>> unlikely it makes no difference here. >>>>>>>> But it would be proof against that to use equals, unlikely to >>>>>>>> matter as it might be .. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 05/31/2016 03:19 PM, Jim Graham wrote: >>>>>>>>> On 05/31/2016 02:50 PM, Phil Race wrote: >>>>>>>>>> On 05/31/2016 12:20 PM, Jim Graham wrote: >>>>>>>>>>> Hi Jay, >>>>>>>>>>> >>>>>>>>>>> You were going to remove hashCode/equals from CCM, but >>>>>>>>>>> instead you simply removed it from the patch. You still need >>>>>>>>>>> to edit it to remove the existing methods. >>>>>>>>>> Oh yeah ! CCM is gone from the latest webrev. I expect that >>>>>>>>>> was not intentional. >>>>>>>>>> >>>>>>>>>>> Also, I'm not sure == is a good way to compare ColorSpace >>>>>>>>>>> instances >>>>>>>>>>> - Phil? >>>>>>>>>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or >>>>>>>>>> hashCode and all the predefined ones are constructed as >>>>>>>>>> singletons so it seems unlikely to cause problems >>>>>>>>> Should it use .equals() on principle, though? Otherwise we are >>>>>>>>> baking in the assumption that it doesn't implement equals() >>>>>>>>> into our implementation of the CM.equals() method. Might it >>>>>>>>> some day implement equals (perhaps it isn't a practical issue >>>>>>>>> today, but it might be in the future when we forget that it was >>>>>>>>> omitted in this usage we create today). >>>>>>>>> >>>>>>>>> I guess what I'm asking is if it is a design feature that >>>>>>>>> different objects are considered non-equal (such as an object >>>>>>>>> that, for instance, has only predetermined instances that are >>>>>>>>> shared by reference and reused). I think color spaces are sort >>>>>>>>> of in-between in that we define a few constants that simply get >>>>>>>>> used by reference in 99% of cases, but that isn't a design >>>>>>>>> feature, more like a practical issue... >>>>>>>>> >>>>>>>>> ...jim From dmitry.batrak at jetbrains.com Mon Jan 30 08:53:41 2017 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Mon, 30 Jan 2017 11:53:41 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8170950: Text is displayed in bold when fonts are installed into symlinked folder Message-ID: Hello, I'd like to propose a fix for JDK-8170950. bug: https://bugs.openjdk.java.net/browse/JDK-8170950 webrev: http://cr.openjdk.java.net/~dmarkov/8170950/webrev.00/ I have only a Contributor status, so I'll require a sponsor. The issue is a special case of JDK-8012351 (fixed previously) - when font files are located in symlinked folders. Physical components of logical fonts are registered 'directly', but other fonts are registered with resolving of symbolic links (see registerFontsOnPath invocation in SunFontManager.loadFonts()). So paths comparison in FontFamily.isFromSameSource doesn't always work currently. The proposal is to add symlink resolution to FontFamily.isFromSameSource before path comparison. There are probably other ways to fix the issue - by changing the way fonts are registered, but this one seems to be safer in terms of possible regressions. Best regards, Dmitry Batrak -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.batrak at jetbrains.com Mon Jan 30 09:09:34 2017 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Mon, 30 Jan 2017 12:09:34 +0300 Subject: [OpenJDK 2D-Dev] Obtaining an Author status Message-ID: Hello again, Could you please let me know how can I request an Author status? I have 2 contributions already accepted, and I'd like to continue contributing 2d-related changes to OpenJDK. Having an Author role will make it much simpler, as I won't need anyone's help for creating and updating webrevs on cr.openjdk.java.net. A month ago I've sent a request to Mark Reinhold, jdk9 project lead, as described at http://openjdk.java.net/projects/, but didn't receive any response. Best regards, Dmitry Batrak -------------- next part -------------- An HTML attachment was scrubbed... URL: From neugens at redhat.com Mon Jan 30 09:49:59 2017 From: neugens at redhat.com (Mario Torre) Date: Mon, 30 Jan 2017 10:49:59 +0100 Subject: [OpenJDK 2D-Dev] Obtaining an Author status In-Reply-To: References: Message-ID: Hello Dmitry, Quoting from: http://openjdk.java.net/projects/#project-author """ Becoming an Author Any Contributor may request the Author role by contacting the relevant Project Lead. References to at least two sponsored contributions to the Project are required. [...] Project Leads are encouraged to grant the Author role only to Contributors who appear likely to continue to contribute for some time so that they will eventually be nominated to the Committer role. """ To request the Author status, you need to send an email to the project lead with links to your contributions and your email and name details, afaik this is "self service", i.e. you don't need somebody presenting you to become an author. Since you said you already sent the email to the jdk9 project lead there's not much else to do at this stage, it's simply a very busy period so I'm sure the project lead will get back to you shortly. Cheers, Mario On Mon, Jan 30, 2017 at 10:09 AM, Dmitry Batrak wrote: > Hello again, > > Could you please let me know how can I request an Author status? I have 2 > contributions already accepted, and I'd like to continue contributing > 2d-related changes to OpenJDK. Having an Author role will make it much > simpler, as I won't need anyone's help for creating and updating webrevs on > cr.openjdk.java.net. > > A month ago I've sent a request to Mark Reinhold, jdk9 project lead, as > described at http://openjdk.java.net/projects/, but didn't receive any > response. > > Best regards, > Dmitry Batrak From jayathirth.d.v at oracle.com Mon Jan 30 10:22:07 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 30 Jan 2017 02:22:07 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <24ca2994-aa27-4a70-8cf9-0bda35664f3f@default> <574809B2.5040901@oracle.com> <9f641938-f979-4021-9e94-bde47e1d3c67@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> <57744D0D.9080809@oracle.com> <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> <3aefa53e-dd6f-46ba-9345-4f78e76c23d6@default> Message-ID: <541429c8-583d-4824-b0b3-1ca10322a82d@default> Hi Phil, Thanks for your review, I have updated the webrev to include your suggestions : http://cr.openjdk.java.net/~jdv/7107905/webrev.15/ I just noticed that some JCK test are failing because of this change : 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. test cases: 4; passed: 3; failed: 1; first test case failure: ColorModel2001 This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we have in ColorModel class as "nBits = Arrays.copyOf(bits, numComponents);" . "numComponents" will be 3 if hasAlpha is false. 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test cases: 3; passed: 2; failed: 1; first test case failure: ColorModel0004 Here they check for equality between 2 ColorModel objects having same values, but it fails because now we are using identity-as-equals check in ColorModel. 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test cases: 2; passed: 1; failed: 1; first test case failure: ColorModel2006 Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we don't have hashCode check in ColorModel and it will be different between 2 Objects. 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttestCase1: Failed. test cases: 2; passed: 1; failed: 1; first test case failure: testCase1 Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() with index 3 which throws ArrayIndexOutOfBoundsException. Please provide your inputs. Thanks, Jay -----Original Message----- From: Phil Race Sent: Friday, January 27, 2017 10:12 PM To: Jayathirth D V; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods Hi Jay, Joe had suggested >ColorModel is redefined to use identity-is-equality equals semantics, the default behavior from object. > This avoids the need to define a hashcode method in the base class. However you have restored the problem that started this. ColorModel now over-rides equals but not hashCode and it doesn't matter that it just delegates. Code that checks for this pattern can't tell that. I think Joe must have meant to *remove* the ColorModel.equals() method entirely. Other than that it looks fine to me. -phil. On 01/19/2017 02:17 AM, Jayathirth D V wrote: > Hello All, > > After getting feedback from Joe in CCC I have made changes to the code to reflect Joe's suggestions. > > For ColorModel class I have just added identity-is-equality equals(). > For its subclasses like IndexColorModel, PackedColorModel & ComponentColorModel, I have added instanceOf checks and checking all fields for equality. Since we are not checking any fields in ColorModel, in subclasses there will be redundant checks. > DirectColorModel has no unique properties to check so it will be using PackedColorModel equals() and hashCode(). > > Please review the updated code at your convenience: > http://cr.openjdk.java.net/~jdv/7107905/webrev.14/ > > Thanks, > Jay > > -----Original Message----- > From: Jim Graham > Sent: Friday, July 22, 2016 3:15 AM > To: Jayathirth D V; Philip Race > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: > ColorModel subclasses are missing hashCode() or equals() or both > methods > > Looks good to me... > > ...jim > > On 07/20/2016 09:53 AM, Jayathirth D V wrote: >> Hi Jim, >> >> Thanks for your input. >> I have updated specification of ColorModel and its subclasses. >> Please find new webrev for review: >> http://cr.openjdk.java.net/~jdv/7107905/webrev.13/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Jim Graham >> Sent: Tuesday, July 12, 2016 7:41 PM >> To: Jayathirth D V; Philip Race >> Cc: 2d-dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >> ColorModel subclasses are missing hashCode() or equals() or both >> methods >> >> Hi Jay, >> >> When I write javadoc suggestions I sometimes use the short-hand "{some text}" to indicate that it should be formatted using javadoc protocols, typically that expands to "{@code some text}", but sometimes a link may be appropriate. It looks like you copied and pasted a number of places where I wrote "{foo}" in email and just left the bare braces there, please adjust those (most of them should probably just have "@code" inserted. >> >> In ColorModel.equals(), I'd replace the entire "following properties" sentence with: >> >> * Subclasses may check additional properties, but this method >> * will check the following basic properties for equivalence to >> * determine if the target object equals this object: >> >> The text for IndexColorModel is also a little odd. I'd change it to something like: >> >> * The target object and this object will be equal iff >> * {@link ColorModel#equals()} returns true and the following >> * properties are also the same: >> >> For Packed: >> >> * The target object and this object will be equal iff >> * {@link ColorModel#equals()} returns true and the masks >> * of the color and alpha samples are the same. >> >> In terms of Joe's request, I'd add the following text to ColorModel.equals() right after we talk about all of the properties that it checks: >> >> *

>> * Subclasses should override this method if they have any additional >> * properties to compare and should use the following implementation. >> * Note that the base {@code ColorModel} class already ensures that >> * the target object is the same class as this object so the cast to >> * the subclass type can be assumed if {@code super.equals(obj)} >> returns >> * true. >> * 

>> *     public boolean equals(Object obj) {
>> *         if (!super.equals(obj)) {
>> *             return false;
>> *         }
>> *         MyCMClass cm = (MyCMClass) obj;
>> *         // test additional properties on "cm" and "this"
>> *     }
>> *
>> >> >> On 7/1/16 3:31 AM, Jayathirth D V wrote: >>> Hi Jim, >>> >>> Thanks for your inputs. >>> I have discussed with Phil also regarding the same issue offline. >>> I have collated all the changes mentioned by you and Phil in the latest webrev: >>> http://cr.openjdk.java.net/~jdv/7107905/webrev.12/ >>> >>> But I was not able to understand your statement - "Arguably, we could omit the class comparison text from the subclasses as well by using a reference like that, but I think that the class equivalence test is enough out of the ordinary that it does bear reiterating it in every subclass as you already do now even though we only reference the specific other properties tested by a reference.", please clarify. >>> >>> Also I am not able find a way to describe Joe's concern of "The ColorModel equals and hashCode methods should spell out the protocol subclasses need to follow to obey the respective contracts of methods.", I have discussed with Phil also regarding the same offline. Any inputs on this also would be helpful. >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Jim Graham >>> Sent: Thursday, June 30, 2016 4:05 AM >>> To: Jayathirth D V; Philip Race; 2d-dev at openjdk.java.net >>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >>> ColorModel subclasses are missing hashCode() or equals() or both >>> methods >>> >>> Hi Jay, >>> >>> We need to reference the properties from the base class in the subclasses. We don't need to list them every time, but we could introduce the "additional properties" using something like: >>> >>> "... we check all of the properties checked by the {equals} method of {ColorModel}, and the following additional properties:" >>> >>> Arguably, we could omit the class comparison text from the subclasses as well by using a reference like that, but I think that the class equivalence test is enough out of the ordinary that it does bear reiterating it in every subclass as you already do now even though we only reference the specific other properties tested by a reference. >>> >>> A few grammar fixes: >>> >>> In all of the classes, insert a space before any parentheses in >>> comment text as in "the same class (and not a subclass)". (That >>> wouldn't apply if the text in the comment is referring to code - >>> then space it as you would actual code.) >>> >>> In CM, insert the word "the" as in "also check the following ..." >>> >>> In ICM I would refer to the "Valid bits of" instead as "The list of valid pixel indices in". >>> >>> In PCM I would change "check maskArray of ..." to "check the masks of the ..." and pluralize the word "samples". >>> >>> ...jim >>> >>> On 06/29/2016 04:13 AM, Jayathirth D V wrote: >>>> Hi, >>>> >>>> Since Joe mentioned to add information related to what fields we are using to calculate equals() method in ColorModel and its subclasses I have updated the spec for the same. >>>> >>>> Please find updated webrev for review: >>>> http://cr.openjdk.java.net/~jdv/7107905/webrev.11/ >>>> >>>> Thanks, >>>> Jay >>>> >>>> -----Original Message----- >>>> From: Jim Graham >>>> Sent: Saturday, June 04, 2016 4:52 AM >>>> To: Jayathirth D V; Philip Race >>>> Cc: 2d-dev at openjdk.java.net >>>> Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: >>>> ColorModel subclasses are missing hashCode() or equals() or both >>>> methods >>>> >>>> That looks good to me. Has the CCC cleared yet? >>>> >>>> ...jim >>>> >>>> On 6/3/16 2:49 AM, Jayathirth D V wrote: >>>>> Hi Jim, >>>>> >>>>> Oh that's an important change. >>>>> Thanks for your review. >>>>> >>>>> I have updated ColorModel constructor to copy nBIts only of numOfComponents length and I have removed validBits check in hashCode() of ICM. >>>>> Please find updated webrev for review: >>>>> http://cr.openjdk.java.net/~jdv/7107905/webrev.10/ >>>>> >>>>> Thanks, >>>>> Jay >>>>> >>>>> -----Original Message----- >>>>> From: Jim Graham >>>>> Sent: Friday, June 03, 2016 2:25 AM >>>>> To: Jayathirth D V; Philip Race >>>>> Cc: 2d-dev at openjdk.java.net >>>>> Subject: Re: Review Request for JDK-7107905: ColorModel subclasses >>>>> are missing hashCode() or equals() or both methods >>>>> >>>>> I just noticed a hashCode/equals violation that we created a few revisions ago. We compute the hash of the validBits in ICM, but we only compare validBits up to the number of colors in the colormap. One could construct two ICMs that have different validBits that are identical in the first N bits (N = number of colors), but have different bits beyond that, and those 2 ICMs would evaluate as equals(), but their hashcodes would be different. >>>>> >>>>> Possible solutions: >>>>> >>>>> - Truncate validBits when it is accepted in the constructor >>>>> (validBits.and(...)) >>>>> - Manually compute the hash of the first N bits of validBits >>>>> - Not use validBits in the hash code since it is allowed to omit >>>>> significant data from the hash >>>>> >>>>> (Note that everything in hashcode must participate in equals(), >>>>> but not vice versa) >>>>> >>>>> The same is true of nBits in ColorModel. (nBits can be copied and >>>>> truncated with Arrays.copyOf) >>>>> >>>>> The same is *not* true of maskBits in PCM since the constructor creates an array of the precise length it needs... >>>>> >>>>> ...jim >>>>> >>>>> On 6/2/16 7:07 AM, Jayathirth D V wrote: >>>>>> Hi Phil, >>>>>> >>>>>> I have updated the code with all the changes I mentioned previously. I am caching hashCode when first time hashCode() is called. >>>>>> Please find the updated webrev for review: >>>>>> http://cr.openjdk.java.net/~jdv/7107905/webrev.09/ >>>>>> >>>>>> Thanks, >>>>>> Jay >>>>>> >>>>>> -----Original Message----- >>>>>> From: Philip Race >>>>>> Sent: Wednesday, June 01, 2016 10:06 PM >>>>>> To: Jayathirth D V >>>>>> Cc: Jim Graham; 2d-dev at openjdk.java.net >>>>>> Subject: Re: Review Request for JDK-7107905: ColorModel >>>>>> subclasses are missing hashCode() or equals() or both methods >>>>>> >>>>>> Please post the updated webrev. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 6/1/16, 12:02 AM, Jayathirth D V wrote: >>>>>>> Hi Phil& Jim, >>>>>>> >>>>>>> Collating all the changes needed: >>>>>>> 1) I have removed both equals()& hashCode() in CCM but forgot to add the file while creating webrev. I will include changes in CCM in updated webrev. >>>>>>> 2) Caching of hashCode value in IndexColorModel& PackedColorModel : >>>>>>> We can cache hashCode value when constructor is called or when hashCode() is called for first time. What approach we have to follow? >>>>>>> 3) Comment section of equals() method, I will update it to : >>>>>>> 1449 * the target object must be the same class (and not a subclass) as this >>>>>>> 4) I will use .equals() to compare colorSpace values in CM.equals() so it will be like we are not intending ColorSpace class to never override equals() method. >>>>>>> >>>>>>> Please let me know your inputs. >>>>>>> >>>>>>> Thanks, >>>>>>> Jay >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Jim Graham >>>>>>> Sent: Wednesday, June 01, 2016 4:14 AM >>>>>>> To: Phil Race >>>>>>> Cc: Jayathirth D V; 2d-dev at openjdk.java.net >>>>>>> Subject: Re: Review Request for JDK-7107905: ColorModel >>>>>>> subclasses are missing hashCode() or equals() or both methods >>>>>>> >>>>>>> I think we should use .equals() here, otherwise it looks like a recommendation that the intent is for those classes to never implement it... >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 05/31/2016 03:31 PM, Phil Race wrote: >>>>>>>> I don't know of any design intent, so yes, I meant more as a >>>>>>>> practical matter. >>>>>>>> Unless they subclass then using equals() which I thought >>>>>>>> unlikely it makes no difference here. >>>>>>>> But it would be proof against that to use equals, unlikely to >>>>>>>> matter as it might be .. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 05/31/2016 03:19 PM, Jim Graham wrote: >>>>>>>>> On 05/31/2016 02:50 PM, Phil Race wrote: >>>>>>>>>> On 05/31/2016 12:20 PM, Jim Graham wrote: >>>>>>>>>>> Hi Jay, >>>>>>>>>>> >>>>>>>>>>> You were going to remove hashCode/equals from CCM, but >>>>>>>>>>> instead you simply removed it from the patch. You still >>>>>>>>>>> need to edit it to remove the existing methods. >>>>>>>>>> Oh yeah ! CCM is gone from the latest webrev. I expect that >>>>>>>>>> was not intentional. >>>>>>>>>> >>>>>>>>>>> Also, I'm not sure == is a good way to compare ColorSpace >>>>>>>>>>> instances >>>>>>>>>>> - Phil? >>>>>>>>>> Neither ColorSpace nor ICC_ColorSpace over-ride equals or >>>>>>>>>> hashCode and all the predefined ones are constructed as >>>>>>>>>> singletons so it seems unlikely to cause problems >>>>>>>>> Should it use .equals() on principle, though? Otherwise we >>>>>>>>> are baking in the assumption that it doesn't implement >>>>>>>>> equals() into our implementation of the CM.equals() method. >>>>>>>>> Might it some day implement equals (perhaps it isn't a >>>>>>>>> practical issue today, but it might be in the future when we >>>>>>>>> forget that it was omitted in this usage we create today). >>>>>>>>> >>>>>>>>> I guess what I'm asking is if it is a design feature that >>>>>>>>> different objects are considered non-equal (such as an object >>>>>>>>> that, for instance, has only predetermined instances that are >>>>>>>>> shared by reference and reused). I think color spaces are >>>>>>>>> sort of in-between in that we define a few constants that >>>>>>>>> simply get used by reference in 99% of cases, but that isn't a >>>>>>>>> design feature, more like a practical issue... >>>>>>>>> >>>>>>>>> ...jim From jayathirth.d.v at oracle.com Mon Jan 30 10:52:59 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 30 Jan 2017 02:52:59 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP In-Reply-To: <5887FCE4.4080200@oracle.com> References: <3bb30333-41ef-4ad3-99c1-71388097e5dc@default> <58829788.40509@oracle.com> <94A4ABDA-52F1-4A0E-A5EB-465187442A87@oracle.com> <220D4634-7558-4D09-B98F-8984759CCF1F@oracle.com> <8135383b-5ee6-4dc1-b748-077c010f166b@default> <5887FCE4.4080200@oracle.com> Message-ID: <200e0374-47a1-435c-b4fe-9bea3f586db9@default> Hi Prahalad, Changes are fine. Thanks, Jay -----Original Message----- From: Philip Race Sent: Wednesday, January 25, 2017 6:48 AM To: Prahalad Kumar Narayanan Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) with RLE4 BMP OK .. +1 -phil. On 1/24/17, 12:57 AM, Prahalad Kumar Narayanan wrote: > Hello Phil > > I agree with you in your observation. We cannot include the image in the test case. > > This morning, I created many RLE4 bitmap images using Gimp. But none of the created images contained Delta sequence /or corrupt image data to cause ArrayIndexOutOfBounds Exception. Henceforth, I 've removed the test case from the proposed fix. I 've also substantiated the reasons in JBS for not including a test case. > > The new webrev without test-case is available under > Link: http://cr.openjdk.java.net/~pnarayanan/8167278/webrev.03/ > > Kindly review at your convenience and share the feedback. > > Thank you for your time > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Phil Race > Sent: Tuesday, January 24, 2017 2:06 AM > To: Prahalad Kumar Narayanan; Brian Burkhalter > Cc: 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: > ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) > with RLE4 BMP > > I just noticed something. The bug report says :- > > > However, I have a public web application that allows users to upload images, > > and I was surprised to find a failure caused by an unexpected > > ArrayIndexOutOfBoundsException when a user uploaded an apparently-valid RLE4 BMP file. > > The attached code contains this BMP file, as a byte array. > > This means the submitter of this bug report almost certainly does not own this image ! > So we cannot include it in the test to be checked in no matter how encoded. > > Thus you will need to create your own RLE4 encoded BMP. > If you can't do that then we won't be able to check in a test. > > -phil. > > On 01/23/2017 06:24 AM, Prahalad Kumar Narayanan wrote: >> Hello Phil& Brian >> >> Thank you for your time in review and feedback. >> >> . Testing with bmptestsuite >> . The test suite came handy to test the changes and confirm our approach. >> . The test suite has a collection of RLE4 compressed images that are- valid, questionable and corrupt. >> . The collection includes image with Delta sequence as well. >> >> . Handling of Delta sequence (0x00 0x02 xOffset yOffset) >> . The decodeRLE4(...) function deploys line-by-line decoding of compressed bitmap image. >> . Until decoding of one row (or line) of pixels is complete, the values are stored in intermediate scanline buffer : val. >> . Upon completion of decoding one row of pixels (ie., with EoL, EoF sequence ), contents of val are copied to destination image's buffer. >> >> . Declaration of val buffer is given as >> . Line 1619: byte[] val = new byte[width]; >> >> . As we see, the intermediate scanline array ' val ' is of size : width ( Not- height x width ) >> . Thus the offset addition to ' l ', in delta sequence will cause index out of bounds if accumulated offset goes beyond size of ' val ' buffer. >> . Hence the new expression at Line 1691 that limits the offset within the capacity of the buffer- val. >> . Line 1690: l += xoff + yoff*width; >> . Line 1691: l %= width; >> >> . If the yOffset shifts the decoding to another line, we should ensure to copy the decoded row to destination bitmap. >> . Failing to do so, will cause the current row to be missed on the destination image. >> . This is achieved with the new set of lines. >> . Line 1677: if (yoff != 0) { >> Line 1678: // Copy the decoded scanline to destination >> Line 1679: if (copyRLE4ScanlineToDst(lineNo, val, bdata)) { >> >> . When tested with bmptestsuite's rle4 images, Delta sequence >> handling required two additional changes (mentioned in 3.a and 3.b) >> >> 3. Changes from previous webrev >> 3.a. Proper update to the variable- lineNo >> . After handling a delta sequence (xOffset yOffsest), the variable- lineNo must be updated correspondingly >> . Reason: lineNo is used to locate exact row on Destination buffer to store intermediate scanline. >> . Line 1684: lineNo += isBottomUp ? -yOffset : yOffset; >> >> 3.b. Clearing of intermediate scanline buffer before starting to decode new row/line. >> . Ensures the previous row's decoded pixels do not appear on current row >> 3.c. Minor change to the condition in the while loop to ensure sufficient data is available before every iteration. >> 3.d. Removal of main/othervm from the jtreg comments in test file. >> >> 4. The build with changes was run through Jreg and JCK tests. No regressions were seen. >> . In addition, the build works well for all input RLE4 >> bitmap images from the test suite >> >> The changes are available for review in the link: >> http://cr.openjdk.java.net/~pnarayanan/8167278/webrev.02/ >> >> Kindly review the changes at your convenience& share your feedback. >> >> Thank you once again >> Have a good day >> >> Prahalad N. >> >> --- Original message --- >> From: Brian Burkhalter >> Sent: Saturday, January 21, 2017 6:05 AM >> To: Philip Race >> Cc: 2d-dev at openjdk.java.net; Prahalad Kumar Narayanan >> Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8167278: >> ArrayIndexOutOfBoundsException when calling ImageIO.read(InputStream) >> with RLE4 BMP >> >> On Jan 20, 2017, at 4:30 PM, Brian Burkhalter wrote: >> >> >> That is worrying me since I don't follow these lines are part of >> that:- >> >> 1684 // Move to the position (xoff, yoff). Since l-is used >> 1685 // to index into the scanline buffer, the calculation >> 1686 // must be limited by the size >> 1687 l += xoff + yoff*width; >> 1688 l %= width; >> 1687 was already there but 1688 and the comment are new and 1688 >> looks wrong to me as it would seem to throw away the y it just added in ... >> >> Indeed, if xoff is in the half-closed interval [0,width), then (xoff + yoff*width) % width == xoff. >> >> This does not however account for the accumulation into "l" which might negate my observation. >> >> Brian From dmitry.markov at oracle.com Mon Jan 30 12:36:20 2017 From: dmitry.markov at oracle.com (dmitry markov) Date: Mon, 30 Jan 2017 15:36:20 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8170950: Text is displayed in bold when fonts are installed into symlinked folder In-Reply-To: References: Message-ID: <588F3344.90008@oracle.com> Hello Dmitry, The fix looks good to me, but I am not a reviewer. I will sponsor the integration of the fix once the review is completed. Thanks, Dmitry On 30/01/2017 11:53, Dmitry Batrak wrote: > Hello, > > I'd like to propose a fix for JDK-8170950. > bug: https://bugs.openjdk.java.net/browse/JDK-8170950 > webrev: http://cr.openjdk.java.net/~dmarkov/8170950/webrev.00/ > > > I have only a Contributor status, so I'll require a sponsor. > > The issue is a special case of JDK-8012351 (fixed previously) - when > font files > are located in symlinked folders. Physical components of logical fonts are > registered 'directly', but other fonts are registered with resolving > of symbolic > links (see registerFontsOnPath invocation in SunFontManager.loadFonts()). > So paths comparison in FontFamily.isFromSameSource doesn't always work > currently. The proposal is to add symlink resolution to > FontFamily.isFromSameSource before path comparison. There are probably > other > ways to fix the issue - by changing the way fonts are registered, but > this one > seems to be safer in terms of possible regressions. > > Best regards, > Dmitry Batrak From james.graham at oracle.com Mon Jan 30 21:40:15 2017 From: james.graham at oracle.com (Jim Graham) Date: Mon, 30 Jan 2017 13:40:15 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <541429c8-583d-4824-b0b3-1ca10322a82d@default> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <57489033.7020901@oracle.com> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> <57744D0D.9080809@oracle.com> <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> <3aefa53e-dd6f-46ba-9345-4f78e76c23d6@default> <541429c8-583d-4824-b0b3-1ca10322a82d@default> Message-ID: <6d6bf61d-43ed-4386-423f-28cd36c57792@oracle.com> Hmmm. Sounds like the test cases were written based on bugs in the implementation. I'm not sure what the best tactic is here for the short term for getting this in, but many of these changes should eventually be considered bugs in the tests. Is it acceptable to break API tests like this at the last minute even if the tests are at fault? Phil? Notes on specific instances below... On 1/30/17 2:22 AM, Jayathirth D V wrote: > Hi Phil, > > 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. test cases: 4; passed: 3; failed: 1; first test case failure: ColorModel2001 > > This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we have in ColorModel class as "nBits = Arrays.copyOf(bits, numComponents);" . "numComponents" will be 3 if hasAlpha is false. This is a bug in the test then, especially if the size of our array matches the return value of getNumComponents. > 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test cases: 3; passed: 2; failed: 1; first test case failure: ColorModel0004 > > Here they check for equality between 2 ColorModel objects having same values, but it fails because now we are using identity-as-equals check in ColorModel. How do they accomplish this when the CM class is abstract? Do they create a relatively empty subclass and instantiate that? The documentation for the equals() method does not document the conditions under which it returns true, it uses a vague concept of "equals this ColorModel". I don't see how they could test anything given that documentation. > 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test cases: 2; passed: 1; failed: 1; first test case failure: ColorModel2006 > > Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we don't have hashCode check in ColorModel and it will be different between 2 Objects. Same as above, there are no promises documented. > 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttestCase1: Failed. test cases: 2; passed: 1; failed: 1; first test case failure: testCase1 > > Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() with index 3 which throws ArrayIndexOutOfBoundsException. Same assessment as #1 above... Again, while these are my recommendations about the correctness of these tests, the question remains whether we want to introduce a change at this point in the release cycle that will essentially invalidate a number of tests that have been working for several releases already. I'll leave that tactic issue to Phil... ...jim From philip.race at oracle.com Mon Jan 30 23:56:46 2017 From: philip.race at oracle.com (Phil Race) Date: Mon, 30 Jan 2017 15:56:46 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <6d6bf61d-43ed-4386-423f-28cd36c57792@oracle.com> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> <57744D0D.9080809@oracle.com> <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> <3aefa53e-dd6f-46ba-9345-4f78e76c23d6@default> <541429c8-583d-4824-b0b3-1ca10322a82d@default> <6d6bf61d-43ed-4386-423f-28cd36c57792@oracle.com> Message-ID: Sounds like we should at least try to get the tests updated so they only test what the spec. says. Although it does indicate that there is at least a chance that application code might also fail due to similar assumptions. Does #1 not fail with the previous iteration of this change too ? -phil. On 01/30/2017 01:40 PM, Jim Graham wrote: > Hmmm. Sounds like the test cases were written based on bugs in the > implementation. I'm not sure what the best tactic is here for the > short term for getting this in, but many of these changes should > eventually be considered bugs in the tests. Is it acceptable to break > API tests like this at the last minute even if the tests are at > fault? Phil? > > Notes on specific instances below... > > On 1/30/17 2:22 AM, Jayathirth D V wrote: >> Hi Phil, >> >> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. >> test cases: 4; passed: 3; failed: 1; first test case failure: >> ColorModel2001 >> >> This test fails because getComponentSize() returned an array with >> length 3 but it expects the length to be 4. In the test case they >> have bits per component array of length 4 like {8, 8, 8, 8}. But >> in the test case wherever they are passing "has Alpha" as "false" we >> omit the alpha component bit. This is because of tighter check >> that we have in ColorModel class as "nBits = Arrays.copyOf(bits, >> numComponents);" . "numComponents" will be 3 if hasAlpha is false. > > This is a bug in the test then, especially if the size of our array > matches the return value of getNumComponents. > >> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test >> cases: 3; passed: 2; failed: 1; first test case failure: ColorModel0004 >> >> Here they check for equality between 2 ColorModel objects having >> same values, but it fails because now we are using identity-as-equals >> check in ColorModel. > > How do they accomplish this when the CM class is abstract? Do they > create a relatively empty subclass and instantiate that? > > The documentation for the equals() method does not document the > conditions under which it returns true, it uses a vague concept of > "equals this ColorModel". I don't see how they could test anything > given that documentation. > >> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test >> cases: 2; passed: 1; failed: 1; first test case failure: ColorModel2006 >> >> Here they check for hashCode equality between 2 ColorModel >> objects having same values, but it fails since we don't have hashCode >> check in ColorModel and it will be different between 2 Objects. > > Same as above, there are no promises documented. > >> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttestCase1: >> Failed. test cases: 2; passed: 1; failed: 1; first test case failure: >> testCase1 >> >> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is >> also happening because of same reason as why the first JCK test is >> failing. We omit alpha bit if hasAlpha is false but JCK test >> tries to call getComponentSize() with index 3 which throws >> ArrayIndexOutOfBoundsException. > > Same assessment as #1 above... > > Again, while these are my recommendations about the correctness of > these tests, the question remains whether we want to introduce a > change at this point in the release cycle that will essentially > invalidate a number of tests that have been working for several > releases already. I'll leave that tactic issue to Phil... > > ...jim > From jayathirth.d.v at oracle.com Tue Jan 31 06:23:08 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 30 Jan 2017 22:23:08 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> <57744D0D.9080809@oracle.com> <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> <3aefa53e-dd6f-46ba-9345-4f78e76c23d6@default> <541429c8-583d-4824-b0b3-1ca10322a82d@default> <6d6bf61d-43ed-4386-423f-28cd36c57792@oracle.com> Message-ID: Hi Phil & Jim, Thanks for your inputs. I have verified with previous iteration of the changes and both #1 and #4 fail from the time we have introduced the change in how we calculate "nBits" in ColorModel. - nBits = bits.clone(); + /* + * We need significant bits value only for the length + * of number of components, so we truncate remaining part. + * It also helps in hashCode calculation since bits[] can contain + * different values after the length of number of components between + * two ColorModels. + */ + nBits = Arrays.copyOf(bits, numComponents); #2 and #3 would fail from the time we have removed equals() and hashCode() methods from ColorModel, to follow identity-as-equals verification. Collectively all of them are failing right now as we have both the changes at http://cr.openjdk.java.net/~jdv/7107905/webrev.15/ . Thanks, Jay -----Original Message----- From: Phil Race Sent: Tuesday, January 31, 2017 5:27 AM To: Jim Graham; Jayathirth D V; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods Sounds like we should at least try to get the tests updated so they only test what the spec. says. Although it does indicate that there is at least a chance that application code might also fail due to similar assumptions. Does #1 not fail with the previous iteration of this change too ? -phil. On 01/30/2017 01:40 PM, Jim Graham wrote: > Hmmm. Sounds like the test cases were written based on bugs in the > implementation. I'm not sure what the best tactic is here for the > short term for getting this in, but many of these changes should > eventually be considered bugs in the tests. Is it acceptable to break > API tests like this at the last minute even if the tests are at fault? > Phil? > > Notes on specific instances below... > > On 1/30/17 2:22 AM, Jayathirth D V wrote: >> Hi Phil, >> >> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. >> test cases: 4; passed: 3; failed: 1; first test case failure: >> ColorModel2001 >> >> This test fails because getComponentSize() returned an array with >> length 3 but it expects the length to be 4. In the test case they >> have bits per component array of length 4 like {8, 8, 8, 8}. But >> in the test case wherever they are passing "has Alpha" as "false" we >> omit the alpha component bit. This is because of tighter check >> that we have in ColorModel class as "nBits = Arrays.copyOf(bits, >> numComponents);" . "numComponents" will be 3 if hasAlpha is false. > > This is a bug in the test then, especially if the size of our array > matches the return value of getNumComponents. > >> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test >> cases: 3; passed: 2; failed: 1; first test case failure: >> ColorModel0004 >> >> Here they check for equality between 2 ColorModel objects having >> same values, but it fails because now we are using identity-as-equals >> check in ColorModel. > > How do they accomplish this when the CM class is abstract? Do they > create a relatively empty subclass and instantiate that? > > The documentation for the equals() method does not document the > conditions under which it returns true, it uses a vague concept of > "equals this ColorModel". I don't see how they could test anything > given that documentation. > >> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test >> cases: 2; passed: 1; failed: 1; first test case failure: >> ColorModel2006 >> >> Here they check for hashCode equality between 2 ColorModel >> objects having same values, but it fails since we don't have hashCode >> check in ColorModel and it will be different between 2 Objects. > > Same as above, there are no promises documented. > >> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttestCase1: >> Failed. test cases: 2; passed: 1; failed: 1; first test case failure: >> testCase1 >> >> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is >> also happening because of same reason as why the first JCK test is >> failing. We omit alpha bit if hasAlpha is false but JCK test >> tries to call getComponentSize() with index 3 which throws >> ArrayIndexOutOfBoundsException. > > Same assessment as #1 above... > > Again, while these are my recommendations about the correctness of > these tests, the question remains whether we want to introduce a > change at this point in the release cycle that will essentially > invalidate a number of tests that have been working for several > releases already. I'll leave that tactic issue to Phil... > > ...jim > From jayathirth.d.v at oracle.com Tue Jan 31 06:37:41 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 30 Jan 2017 22:37:41 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <77d5b327-066b-4d86-a44d-8e681aeb71f8@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> <57744D0D.9080809@oracle.com> <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> <3aefa53e-dd6f-46ba-9345-4f78e76c23d6@default> <541429c8-583d-4824-b0b3-1ca10322a82d@default> <6d6bf61d-43ed-4386-423f-28cd36c57792@oracle.com> Message-ID: <9c622114-85c4-4a4f-b3a4-08a5b989ac02@default> Hi, Regarding Jim's query of #2 JCK test case: How do they accomplish this when the CM class is abstract? Do they create a relatively empty subclass and instantiate that? Yes they have simple subclass(MyColorModel) of ColorModel and they instantiate that with same "bits" and try to compare. MyColorModel cm = new MyColorModel(4); ColorModel x = new MyColorModel(4) if (!cm.equals(x)) { return Status.failed("Should return true on two instances instantiated by the same constructor"); } Thanks, Jay -----Original Message----- From: Jayathirth D V Sent: Tuesday, January 31, 2017 11:53 AM To: Philip Race; Jim Graham; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods Hi Phil & Jim, Thanks for your inputs. I have verified with previous iteration of the changes and both #1 and #4 fail from the time we have introduced the change in how we calculate "nBits" in ColorModel. - nBits = bits.clone(); + /* + * We need significant bits value only for the length + * of number of components, so we truncate remaining part. + * It also helps in hashCode calculation since bits[] can contain + * different values after the length of number of components between + * two ColorModels. + */ + nBits = Arrays.copyOf(bits, numComponents); #2 and #3 would fail from the time we have removed equals() and hashCode() methods from ColorModel, to follow identity-as-equals verification. Collectively all of them are failing right now as we have both the changes at http://cr.openjdk.java.net/~jdv/7107905/webrev.15/ . Thanks, Jay -----Original Message----- From: Phil Race Sent: Tuesday, January 31, 2017 5:27 AM To: Jim Graham; Jayathirth D V; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods Sounds like we should at least try to get the tests updated so they only test what the spec. says. Although it does indicate that there is at least a chance that application code might also fail due to similar assumptions. Does #1 not fail with the previous iteration of this change too ? -phil. On 01/30/2017 01:40 PM, Jim Graham wrote: > Hmmm. Sounds like the test cases were written based on bugs in the > implementation. I'm not sure what the best tactic is here for the > short term for getting this in, but many of these changes should > eventually be considered bugs in the tests. Is it acceptable to break > API tests like this at the last minute even if the tests are at fault? > Phil? > > Notes on specific instances below... > > On 1/30/17 2:22 AM, Jayathirth D V wrote: >> Hi Phil, >> >> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. >> test cases: 4; passed: 3; failed: 1; first test case failure: >> ColorModel2001 >> >> This test fails because getComponentSize() returned an array with >> length 3 but it expects the length to be 4. In the test case they >> have bits per component array of length 4 like {8, 8, 8, 8}. But >> in the test case wherever they are passing "has Alpha" as "false" we >> omit the alpha component bit. This is because of tighter check >> that we have in ColorModel class as "nBits = Arrays.copyOf(bits, >> numComponents);" . "numComponents" will be 3 if hasAlpha is false. > > This is a bug in the test then, especially if the size of our array > matches the return value of getNumComponents. > >> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test >> cases: 3; passed: 2; failed: 1; first test case failure: >> ColorModel0004 >> >> Here they check for equality between 2 ColorModel objects having >> same values, but it fails because now we are using identity-as-equals >> check in ColorModel. > > How do they accomplish this when the CM class is abstract? Do they > create a relatively empty subclass and instantiate that? > > The documentation for the equals() method does not document the > conditions under which it returns true, it uses a vague concept of > "equals this ColorModel". I don't see how they could test anything > given that documentation. > >> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test >> cases: 2; passed: 1; failed: 1; first test case failure: >> ColorModel2006 >> >> Here they check for hashCode equality between 2 ColorModel >> objects having same values, but it fails since we don't have hashCode >> check in ColorModel and it will be different between 2 Objects. > > Same as above, there are no promises documented. > >> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttestCase1: >> Failed. test cases: 2; passed: 1; failed: 1; first test case failure: >> testCase1 >> >> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is >> also happening because of same reason as why the first JCK test is >> failing. We omit alpha bit if hasAlpha is false but JCK test >> tries to call getComponentSize() with index 3 which throws >> ArrayIndexOutOfBoundsException. > > Same assessment as #1 above... > > Again, while these are my recommendations about the correctness of > these tests, the question remains whether we want to introduce a > change at this point in the release cycle that will essentially > invalidate a number of tests that have been working for several > releases already. I'll leave that tactic issue to Phil... > > ...jim > From philip.race at oracle.com Tue Jan 31 19:10:08 2017 From: philip.race at oracle.com (Philip Race) Date: Tue, 31 Jan 2017 11:10:08 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8170578: The Pages Range From in print dialog is disabled In-Reply-To: <65c06ba2-0e8e-3219-76bd-220fe15bb973@oracle.com> References: <39f21e6d-78fb-6486-0260-620f42a63ccb@oracle.com> <90c7f438-27ee-3334-d91a-5b1aff84e025@oracle.com> <224e283e-47c5-f254-bafd-de5beccf1584@oracle.com> <68d7b1d5-40f9-0841-0d6c-328861391f33@oracle.com> <5876EB50.2010305@oracle.com> <65c06ba2-0e8e-3219-76bd-220fe15bb973@oracle.com> Message-ID: <5890E110.70502@oracle.com> I spent some significant amount of time trying to make sure I know the IPP protocol that is underpinning this. Prasanta provided me with some additional logging from which it seems that there are 3 repeated attributes. : IPPPrintService>> readIPPResponse pwg-raster-document-resolution-supported IPPPrintService>> readIPPResponse pwg-raster-document-sheet-back IPPPrintService>> readIPPResponse pwg-raster-document-type-supported Furthermore I have determined that 16.10 ships with CUPS 2.2 - released only a few weeks before 16.10 Whereas 16.04 has 2.1.3. So what we have here is a major CUPS upgrade and I am still not 100% sure if these duplicates are a CUPS bug - but I think it probable. These duplicated attributes are not important to our implementation, so all we need to do is make sure they don't break us. I don't see a reason to care if we keep the first or replace it with the second. Any new attributes we've previously ignored will still be ignored. What Prasanta has implemented will fix our bug so I am approving. However our implementation looks odd to me - I do not understand why there was an expectation a new HashMap ever needed to be created. It only makes sense if duplicate attributes are normal. But then there is no rhyme nor reason to then simply picking the first HashMap and ignoring the rest. If anything I'd expect that you may want to tie a HashMap to each group tag. In which case the first one would be operational attributes, not printer attributes. And it isn't done like that anyway. It just creates a new one "on demand" when it sees the key is already used. This happens in the middle of processing a particular group. So it still makes no sense. Accordingly I think we need a follow-on bug to examine, explain and if necessary update this in 10. -phil. On 1/18/17, 3:11 AM, Prasanta Sadhukhan wrote: > > Ok. Updated webrev just in case we are not reading the protocol wrongly. > > http://cr.openjdk.java.net/~psadhukhan/8170578/webrev.02/ > > Regards > Prasanta > On 1/12/2017 8:04 AM, Philip Race wrote: >> I am looking at this and the hold up is I can't remember the protocol >> readIPPResponse() is >> trying to follow. Without that understanding it is hard to say much >> .. so I need to go read >> up and remember .. >> >> Two comments : There is an extra space in >> if (responseMap.length> 1) { >> The test update is bogus in referring to this bug. The change is >> nothing to do with the bug. >> And I actually prefer printer tests to throw nasty exceptions when >> there are no printers >> and they need one ... else SQE just don't configure printers on test >> systems and the tests all wrongly pass. >> Would you run Linux UI tests on a blade with no X-server running ? >> >> -phil. >> >> On 1/10/17, 1:14 AM, Prasanta Sadhukhan wrote: >>> >>> >>> >>> On 1/10/2017 2:43 PM, Prasanta Sadhukhan wrote: >>>> Actually, in ubuntu16.10 attribute map did not have >>>> "page-ranges-supported" attribute because 2 attribute hashmap is >>>> created in IPPPrintService#readIPPResponse() and most of the >>>> supported attributes are part of the 2nd hashmap (responseMap[1]) >>>> whereas only the 1st hashmap is utilised through responseMap[0] >>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/8be0bb1aa238/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1760] >>>> >>>> As to why 2 hashmaps are created in ubuntu16.10, it is because >>>> readIPPResponse() checks if key is already present in existing map, >>>> then create a new hashmap through this code >>>> >>>> and in ubuntu16.10, some attributes (like >>>> pwg-raster-document-type-supported which is not there in ubuntu >>>> 14.04] are duplicated. >>>> >>>> Proposed fix is to check if there are more than 1 hashmaps, if it >>>> is, get the entries from those maps, remove duplicate entries and >>>> append to existing hashmap to get a consolidated map having all the >>>> IPP attributes. >>>> >>> Missing webrev link: >>> http://cr.openjdk.java.net/~psadhukhan/8170578/webrev.01/ >>>> Regards >>>> Prasanta >>>> On 12/21/2016 11:28 PM, Phil Race wrote: >>>>> So now I am very suspicious. >>>>> First (previous fix I reviewed) Job Sheets weren't supported on >>>>> 16.10, now its PageRanges. >>>>> >>>>> I think this merits investigation of what is going on before we >>>>> commit this fix. >>>>> Why are attributes that have always been supported by CUPS >>>>> suddenly unavailable ? >>>>> >>>>> And for the cases we image the pages ourselves, we can implement >>>>> PageRanges >>>>> internally, so for a normal PrinterJob it always can be supported >>>>> .. regardless of >>>>> what the printer says. >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 12/14/2016 09:50 PM, Prasanta Sadhukhan wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> Please review a testbug fix for jdk9 for an issue where it it >>>>>> seen that PageRanges option is disabled in printer dialog in >>>>>> ubuntu16.10. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170578 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8170578/webrev.00/ >>>>>> >>>>>> Issue was, in ubuntu16.10 the attribute map [obtained here >>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1767] >>>>>> does not have >>>>>> "pageranges-supported" attribute returned by CUPS >>>>>> so this category is not added to supported categories >>>>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1030] >>>>>> so isAttributeCategorySupported() called by ServiceDialog returns >>>>>> false >>>>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1141] >>>>>> resulting in PageRanges option getting disabled. >>>>>> >>>>>> Fix is to check if PageRanges category is supported in underlying >>>>>> platform, only then proceed with the test. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Tue Jan 31 22:13:33 2017 From: james.graham at oracle.com (Jim Graham) Date: Tue, 31 Jan 2017 14:13:33 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: <9c622114-85c4-4a4f-b3a4-08a5b989ac02@default> References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> <57744D0D.9080809@oracle.com> <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> <3aefa53e-dd6f-46ba-9345-4f78e76c23d6@default> <541429c8-583d-4824-b0b3-1ca10322a82d@default> <6d6bf61d-43ed-4386-423f-28cd36c57792@oracle.com> <9c622114-85c4-4a4f-b3a4-08a5b989ac02@default> Message-ID: <8192ad71-3583-ba75-e6bd-1897530f3888@oracle.com> I don't think there is a spec anywhere that 2 objects created by the same constructor must evaluate as equals(). In particular, 2 instances of Object created with the null constructor do not evaluate as equals(). So, with respect to testing a spec, they are reading a promise into the base class there. On the other hand, it makes sense that similar construction would be equals() for objects intended to be compared and the CM subclasses have always tried to be comparable. But, since CM is abstract you can't really test its constructors directly. With these fixes we should end up having all subclasses compare as equals() for similar construction so we are still making good on the implied promise that they are testing here for all constructable objects. Should we consider that CM might promise proper equals() tests for subclasses? For one, we can't really fully promise that since subclasses may differ for reasons other than what CM can test, so its implementation of equals() can't be authoritative in general. It is true that we used to provide a conditionally appropriate test for just the parts that CM was responsible for, but we never documented that. In practice that potential promise doesn't matter for our internal classes, it only matters for external classes that aren't being updated here. With regards to Phil's question about whether these changes will affect application code - since you can't instantiate CM directly, and since we deal with these conditions properly in all sub-classes this boils down to whether applications use their own subclass of CM, and I don't have a lot of data for that. Phil? ...jim On 1/30/17 10:37 PM, Jayathirth D V wrote: > Hi, > > Regarding Jim's query of #2 JCK test case: > > How do they accomplish this when the CM class is abstract? Do they create a relatively empty subclass and instantiate that? > Yes they have simple subclass(MyColorModel) of ColorModel and they instantiate that with same "bits" and try to compare. > > MyColorModel cm = new MyColorModel(4); > ColorModel x = new MyColorModel(4) > if (!cm.equals(x)) { > return Status.failed("Should return true on two instances instantiated by the same constructor"); > } > > Thanks, > Jay > > -----Original Message----- > From: Jayathirth D V > Sent: Tuesday, January 31, 2017 11:53 AM > To: Philip Race; Jim Graham; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods > > Hi Phil & Jim, > > Thanks for your inputs. > > I have verified with previous iteration of the changes and both #1 and #4 fail from the time we have introduced the change in how we calculate "nBits" in ColorModel. > > - nBits = bits.clone(); > + /* > + * We need significant bits value only for the length > + * of number of components, so we truncate remaining part. > + * It also helps in hashCode calculation since bits[] can contain > + * different values after the length of number of components between > + * two ColorModels. > + */ > + nBits = Arrays.copyOf(bits, numComponents); > > #2 and #3 would fail from the time we have removed equals() and hashCode() methods from ColorModel, to follow identity-as-equals verification. > Collectively all of them are failing right now as we have both the changes at http://cr.openjdk.java.net/~jdv/7107905/webrev.15/ . > > Thanks, > Jay > > -----Original Message----- > From: Phil Race > Sent: Tuesday, January 31, 2017 5:27 AM > To: Jim Graham; Jayathirth D V; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods > > Sounds like we should at least try to get the tests updated so they only test what the spec. says. > Although it does indicate that there is at least a chance that application code might also fail due to similar assumptions. > Does #1 not fail with the previous iteration of this change too ? > > -phil. > > On 01/30/2017 01:40 PM, Jim Graham wrote: >> Hmmm. Sounds like the test cases were written based on bugs in the >> implementation. I'm not sure what the best tactic is here for the >> short term for getting this in, but many of these changes should >> eventually be considered bugs in the tests. Is it acceptable to break >> API tests like this at the last minute even if the tests are at fault? >> Phil? >> >> Notes on specific instances below... >> >> On 1/30/17 2:22 AM, Jayathirth D V wrote: >>> Hi Phil, >>> >>> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. >>> test cases: 4; passed: 3; failed: 1; first test case failure: >>> ColorModel2001 >>> >>> This test fails because getComponentSize() returned an array with >>> length 3 but it expects the length to be 4. In the test case they >>> have bits per component array of length 4 like {8, 8, 8, 8}. But >>> in the test case wherever they are passing "has Alpha" as "false" we >>> omit the alpha component bit. This is because of tighter check >>> that we have in ColorModel class as "nBits = Arrays.copyOf(bits, >>> numComponents);" . "numComponents" will be 3 if hasAlpha is false. >> >> This is a bug in the test then, especially if the size of our array >> matches the return value of getNumComponents. >> >>> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test >>> cases: 3; passed: 2; failed: 1; first test case failure: >>> ColorModel0004 >>> >>> Here they check for equality between 2 ColorModel objects having >>> same values, but it fails because now we are using identity-as-equals >>> check in ColorModel. >> >> How do they accomplish this when the CM class is abstract? Do they >> create a relatively empty subclass and instantiate that? >> >> The documentation for the equals() method does not document the >> conditions under which it returns true, it uses a vague concept of >> "equals this ColorModel". I don't see how they could test anything >> given that documentation. >> >>> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test >>> cases: 2; passed: 1; failed: 1; first test case failure: >>> ColorModel2006 >>> >>> Here they check for hashCode equality between 2 ColorModel >>> objects having same values, but it fails since we don't have hashCode >>> check in ColorModel and it will be different between 2 Objects. >> >> Same as above, there are no promises documented. >> >>> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttestCase1: >>> Failed. test cases: 2; passed: 1; failed: 1; first test case failure: >>> testCase1 >>> >>> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is >>> also happening because of same reason as why the first JCK test is >>> failing. We omit alpha bit if hasAlpha is false but JCK test >>> tries to call getComponentSize() with index 3 which throws >>> ArrayIndexOutOfBoundsException. >> >> Same assessment as #1 above... >> >> Again, while these are my recommendations about the correctness of >> these tests, the question remains whether we want to introduce a >> change at this point in the release cycle that will essentially >> invalidate a number of tests that have been working for several >> releases already. I'll leave that tactic issue to Phil... >> >> ...jim >> > From james.graham at oracle.com Tue Jan 31 22:34:03 2017 From: james.graham at oracle.com (Jim Graham) Date: Tue, 31 Jan 2017 14:34:03 -0800 Subject: [OpenJDK 2D-Dev] Review Request for JDK-7107905: ColorModel subclasses are missing hashCode() or equals() or both methods In-Reply-To: References: <6f83b633-3910-47fa-b872-e042fe4c24d3@default> <574DE3F9.40709@oracle.com> <574E0717.5060405@oracle.com> <574E0DF9.20508@oracle.com> <574E10B0.4070003@oracle.com> <574E13BD.9060701@oracle.com> <9a87056b-2646-4d5f-bfec-d50bea489381@default> <574F0EFE.2070300@oracle.com> <2e485b6b-3df0-41db-ba40-a96528883e95@default> <20a4c021-6814-9423-2891-c45c1ab94396@oracle.com> <0042f492-5fc4-481c-8b2d-35a242a5af93@default> <6341d4b6-f281-3f58-efc3-32d1ed0ecc42@oracle.com> <57744D0D.9080809@oracle.com> <23f4baba-47fb-41c5-be34-478e23b2d7ea@default> <0acc99be-70d0-6380-0b83-d081e62e1161@oracle.com> <3aefa53e-dd6f-46ba-9345-4f78e76c23d6@default> <541429c8-583d-4824-b0b3-1ca10322a82d@default> <6d6bf61d-43ed-4386-423f-28cd36c57792@oracle.com> Message-ID: <81fdf4d1-3d0e-a780-0e25-743d222ed5fc@oracle.com> For an application to run into this same issue they'd have to expect getCompSizes() to return data for components that don't exist. It's unlikely they would use that data if they really understand the objects. While that would be odd, I guess I can see someone might be constructing all of their CM's from an array of 4 components regardless of the number of actual components and we'd be happily remembering the useless extra components and returning an array of 4 from getCompSizes(). As I said, they shouldn't really be reading and interpreting those extra components for any image processing, but I can imagine that they might do something like create a variant CM by calling the CompSizes() and copying them into a new array to construct a new CM with modifications. They might just robotically always copy 4 values without really checking how many are valid. That's a stretch, and their code is weak. I can conceive of how this might happen, but I really have no idea how likely it is... ...jim On 1/30/17 3:56 PM, Phil Race wrote: > Sounds like we should at least try to get the tests updated so they only test what the spec. says. > Although it does indicate that there is at least a chance that application code might also fail due to similar assumptions. > Does #1 not fail with the previous iteration of this change too ? > > -phil. > > On 01/30/2017 01:40 PM, Jim Graham wrote: >> Hmmm. Sounds like the test cases were written based on bugs in the implementation. I'm not sure what the best tactic >> is here for the short term for getting this in, but many of these changes should eventually be considered bugs in the >> tests. Is it acceptable to break API tests like this at the last minute even if the tests are at fault? Phil? >> >> Notes on specific instances below... >> >> On 1/30/17 2:22 AM, Jayathirth D V wrote: >>> Hi Phil, >>> >>> 1)api/java_awt/Image/ColorModel/index.html#Constructor: Failed. test cases: 4; passed: 3; failed: 1; first test >>> case failure: ColorModel2001 >>> >>> This test fails because getComponentSize() returned an array with length 3 but it expects the length to be 4. In >>> the test case they have bits per component array of length 4 like {8, 8, 8, 8}. But in the test case wherever >>> they are passing "has Alpha" as "false" we omit the alpha component bit. This is because of tighter check that we >>> have in ColorModel class as "nBits = Arrays.copyOf(bits, numComponents);" . "numComponents" will be 3 if hasAlpha is >>> false. >> >> This is a bug in the test then, especially if the size of our array matches the return value of getNumComponents. >> >>> 2)api/java_awt/Image/ColorModel/index.html#Equals: Failed. test cases: 3; passed: 2; failed: 1; first test case >>> failure: ColorModel0004 >>> >>> Here they check for equality between 2 ColorModel objects having same values, but it fails because now we are >>> using identity-as-equals check in ColorModel. >> >> How do they accomplish this when the CM class is abstract? Do they create a relatively empty subclass and instantiate >> that? >> >> The documentation for the equals() method does not document the conditions under which it returns true, it uses a >> vague concept of "equals this ColorModel". I don't see how they could test anything given that documentation. >> >>> 3)api/java_awt/Image/ColorModel/index.html#HashCode: Failed. test cases: 2; passed: 1; failed: 1; first test case >>> failure: ColorModel2006 >>> >>> Here they check for hashCode equality between 2 ColorModel objects having same values, but it fails since we >>> don't have hashCode check in ColorModel and it will be different between 2 Objects. >> >> Same as above, there are no promises documented. >> >>> 4)api/java_awt/Image/ComponentColorModel/index.html#ConstructorTesttestCase1: Failed. test cases: 2; passed: 1; >>> failed: 1; first test case failure: testCase1 >>> >>> Throws "java.lang.ArrayIndexOutOfBoundsException: 3". This is also happening because of same reason as why the >>> first JCK test is failing. We omit alpha bit if hasAlpha is false but JCK test tries to call getComponentSize() >>> with index 3 which throws ArrayIndexOutOfBoundsException. >> >> Same assessment as #1 above... >> >> Again, while these are my recommendations about the correctness of these tests, the question remains whether we want >> to introduce a change at this point in the release cycle that will essentially invalidate a number of tests that have >> been working for several releases already. I'll leave that tactic issue to Phil... >> >> ...jim >> >