From mjw at redhat.com Thu Jun 4 04:34:03 2009 From: mjw at redhat.com (Mark Wielaard) Date: Thu, 04 Jun 2009 13:34:03 +0200 Subject: [OpenJDK 2D-Dev] freetype version check (2.3.0 -> 2.2.1) In-Reply-To: <1241467043.26874.12.camel@hermans.wildebeest.org> References: <1241444279.2359.56.camel@fedora.wildebeest.org> <49FF4337.9000502@sun.com> <1241467043.26874.12.camel@hermans.wildebeest.org> Message-ID: <1244115243.3575.20.camel@hermans.wildebeest.org> Hi Phil, Hi Igor, On Mon, 2009-05-04 at 21:57 +0200, Mark Wielaard wrote: > On Mon, 2009-05-04 at 12:34 -0700, Phil Race wrote: > > Igor did the freetype work and in he commented in email on 23rd July 2007 : > > > > > - Changed required freetype version from 2.3.4 to 2.3.0 > > > (it did compile with 2.2.1 too for me but Font2DTest was showing garbage > > > and i had no chance to investigate why this happens) > > > > So I don't think we want to move it down without knowing what that was about. > > It may have been platform-specific. Igor - can you remember two years back ? > > Interesting, to make sure everything was fine I did also check with that > Font2DTest (and some others) and the fact that everything looked just > fine was the reason to push it. > > > I also recall there was a nasty bug where having fonts with embedded > > bitmaps on your system caused an infinite loop inside freetype. > > I think we needed to update the freetype lib because of that, but > > I can't remember the details to be sure. > > The freetype 2.2.1 package on RHEL and CentOS 5 do have some fixes > applied to them. And the java-1.6.0-openjdk package has been deployed on > those platforms for some time. So I assume if there were any real bugs > they will have been backported at least on those platforms. > > Ideally of course we would have a autoconf test for the features that > the backend relies on. The problem with the hard version check is that > it prevents compilation for everybody, even when they really just want > to compile against an earlier (patched/fixed) version that might just be > what is available for the platform. > > Let me know if I can help with coming up with a feature test for any > issues. For now to not forget this patch it has been filed at: https://bugs.openjdk.java.net/show_bug.cgi?id=100061 Please do let me know if you find out anything about your earlier concerns and what I can do to help move this forward. Thanks, Mark From mjw at redhat.com Thu Jun 4 05:29:24 2009 From: mjw at redhat.com (Mark Wielaard) Date: Thu, 04 Jun 2009 14:29:24 +0200 Subject: [OpenJDK 2D-Dev] Bug in pisces Renderer (uninitialized crossings) In-Reply-To: <1227202342.3306.33.camel@dijkstra.wildebeest.org> References: <1225119212.3329.29.camel@dijkstra.wildebeest.org> <1225791009.3320.4.camel@dijkstra.wildebeest.org> <1226579411.4563.17.camel@dijkstra.wildebeest.org> <491C64FE.4070408@sun.com> <1227202342.3306.33.camel@dijkstra.wildebeest.org> Message-ID: <1244118565.3575.47.camel@hermans.wildebeest.org> Hi Igor and Alexey, On Thu, 2008-11-20 at 18:32 +0100, Mark Wielaard wrote: > On Thu, 2008-11-13 at 20:33 +0300, Igor Nekrestyanov wrote: > > your patch looks ok to me but i am not expert in pisces. > > > > Alexey Ushakov, who is our expert in pisces should have returned from > > vacation today > > and i think he will review this soon. > > Thanks for looking at it. If I can help with any review, by clarifying > anything, please let me know. To make sure this doesn't get forgotten I also filed it as: https://bugs.openjdk.java.net/show_bug.cgi?id=100063 Thanks, Mark From mjw at redhat.com Thu Jun 4 05:50:19 2009 From: mjw at redhat.com (Mark Wielaard) Date: Thu, 04 Jun 2009 14:50:19 +0200 Subject: [OpenJDK 2D-Dev] Bug in pisces Stroker (div by zero) In-Reply-To: <1227304315.9475.12.camel@hermans.wildebeest.org> References: <1227304315.9475.12.camel@hermans.wildebeest.org> Message-ID: <1244119819.3565.6.camel@hermans.wildebeest.org> Hi, On Fri, 2008-11-21 at 22:51 +0100, Mark Wielaard wrote: > There is a bug in the pisces Stroker in finish(). When ldx and ldy are > so small (zero) that lineLength() will return zero, then you will get a > div by zero exception. > > You can see this with for example this webstart application (you will > need to have IcedTeaWebstart [netx] installed): > http://linuxhippy.blogspot.com/2008/11/jgears2-rendermark.html > > java.lang.ArithmeticException: / by zero > at sun.java2d.pisces.Stroker.finish(Stroker.java:698) > at sun.java2d.pisces.Stroker.close(Stroker.java:592) > [...] To make sure that the patch isn't forgotten I also filed this as: https://bugs.openjdk.java.net/show_bug.cgi?id=100064 Thanks, Mark From linuxhippy at gmail.com Sat Jun 6 01:21:22 2009 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 6 Jun 2009 04:21:22 -0400 Subject: [OpenJDK 2D-Dev] How to determine if SurfaceType supports transparency? Message-ID: <194f62550906060121m6589db58jb6456ab8864b22d0@mail.gmail.com> Hello, Is it possible to determine wether a SurfaceType does support transparency? I know its possible with SurfaceData, but I need to know at loop-registerion time where I only have access to SurfaceTypes of course. Thank you in advance, Clemens From Jim.A.Graham at Sun.COM Sun Jun 7 14:04:29 2009 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Sun, 07 Jun 2009 14:04:29 -0700 Subject: [OpenJDK 2D-Dev] How to determine if SurfaceType supports transparency? In-Reply-To: <194f62550906060121m6589db58jb6456ab8864b22d0@mail.gmail.com> References: <194f62550906060121m6589db58jb6456ab8864b22d0@mail.gmail.com> Message-ID: <0KKV00CMNZVH3S00@fe-sfbay-09.sun.com> That isn't currently possible, but it sounds like a useful thing to add. One problem is that there are some types that know that they have alpha, others that know that they do not, and still others which are too general and may have alpha or may not, so how do you encapsulate that information in a query? For example, IntArgb does have alpha, IntRgb does not, but AnyIntDcm may or may not have alpha. If we simply have ST implement Transparency then I suppose the types that are too general could simply return "Translucent" in order to avoid the promise of opacity. It's the "safe" answer since Translucent doesn't guarantee that the pixels themselves will not be opaque - just that they have the option to be non-opaque... ...jim Clemens Eisserer wrote: > Hello, > > Is it possible to determine wether a SurfaceType does support transparency? > I know its possible with SurfaceData, but I need to know at > loop-registerion time where I only have access to SurfaceTypes of > course. > > Thank you in advance, Clemens From jennifer.godinez at sun.com Mon Jun 8 17:19:04 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Tue, 09 Jun 2009 00:19:04 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d: 6 new changesets Message-ID: <20090609001905.38A4DE0EF@hg.openjdk.java.net> Changeset: 0d76c4da605f Author: vasya Date: 2009-05-14 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/0d76c4da605f Added tag jdk7-b59 for changeset 030142474602 ! .hgtags Changeset: a942ea653d97 Author: aph Date: 2009-04-17 15:37 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/rev/a942ea653d97 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/sanity-rules.gmk Changeset: f5ab6d6ae4b1 Author: xdono Date: 2009-05-07 10:30 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/f5ab6d6ae4b1 Merge - make/jprt.config Changeset: 37fad8722d92 Author: ohair Date: 2009-03-26 16:46 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/37fad8722d92 6822913: Consolidate make/jprt.config files, let JPRT manage this file make it optional in repos Reviewed-by: tbell - make/jprt.config Changeset: b284e021293c Author: ohair Date: 2009-05-08 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/b284e021293c Merge Changeset: 39565502682c Author: ohair Date: 2009-05-15 13:27 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/39565502682c Merge From jennifer.godinez at sun.com Mon Jun 8 17:23:13 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Tue, 09 Jun 2009 00:23:13 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/corba: 6 new changesets Message-ID: <20090609002319.2A608E0F6@hg.openjdk.java.net> Changeset: e9ba2b962ddf Author: vasya Date: 2009-05-14 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/e9ba2b962ddf Added tag jdk7-b59 for changeset 7e6b2b55c00c ! .hgtags Changeset: 7b47536c234e Author: ohair Date: 2009-03-26 16:47 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/7b47536c234e 6822374: Windows: detect X64 when PROCESSOR_IDENTIFIER contains EM64T or Intel64 6822913: Consolidate make/jprt.config files, let JPRT manage this file make it optional in repos Reviewed-by: tbell ! make/common/shared/Platform.gmk - make/jprt.config Changeset: 39aa6ae82075 Author: ohair Date: 2009-05-08 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/39aa6ae82075 Merge Changeset: da27d54e06bd Author: ohair Date: 2009-05-15 13:18 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/da27d54e06bd Merge Changeset: 5dcbe748e580 Author: ohair Date: 2009-05-19 17:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/5dcbe748e580 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README Changeset: f1e1cccbd13a Author: ohair Date: 2009-05-19 18:09 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/f1e1cccbd13a 6733313: corba build warnings: /bin/sh: gcc: not found Reviewed-by: tbell ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-sun.gmk From jennifer.godinez at sun.com Mon Jun 8 17:30:36 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Tue, 09 Jun 2009 00:30:36 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/hotspot: 6 new changesets Message-ID: <20090609003050.7421EE0FD@hg.openjdk.java.net> Changeset: aa0c48844632 Author: vasya Date: 2009-05-14 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/aa0c48844632 Added tag jdk7-b59 for changeset c55be0c7bd32 ! .hgtags Changeset: 5d4dd2f5f6a1 Author: aph Date: 2009-04-17 15:50 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/5d4dd2f5f6a1 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make Changeset: 7a485bc4da16 Author: xdono Date: 2009-05-07 10:30 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/7a485bc4da16 Merge Changeset: 116b019a3961 Author: ohair Date: 2009-05-08 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/116b019a3961 6839126: Type error found by newer windows compiler Reviewed-by: never, kvn ! src/share/vm/adlc/filebuff.hpp Changeset: f5ee65f94d9a Author: ohair Date: 2009-05-15 13:41 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f5ee65f94d9a Merge - make/jprt.config ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make Changeset: a77eddcd510c Author: ohair Date: 2009-05-19 17:40 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a77eddcd510c 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README From jennifer.godinez at sun.com Mon Jun 8 17:42:09 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Tue, 09 Jun 2009 00:42:09 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxp: 8 new changesets Message-ID: <20090609004222.2B44BE102@hg.openjdk.java.net> Changeset: 748976d69503 Author: vasya Date: 2009-05-14 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/748976d69503 Added tag jdk7-b59 for changeset 75113d7ce083 ! .hgtags Changeset: 19c316392d9e Author: aph Date: 2009-04-17 15:55 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/19c316392d9e 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile ! make/build.xml Changeset: 7967d26b229c Author: aph Date: 2009-04-20 19:00 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/7967d26b229c 6832141: Bug 100045 - Fix for 100028 breaks debug info for class files Summary: Correct fallout from 100028 patch Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile Changeset: 04af70c1189c Author: ohair Date: 2009-05-06 11:27 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/04af70c1189c 6837665: Deal with windows ant problem where commas in -D options do not work Reviewed-by: xdono ! make/Makefile ! make/build.properties Changeset: 44e5ca2a846c Author: xdono Date: 2009-05-07 10:30 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/44e5ca2a846c Merge Changeset: 0ea9bb9c6ddc Author: xdono Date: 2009-05-07 12:26 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/0ea9bb9c6ddc Merge - src/share/classes/com/sun/org/apache/xalan/internal/client/XSLTProcessorApplet.java - src/share/classes/com/sun/org/apache/xalan/internal/client/package.html Changeset: cdc8761f136a Author: ohair Date: 2009-05-15 13:24 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/cdc8761f136a Merge Changeset: 259aef5045a1 Author: ohair Date: 2009-05-19 17:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/259aef5045a1 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README From jennifer.godinez at sun.com Mon Jun 8 17:46:43 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Tue, 09 Jun 2009 00:46:43 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxws: 8 new changesets Message-ID: <20090609004654.4324BE107@hg.openjdk.java.net> Changeset: 4fa7398559d0 Author: vasya Date: 2009-05-14 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/4fa7398559d0 Added tag jdk7-b59 for changeset f64566bf4c2b ! .hgtags Changeset: a92183572d99 Author: aph Date: 2009-04-17 15:56 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/a92183572d99 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile ! make/build.xml Changeset: ab30d5761947 Author: aph Date: 2009-04-20 19:01 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/ab30d5761947 6832141: Bug 100045 - Fix for 100028 breaks debug info for class files Summary: Correct fallout from 100028 patch Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile Changeset: 35c29ff8d904 Author: ohair Date: 2009-05-06 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/35c29ff8d904 6837665: Deal with windows ant problem where commas in -D options do not work Reviewed-by: xdono ! make/Makefile ! make/build.properties Changeset: d95fec0fa489 Author: xdono Date: 2009-05-07 10:30 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/d95fec0fa489 Merge ! make/Makefile ! make/build.xml - src/share/classes/com/sun/tools/internal/txw2/AntErrorListener.java - src/share/classes/com/sun/tools/internal/txw2/ConsoleErrorReporter.java - src/share/classes/com/sun/tools/internal/txw2/ErrorListener.java - src/share/classes/com/sun/tools/internal/txw2/Main.java - src/share/classes/com/sun/tools/internal/txw2/NameUtil.java - src/share/classes/com/sun/tools/internal/txw2/RELAXNGLoader.java - src/share/classes/com/sun/tools/internal/txw2/SchemaBuilder.java - src/share/classes/com/sun/tools/internal/txw2/TxwOptions.java - src/share/classes/com/sun/tools/internal/txw2/TxwTask.java - src/share/classes/com/sun/tools/internal/txw2/XmlSchemaLoader.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/AnnotationsImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/CommentListImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/DataPatternBuilderImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/DatatypeFactory.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/DivImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/ElementAnnotationBuilderImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/GrammarImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/GrammarSectionImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/SchemaBuilderImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/package.html - src/share/classes/com/sun/tools/internal/txw2/builder/xsd/XmlSchemaBuilder.java - src/share/classes/com/sun/tools/internal/txw2/builder/xsd/package.html - src/share/classes/com/sun/tools/internal/txw2/model/Attribute.java - src/share/classes/com/sun/tools/internal/txw2/model/CycleIterator.java - src/share/classes/com/sun/tools/internal/txw2/model/Data.java - src/share/classes/com/sun/tools/internal/txw2/model/Define.java - src/share/classes/com/sun/tools/internal/txw2/model/Element.java - src/share/classes/com/sun/tools/internal/txw2/model/Empty.java - src/share/classes/com/sun/tools/internal/txw2/model/Grammar.java - src/share/classes/com/sun/tools/internal/txw2/model/Leaf.java - src/share/classes/com/sun/tools/internal/txw2/model/List.java - src/share/classes/com/sun/tools/internal/txw2/model/Node.java - src/share/classes/com/sun/tools/internal/txw2/model/NodeSet.java - src/share/classes/com/sun/tools/internal/txw2/model/Ref.java - src/share/classes/com/sun/tools/internal/txw2/model/Text.java - src/share/classes/com/sun/tools/internal/txw2/model/Value.java - src/share/classes/com/sun/tools/internal/txw2/model/WriterNode.java - src/share/classes/com/sun/tools/internal/txw2/model/XmlNode.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/AttributeProp.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/ElementProp.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/LeafElementProp.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/Prop.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/ValueProp.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/XmlItemProp.java - src/share/classes/com/sun/tools/internal/ws/processor/Processor.java - src/share/classes/com/sun/tools/internal/ws/processor/ProcessorAction.java - src/share/classes/com/sun/tools/internal/ws/processor/ProcessorActionVersion.java - src/share/classes/com/sun/tools/internal/ws/processor/ProcessorConstants.java - src/share/classes/com/sun/tools/internal/ws/processor/ProcessorNotificationListener.java - src/share/classes/com/sun/tools/internal/ws/processor/ProcessorOptions.java - src/share/classes/com/sun/tools/internal/ws/processor/config/ClassModelInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/config/Configuration.java - src/share/classes/com/sun/tools/internal/ws/processor/config/ConfigurationException.java - src/share/classes/com/sun/tools/internal/ws/processor/config/HandlerChainInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/config/HandlerInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/config/ModelInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/config/WSDLModelInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/ClassModelParser.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/CustomizationParser.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/InputParser.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/JAXWSBindingInfoParser.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/ParserUtil.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/Reader.java - src/share/classes/com/sun/tools/internal/ws/processor/generator/JAXBTypeGenerator.java - src/share/classes/com/sun/tools/internal/ws/processor/generator/SimpleToBoxedUtil.java - src/share/classes/com/sun/tools/internal/ws/processor/modeler/ModelerUtils.java - src/share/classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceReferenceCollector.java - src/share/classes/com/sun/tools/internal/ws/processor/util/ClientProcessorEnvironment.java - src/share/classes/com/sun/tools/internal/ws/processor/util/GeneratedFileInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/util/ProcessorEnvironment.java - src/share/classes/com/sun/tools/internal/ws/processor/util/ProcessorEnvironmentBase.java - src/share/classes/com/sun/tools/internal/ws/util/JAXWSClassFactory.java - src/share/classes/com/sun/tools/internal/ws/util/JavaCompilerHelper.java - src/share/classes/com/sun/tools/internal/ws/util/MapBase.java - src/share/classes/com/sun/tools/internal/ws/util/ToolBase.java - src/share/classes/com/sun/tools/internal/ws/util/xml/NodeListIterator.java - src/share/classes/com/sun/tools/internal/ws/util/xml/NullEntityResolver.java - src/share/classes/com/sun/tools/internal/ws/util/xml/PrettyPrintingXmlWriter.java - src/share/classes/com/sun/tools/internal/ws/util/xml/XmlWriter.java - src/share/classes/com/sun/tools/internal/ws/wscompile/ActionConstants.java - src/share/classes/com/sun/tools/internal/ws/wscompile/CompileTool.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/BuiltInTypes.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/Schema.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaAttribute.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaDocument.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaElement.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaEntity.java - src/share/classes/com/sun/tools/internal/ws/wsdl/framework/Extensible.java - src/share/classes/com/sun/tools/internal/ws/wsdl/framework/Extension.java - src/share/classes/com/sun/tools/internal/ws/wsdl/framework/ParserContext.java - src/share/classes/com/sun/tools/internal/ws/wsdl/framework/WriterContext.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/ExtensionHandler.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/ExtensionHandlerBase.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/SchemaExtensionHandler.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/SchemaParser.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/SchemaWriter.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/WSDLWriter.java - src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/DOM4JLocator.java - src/share/classes/com/sun/tools/internal/xjc/util/XMLStreamReaderToContentHandler.java - src/share/classes/com/sun/xml/internal/bind/v2/doc-files/packages.png - src/share/classes/com/sun/xml/internal/bind/v2/doc-files/packages.vsd - src/share/classes/com/sun/xml/internal/bind/v2/doc-files/readme.txt - src/share/classes/com/sun/xml/internal/ws/binding/http/HTTPBindingImpl.java - src/share/classes/com/sun/xml/internal/ws/binding/soap/SOAPBindingImpl.java - src/share/classes/com/sun/xml/internal/ws/client/AsyncHandlerService.java - src/share/classes/com/sun/xml/internal/ws/client/ClientConfigurationException.java - src/share/classes/com/sun/xml/internal/ws/client/ContactInfoBase.java - src/share/classes/com/sun/xml/internal/ws/client/ContactInfoListImpl.java - src/share/classes/com/sun/xml/internal/ws/client/ContactInfoListIteratorBase.java - src/share/classes/com/sun/xml/internal/ws/client/ContextMap.java - src/share/classes/com/sun/xml/internal/ws/client/EndpointIFBase.java - src/share/classes/com/sun/xml/internal/ws/client/EndpointIFContext.java - src/share/classes/com/sun/xml/internal/ws/client/EndpointIFInvocationHandler.java - src/share/classes/com/sun/xml/internal/ws/client/InternalBindingProvider.java - src/share/classes/com/sun/xml/internal/ws/client/PortInfoBase.java - src/share/classes/com/sun/xml/internal/ws/client/ServiceContext.java - src/share/classes/com/sun/xml/internal/ws/client/ServiceContextBuilder.java - src/share/classes/com/sun/xml/internal/ws/client/WSFuture.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/DispatchBase.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/DispatchContext.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/ResponseImpl.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/DispatchContactInfoList.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/DispatchDelegate.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/encoding/DispatchSerializer.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/encoding/DispatchUtil.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/protocol/MessageDispatcherHelper.java - src/share/classes/com/sun/xml/internal/ws/encoding/EncoderDecoderBase.java - src/share/classes/com/sun/xml/internal/ws/encoding/JAXWSAttachmentMarshaller.java - src/share/classes/com/sun/xml/internal/ws/encoding/JAXWSAttachmentUnmarshaller.java - src/share/classes/com/sun/xml/internal/ws/encoding/internal/InternalEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/JAXBBeanInfo.java - src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/JAXBBridgeInfo.java - src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/JAXBTypeSerializer.java - src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/RpcLitPayload.java - src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/RpcLitPayloadSerializer.java - src/share/classes/com/sun/xml/internal/ws/encoding/simpletype/EncoderUtils.java - src/share/classes/com/sun/xml/internal/ws/encoding/simpletype/SimpleTypeConstants.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/ClientEncoderDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/EncoderDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/SOAPDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/SOAPEPTFactory.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/SOAPEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/SOAPVersion.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/ServerEncoderDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/client/SOAP12XMLDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/client/SOAP12XMLEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/client/SOAPXMLDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/client/SOAPXMLEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/AttachmentBlock.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/BodyBlock.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/DelegateBase.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/HeaderBlock.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/InternalMessage.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/MessageBlock.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/MessageInfoBase.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/SOAP12NotUnderstoodHeaderBlock.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultCode.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultCodeEnum.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultReason.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultReasonText.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultSubcode.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/SOAP12FaultInfo.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/SOAPFaultInfo.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/SOAPMsgCreateException.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/SOAPMsgFactoryCreateException.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/ProviderSED.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/SOAP12XMLDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/SOAP12XMLEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/SOAPXMLDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/SOAPXMLEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/xml/XMLDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/xml/XMLEPTFactory.java - src/share/classes/com/sun/xml/internal/ws/encoding/xml/XMLEncoder.java - src/share/classes/com/sun/xml/internal/ws/handler/HandlerChainCaller.java - src/share/classes/com/sun/xml/internal/ws/handler/HandlerContext.java - src/share/classes/com/sun/xml/internal/ws/handler/HandlerResolverImpl.java - src/share/classes/com/sun/xml/internal/ws/handler/MessageContextUtil.java - src/share/classes/com/sun/xml/internal/ws/handler/SHDSOAPMessageContext.java - src/share/classes/com/sun/xml/internal/ws/handler/SOAPHandlerContext.java - src/share/classes/com/sun/xml/internal/ws/handler/XMLHandlerContext.java - src/share/classes/com/sun/xml/internal/ws/handler/XMLLogicalMessageContextImpl.java - src/share/classes/com/sun/xml/internal/ws/handler/XMLLogicalMessageImpl.java - src/share/classes/com/sun/xml/internal/ws/handler/package-info.java - src/share/classes/com/sun/xml/internal/ws/model/CheckedException.java - src/share/classes/com/sun/xml/internal/ws/model/ExceptionType.java - src/share/classes/com/sun/xml/internal/ws/model/JavaMethod.java - src/share/classes/com/sun/xml/internal/ws/model/Mode.java - src/share/classes/com/sun/xml/internal/ws/model/Parameter.java - src/share/classes/com/sun/xml/internal/ws/model/ParameterBinding.java - src/share/classes/com/sun/xml/internal/ws/model/RuntimeModel.java - src/share/classes/com/sun/xml/internal/ws/model/soap/SOAPBinding.java - src/share/classes/com/sun/xml/internal/ws/model/soap/SOAPRuntimeModel.java - src/share/classes/com/sun/xml/internal/ws/model/soap/Style.java - src/share/classes/com/sun/xml/internal/ws/model/soap/Use.java - src/share/classes/com/sun/xml/internal/ws/modeler/RuntimeModeler.java - src/share/classes/com/sun/xml/internal/ws/modeler/RuntimeModelerException.java - src/share/classes/com/sun/xml/internal/ws/pept/Delegate.java - src/share/classes/com/sun/xml/internal/ws/pept/encoding/Decoder.java - src/share/classes/com/sun/xml/internal/ws/pept/encoding/Encoder.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/Acceptor.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/ContactInfo.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/ContactInfoList.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/ContactInfoListIterator.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/EPTFactory.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/MessageInfo.java - src/share/classes/com/sun/xml/internal/ws/pept/presentation/MessageStruct.java - src/share/classes/com/sun/xml/internal/ws/pept/presentation/Stub.java - src/share/classes/com/sun/xml/internal/ws/pept/presentation/TargetFinder.java - src/share/classes/com/sun/xml/internal/ws/pept/presentation/Tie.java - src/share/classes/com/sun/xml/internal/ws/pept/protocol/Interceptors.java - src/share/classes/com/sun/xml/internal/ws/pept/protocol/MessageDispatcher.java - src/share/classes/com/sun/xml/internal/ws/protocol/soap/client/SOAPMessageDispatcher.java - src/share/classes/com/sun/xml/internal/ws/protocol/soap/server/ProviderSOAPMD.java - src/share/classes/com/sun/xml/internal/ws/protocol/soap/server/SOAPMessageDispatcher.java - src/share/classes/com/sun/xml/internal/ws/protocol/xml/client/XMLMessageDispatcher.java - src/share/classes/com/sun/xml/internal/ws/protocol/xml/server/ProviderXMLMD.java - src/share/classes/com/sun/xml/internal/ws/protocol/xml/server/XMLMessageDispatcher.java - src/share/classes/com/sun/xml/internal/ws/server/AppMsgContextImpl.java - src/share/classes/com/sun/xml/internal/ws/server/DocInfo.java - src/share/classes/com/sun/xml/internal/ws/server/EPTFactoryBase.java - src/share/classes/com/sun/xml/internal/ws/server/EPTFactoryFactoryBase.java - src/share/classes/com/sun/xml/internal/ws/server/PeptTie.java - src/share/classes/com/sun/xml/internal/ws/server/RuntimeContext.java - src/share/classes/com/sun/xml/internal/ws/server/RuntimeEndpointInfo.java - src/share/classes/com/sun/xml/internal/ws/server/TargetFinderImpl.java - src/share/classes/com/sun/xml/internal/ws/server/Tie.java - src/share/classes/com/sun/xml/internal/ws/server/XMLEPTFactoryImpl.java - src/share/classes/com/sun/xml/internal/ws/server/provider/ProviderModel.java - src/share/classes/com/sun/xml/internal/ws/server/provider/ProviderPeptTie.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/Binding.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/ClientTransportFactory.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/ClientTransportFactoryTypes.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/InternalSoapEncoder.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/Invoker.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/MessageContext.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/MtomCallback.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/RuntimeEndpointInfo.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/SOAPMessageContext.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/StubBase.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/SystemHandlerDelegate.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/SystemHandlerDelegateFactory.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/Tie.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/WSConnection.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/WebServiceContext.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/package-info.java - src/share/classes/com/sun/xml/internal/ws/streaming/XMLStreamReaderFactory.java - src/share/classes/com/sun/xml/internal/ws/streaming/XMLStreamWriterFactory.java - src/share/classes/com/sun/xml/internal/ws/transport/WSConnectionImpl.java - src/share/classes/com/sun/xml/internal/ws/transport/http/client/HttpClientTransportFactory.java - src/share/classes/com/sun/xml/internal/ws/transport/http/server/EndpointDocInfo.java - src/share/classes/com/sun/xml/internal/ws/transport/http/server/EndpointEntityResolver.java - src/share/classes/com/sun/xml/internal/ws/transport/http/server/WebServiceContextImpl.java - src/share/classes/com/sun/xml/internal/ws/transport/local/LocalMessage.java - src/share/classes/com/sun/xml/internal/ws/transport/local/client/LocalClientTransport.java - src/share/classes/com/sun/xml/internal/ws/transport/local/client/LocalClientTransportFactory.java - src/share/classes/com/sun/xml/internal/ws/transport/local/server/LocalConnectionImpl.java - src/share/classes/com/sun/xml/internal/ws/transport/local/server/LocalWSContextImpl.java - src/share/classes/com/sun/xml/internal/ws/util/Base64Util.java - src/share/classes/com/sun/xml/internal/ws/util/MessageInfoUtil.java - src/share/classes/com/sun/xml/internal/ws/util/NullIterator.java - src/share/classes/com/sun/xml/internal/ws/util/SOAPConnectionUtil.java - src/share/classes/com/sun/xml/internal/ws/util/SOAPUtil.java - src/share/classes/com/sun/xml/internal/ws/util/SunStAXReflection.java - src/share/classes/com/sun/xml/internal/ws/util/XMLConnectionUtil.java - src/share/classes/com/sun/xml/internal/ws/util/xml/XMLStreamReaderToContentHandler.java - src/share/classes/com/sun/xml/internal/ws/wsdl/WSDLContext.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Binding.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/BindingOperation.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Message.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Part.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Port.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/PortType.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/PortTypeOperation.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Service.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/WSDLDocument.java - src/share/classes/com/sun/xml/internal/ws/wsdl/writer/WSDLOutputResolver.java - src/share/classes/com/sun/xml/internal/xsom/impl/util/ConcatIterator.java - src/share/classes/com/sun/xml/internal/xsom/impl/util/FilterIterator.java Changeset: 1626ba49a98e Author: xdono Date: 2009-05-07 12:26 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/1626ba49a98e Merge Changeset: af4d62e31af8 Author: ohair Date: 2009-05-15 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/af4d62e31af8 Merge Changeset: 3b054db3e277 Author: ohair Date: 2009-05-19 17:39 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/3b054db3e277 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README From jennifer.godinez at sun.com Mon Jun 8 17:51:39 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Tue, 09 Jun 2009 00:51:39 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 13 new changesets Message-ID: <20090609005429.4064BE10C@hg.openjdk.java.net> Changeset: 827a93c4d06a Author: vasya Date: 2009-05-14 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/827a93c4d06a Added tag jdk7-b59 for changeset 2a5a1b269e89 ! .hgtags Changeset: 9ad7e6462145 Author: aph Date: 2009-04-17 15:56 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9ad7e6462145 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/common/Defs-linux.gmk ! make/sun/awt/mawt.gmk Changeset: 5ceb9eb621d1 Author: chegar Date: 2009-05-07 17:02 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/5ceb9eb621d1 6837982: SCTP API docs not being generated. Summary: Update docs makefile to build javadoc for the com.sun.nio.sctp package. Reviewed-by: jccollet, alanb, weijun ! make/docs/Makefile Changeset: 86d2541a9ba2 Author: xdono Date: 2009-05-07 10:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/86d2541a9ba2 Merge - src/share/native/java/util/zip/ZipEntry.c - src/share/native/sun/java2d/pipe/RenderBuffer.c - test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java Changeset: 39d93fb6926c Author: xdono Date: 2009-05-07 12:26 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/39d93fb6926c Merge Changeset: 6ca1c622dd6e Author: ohair Date: 2009-05-07 18:19 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/6ca1c622dd6e 6835803: Type error in src/windows/native/sun/windows/awt_Window.cpp Reviewed-by: prr ! src/windows/native/sun/windows/awt_Window.cpp Changeset: 7ec6857812d2 Author: ohair Date: 2009-05-08 11:24 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7ec6857812d2 Merge ! src/windows/native/sun/windows/awt_Window.cpp Changeset: 9eeeeee69368 Author: ohair Date: 2009-05-15 13:14 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9eeeeee69368 6841873: Fix windows redist default location for msvc runtime dlls Reviewed-by: tbell ! make/common/shared/Defs-windows.gmk Changeset: 97064d73976f Author: ohair Date: 2009-05-15 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/97064d73976f Merge Changeset: fdbc48164a8b Author: ohair Date: 2009-05-18 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/fdbc48164a8b 6842023: Improve test reliability, Increase timeout factor on jtreg tests, etc. Reviewed-by: tbell ! make/jprt.properties ! test/Makefile ! test/java/lang/ThreadGroup/NullThreadName.java ! test/java/util/ResourceBundle/RestrictedBundleTest.java ! test/java/util/WeakHashMap/GCDuringIteration.java Changeset: c06d30bd8c69 Author: andrew Date: 2009-05-21 16:29 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c06d30bd8c69 6841728: Make building the Nimbus L 'n' F optional (100054) Summary: Add DISABLE_NIMBUS variable to prevent Nimbus subdirs being built Reviewed-by: mr, ohair ! make/common/shared/Sanity.gmk ! make/javax/swing/plaf/Makefile ! make/tools/Makefile Changeset: 238591c80bc5 Author: aph Date: 2009-05-21 18:41 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/238591c80bc5 6839133: lcms 1.18 update breaks ICC_ProfileRGB Tests Reviewed-by: avu, prr ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: b92e3fbbcb63 Author: jgodinez Date: 2009-06-08 13:56 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b92e3fbbcb63 Merge From jennifer.godinez at sun.com Mon Jun 8 18:02:42 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Tue, 09 Jun 2009 01:02:42 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/langtools: 8 new changesets Message-ID: <20090609010255.83DECE111@hg.openjdk.java.net> Changeset: 0f653be1a42f Author: vasya Date: 2009-05-14 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/0f653be1a42f Added tag jdk7-b59 for changeset 88bcb6772159 ! .hgtags Changeset: 4b72c2556789 Author: aph Date: 2009-04-17 15:56 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/4b72c2556789 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile Changeset: 321854d9ab19 Author: aph Date: 2009-04-20 19:01 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/321854d9ab19 6832141: Bug 100045 - Fix for 100028 breaks debug info for class files Summary: Correct fallout from 100028 patch Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile Changeset: f3d27f02683c Author: aph Date: 2009-05-06 18:04 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/f3d27f02683c 6837665: Deal with windows ant problem where commas in -D options do not work Summary: Rewrite to avoid commas in -D options Reviewed-by: ohair ! make/Makefile ! make/build.xml Changeset: 43a781cc6473 Author: xdono Date: 2009-05-07 10:32 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/43a781cc6473 Merge Changeset: 846944dd48a4 Author: xdono Date: 2009-05-07 12:26 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/846944dd48a4 Merge Changeset: 65f2ee956fb9 Author: ohair Date: 2009-05-15 13:30 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/65f2ee956fb9 Merge Changeset: 5cdce469ea2a Author: ohair Date: 2009-05-19 17:39 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/5cdce469ea2a 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad ! README - make/README From mario.torre at aicas.com Tue Jun 9 15:58:07 2009 From: mario.torre at aicas.com (Mario Torre) Date: Wed, 10 Jun 2009 00:58:07 +0200 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised Message-ID: <1244588287.3580.53.camel@localhost.localdomain> Hello all! While hacking on Cacio I've found that SunGraphics2D exposes a reference to "this" inside the constructor to another class, while initialising a field that contains the RederingLoops. I filed a bug report and proposed a patch for review: https://bugs.openjdk.java.net/show_bug.cgi?id=100068 The webrew is here: http://cr.openjdk.java.net/~neugens/100068/webrev.01/ There is not much to say about the rationale for the bug/fix, just that the code looks a bit borked to me with those public references (there are others around, I think I should fix them all at some point), but the real problem is indeed exposing "this" in the constructor. I hope I did the webrew correctly, as I had other patches around and no patch queue on this tree (yeah, yeah, I know...) so I had to do some manual tricks to make webrew happy, but the patch should be complete. I tested with all the swing apps that come with OpenJDK, as well as those two nice things: http://java.sun.com/products/java-media/2D/samples/index.html I'll bug you every day if you make me wait too much about that review :) Have fun, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ From Jim.A.Graham at Sun.COM Wed Jun 10 03:02:10 2009 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Wed, 10 Jun 2009 03:02:10 -0700 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <1244588287.3580.53.camel@localhost.localdomain> References: <1244588287.3580.53.camel@localhost.localdomain> Message-ID: <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> What is the need for this fix? Is there a bug being fixed here other than you don't like the look of the code? The reason I ask is that your fix requires a method call with a test for every graphics operation. I'd prefer if we didn't add overhead unless it was necessary for correct function. Also, the partially initialized state issue - while that technique can "in general" lead to issues, I don't think it is problematic here. If that is the concern then we could target removing just that line. Any references to the field from pipeline objects is safe since they won't be installed until a validate() is called which always sets the loops. The only suspect reference to loops would be the call from checkFontInfo() which might be invoked before the first validate() so it would need the protection against null, but almost no other piece of code you've modified can ever encounter a null loops field (or if it does then some validate() code forgot to set it)... ...jim Mario Torre wrote: > Hello all! > > While hacking on Cacio I've found that SunGraphics2D exposes a reference > to "this" inside the constructor to another class, while initialising a > field that contains the RederingLoops. > > I filed a bug report and proposed a patch for review: > > https://bugs.openjdk.java.net/show_bug.cgi?id=100068 > > The webrew is here: > > http://cr.openjdk.java.net/~neugens/100068/webrev.01/ > > There is not much to say about the rationale for the bug/fix, just that > the code looks a bit borked to me with those public references (there > are others around, I think I should fix them all at some point), but the > real problem is indeed exposing "this" in the constructor. > > I hope I did the webrew correctly, as I had other patches around and no > patch queue on this tree (yeah, yeah, I know...) so I had to do some > manual tricks to make webrew happy, but the patch should be complete. > > I tested with all the swing apps that come with OpenJDK, as well as > those two nice things: > > http://java.sun.com/products/java-media/2D/samples/index.html > > I'll bug you every day if you make me wait too much about that review :) > > Have fun, > Mario From linuxhippy at gmail.com Wed Jun 10 03:53:30 2009 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 10 Jun 2009 06:53:30 -0400 Subject: [OpenJDK 2D-Dev] How to determine if SurfaceType supports transparency? In-Reply-To: <0KKV00CMNZVH3S00@fe-sfbay-09.sun.com> References: <194f62550906060121m6589db58jb6456ab8864b22d0@mail.gmail.com> <0KKV00CMNZVH3S00@fe-sfbay-09.sun.com> Message-ID: <194f62550906100353k52647cafha40a6a6f6e8fc01b@mail.gmail.com> Hi Jim, I thought about something like supportsTransparency() or something with the same semantics as you described. However, I'll simply look at it at blit-time. Thanks, Clemens > That isn't currently possible, but it sounds like a useful thing to add. > ?One problem is that there are some types that know that they have alpha, > others that know that they do not, and still others which are too general > and may have alpha or may not, so how do you encapsulate that information in > a query? > > For example, IntArgb does have alpha, IntRgb does not, but AnyIntDcm may or > may not have alpha. > > If we simply have ST implement Transparency then I suppose the types that > are too general could simply return "Translucent" in order to avoid the > promise of opacity. ?It's the "safe" answer since Translucent doesn't > guarantee that the pixels themselves will not be opaque - just that they > have the option to be non-opaque... > > ? ? ? ? ? ? ? ? ? ? ? ?...jim > > Clemens Eisserer wrote: >> >> Hello, >> >> Is it possible to determine wether a SurfaceType does support >> transparency? >> I know its possible with SurfaceData, but I need to know at >> loop-registerion time where I only have access to SurfaceTypes of >> course. >> >> Thank you in advance, Clemens > From andrew.brygin at sun.com Thu Jun 11 03:12:06 2009 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Thu, 11 Jun 2009 10:12:06 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6296893: BMP Writer handles TopDown property incorrectly for some of the compression types Message-ID: <20090611101228.75622E350@hg.openjdk.java.net> Changeset: 378feb59435b Author: bae Date: 2009-06-11 13:47 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/378feb59435b 6296893: BMP Writer handles TopDown property incorrectly for some of the compression types Reviewed-by: igor, prr ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java + test/javax/imageio/plugins/bmp/TopDownTest.java From andrew.brygin at sun.com Thu Jun 11 04:18:46 2009 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Thu, 11 Jun 2009 11:18:46 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 5101862: WBMP Image reader tries to load Quicktime MOV files Message-ID: <20090611111908.EE6C9E35F@hg.openjdk.java.net> Changeset: e138ae33b128 Author: bae Date: 2009-06-11 14:22 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/e138ae33b128 5101862: WBMP Image reader tries to load Quicktime MOV files Reviewed-by: igor, prr ! src/share/classes/com/sun/imageio/plugins/common/ReaderUtil.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReader.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java + test/javax/imageio/plugins/wbmp/CanDecodeTest.java From mario.torre at aicas.com Thu Jun 11 09:18:32 2009 From: mario.torre at aicas.com (Mario Torre) Date: Thu, 11 Jun 2009 18:18:32 +0200 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> Message-ID: <1244737112.3699.43.camel@localhost.localdomain> Il giorno mer, 10/06/2009 alle 03.02 -0700, Jim Graham ha scritto: > What is the need for this fix? Is there a bug being fixed here other > than you don't like the look of the code? > > The reason I ask is that your fix requires a method call with a test for > every graphics operation. I'd prefer if we didn't add overhead unless > it was necessary for correct function. > > Also, the partially initialized state issue - while that technique can > "in general" lead to issues, I don't think it is problematic here. If > that is the concern then we could target removing just that line. Any > references to the field from pipeline objects is safe since they won't > be installed until a validate() is called which always sets the loops. > The only suspect reference to loops would be the call from > checkFontInfo() which might be invoked before the first validate() so it > would need the protection against null, but almost no other piece of > code you've modified can ever encounter a null loops field (or if it > does then some validate() code forgot to set it)... > > ...jim Hi Jim! Thanks for the kind reply. I was tracking a bug in our SDL backend when I put my eyes on this code, but the bug itself is not related, just thought that this kind of code leads to unexpected errors (I shoot myself in the foot already with this stuff sometime ago...). I noticed that the references to this variable are not always protected by a call to validate though. If I don't set the loop in the constructor, and don't check for null in the getter, I get NPE in various places, for example: sun.java2d.pipe.GlyphListLoopPipe.drawGlyphList sun.java2d.pipe.AATextRenderer.drawGlyphList I get those two with the Java2D demo, but there are other places that blindly just use the loop (in fact, everywhere loops is referenced, it is just used without checking for null), and they trust on the fact that loops is just never null. There are two solution to this in my mind, either check for null everywhere loops is used (which is what I proposed with the getter) or selectively check for null in places we know it may be null (for example either in AATextRenderer.drawGlyphList, GlyphListLoopPipe.drawGlyphList, or in general in the various calls inside SunGraphics2D that end up in those methods). The third solution, that works so far, is to protect checkFontInfo() with a null check like you proposed, because in fact checkFontInfo is called before validate, and initialise there a valid instance of the RenderLoops, if they are null, which is the best option for performances, too. To be honest, those solutions looks a bit hacky to me, because we end up checking in places where "it may be used" other than in places where "it is actually used", but for the sake of saving few bytecodes and a method invocation, maybe we can go this path. Or, because it seems I opened a can of worm, I understand if you don't want to fix this issue at all ;) I have prepared a new webrew with the proposed fix, where I check for null in checkFontInfo: http://cr.openjdk.java.net/~neugens/100068/webrev.02/ I added a small comment to make clear that this guy may be null if not set via validate, checkFontInfo or setLoops. Hope this helps! Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ From Phil.Race at Sun.COM Fri Jun 12 10:13:34 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Fri, 12 Jun 2009 10:13:34 -0700 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <1244737112.3699.43.camel@localhost.localdomain> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> Message-ID: <4A328CBE.7090005@sun.com> > If I don't set the loop in the > constructor, and don't check for null in the getter, I get NPE in > various places, Isn't that just a bug in (I guess) your SurfaceData subclass ? -phil. Mario Torre wrote: > Il giorno mer, 10/06/2009 alle 03.02 -0700, Jim Graham ha scritto: >> What is the need for this fix? Is there a bug being fixed here other >> than you don't like the look of the code? >> >> The reason I ask is that your fix requires a method call with a test for >> every graphics operation. I'd prefer if we didn't add overhead unless >> it was necessary for correct function. >> >> Also, the partially initialized state issue - while that technique can >> "in general" lead to issues, I don't think it is problematic here. If >> that is the concern then we could target removing just that line. Any >> references to the field from pipeline objects is safe since they won't >> be installed until a validate() is called which always sets the loops. >> The only suspect reference to loops would be the call from >> checkFontInfo() which might be invoked before the first validate() so it >> would need the protection against null, but almost no other piece of >> code you've modified can ever encounter a null loops field (or if it >> does then some validate() code forgot to set it)... >> >> ...jim > > Hi Jim! > > Thanks for the kind reply. > > I was tracking a bug in our SDL backend when I put my eyes on this code, > but the bug itself is not related, just thought that this kind of code > leads to unexpected errors (I shoot myself in the foot already with this > stuff sometime ago...). > > I noticed that the references to this variable are not always protected > by a call to validate though. If I don't set the loop in the > constructor, and don't check for null in the getter, I get NPE in > various places, for example: > > sun.java2d.pipe.GlyphListLoopPipe.drawGlyphList > sun.java2d.pipe.AATextRenderer.drawGlyphList > > I get those two with the Java2D demo, but there are other places that > blindly just use the loop (in fact, everywhere loops is referenced, it > is just used without checking for null), and they trust on the fact that > loops is just never null. > > There are two solution to this in my mind, either check for null > everywhere loops is used (which is what I proposed with the getter) or > selectively check for null in places we know it may be null (for example > either in AATextRenderer.drawGlyphList, GlyphListLoopPipe.drawGlyphList, > or in general in the various calls inside SunGraphics2D that end up in > those methods). > > The third solution, that works so far, is to protect checkFontInfo() > with a null check like you proposed, because in fact checkFontInfo is > called before validate, and initialise there a valid instance of the > RenderLoops, if they are null, which is the best option for > performances, too. > > To be honest, those solutions looks a bit hacky to me, because we end up > checking in places where "it may be used" other than in places where "it > is actually used", but for the sake of saving few bytecodes and a method > invocation, maybe we can go this path. Or, because it seems I opened a > can of worm, I understand if you don't want to fix this issue at all ;) > > I have prepared a new webrew with the proposed fix, where I check for > null in checkFontInfo: > > http://cr.openjdk.java.net/~neugens/100068/webrev.02/ > > I added a small comment to make clear that this guy may be null if not > set via validate, checkFontInfo or setLoops. > > Hope this helps! > > Cheers, > Mario From Jennifer.Godinez at Sun.COM Fri Jun 12 10:30:59 2009 From: Jennifer.Godinez at Sun.COM (Jennifer Godinez) Date: Fri, 12 Jun 2009 10:30:59 -0700 Subject: [OpenJDK 2D-Dev] upcoming 2d JDK 7 integration Message-ID: <4A3290D3.4080202@sun.com> Just a heads-up that 2D will integrate on 6/30th for b63 . Please plan to put your fixes before the code freeze which is 6/23rd, 5 PM. Thank you. Jennifer From mario.torre at aicas.com Fri Jun 12 17:57:44 2009 From: mario.torre at aicas.com (Mario Torre) Date: Sat, 13 Jun 2009 02:57:44 +0200 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <4A328CBE.7090005@sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <4A328CBE.7090005@sun.com> Message-ID: <1244854664.17489.13.camel@localhost.localdomain> Il giorno ven, 12/06/2009 alle 10.13 -0700, Phil Race ha scritto: > > If I don't set the loop in the > > constructor, and don't check for null in the getter, I get NPE in > > various places, > > Isn't that just a bug in (I guess) your SurfaceData subclass ? > > -phil. Hi Phil! No, because this is with the "plain" OpenJDK and not with my SurfaceData. This is because all the users of this field expect a valid non null value, but if we don't set it in the constructor, only the calls that happens after validate() will see a non null value. Having this null check in checkFontInfo also makes the NPE disappear in the Java2D demo, thus obtaining the same effect as initialising in the constructor, but without exposing "this". It has to be checked if there are other possible location where this variable is used non initialised, but I doubt. It's not really robust though if we depend on this initialisation in the constructor the way it is in my opinion. Not that is a serious bug, and in fact we could even say it's not a bug because the code works, but it's not correct in my point of view and looks easy to fix, so... Just want to be sure that the proposed solution doesn't add new bugs in some corner cases or doesn't add overhead, so who knows the code better has the last word on that, of course. Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ From Phil.Race at Sun.COM Fri Jun 12 18:41:59 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Fri, 12 Jun 2009 18:41:59 -0700 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <1244854664.17489.13.camel@localhost.localdomain> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <4A328CBE.7090005@sun.com> <1244854664.17489.13.camel@localhost.localdomain> Message-ID: <4A3303E7.80307@sun.com> Mario, Did you, or can you, share a test case (and any platform specific info needed) to repro this? -phil. Mario Torre wrote: > Il giorno ven, 12/06/2009 alle 10.13 -0700, Phil Race ha scritto: > >>> If I don't set the loop in the >>> >> > constructor, and don't check for null in the getter, I get NPE in >> > various places, >> >> Isn't that just a bug in (I guess) your SurfaceData subclass ? >> >> -phil. >> > > Hi Phil! > > No, because this is with the "plain" OpenJDK and not with my > SurfaceData. This is because all the users of this field expect a valid > non null value, but if we don't set it in the constructor, only the > calls that happens after validate() will see a non null value. Having > this null check in checkFontInfo also makes the NPE disappear in the > Java2D demo, thus obtaining the same effect as initialising in the > constructor, but without exposing "this". It has to be checked if there > are other possible location where this variable is used non initialised, > but I doubt. It's not really robust though if we depend on this > initialisation in the constructor the way it is in my opinion. Not that > is a serious bug, and in fact we could even say it's not a bug because > the code works, but it's not correct in my point of view and looks easy > to fix, so... Just want to be sure that the proposed solution doesn't > add new bugs in some corner cases or doesn't add overhead, so who knows > the code better has the last word on that, of course. > > Cheers, > Mario > From andrew.brygin at sun.com Mon Jun 15 04:10:22 2009 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Mon, 15 Jun 2009 11:10:22 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6829549: JVM crash on certain images Message-ID: <20090615111050.ED812E60B@hg.openjdk.java.net> Changeset: 0ce29cbeb6a9 Author: bae Date: 2009-06-15 14:49 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0ce29cbeb6a9 6829549: JVM crash on certain images Reviewed-by: igor, prr ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java From mario.torre at aicas.com Mon Jun 15 05:33:01 2009 From: mario.torre at aicas.com (Mario Torre) Date: Mon, 15 Jun 2009 14:33:01 +0200 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <4A3303E7.80307@sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <4A328CBE.7090005@sun.com> <1244854664.17489.13.camel@localhost.localdomain> <4A3303E7.80307@sun.com> Message-ID: <1245069181.3675.35.camel@localhost.localdomain> Il giorno ven, 12/06/2009 alle 18.41 -0700, Phil Race ha scritto: > Mario, > > Did you, or can you, share a test case (and any platform specific info > needed) to repro this? > > -phil. Hi Phil! I think I didn't explained myself very well :) The purpose of my change is to remove the line of code that initialises the loops from the constructor: @@ -254,11 +254,10 @@ font = f; if (font == null) { font = defaultFont; } - loops = sd.getRenderLoops(this); setDevClip(sd.getBounds()); invalidatePipe(); } protected Object clone() { The reason I want to do this is to avoid a reference to "this" to be passed to an external class because SG2D may not be fully initialised, and I would say that this is at least non nice :) As for the NPE, I was referring to the fact that just removing the call to sd.getRenderLoops(this) (which is, again, what I want to do), leaves the loops uninitialised. This happens in the Java2D demo, for example, because validate is not called in all the cases as the first thing. A solution could be to put a check for null in checkFontInfo, like Jim suggested, because this is called before validate. I'll prepare a test case for this issue based on the J2D demo, but of course it's only useful to show the NPE if you remove the sd.getRenderLoops(this) line from the constructor. I hope this clarifies a bit my idea. Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ From andrew.brygin at sun.com Mon Jun 15 06:37:06 2009 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Mon, 15 Jun 2009 13:37:06 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6684104: Applets fails to launch using ImageIO if .java.policy with File permissions present on the system Message-ID: <20090615133718.7C7A0E615@hg.openjdk.java.net> Changeset: 5896dcd01fe3 Author: bae Date: 2009-06-15 17:19 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/5896dcd01fe3 6684104: Applets fails to launch using ImageIO if .java.policy with File permissions present on the system Reviewed-by: igor, prr ! src/share/classes/javax/imageio/ImageIO.java + test/javax/imageio/CachePremissionsTest/CachePermissionsTest.java + test/javax/imageio/CachePremissionsTest/rw.policy + test/javax/imageio/CachePremissionsTest/rwd.policy + test/javax/imageio/CachePremissionsTest/w.policy From jennifer.godinez at sun.com Mon Jun 15 13:28:22 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Mon, 15 Jun 2009 20:28:22 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d: Added tag jdk7-b60 for changeset 39565502682c Message-ID: <20090615202822.359AEE697@hg.openjdk.java.net> Changeset: 472c21584cfd Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/472c21584cfd Added tag jdk7-b60 for changeset 39565502682c ! .hgtags From jennifer.godinez at sun.com Mon Jun 15 13:32:43 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Mon, 15 Jun 2009 20:32:43 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/corba: Added tag jdk7-b60 for changeset f1e1cccbd13a Message-ID: <20090615203244.B3C71E69C@hg.openjdk.java.net> Changeset: e906b16a12a9 Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/e906b16a12a9 Added tag jdk7-b60 for changeset f1e1cccbd13a ! .hgtags From Jim.A.Graham at Sun.COM Mon Jun 15 13:37:09 2009 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Mon, 15 Jun 2009 13:37:09 -0700 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <1244737112.3699.43.camel@localhost.localdomain> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> Message-ID: <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> Hi Mario, How are the drawGlyphList methods called when the loops is null? I ask because they are only ever installed on the SunGraphics2D object by virtue of a call to validatePipe() and all calls to validatePipe() should set the loops. So, there is a bug somewhere that causes these loops to be installed without a full validate process. As I said in the email you quoted. All calls from pipelines (GlyphListLoopPipe and AATextRenderer are both pipeline objects) should be safe because all calls to validatePipe() should set the loops. Having said that I note that there are some pipelines that do not require loops and it would be OK for a call to validate that only uses such "non-loop-based" pipelines to leave the loops field uninitialized, but all validate calls which use loop-based pipes must update the loops field. Eliminating all of those uses of loops we then fall into the case where the usage in checkFontInfo is the only usage that does not occur from a pipeline... ...jim Mario Torre wrote: > Il giorno mer, 10/06/2009 alle 03.02 -0700, Jim Graham ha scritto: >> What is the need for this fix? Is there a bug being fixed here other >> than you don't like the look of the code? >> >> The reason I ask is that your fix requires a method call with a test for >> every graphics operation. I'd prefer if we didn't add overhead unless >> it was necessary for correct function. >> >> Also, the partially initialized state issue - while that technique can >> "in general" lead to issues, I don't think it is problematic here. If >> that is the concern then we could target removing just that line. Any >> references to the field from pipeline objects is safe since they won't >> be installed until a validate() is called which always sets the loops. >> The only suspect reference to loops would be the call from >> checkFontInfo() which might be invoked before the first validate() so it >> would need the protection against null, but almost no other piece of >> code you've modified can ever encounter a null loops field (or if it >> does then some validate() code forgot to set it)... >> >> ...jim > > Hi Jim! > > Thanks for the kind reply. > > I was tracking a bug in our SDL backend when I put my eyes on this code, > but the bug itself is not related, just thought that this kind of code > leads to unexpected errors (I shoot myself in the foot already with this > stuff sometime ago...). > > I noticed that the references to this variable are not always protected > by a call to validate though. If I don't set the loop in the > constructor, and don't check for null in the getter, I get NPE in > various places, for example: > > sun.java2d.pipe.GlyphListLoopPipe.drawGlyphList > sun.java2d.pipe.AATextRenderer.drawGlyphList > > I get those two with the Java2D demo, but there are other places that > blindly just use the loop (in fact, everywhere loops is referenced, it > is just used without checking for null), and they trust on the fact that > loops is just never null. > > There are two solution to this in my mind, either check for null > everywhere loops is used (which is what I proposed with the getter) or > selectively check for null in places we know it may be null (for example > either in AATextRenderer.drawGlyphList, GlyphListLoopPipe.drawGlyphList, > or in general in the various calls inside SunGraphics2D that end up in > those methods). > > The third solution, that works so far, is to protect checkFontInfo() > with a null check like you proposed, because in fact checkFontInfo is > called before validate, and initialise there a valid instance of the > RenderLoops, if they are null, which is the best option for > performances, too. > > To be honest, those solutions looks a bit hacky to me, because we end up > checking in places where "it may be used" other than in places where "it > is actually used", but for the sake of saving few bytecodes and a method > invocation, maybe we can go this path. Or, because it seems I opened a > can of worm, I understand if you don't want to fix this issue at all ;) > > I have prepared a new webrew with the proposed fix, where I check for > null in checkFontInfo: > > http://cr.openjdk.java.net/~neugens/100068/webrev.02/ > > I added a small comment to make clear that this guy may be null if not > set via validate, checkFontInfo or setLoops. > > Hope this helps! > > Cheers, > Mario From jennifer.godinez at sun.com Mon Jun 15 13:39:45 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Mon, 15 Jun 2009 20:39:45 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/hotspot: Added tag jdk7-b60 for changeset a77eddcd510c Message-ID: <20090615203947.56D19E6A1@hg.openjdk.java.net> Changeset: 86092459c54d Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/86092459c54d Added tag jdk7-b60 for changeset a77eddcd510c ! .hgtags From Jim.A.Graham at Sun.COM Mon Jun 15 13:48:33 2009 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Mon, 15 Jun 2009 13:48:33 -0700 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <1245069181.3675.35.camel@localhost.localdomain> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <4A328CBE.7090005@sun.com> <1244854664.17489.13.camel@localhost.localdomain> <4A3303E7.80307@sun.com> <1245069181.3675.35.camel@localhost.localdomain> Message-ID: <0KLA001HRSGMD3G0@fe-sfbay-09.sun.com> Hi Mario, Ah, I can see that I was behind a bit in my emails. The question I still have is why the loops can be null while valid pipelines are installed? The SG2D starts life with invalid pipes installed, which means that *ALL* graphics operations get vectored through a validate process before any work is done. Since no pipeline operation objects are installed at that point (i.e. all pipeline fields in SG2D have a reference to an InvalidPipe instance installed in them), then no references to loops can occur. When the InvalidPipe methods are invoked it validates the SG2D, which both installs real pipelines and fills in the loops member, and then reinvokes on the new pipelines - which should be OK since the loops field should have been installed by then. So, some other bug must exist, one of: - Some validatePipe implementation in some SurfaceData class is installing a loop-based pipeline without initializing the loops - Some code is calling a method on a loop-based pipeline that it did not get from the SG2D itself (i.e. it got it from a different SG2D, but invoked it on this SG2D - or it had a static reference to a pipeline object and just invoked it directly rather than invoking the one that was installed on the SG2D it is using). All calls to pipeline objects should be using the paradigm of "sg2d.fooPipe.Render(sg2d, ...)". - A race condition where thread A is validating the pipeline and installs the pipeline objects but hasn't yet reached the code to install the loops while thread B starts rendering using that SG2D thus invoking an operation on a partially initialized pipeline - in this case the NPE is appropriate and allowed since we don't support multi-threaded use of the Graphics2D objects. ...jim Mario Torre wrote: > Il giorno ven, 12/06/2009 alle 18.41 -0700, Phil Race ha scritto: >> Mario, >> >> Did you, or can you, share a test case (and any platform specific info >> needed) to repro this? >> >> -phil. > > Hi Phil! > > I think I didn't explained myself very well :) > > The purpose of my change is to remove the line of code that initialises > the loops from the constructor: > > @@ -254,11 +254,10 @@ > font = f; > if (font == null) { > font = defaultFont; > } > > - loops = sd.getRenderLoops(this); > setDevClip(sd.getBounds()); > invalidatePipe(); > } > > protected Object clone() { > > The reason I want to do this is to avoid a reference to "this" > to be passed to an external class because SG2D may not be fully initialised, > and I would say that this is at least non nice :) > > As for the NPE, I was referring to the fact that just removing the call to > sd.getRenderLoops(this) (which is, again, what I want to do), leaves the loops > uninitialised. This happens in the Java2D demo, for example, because validate > is not called in all the cases as the first thing. > > A solution could be to put a check for null in checkFontInfo, like Jim suggested, > because this is called before validate. > > I'll prepare a test case for this issue based on the J2D demo, > but of course it's only useful to show the NPE if you remove the > sd.getRenderLoops(this) line from the constructor. > > I hope this clarifies a bit my idea. > > Cheers, > Mario From jennifer.godinez at sun.com Mon Jun 15 13:50:46 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Mon, 15 Jun 2009 20:50:46 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxp: Added tag jdk7-b60 for changeset 259aef5045a1 Message-ID: <20090615205048.0E309E6AA@hg.openjdk.java.net> Changeset: f1ac756616ea Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/f1ac756616ea Added tag jdk7-b60 for changeset 259aef5045a1 ! .hgtags From jennifer.godinez at sun.com Mon Jun 15 13:55:05 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Mon, 15 Jun 2009 20:55:05 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxws: Added tag jdk7-b60 for changeset 3b054db3e277 Message-ID: <20090615205506.8B7D5E6AF@hg.openjdk.java.net> Changeset: aeabf802f2a1 Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/aeabf802f2a1 Added tag jdk7-b60 for changeset 3b054db3e277 ! .hgtags From jennifer.godinez at sun.com Mon Jun 15 14:00:15 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Mon, 15 Jun 2009 21:00:15 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 21 new changesets Message-ID: <20090615210423.D6E6AE6B4@hg.openjdk.java.net> Changeset: f62f7fcc9965 Author: art Date: 2009-05-15 15:40 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f62f7fcc9965 6678385: Random java.lang.StackOverflowError from various JDKs Reviewed-by: stayer ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/MotifDnDConstants.java ! src/solaris/classes/sun/awt/X11/MotifDnDDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/WindowPropertyGetter.java ! src/solaris/classes/sun/awt/X11/XAWTXSettings.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XDnDDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDnDDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDropTargetRegistry.java ! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java + src/solaris/classes/sun/awt/X11/XErrorHandler.java ! src/solaris/classes/sun/awt/X11/XProtocol.java ! src/solaris/classes/sun/awt/X11/XQueryTree.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XTranslateCoordinates.java ! src/solaris/classes/sun/awt/X11/XWM.java ! src/solaris/classes/sun/awt/X11/XlibUtil.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_InputMethod.c ! src/solaris/native/sun/awt/awt_MToolkit.c ! src/solaris/native/sun/xawt/XToolkit.c ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: 019fd945ebc5 Author: yan Date: 2009-05-18 12:39 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/019fd945ebc5 6834525: PIT: RowToleranceTransitivityTest test fail with crash on rhel4 x86 and rhel 5x86 Summary: do not try to use released XKB resources Reviewed-by: art ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h Changeset: 875524a2b311 Author: anthony Date: 2009-05-19 12:15 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/875524a2b311 6811219: Deadlock java AWT in XWarningWindow Summary: The locking scheme has been re-architected, the code slightly refactored. Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XWarningWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: 5eaa495dc929 Author: anthony Date: 2009-05-19 14:14 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/5eaa495dc929 6812298: Dynamic GraphicsConfig changes don't work on X11 platforms Summary: The peer gets recreated if the visual of the new GC differs from the previous one Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/sun/awt/NullComponentPeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java Changeset: ac08fa3d6c98 Author: anthony Date: 2009-05-19 14:43 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ac08fa3d6c98 6833444: _BOOTDIR1/_BOOTDIR2 on MS Windows should be consistent with other platforms Summary: Added optional _BOOTDIR3 that provides the J: path for the BOOTDIR on Windows Reviewed-by: ohair, xdono ! make/common/Sanity.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity.gmk Changeset: 315f315b8d3c Author: anthony Date: 2009-05-19 17:03 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/315f315b8d3c 6839999: Cumulative fix for 6762511 and 6838003 Summary: Adds support for ARGB and ABGR X11 surfaces. Reviewed-by: art, yan ! src/solaris/classes/sun/awt/X11/generator/sizes.64-solaris-i386 ! src/solaris/classes/sun/awt/X11/generator/xlibtypes.txt ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitLoops.java ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java ! src/solaris/native/sun/awt/X11Color.c ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_p.h Changeset: b33466bb2fed Author: art Date: 2009-05-21 12:29 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b33466bb2fed 6794764: Translucent windows are completely repainted on every paint event, on Windows 6719382: Printing of AWT components on windows is not working 6726866: Repainting artifacts when resizing or dragging JInternalFrames in non-opaque toplevel 6683775: Painting artifacts is seen when panel is made setOpaque(false) for a translucent window Reviewed-by: anthony, tdv, alexp ! src/share/classes/java/awt/GraphicsConfiguration.java ! src/share/classes/java/awt/GraphicsDevice.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/peer/WindowPeer.java ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java ! src/windows/classes/sun/awt/windows/WCanvasPeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WObjectPeer.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h + test/javax/swing/JComponent/6683775/bug6683775.java + test/javax/swing/JInternalFrame/6726866/bug6726866.html + test/javax/swing/JInternalFrame/6726866/bug6726866.java Changeset: 97ece6b3d84f Author: ant Date: 2009-05-21 15:04 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/97ece6b3d84f 6833019: KeyboardFocusManager.getCurrentKeyboardFocusManager() throws unspecified HeadlessException Reviewed-by: art ! src/share/classes/sun/awt/HeadlessToolkit.java Changeset: cfe73335a065 Author: dav Date: 2009-05-22 16:09 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/cfe73335a065 6799099: All automatic regression tests that create Robot fail on X11 Reviewed-by: art, ant ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/Robot.java ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/awt/event/MouseEvent.java ! src/share/classes/java/awt/peer/RobotPeer.java ! src/share/classes/sun/awt/SunToolkit.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java ! src/solaris/classes/sun/awt/X11/XRobotPeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/native/sun/awt/awt_MToolkit.c ! src/solaris/native/sun/awt/awt_Robot.c ! src/solaris/native/sun/xawt/XToolkit.c ! src/windows/classes/sun/awt/windows/WRobotPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 52493efeb137 Author: dav Date: 2009-05-25 18:22 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/52493efeb137 6844750: Solaris build failed after 6799099 Reviewed-by: yan ! src/solaris/native/sun/xawt/XToolkit.c Changeset: 7da360c3baf6 Author: yan Date: 2009-06-01 01:05 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7da360c3baf6 Merge Changeset: f29cd35647b1 Author: peytoia Date: 2009-05-12 15:21 +0900 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f29cd35647b1 6834474: (tz) Support tzdata2009g Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: 62bfe2674e48 Author: yan Date: 2009-05-14 00:17 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/62bfe2674e48 Merge - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: 455b357442c7 Author: peterz Date: 2009-05-14 18:12 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/455b357442c7 6741426: ClassCastException from ComboBoxEditableState (Nimbus LaF) in JDK 1.6.0_10 RC Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/nimbus/skin.laf + test/javax/swing/plaf/nimbus/Test6741426.java Changeset: af491a9b7c1d Author: peterz Date: 2009-05-15 12:06 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/af491a9b7c1d 6827581: Contextkey does not work in Nimbus Reviewed-by: rupashka ! src/share/classes/sun/swing/plaf/GTKKeybindings.java ! src/share/classes/sun/swing/plaf/WindowsKeybindings.java Changeset: 993a5f0fe2e0 Author: rupashka Date: 2009-05-15 17:26 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/993a5f0fe2e0 6713352: Deadlock in JFileChooser with synchronized custom FileSystemView Reviewed-by: malenkov, peterz ! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java ! src/share/classes/sun/awt/shell/ShellFolder.java ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java + test/javax/swing/JFileChooser/6713352/bug6713352.java Changeset: 019908df0313 Author: rupashka Date: 2009-05-28 18:11 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/019908df0313 6845805: Test for CR 6713352 is failed under Linux Reviewed-by: malenkov ! test/javax/swing/JFileChooser/6713352/bug6713352.java Changeset: 951ecbad4068 Author: yan Date: 2009-06-01 01:06 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/951ecbad4068 Merge Changeset: 0c3ef2d612a4 Author: yan Date: 2009-06-09 23:47 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0c3ef2d612a4 Merge ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity.gmk ! src/windows/native/sun/windows/awt_Window.cpp Changeset: f72c0dc047b9 Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f72c0dc047b9 Added tag jdk7-b60 for changeset 0c3ef2d612a4 ! .hgtags Changeset: 956715ded919 Author: jgodinez Date: 2009-06-15 09:59 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/956715ded919 Merge From jennifer.godinez at sun.com Mon Jun 15 14:17:34 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Mon, 15 Jun 2009 21:17:34 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/langtools: Added tag jdk7-b60 for changeset 5cdce469ea2a Message-ID: <20090615211735.F02EDE6BB@hg.openjdk.java.net> Changeset: 522520757dd3 Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/522520757dd3 Added tag jdk7-b60 for changeset 5cdce469ea2a ! .hgtags From Roman.Kennke at Sun.COM Tue Jun 16 08:01:20 2009 From: Roman.Kennke at Sun.COM (Roman Kennke) Date: Tue, 16 Jun 2009 11:01:20 -0400 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <0KLA001HRSGMD3G0@fe-sfbay-09.sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <4A328CBE.7090005@sun.com> <1244854664.17489.13.camel@localhost.localdomain> <4A3303E7.80307@sun.com> <1245069181.3675.35.camel@localhost.localdomain> <0KLA001HRSGMD3G0@fe-sfbay-09.sun.com> Message-ID: <4A37B3C0.7010907@sun.com> Hi there, first of all, let me say that - especially in the light of this thread, I support Mario's change (removal of this one line from the constructor) for the following reasons: - It should not be necessary as you say, this field should always be initialized before use by validatePipe(). - If it's not, it's most likely a bug. - Therefore this line is only good for hiding bugs. One thing is not quite clear to me: > - A race condition where thread A is validating the pipeline and > installs the pipeline objects but hasn't yet reached the code to install > the loops while thread B starts rendering using that SG2D thus invoking > an operation on a partially initialized pipeline - in this case the NPE > is appropriate and allowed since we don't support multi-threaded use of > the Graphics2D objects. I was always under the assumption, that Java2D should be thread safe. And in many places we make sure it is, e.g. in the SurfaceData objects. But now you say, it isn't. So what is the real thing about Java2D and thread safety. Is it only supposed to be thread safe when each thread gets its own Graphics2D object? I think I remember back in the GNU Classpath days we had a test case that shared a Graphics (no Graphics2D back then..) object between threads and was supposed to be ok, but I might be wrong here... Can you enlighten me what is the situation w/ Java2D and thread safety? / Roman From Jim.A.Graham at Sun.COM Tue Jun 16 11:45:10 2009 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Tue, 16 Jun 2009 11:45:10 -0700 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <4A37B3C0.7010907@sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <4A328CBE.7090005@sun.com> <1244854664.17489.13.camel@localhost.localdomain> <4A3303E7.80307@sun.com> <1245069181.3675.35.camel@localhost.localdomain> <0KLA001HRSGMD3G0@fe-sfbay-09.sun.com> <4A37B3C0.7010907@sun.com> Message-ID: <0KLC001ZEHEYIIG0@fe-sfbay-10.sun.com> My design goal was "doesn't corrupt anything if run from multiple threads" (in other words don't require synchronization in any common places just to keep it functional and don't require it to be used from a particular thread), but only correct behavior if run from 1 thread at a time. In other words, it can be used by multiple threads in sequence, but not simultaneously. ...jim Roman Kennke wrote: > Hi there, > > first of all, let me say that - especially in the light of this thread, > I support Mario's change (removal of this one line from the constructor) > for the following reasons: > > - It should not be necessary as you say, this field should always be > initialized before use by validatePipe(). > - If it's not, it's most likely a bug. > - Therefore this line is only good for hiding bugs. > > One thing is not quite clear to me: > >> - A race condition where thread A is validating the pipeline and >> installs the pipeline objects but hasn't yet reached the code to >> install the loops while thread B starts rendering using that SG2D thus >> invoking an operation on a partially initialized pipeline - in this >> case the NPE is appropriate and allowed since we don't support >> multi-threaded use of the Graphics2D objects. > > I was always under the assumption, that Java2D should be thread safe. > And in many places we make sure it is, e.g. in the SurfaceData objects. > But now you say, it isn't. So what is the real thing about Java2D and > thread safety. Is it only supposed to be thread safe when each thread > gets its own Graphics2D object? I think I remember back in the GNU > Classpath days we had a test case that shared a Graphics (no Graphics2D > back then..) object between threads and was supposed to be ok, but I > might be wrong here... Can you enlighten me what is the situation w/ > Java2D and thread safety? > > / Roman > From Jim.A.Graham at Sun.COM Tue Jun 16 12:08:30 2009 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Tue, 16 Jun 2009 12:08:30 -0700 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <0KLC001ZEHEYIIG0@fe-sfbay-10.sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <4A328CBE.7090005@sun.com> <1244854664.17489.13.camel@localhost.localdomain> <4A3303E7.80307@sun.com> <1245069181.3675.35.camel@localhost.localdomain> <0KLA001HRSGMD3G0@fe-sfbay-09.sun.com> <4A37B3C0.7010907@sun.com> <0KLC001ZEHEYIIG0@fe-sfbay-10.sun.com> Message-ID: <0KLC00EWMIHTBF80@fe-sfbay-10.sun.com> I should clarify that what I meant by "doesn't corrupt anything" is that the world won't come to an end or the system crash. It's protected against harm from MT, but it doesn't support MT. And another way of stating it is that we won't consider race condition bugs when it is used in an MT fashion, but we would consider fixing bugs that cause it to crash or that cause a G2D to latch onto a specific thread. It's probably also a good place to let slip that a certain demo that was mentioned previously in the thread has always been considered "poorly written" and I wouldn't put it past it to be violating the threading design goals we have. But I would never come right out and say something like that since it serves as a good "make sure even kooky things continue to work" telltale... [goes back to looking nonchalant] ...jim Jim Graham wrote: > My design goal was "doesn't corrupt anything if run from multiple > threads" (in other words don't require synchronization in any common > places just to keep it functional and don't require it to be used from a > particular thread), but only correct behavior if run from 1 thread at a > time. > > In other words, it can be used by multiple threads in sequence, but not > simultaneously. > > ...jim From mario.torre at aicas.com Tue Jun 16 13:14:54 2009 From: mario.torre at aicas.com (Mario Torre) Date: Tue, 16 Jun 2009 22:14:54 +0200 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <0KLC00EWMIHTBF80@fe-sfbay-10.sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <4A328CBE.7090005@sun.com> <1244854664.17489.13.camel@localhost.localdomain> <4A3303E7.80307@sun.com> <1245069181.3675.35.camel@localhost.localdomain> <0KLA001HRSGMD3G0@fe-sfbay-09.sun.com> <4A37B3C0.7010907@sun.com> <0KLC001ZEHEYIIG0@fe-sfbay-10.sun.com> <0KLC00EWMIHTBF80@fe-sfbay-10.sun.com> Message-ID: <1245183294.3614.404.camel@localhost.localdomain> Il giorno mar, 16/06/2009 alle 12.08 -0700, Jim Graham ha scritto: > It's probably also a good place to let slip that a certain demo that was > mentioned previously in the thread has always been considered "poorly > written" and I wouldn't put it past it to be violating the threading > design goals we have. But I would never come right out and say > something like that since it serves as a good "make sure even kooky > things continue to work" telltale... [goes back to looking nonchalant] > Ugh... don't tell me I'm debugging with a wrong test case... :S Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ From Jim.A.Graham at Sun.COM Tue Jun 16 15:24:05 2009 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Tue, 16 Jun 2009 15:24:05 -0700 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <1245183294.3614.404.camel@localhost.localdomain> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <4A328CBE.7090005@sun.com> <1244854664.17489.13.camel@localhost.localdomain> <4A3303E7.80307@sun.com> <1245069181.3675.35.camel@localhost.localdomain> <0KLA001HRSGMD3G0@fe-sfbay-09.sun.com> <4A37B3C0.7010907@sun.com> <0KLC001ZEHEYIIG0@fe-sfbay-10.sun.com> <0KLC00EWMIHTBF80@fe-sfbay-10.sun.com> <1245183294.3614.404.camel@localhost.localdomain> Message-ID: <0KLC00GTRRJRQ8F0@fe-sfbay-10.sun.com> Not necessarily. The demo serves to test a wide variety of 2D functionality all in one place. It has worked very well to point out real bugs in the past that we have fixed, though it does have some questionable practices inside it that can turn up false bugs and I believe its abuse of threading is one such practice. Send me (off-line) the full stack traces of the failures you were seeing and I'll check and see if they occur in areas where it might be trying to do graphics from multiple threads at once... ...jim Mario Torre wrote: > Il giorno mar, 16/06/2009 alle 12.08 -0700, Jim Graham ha scritto: > >> It's probably also a good place to let slip that a certain demo that was >> mentioned previously in the thread has always been considered "poorly >> written" and I wouldn't put it past it to be violating the threading >> design goals we have. But I would never come right out and say >> something like that since it serves as a good "make sure even kooky >> things continue to work" telltale... [goes back to looking nonchalant] >> > > Ugh... don't tell me I'm debugging with a wrong test case... :S > > Cheers, > Mario From mario.torre at aicas.com Tue Jun 16 15:48:11 2009 From: mario.torre at aicas.com (Mario Torre) Date: Wed, 17 Jun 2009 00:48:11 +0200 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> Message-ID: <1245192491.3614.558.camel@localhost.localdomain> Il giorno lun, 15/06/2009 alle 13.37 -0700, Jim Graham ha scritto: > Hi Mario, > > How are the drawGlyphList methods called when the loops is null? I ask > because they are only ever installed on the SunGraphics2D object by > virtue of a call to validatePipe() and all calls to validatePipe() > should set the loops. So, there is a bug somewhere that causes these > loops to be installed without a full validate process. Hi Jim, So, I spent some time today (sorry for the delay, I had to find some free time slot for that and had to make a cake for my girl friend, which was the most difficult part :), and I debugged the Java2D demo with just the non initialised loops (so, no checks for null loops anywhere else in the code). The Demo starts fine, but after some point I get the error attached in this mail. > As I said in the email you quoted. All calls from pipelines > (GlyphListLoopPipe and AATextRenderer are both pipeline objects) should > be safe because all calls to validatePipe() should set the loops. I see that validatePipe is indeed called always, but sometimes the path that is chosen doesn't validate the rendering loop. I've seen that most of the time this is ok, because the loops are not used. I guess this is the case for all the various text rendering (LCD or AA) in swing components, for example (is this correct?). > Having said that I note that there are some pipelines that do not > require loops and it would be OK for a call to validate that only uses > such "non-loop-based" pipelines to leave the loops field uninitialized, > but all validate calls which use loop-based pipes must update the loops > field. Exactly. I'm not deep into the code yet to distinguish when they are needed or not, but... > Eliminating all of those uses of loops we then fall into the case where > the usage in checkFontInfo is the only usage that does not occur from a > pipeline... ...this is exactly the case, putting a null check here solves the NPE. For what I can see, at some point some component needs to paint to an offscreen surface (I don't think the offscreen surface is special, I think it's the application code that drives the bug, but anyway...). This is the background image from the Java2D Intro pane, I think the other pane do something similar. Once the SunGraphics2d object is created, some redering hints are set. This is the application code: g2.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON); That is, turn on antialiasing, then: g2.clearRect(0, 0, d.width, d.height); Now what? This of course goes through validatePipe: The first two if/else statements fall through but not this (SurfaceData, line 535 in OpenJDK): } else if (sg2d.antialiasHint == SunHints.INTVAL_ANTIALIAS_ON) { This guy sets the pipes but doesn't set the RederingLoops. Then, again application code: scene.render(d.width, d.height, g2); Which after few loops finally renders the string on screen, which causes the crash. So, in other words, everything goes fine until we draw text with the AA redering hints turned on. Of course, before it was not failing because of the rendering loops were initialised in the constructor. I'm not sure if we need to check for a null loops at the beginning of validatePipe or in checkFontoInfo. Maybe we can save something if we use checkFontInfo but I'm not so sure. I hope this helps, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ -------------- next part -------------- In various place after some time the demo is started or when selecting the ArcsCurves panel: In Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException at sun.java2d.pipe.AATextRenderer.drawGlyphList(AATextRenderer.java:40) at sun.java2d.pipe.GlyphListPipe.drawString(GlyphListPipe.java:72) at sun.java2d.SunGraphics2D.drawString(SunGraphics2D.java:2808) at demos.Arcs_Curves.Arcs.drawDemo(Arcs.java:128) at DemoSurface.paint(DemoSurface.java:303) at javax.swing.JComponent.paintToOffscreen(JComponent.java:5180) at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:302) at javax.swing.RepaintManager.paint(RepaintManager.java:1232) at javax.swing.JComponent._paintImmediately(JComponent.java:5128) at javax.swing.JComponent.paintImmediately(JComponent.java:4938) at DemoSurface.paintImmediately(DemoSurface.java:275) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:818) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:770) at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:712) at javax.swing.RepaintManager.access$700(RepaintManager.java:60) at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1647) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:235) at java.awt.EventQueue.dispatchEvent(EventQueue.java:603) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:286) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:191) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:186) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:178) at java.awt.EventDispatchThread.run(EventDispatchThread.java:139) After selecting the Tranform panel: Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException at sun.java2d.pipe.GlyphListLoopPipe.drawGlyphList(GlyphListLoopPipe.java:49) at sun.java2d.pipe.GlyphListPipe.drawGlyphVector(GlyphListPipe.java:137) at sun.java2d.pipe.ValidatePipe.drawGlyphVector(ValidatePipe.java:171) at sun.java2d.SunGraphics2D.drawGlyphVector(SunGraphics2D.java:2883) at sun.font.ExtendedTextSourceLabel.handleDraw(ExtendedTextSourceLabel.java:193) at sun.font.Decoration.drawTextAndDecorations(Decoration.java:122) at sun.font.ExtendedTextSourceLabel.draw(ExtendedTextSourceLabel.java:197) at java.awt.font.TextLine.draw(TextLine.java:774) at java.awt.font.TextLayout.draw(TextLayout.java:2638) at demos.Transforms.SelectTx.drawDemo(SelectTx.java:210) at DemoSurface.paint(DemoSurface.java:303) at javax.swing.JComponent.paintToOffscreen(JComponent.java:5180) at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:302) at javax.swing.RepaintManager.paint(RepaintManager.java:1232) at javax.swing.JComponent._paintImmediately(JComponent.java:5128) at javax.swing.JComponent.paintImmediately(JComponent.java:4938) at DemoSurface.paintImmediately(DemoSurface.java:275) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:818) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:770) at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:712) at javax.swing.RepaintManager.access$700(RepaintManager.java:60) at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1647) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:235) at java.awt.EventQueue.dispatchEvent(EventQueue.java:603) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:286) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:191) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:186) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:178) at java.awt.EventDispatchThread.run(EventDispatchThread.java:139) From Jim.A.Graham at Sun.COM Tue Jun 16 16:18:03 2009 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Tue, 16 Jun 2009 16:18:03 -0700 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <1245192491.3614.558.camel@localhost.localdomain> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> Message-ID: <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> Ah, I think I see the problem. Phil can chime in here if I'm wrong. Text now uses loops in most cases, but many of the validate methods assume that they don't need the loops. I don't think that used to be the case, but it changed as a result of the LCD text loop work. It used to be that AA used the alphafill field of SG2D and not the loops, and it still does for most rendering. But now text rendering will almost always go through the loops and it is only working because of that call to getRenderLoops() in the constructor (and the fact that we never set it back to null. I'd like to see invalidate() set the loops to null and see how far we get - I'll bet that we'd get NPEs all over the place, especially with AA rendering. In the long run, this is another straw on the camel's back as far as rethinking the validation framework. It's been tweaked and hacked quite a lot over the past 10 years and so there are a lot of issues that arise like this that aren't readily obvious from the code. I don't think the camel's back is broken yet, but it is becoming more and more confusing for new engineers to start tinkering with it without seeing things break from seemingly innocuous changes. :-( For now, I'm wary of removing that call without a lot of testing. I think putting a "loops=null" line in invalidatePipe() might accelerate some of that testing, though. And Phil might want to chime in with a description of the new requirements on loops in light of the post-LCD text work... Phil? ...jim Mario Torre wrote: > Il giorno lun, 15/06/2009 alle 13.37 -0700, Jim Graham ha scritto: >> Hi Mario, >> >> How are the drawGlyphList methods called when the loops is null? I ask >> because they are only ever installed on the SunGraphics2D object by >> virtue of a call to validatePipe() and all calls to validatePipe() >> should set the loops. So, there is a bug somewhere that causes these >> loops to be installed without a full validate process. > > Hi Jim, > > So, I spent some time today (sorry for the delay, I had to find some > free time slot for that and had to make a cake for my girl friend, which > was the most difficult part :), and I debugged the Java2D demo with just > the non initialised loops (so, no checks for null loops anywhere else in > the code). > > The Demo starts fine, but after some point I get the error attached in > this mail. > >> As I said in the email you quoted. All calls from pipelines >> (GlyphListLoopPipe and AATextRenderer are both pipeline objects) should >> be safe because all calls to validatePipe() should set the loops. > > I see that validatePipe is indeed called always, but sometimes the path > that is chosen doesn't validate the rendering loop. I've seen that > most of the time this is ok, because the loops are not used. > > I guess this is the case for all the various text rendering (LCD or AA) > in swing components, for example (is this correct?). > >> Having said that I note that there are some pipelines that do not >> require loops and it would be OK for a call to validate that only uses >> such "non-loop-based" pipelines to leave the loops field uninitialized, >> but all validate calls which use loop-based pipes must update the loops >> field. > > Exactly. I'm not deep into the code yet to distinguish when they are > needed or not, but... > >> Eliminating all of those uses of loops we then fall into the case where >> the usage in checkFontInfo is the only usage that does not occur from a >> pipeline... > > ...this is exactly the case, putting a null check here solves the NPE. > > For what I can see, at some point some component needs to paint to an > offscreen surface (I don't think the offscreen surface is special, > I think it's the application code that drives the bug, but anyway...). > > This is the background image from the Java2D Intro pane, I think the > other pane do something similar. Once the SunGraphics2d object is created, > some redering hints are set. This is the application code: > > g2.setRenderingHint(RenderingHints.KEY_ANTIALIASING, > RenderingHints.VALUE_ANTIALIAS_ON); > > That is, turn on antialiasing, then: > > g2.clearRect(0, 0, d.width, d.height); > > Now what? This of course goes through validatePipe: > > The first two if/else statements fall through but not this > (SurfaceData, line 535 in OpenJDK): > > } else if (sg2d.antialiasHint == SunHints.INTVAL_ANTIALIAS_ON) { > > This guy sets the pipes but doesn't set the RederingLoops. > > Then, again application code: > > scene.render(d.width, d.height, g2); > > Which after few loops finally renders the string on screen, > which causes the crash. > > So, in other words, everything goes fine until we draw text with > the AA redering hints turned on. > > Of course, before it was not failing because of the rendering loops > were initialised in the constructor. > > I'm not sure if we need to check for a null loops at the beginning > of validatePipe or in checkFontoInfo. Maybe we can save something if we > use checkFontInfo but I'm not so sure. > > I hope this helps, > Mario > From mario.torre at aicas.com Tue Jun 16 16:52:04 2009 From: mario.torre at aicas.com (Mario Torre) Date: Wed, 17 Jun 2009 01:52:04 +0200 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> Message-ID: <1245196324.3614.577.camel@localhost.localdomain> Il giorno mar, 16/06/2009 alle 16.18 -0700, Jim Graham ha scritto: > Ah, I think I see the problem. Phil can chime in here if I'm wrong. Yay, glad it helped :) > Text now uses loops in most cases, but many of the validate methods > assume that they don't need the loops. I don't think that used to be > the case, but it changed as a result of the LCD text loop work. It used > to be that AA used the alphafill field of SG2D and not the loops, and it > still does for most rendering. But now text rendering will almost > always go through the loops and it is only working because of that call > to getRenderLoops() in the constructor (and the fact that we never set > it back to null. That makes completely sense to me. > I'd like to see invalidate() set the loops to null and see how far we > get - I'll bet that we'd get NPEs all over the place, especially with AA > rendering. I'll try that tomorrow. I can also help with the testing, I would like to see those changes in the main code base at some point, and they will be surely useful for Cacio too. > In the long run, this is another straw on the camel's back as far as > rethinking the validation framework. It's been tweaked and hacked quite > a lot over the past 10 years and so there are a lot of issues that arise > like this that aren't readily obvious from the code. I don't think the > camel's back is broken yet, but it is becoming more and more confusing > for new engineers to start tinkering with it without seeing things break > from seemingly innocuous changes. :-( Eh... I've seen this in the FontManager code too, and in Classpath we had similar problems for some of the most obscure things too, that's an obvious consequence of code that has to preserve backward forever-compatibility, but I have to say that the Java2D code does some really cool things in many places :) > And Phil might want to chime in with a description of the new > requirements on loops in light of the post-LCD text work... Phil? That would be interesting :) Cheers (and good night!), Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ From Phil.Race at Sun.COM Wed Jun 17 12:41:42 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 17 Jun 2009 12:41:42 -0700 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> Message-ID: <4A3946F6.2040902@sun.com> I don't think it is related to the LCD text work. I think it was the JDK 7 b17 fix: 6263951: Java does not use fast AA text loops when regular AA hint is set. So there's a requirement that renderLoops is non-null in some case when they would not previously have been used. -phil. Jim Graham wrote: > Ah, I think I see the problem. Phil can chime in here if I'm wrong. > > Text now uses loops in most cases, but many of the validate methods > assume that they don't need the loops. I don't think that used to be > the case, but it changed as a result of the LCD text loop work. It used > to be that AA used the alphafill field of SG2D and not the loops, and it > still does for most rendering. But now text rendering will almost > always go through the loops and it is only working because of that call > to getRenderLoops() in the constructor (and the fact that we never set > it back to null. > > I'd like to see invalidate() set the loops to null and see how far we > get - I'll bet that we'd get NPEs all over the place, especially with AA > rendering. > > In the long run, this is another straw on the camel's back as far as > rethinking the validation framework. It's been tweaked and hacked quite > a lot over the past 10 years and so there are a lot of issues that arise > like this that aren't readily obvious from the code. I don't think the > camel's back is broken yet, but it is becoming more and more confusing > for new engineers to start tinkering with it without seeing things break > from seemingly innocuous changes. :-( > > For now, I'm wary of removing that call without a lot of testing. I > think putting a "loops=null" line in invalidatePipe() might accelerate > some of that testing, though. > > And Phil might want to chime in with a description of the new > requirements on loops in light of the post-LCD text work... Phil? > > ...jim > > Mario Torre wrote: >> Il giorno lun, 15/06/2009 alle 13.37 -0700, Jim Graham ha scritto: >>> Hi Mario, >>> >>> How are the drawGlyphList methods called when the loops is null? I >>> ask because they are only ever installed on the SunGraphics2D object >>> by virtue of a call to validatePipe() and all calls to validatePipe() >>> should set the loops. So, there is a bug somewhere that causes these >>> loops to be installed without a full validate process. >> >> Hi Jim, >> >> So, I spent some time today (sorry for the delay, I had to find some >> free time slot for that and had to make a cake for my girl friend, which >> was the most difficult part :), and I debugged the Java2D demo with just >> the non initialised loops (so, no checks for null loops anywhere else in >> the code). >> >> The Demo starts fine, but after some point I get the error attached in >> this mail. >> >>> As I said in the email you quoted. All calls from pipelines >>> (GlyphListLoopPipe and AATextRenderer are both pipeline objects) >>> should be safe because all calls to validatePipe() should set the loops. >> >> I see that validatePipe is indeed called always, but sometimes the path >> that is chosen doesn't validate the rendering loop. I've seen that >> most of the time this is ok, because the loops are not used. >> >> I guess this is the case for all the various text rendering (LCD or AA) >> in swing components, for example (is this correct?). >> >>> Having said that I note that there are some pipelines that do not >>> require loops and it would be OK for a call to validate that only >>> uses such "non-loop-based" pipelines to leave the loops field >>> uninitialized, but all validate calls which use loop-based pipes must >>> update the loops field. >> >> Exactly. I'm not deep into the code yet to distinguish when they are >> needed or not, but... >> >>> Eliminating all of those uses of loops we then fall into the case >>> where the usage in checkFontInfo is the only usage that does not >>> occur from a pipeline... >> >> ...this is exactly the case, putting a null check here solves the NPE. >> >> For what I can see, at some point some component needs to paint to an >> offscreen surface (I don't think the offscreen surface is special, >> I think it's the application code that drives the bug, but anyway...). >> >> This is the background image from the Java2D Intro pane, I think the >> other pane do something similar. Once the SunGraphics2d object is >> created, >> some redering hints are set. This is the application code: >> >> g2.setRenderingHint(RenderingHints.KEY_ANTIALIASING, >> RenderingHints.VALUE_ANTIALIAS_ON); >> >> That is, turn on antialiasing, then: >> >> g2.clearRect(0, 0, d.width, d.height); >> >> Now what? This of course goes through validatePipe: >> >> The first two if/else statements fall through but not this >> (SurfaceData, line 535 in OpenJDK): >> >> } else if (sg2d.antialiasHint == SunHints.INTVAL_ANTIALIAS_ON) { >> >> This guy sets the pipes but doesn't set the RederingLoops. >> >> Then, again application code: >> >> scene.render(d.width, d.height, g2); >> >> Which after few loops finally renders the string on screen, >> which causes the crash. >> >> So, in other words, everything goes fine until we draw text with >> the AA redering hints turned on. >> >> Of course, before it was not failing because of the rendering loops >> were initialised in the constructor. >> >> I'm not sure if we need to check for a null loops at the beginning >> of validatePipe or in checkFontoInfo. Maybe we can save something if we >> use checkFontInfo but I'm not so sure. >> >> I hope this helps, >> Mario >> From Jim.A.Graham at Sun.COM Wed Jun 17 14:07:39 2009 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Wed, 17 Jun 2009 14:07:39 -0700 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <4A3946F6.2040902@sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> Message-ID: <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> I guess the thing that bothers me here is that the cases which "incidentally" rather than "intentionally" rely on the text loops may be using whatever text loops happened to have been installed by a prior validation pipeline, because they clearly are not installing any. If those pipelines can use a text loop then they need to "intentionally" install the right text loop rather than rely on whatever is already installed, otherwise the wrong rendering attributes (composite mode or paint type, etc.) may be used, no? So, doesn't this represent a (potential) bug which won't be fixed even if we do lazy initialization of the loops? I go back to my previous comment that perhaps what we need is for invalidatePipe to set the loops to null and then fix all the places where we were relying on "old loops" by setting them intentionally in the corresponding validate sequences... ...jim Phil Race wrote: > I don't think it is related to the LCD text work. I think it was the JDK > 7 b17 fix: > 6263951: Java does not use fast AA text loops when regular AA hint is set. > So there's a requirement that renderLoops is non-null in some case when > they would not previously have been used. > > -phil. > > Jim Graham wrote: >> Ah, I think I see the problem. Phil can chime in here if I'm wrong. >> >> Text now uses loops in most cases, but many of the validate methods >> assume that they don't need the loops. I don't think that used to be >> the case, but it changed as a result of the LCD text loop work. It >> used to be that AA used the alphafill field of SG2D and not the loops, >> and it still does for most rendering. But now text rendering will >> almost always go through the loops and it is only working because of >> that call to getRenderLoops() in the constructor (and the fact that we >> never set it back to null. >> >> I'd like to see invalidate() set the loops to null and see how far we >> get - I'll bet that we'd get NPEs all over the place, especially with >> AA rendering. >> >> In the long run, this is another straw on the camel's back as far as >> rethinking the validation framework. It's been tweaked and hacked >> quite a lot over the past 10 years and so there are a lot of issues >> that arise like this that aren't readily obvious from the code. I >> don't think the camel's back is broken yet, but it is becoming more >> and more confusing for new engineers to start tinkering with it >> without seeing things break from seemingly innocuous changes. :-( >> >> For now, I'm wary of removing that call without a lot of testing. I >> think putting a "loops=null" line in invalidatePipe() might accelerate >> some of that testing, though. >> >> And Phil might want to chime in with a description of the new >> requirements on loops in light of the post-LCD text work... Phil? >> >> ...jim From mario.torre at aicas.com Wed Jun 17 15:34:13 2009 From: mario.torre at aicas.com (Mario Torre) Date: Thu, 18 Jun 2009 00:34:13 +0200 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> Message-ID: <1245278053.3658.80.camel@localhost.localdomain> Il giorno mer, 17/06/2009 alle 14.07 -0700, Jim Graham ha scritto: > I go back to my previous comment that perhaps what we need is for > invalidatePipe to set the loops to null and then fix all the places > where we were relying on "old loops" by setting them intentionally in > the corresponding validate sequences... > I think the exceptions attached in my last mail are the two most obvious places to start, because the other pipes install a new loops via validatePipe(). But I'll debug it a little further and send you some updates asap. Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ From Roman.Kennke at Sun.COM Wed Jun 17 15:42:49 2009 From: Roman.Kennke at Sun.COM (Roman Kennke) Date: Wed, 17 Jun 2009 18:42:49 -0400 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> Message-ID: <4A397169.9010701@sun.com> Hi everybody, > I go back to my previous comment that perhaps what we need is for > invalidatePipe to set the loops to null and then fix all the places > where we were relying on "old loops" by setting them intentionally in > the corresponding validate sequences... I am completely in favour of that approach, even if it costs more time (after all, it's Mario's time in the end ;-) ). Relying on some more or less random old loop hanging around is asking for bugs, the subtle kind, those that eat up all your time when the next deadline is lurking around the corner... ;-) / Roman > > ...jim > > Phil Race wrote: >> I don't think it is related to the LCD text work. I think it was the >> JDK 7 b17 fix: >> 6263951: Java does not use fast AA text loops when regular AA hint is >> set. >> So there's a requirement that renderLoops is non-null in some case when >> they would not previously have been used. >> >> -phil. >> >> Jim Graham wrote: >>> Ah, I think I see the problem. Phil can chime in here if I'm wrong. >>> >>> Text now uses loops in most cases, but many of the validate methods >>> assume that they don't need the loops. I don't think that used to be >>> the case, but it changed as a result of the LCD text loop work. It >>> used to be that AA used the alphafill field of SG2D and not the >>> loops, and it still does for most rendering. But now text rendering >>> will almost always go through the loops and it is only working >>> because of that call to getRenderLoops() in the constructor (and the >>> fact that we never set it back to null. >>> >>> I'd like to see invalidate() set the loops to null and see how far we >>> get - I'll bet that we'd get NPEs all over the place, especially with >>> AA rendering. >>> >>> In the long run, this is another straw on the camel's back as far as >>> rethinking the validation framework. It's been tweaked and hacked >>> quite a lot over the past 10 years and so there are a lot of issues >>> that arise like this that aren't readily obvious from the code. I >>> don't think the camel's back is broken yet, but it is becoming more >>> and more confusing for new engineers to start tinkering with it >>> without seeing things break from seemingly innocuous changes. :-( >>> >>> For now, I'm wary of removing that call without a lot of testing. I >>> think putting a "loops=null" line in invalidatePipe() might >>> accelerate some of that testing, though. >>> >>> And Phil might want to chime in with a description of the new >>> requirements on loops in light of the post-LCD text work... Phil? >>> >>> ...jim From Roman.Kennke at Sun.COM Wed Jun 17 18:53:08 2009 From: Roman.Kennke at Sun.COM (Roman Kennke) Date: Wed, 17 Jun 2009 21:53:08 -0400 Subject: [OpenJDK 2D-Dev] [PATCH] FontManager refactoring, rev5 Message-ID: <1245289988.5082.5.camel@saturn> Finally I got back (with some post JavaOne pushing from Phil) to merging the newest stuff into my FontManager tree and here is the 5th revision of the FontManager refactoring patch: http://cr.openjdk.java.net/~rkennke/fontmanager/webrev.05/webrev/ I think I implemented all suggestions from previous cycles and tried to be careful to also merge in all the latest bugfixes and improvements in Font related code from JDK7. I have smoke tested it on Linux. To be honest, I am not sure if it works well on Windows, but now that I have a Windows machine I will try this as soon as possible, but I was thinking that since the Windows specific part is rather small, that we can get the review rolling in parallel. So here we go. Hey, do we actually already have a bug for this guy? /Roman From mario.torre at aicas.com Thu Jun 18 05:39:15 2009 From: mario.torre at aicas.com (Mario Torre) Date: Thu, 18 Jun 2009 14:39:15 +0200 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <1245278053.3658.80.camel@localhost.localdomain> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> <1245278053.3658.80.camel@localhost.localdomain> Message-ID: <1245328755.3609.26.camel@localhost.localdomain> Il giorno gio, 18/06/2009 alle 00.34 +0200, Mario Torre ha scritto: > But I'll debafterug it a little further and send you some updates asap. > > Cheers, > Mario Hello! The pipelines that use a loops after being invalidated without checking if it's valid or not (null) are those so far: LCDTextRenderer GlyphListLoopPipe AATextRenderer Those all are subclasses of GlyphListLoopPipe. The LCDTextRenderer never fails if I don't explicitly set to null the loops in invalidatePipe, same happens for instances of GlyphListLoopPipe which don't fail immediately as when I set the loops to null, so I think some of those calls use loops there were initialised somehow from validatePipe in some previous call to this method, but that should not be valid anymore. There are no other places where I get NPE, but I've tested only with the Java2D demo so far. Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ From Jim.A.Graham at Sun.COM Thu Jun 18 12:52:46 2009 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Thu, 18 Jun 2009 12:52:46 -0700 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <1245328755.3609.26.camel@localhost.localdomain> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> <1245278053.3658.80.camel@localhost.localdomain> <1245328755.3609.26.camel@localhost.localdomain> Message-ID: <0KLG008439VVTV60@fe-sfbay-10.sun.com> That makes a lot of sense since I think the introduction of the GlyphListLoopPipe in its current form was where the original methodology of "always install loops if you plan to use loops" was first (and only time) violated. I think I raised the issue at the time and Phil pointed out that, in practice, the loops never really change for a given surface type (as in, if a different compositing mode is set or if a non-color paint is set then we use entirely different mechanisms to render so the only loops that exist for these are "solid color" loops and those loops are always valid for all cases that use these pipes). While that may mean we don't have a practical bug yet, the weakness of that argument in general, and the desire to resolve the issue from the original bug report may mean we should revisit this practice. One solution would be to always set the loops for the validations that install one of these pipes. That could have potential performance impact, but it would be no worse than the validation sequences that already set the loops every time so I don't think it would be serious, or even measurable. Another solution could involve splitting these loops out into a separate structure that can be set once in the lifetime of an SG2D and then reused as appropriate. But this is banking on the "only one version of these loops really exists anyway" constraint and some day that constraint is likely to disappear and then we really will need to pick new loops on every validate. As such, I think I'd prefer the first solution - to just pick new loops every time they are needed (i.e. unless the pipeline really doesn't use the loops directly, or indirectly through these text pipes)... ...jim Mario Torre wrote: > Il giorno gio, 18/06/2009 alle 00.34 +0200, Mario Torre ha scritto: > >> But I'll debafterug it a little further and send you some updates asap. >> >> Cheers, >> Mario > > Hello! > > The pipelines that use a loops after being invalidated without checking > if it's valid or not (null) are those so far: > > LCDTextRenderer > GlyphListLoopPipe > AATextRenderer > > Those all are subclasses of GlyphListLoopPipe. > > The LCDTextRenderer never fails if I don't explicitly set to null the > loops in invalidatePipe, same happens for instances of GlyphListLoopPipe > which don't fail immediately as when I set the loops to null, so I think > some of those calls use loops there were initialised somehow from > validatePipe in some previous call to this method, but that should not > be valid anymore. > > There are no other places where I get NPE, but I've tested only with the > Java2D demo so far. > > Cheers, > Mario From Roman.Kennke at Sun.COM Thu Jun 18 13:01:05 2009 From: Roman.Kennke at Sun.COM (Roman Kennke) Date: Thu, 18 Jun 2009 16:01:05 -0400 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <0KLG008439VVTV60@fe-sfbay-10.sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> <1245278053.3658.80.camel@localhost.localdomain> <1245328755.3609.26.camel@localhost.localdomain> <0KLG008439VVTV60@fe-sfbay-10.sun.com> Message-ID: <4A3A9D01.8010105@sun.com> Hi Jim, If only one instance of the loops is used during the lifetime of a Surface, then we can easily keep this instance there instead of the SG2D, validating would not initialize any new objects, but only put stuff together that is already present in the SurfaceData anyway. Or did I get something wrong here? i / Roman Jim Graham wrote: > That makes a lot of sense since I think the introduction of the > GlyphListLoopPipe in its current form was where the original methodology > of "always install loops if you plan to use loops" was first (and only > time) violated. > > I think I raised the issue at the time and Phil pointed out that, in > practice, the loops never really change for a given surface type (as in, > if a different compositing mode is set or if a non-color paint is set > then we use entirely different mechanisms to render so the only loops > that exist for these are "solid color" loops and those loops are always > valid for all cases that use these pipes). > > While that may mean we don't have a practical bug yet, the weakness of > that argument in general, and the desire to resolve the issue from the > original bug report may mean we should revisit this practice. > > One solution would be to always set the loops for the validations that > install one of these pipes. That could have potential performance > impact, but it would be no worse than the validation sequences that > already set the loops every time so I don't think it would be serious, > or even measurable. > > Another solution could involve splitting these loops out into a separate > structure that can be set once in the lifetime of an SG2D and then > reused as appropriate. But this is banking on the "only one version of > these loops really exists anyway" constraint and some day that > constraint is likely to disappear and then we really will need to pick > new loops on every validate. > > As such, I think I'd prefer the first solution - to just pick new loops > every time they are needed (i.e. unless the pipeline really doesn't use > the loops directly, or indirectly through these text pipes)... > > ...jim > > Mario Torre wrote: >> Il giorno gio, 18/06/2009 alle 00.34 +0200, Mario Torre ha scritto: >> >>> But I'll debafterug it a little further and send you some updates asap. >>> >>> Cheers, >>> Mario >> >> Hello! >> >> The pipelines that use a loops after being invalidated without checking >> if it's valid or not (null) are those so far: >> >> LCDTextRenderer >> GlyphListLoopPipe >> AATextRenderer >> >> Those all are subclasses of GlyphListLoopPipe. >> >> The LCDTextRenderer never fails if I don't explicitly set to null the >> loops in invalidatePipe, same happens for instances of GlyphListLoopPipe >> which don't fail immediately as when I set the loops to null, so I think >> some of those calls use loops there were initialised somehow from >> validatePipe in some previous call to this method, but that should not >> be valid anymore. >> >> There are no other places where I get NPE, but I've tested only with the >> Java2D demo so far. >> >> Cheers, >> Mario From mario.torre at aicas.com Thu Jun 18 14:28:41 2009 From: mario.torre at aicas.com (Mario Torre) Date: Thu, 18 Jun 2009 23:28:41 +0200 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <4A3A9D01.8010105@sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> <1245278053.3658.80.camel@localhost.localdomain> <1245328755.3609.26.camel@localhost.localdomain> <0KLG008439VVTV60@fe-sfbay-10.sun.com> <4A3A9D01.8010105@sun.com> Message-ID: <1245360521.3662.8.camel@localhost.localdomain> Il giorno gio, 18/06/2009 alle 16.01 -0400, Roman Kennke ha scritto: > Hi Jim, > > If only one instance of the loops is used during the lifetime of a > Surface, then we can easily keep this instance there instead of the > SG2D, validating would not initialize any new objects, but only put > stuff together that is already present in the SurfaceData anyway. Or did > I get something wrong here? > i This make sense, because we can initialise the loops in one place and live with them. If things will change, there will be no risk to forget because the whole thing is in one single place now and has no extra dependencies anymore, but from what I see the loops are always the same from a practical point of view (but I'll check this a bit better just in case). I like both this and the first approach proposed by Jim, so is up to you to decide what to do :) Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ From Roman.Kennke at Sun.COM Thu Jun 18 14:36:16 2009 From: Roman.Kennke at Sun.COM (Roman Kennke) Date: Thu, 18 Jun 2009 17:36:16 -0400 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <1245360521.3662.8.camel@localhost.localdomain> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> <1245278053.3658.80.camel@localhost.localdomain> <1245328755.3609.26.camel@localhost.localdomain> <0KLG008439VVTV60@fe-sfbay-10.sun.com> <4A3A9D01.8010105@sun.com> <1245360521.3662.8.camel@localhost.localdomain> Message-ID: <4A3AB350.5090703@sun.com> Hi folks, The thing is, it might be the case that we only have one loops thing in the pipelines we have in OpenJDK, but thanks to Cacio (hohum) we must consider that there are other implementations out there... which might want to take completely different approaches. So better to keep it clean and nice and not make any assumptions. Right? / Roman Mario Torre wrote: > Il giorno gio, 18/06/2009 alle 16.01 -0400, Roman Kennke ha scritto: >> Hi Jim, >> >> If only one instance of the loops is used during the lifetime of a >> Surface, then we can easily keep this instance there instead of the >> SG2D, validating would not initialize any new objects, but only put >> stuff together that is already present in the SurfaceData anyway. Or did >> I get something wrong here? >> i > > This make sense, because we can initialise the loops in one place and > live with them. If things will change, there will be no risk to forget > because the whole thing is in one single place now and has no extra > dependencies anymore, but from what I see the loops are always the same > from a practical point of view (but I'll check this a bit better just in > case). > > I like both this and the first approach proposed by Jim, so is up to you > to decide what to do :) > > Cheers, > Mario From mario.torre at aicas.com Thu Jun 18 14:51:34 2009 From: mario.torre at aicas.com (Mario Torre) Date: Thu, 18 Jun 2009 23:51:34 +0200 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <4A3AB350.5090703@sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> <1245278053.3658.80.camel@localhost.localdomain> <1245328755.3609.26.camel@localhost.localdomain> <0KLG008439VVTV60@fe-sfbay-10.sun.com> <4A3A9D01.8010105@sun.com> <1245360521.3662.8.camel@localhost.localdomain> <4A3AB350.5090703@sun.com> Message-ID: <1245361894.3662.11.camel@localhost.localdomain> Il giorno gio, 18/06/2009 alle 17.36 -0400, Roman Kennke ha scritto: > Hi folks, > > The thing is, it might be the case that we only have one loops thing in > the pipelines we have in OpenJDK, but thanks to Cacio (hohum) we must > consider that there are other implementations out there... which might > want to take completely different approaches. So better to keep it clean > and nice and not make any assumptions. Right? > > / Roman Well, if we specify the behaviour should be ok. Actually I'm not sure about the best way to go, at this point validate/invalidate may make more sense. Have to think a bit more on that... Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ From Phil.Race at Sun.COM Thu Jun 18 14:55:13 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Thu, 18 Jun 2009 14:55:13 -0700 Subject: [OpenJDK 2D-Dev] [PATCH] FontManager refactoring, rev5 In-Reply-To: <1245289988.5082.5.camel@saturn> References: <1245289988.5082.5.camel@saturn> Message-ID: <4A3AB7C1.2060008@sun.com> Roman, Looks close. Just a few comments. you aren't using these import in sun.font.FontManager : 30 import java.util.Locale; 31 import java.util.TreeMap; 32 33 import javax.swing.plaf.FontUIResource; There may be other such cases but its easy to see in this much reduced file. SunGraphicsEnvironment.java 173 assert fm instanceof FontManagerForSGE; 174 return (FontManagerForSGE) fm; I don't see the point of the assert here because the cast is going to tell you if there's a problem whether asserts are on or not. SharedSecrets.java I think you can restore the empty line (115) you deleted and remove this file from the webrev. FcFontConfiguration.java you aren't using the "fm" instance so can remove that line : 331 SunFontManager fm = SunFontManager.getInstance(); 332 if (FontUtilities.debugFonts()) { 333 Logger logger = Logger.getLogger("sun.awt.FontConfiguration"); 334 logger.warning("Exception identifying Linux distro."); 335 } 336 } 337 } WPathGraphics.java I see you moved the definition of textLayoutIsCompatible in here. Whilst its used only by this code, its also meaning that updating that font internal code in the future will affect the printing code. And the getDirectoryEntry() method isn't public so I'm not sure how this will work! Ah, I just remembered you said you didn't test on windows yet. Puzzlement over, this won't build. I'd prefer this to go back to TrueTypeFont. Clearly you need to get that windows build tested before you push. You don't need to set up a windows machine, you can submit a jprt job now that you have SWAN access. -Phil. Roman Kennke wrote: > Finally I got back (with some post JavaOne pushing from Phil) to merging > the newest stuff into my FontManager tree and here is the 5th revision > of the FontManager refactoring patch: > > http://cr.openjdk.java.net/~rkennke/fontmanager/webrev.05/webrev/ > > I think I implemented all suggestions from previous cycles and tried to > be careful to also merge in all the latest bugfixes and improvements in > Font related code from JDK7. I have smoke tested it on Linux. To be > honest, I am not sure if it works well on Windows, but now that I have a > Windows machine I will try this as soon as possible, but I was thinking > that since the Windows specific part is rather small, that we can get > the review rolling in parallel. So here we go. > > Hey, do we actually already have a bug for this guy? > > /Roman > > From Jim.A.Graham at Sun.COM Thu Jun 18 15:41:50 2009 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Thu, 18 Jun 2009 15:41:50 -0700 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <4A3A9D01.8010105@sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> <1245278053.3658.80.camel@localhost.localdomain> <1245328755.3609.26.camel@localhost.localdomain> <0KLG008439VVTV60@fe-sfbay-10.sun.com> <4A3A9D01.8010105@sun.com> Message-ID: <0KLG002JBHPN75G0@fe-sfbay-10.sun.com> Whoops! I abbreviated and sent you off on a wild goose chase. There are many different loops! There just happen to be (I think!?) only 1 kind of *TEXT* loop in the system for a given surface. I left out that qualifier below and misdirected you. Thus, if the text loops were split out then it "may be" that they can be created once per SurfaceData, but that is definitely *NOT* true of the other loops that reside in the RenderLoops, and it may not be true of the text loops in the future, it just happens to be "probably" true for text loops for now... ...jim Roman Kennke wrote: > Hi Jim, > > If only one instance of the loops is used during the lifetime of a > Surface, then we can easily keep this instance there instead of the > SG2D, validating would not initialize any new objects, but only put > stuff together that is already present in the SurfaceData anyway. Or did > I get something wrong here? > i > / Roman > > Jim Graham wrote: >> That makes a lot of sense since I think the introduction of the >> GlyphListLoopPipe in its current form was where the original >> methodology of "always install loops if you plan to use loops" was >> first (and only time) violated. >> >> I think I raised the issue at the time and Phil pointed out that, in >> practice, the loops never really change for a given surface type (as >> in, if a different compositing mode is set or if a non-color paint is >> set then we use entirely different mechanisms to render so the only >> loops that exist for these are "solid color" loops and those loops are >> always valid for all cases that use these pipes). >> >> While that may mean we don't have a practical bug yet, the weakness of >> that argument in general, and the desire to resolve the issue from the >> original bug report may mean we should revisit this practice. >> >> One solution would be to always set the loops for the validations that >> install one of these pipes. That could have potential performance >> impact, but it would be no worse than the validation sequences that >> already set the loops every time so I don't think it would be serious, >> or even measurable. >> >> Another solution could involve splitting these loops out into a >> separate structure that can be set once in the lifetime of an SG2D and >> then reused as appropriate. But this is banking on the "only one >> version of these loops really exists anyway" constraint and some day >> that constraint is likely to disappear and then we really will need to >> pick new loops on every validate. >> >> As such, I think I'd prefer the first solution - to just pick new >> loops every time they are needed (i.e. unless the pipeline really >> doesn't use the loops directly, or indirectly through these text >> pipes)... >> >> ...jim >> >> Mario Torre wrote: >>> Il giorno gio, 18/06/2009 alle 00.34 +0200, Mario Torre ha scritto: >>> >>>> But I'll debafterug it a little further and send you some updates asap. >>>> >>>> Cheers, >>>> Mario >>> >>> Hello! >>> >>> The pipelines that use a loops after being invalidated without checking >>> if it's valid or not (null) are those so far: >>> >>> LCDTextRenderer >>> GlyphListLoopPipe >>> AATextRenderer >>> >>> Those all are subclasses of GlyphListLoopPipe. >>> >>> The LCDTextRenderer never fails if I don't explicitly set to null the >>> loops in invalidatePipe, same happens for instances of GlyphListLoopPipe >>> which don't fail immediately as when I set the loops to null, so I think >>> some of those calls use loops there were initialised somehow from >>> validatePipe in some previous call to this method, but that should not >>> be valid anymore. >>> >>> There are no other places where I get NPE, but I've tested only with the >>> Java2D demo so far. >>> >>> Cheers, >>> Mario > From jennifer.godinez at sun.com Mon Jun 22 10:12:07 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Mon, 22 Jun 2009 17:12:07 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6850398: Allow GraphicsEnvironment to be loaded by system classloader (edit) Message-ID: <20090622171232.89F6CEE39@hg.openjdk.java.net> Changeset: 70903e2c39e3 Author: jgodinez Date: 2009-06-22 09:47 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/70903e2c39e3 6850398: Allow GraphicsEnvironment to be loaded by system classloader (edit) Reviewed-by: campbell, prr ! src/share/classes/java/awt/GraphicsEnvironment.java From mario.torre at aicas.com Mon Jun 22 13:02:35 2009 From: mario.torre at aicas.com (Mario Torre) Date: Mon, 22 Jun 2009 22:02:35 +0200 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <0KLG008439VVTV60@fe-sfbay-10.sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> <1245278053.3658.80.camel@localhost.localdomain> <1245328755.3609.26.camel@localhost.localdomain> <0KLG008439VVTV60@fe-sfbay-10.sun.com> Message-ID: <4A3FE35B.3030701@aicas.com> Il 18/06/2009 21:52, Jim Graham ha scritto: > One solution would be to always set the loops for the validations that > install one of these pipes. That could have potential performance > impact, but it would be no worse than the validation sequences that > already set the loops every time so I don't think it would be serious, > or even measurable. Hi Jim, I'm trying this approach. Basically, I just set the loops to null now in invalidate and validate them back in validatePipe: http://cr.openjdk.java.net/~neugens/100068/webrev.03/ What I do is to get valid Loops when we call getTextPipe, but other than that, the behavior is basically unchanged. I tried with various applications, including NetBeans, the Java2D demo and the FontTest app, playing around with the text configurations (AA, LCD, size, Glyphs etc.. even output to a PNG file) and looks good, but I may miss something of course. I moved to a 64 bit machine, I don't think this makes any difference in this case, but maybe it's a good thing to say. I would like to see a method in the pipelines that does something like: boolean mustInitialiseLoopsBecauseWeReallyWantToUseThemGranted() or so, that we may call at the end of the validatePipe method, but when I tried this I got a funny StackOverflowException, maybe I did something wrong, but looks like it's not so easy to change this code and still make it behave correctly, so I would like to go deeper in this issue even if you think we can close the bug (of course if the proposed fix is evaluated as complete). Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ From phil.race at sun.com Mon Jun 22 14:19:22 2009 From: phil.race at sun.com (phil.race at sun.com) Date: Mon, 22 Jun 2009 21:19:22 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6853617: race condition in java.awt.Font.getAttributes() (private method) Message-ID: <20090622211934.B69A5EEAB@hg.openjdk.java.net> Changeset: fafa991c27ac Author: prr Date: 2009-06-22 14:10 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/fafa991c27ac 6853617: race condition in java.awt.Font.getAttributes() (private method) Reviewed-by: igor, jgodinez ! src/share/classes/java/awt/Font.java From Jim.A.Graham at Sun.COM Mon Jun 22 16:47:17 2009 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Mon, 22 Jun 2009 16:47:17 -0700 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <4A3FE35B.3030701@aicas.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> <1245278053.3658.80.camel@localhost.localdomain> <1245328755.3609.26.camel@localhost.localdomain> <0KLG008439VVTV60@fe-sfbay-10.sun.com> <4A3FE35B.3030701@aicas.com> Message-ID: <0KLN0010AZEI8L30@fe-sfbay-10.sun.com> Hi Mario, The changes look safe, but I wanted to bring up the following issues: - There are a dozen or so fields in SG2D that are commonly accessed everywhere in the pipelines including loops. These changes introduce an accessor for loops, but that now looks out of place with no accessors for any of the other fields that get accessed directly. Personally the lack of accessors hasn't bothered me, particularly since this is performance sensitive code and accessors can sap performance by nickels and dimes if you don't implement them correctly - to wit: - Accessors can be inlined if they are final, but these aren't. As it turns out, SG2D itself is final and so I believe that is enough for them to be inlined, but I tend to make methods final as well to underscore that they are intended to be inlined, and also in case we eventually decide to make the class non-final. On the other hand, we haven't really bothered with accessors in the first place in this code to avoid the code bloat and the potential points of heuristic failure. - I agree that it would be nice to ask the pipes if they need loops, I'm not sure why your solution didn't work, but I prefer that to making them a side effect of getTextPipe() since it makes it harder to know when the code you are editing needs to get the loops or not, and it makes it hard to see where they come from when editing the many validatePipe() methods. ...jim Mario Torre wrote: > Il 18/06/2009 21:52, Jim Graham ha scritto: > >> One solution would be to always set the loops for the validations that >> install one of these pipes. That could have potential performance >> impact, but it would be no worse than the validation sequences that >> already set the loops every time so I don't think it would be serious, >> or even measurable. > > Hi Jim, > > I'm trying this approach. > > Basically, I just set the loops to null now in invalidate and validate > them back in validatePipe: > > http://cr.openjdk.java.net/~neugens/100068/webrev.03/ > > What I do is to get valid Loops when we call getTextPipe, but other than > that, the behavior is basically unchanged. I tried with various > applications, including NetBeans, the Java2D demo and the FontTest app, > playing around with the text configurations (AA, LCD, size, Glyphs etc.. > even output to a PNG file) and looks good, but I may miss something of > course. > > I moved to a 64 bit machine, I don't think this makes any difference in > this case, but maybe it's a good thing to say. > > I would like to see a method in the pipelines that does something like: > > boolean mustInitialiseLoopsBecauseWeReallyWantToUseThemGranted() > > or so, that we may call at the end of the validatePipe method, but when > I tried this I got a funny StackOverflowException, maybe I did something > wrong, but looks like it's not so easy to change this code and still > make it behave correctly, so I would like to go deeper in this issue > even if you think we can close the bug (of course if the proposed fix is > evaluated as complete). > > Cheers, > Mario From linuxhippy at gmail.com Tue Jun 23 03:41:16 2009 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 23 Jun 2009 06:41:16 -0400 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <0KLN0010AZEI8L30@fe-sfbay-10.sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> <1245278053.3658.80.camel@localhost.localdomain> <1245328755.3609.26.camel@localhost.localdomain> <0KLG008439VVTV60@fe-sfbay-10.sun.com> <4A3FE35B.3030701@aicas.com> <0KLN0010AZEI8L30@fe-sfbay-10.sun.com> Message-ID: <194f62550906230341q405547d0r4e9756604e777201@mail.gmail.com> Hi, > - Accessors can be inlined if they are final, but these aren't. ?As it turns > out, SG2D itself is final and so I believe that is enough for them to be > inlined, but I tend to make methods final as well to underscore that they > are intended to be inlined, and also in case we eventually decide to make > the class non-final. The client-compiler can inline virtual methods since 1.4, however it inserts a conditional to trap if the target is not of the expected type - so setting stuff final at least can't hurt ;) I really hope tiered compiulation will make it into Java7. - Clemens From mario.torre at aicas.com Tue Jun 23 05:31:43 2009 From: mario.torre at aicas.com (Mario Torre) Date: Tue, 23 Jun 2009 14:31:43 +0200 Subject: [OpenJDK 2D-Dev] _LITTLE_ENDIAN Message-ID: <4A40CB2F.6000208@aicas.com> Hello all! I have a problem with a block of code that checks if _LITTLE_ENDIAN is defined, the code is in little cms and looks like: #ifndef _LITTLE_ENDIAN #define USE_BIG_ENDIAN 1 #endif The issue that I have is that on VxWorks, the target I'm working on, there is always a definition of _LITTLE_ENDIAN, just the value change in case of big/little endiannes, and this in my case ends up conflicting with the code in the JDK. I started to replace all the _LITTLE_ENDIAN to be OPENJDK_LITTLE_ENDIAN, and as I think this is nice to have in OpenJDK and will improve portability, I would like to discuss the issue with whoever is interested (cc some mailing list here, sorry for cross posting). Other occurrences of the _LITTLE_ENDIAN define are: jdk/src/share/native/sun/awt/medialib/mlib* jdk/src/share/native/com/sun/media/sound/ jdk/src/solaris/native/sun/java2d/loops/ plus some other little places. I need to prepare a patch for that, but before I would like to have some suggestion or if you are not interested at all, I'll just fix the specific code that we use and not care about all the references. Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ From aph at redhat.com Tue Jun 23 08:52:39 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 23 Jun 2009 16:52:39 +0100 Subject: [OpenJDK 2D-Dev] _LITTLE_ENDIAN In-Reply-To: <4A40CB2F.6000208@aicas.com> References: <4A40CB2F.6000208@aicas.com> Message-ID: <4A40FA47.3000505@redhat.com> Mario Torre wrote: > Hello all! > > I have a problem with a block of code that checks if _LITTLE_ENDIAN is > defined, the code is in little cms and looks like: > > #ifndef _LITTLE_ENDIAN > #define USE_BIG_ENDIAN 1 > #endif > > The issue that I have is that on VxWorks, the target I'm working on, > there is always a definition of _LITTLE_ENDIAN, just the value change in > case of big/little endiannes, and this in my case ends up conflicting > with the code in the JDK. > > I started to replace all the _LITTLE_ENDIAN to be OPENJDK_LITTLE_ENDIAN, > and as I think this is nice to have in OpenJDK and will improve > portability, I would like to discuss the issue with whoever is > interested (cc some mailing list here, sorry for cross posting). > > Other occurrences of the _LITTLE_ENDIAN define are: > > jdk/src/share/native/sun/awt/medialib/mlib* > jdk/src/share/native/com/sun/media/sound/ > jdk/src/solaris/native/sun/java2d/loops/ > > plus some other little places. > > I need to prepare a patch for that, but before I would like to have some > suggestion or if you are not interested at all, I'll just fix the > specific code that we use and not care about all the references. I guess it all depends on how _LITTLE_ENDIAN is commonly defined. It'd be a lot easier just to replace #ifndef _LITTLE_ENDIAN with #if ! _LITTLE_ENDIAN if that's possible. Andrew. From Jennifer.Godinez at Sun.COM Tue Jun 23 09:40:30 2009 From: Jennifer.Godinez at Sun.COM (Jennifer Godinez) Date: Tue, 23 Jun 2009 09:40:30 -0700 Subject: [OpenJDK 2D-Dev] upcoming 2d JDK 7 integration In-Reply-To: <4A3290D3.4080202@sun.com> References: <4A3290D3.4080202@sun.com> Message-ID: <4A41057E.5020204@Sun.COM> Reminder that we will have a code freeze at 5 PM today. Jennifer Jennifer Godinez wrote: > Just a heads-up that 2D will integrate on 6/30th for b63 . Please plan > to put your fixes before the code freeze which is 6/23rd, 5 PM. > > Thank you. > > Jennifer > > From Kelly.Ohair at Sun.COM Tue Jun 23 13:27:01 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 23 Jun 2009 13:27:01 -0700 Subject: [OpenJDK 2D-Dev] _LITTLE_ENDIAN In-Reply-To: <4A40CB2F.6000208@aicas.com> References: <4A40CB2F.6000208@aicas.com> Message-ID: <4A413A95.2040303@sun.com> Mario Torre wrote: > Hello all! > > I have a problem with a block of code that checks if _LITTLE_ENDIAN is > defined, the code is in little cms and looks like: > > #ifndef _LITTLE_ENDIAN > #define USE_BIG_ENDIAN 1 > #endif > > The issue that I have is that on VxWorks, the target I'm working on, > there is always a definition of _LITTLE_ENDIAN, just the value change in > case of big/little endiannes, and this in my case ends up conflicting > with the code in the JDK. So let me get this straight, _LITTLE_ENDIAN is "always" defined, even when it is not "little endian"? That sure seems problematic to me. I suspect this issue will continue to be trouble because it is so easy to just #ifdef _LITTLE_ENDIAN. Can we just have the makefiles define _BIG_ENDIAN on the appropriate machines, and have big consume little if both are set? -kto > > I started to replace all the _LITTLE_ENDIAN to be OPENJDK_LITTLE_ENDIAN, > and as I think this is nice to have in OpenJDK and will improve > portability, I would like to discuss the issue with whoever is > interested (cc some mailing list here, sorry for cross posting). > > Other occurrences of the _LITTLE_ENDIAN define are: > > jdk/src/share/native/sun/awt/medialib/mlib* > jdk/src/share/native/com/sun/media/sound/ > jdk/src/solaris/native/sun/java2d/loops/ > > plus some other little places. > > I need to prepare a patch for that, but before I would like to have some > suggestion or if you are not interested at all, I'll just fix the > specific code that we use and not care about all the references. Since VxWorks seems to be the problematic platform, I would rather see the code that made _BIG_ENDIAN explicit, and it's definition take priority, e.g. #if defined(_BIG_ENDIAN) #elif defined(_LITTLE_ENDIAN) #endif For better or worse, there seems to be ./common/Defs-linux.gmk:CFLAGS_REQUIRED_amd64 += -fno-omit-frame-pointer -D_LITTLE_ENDIAN ./common/Defs-linux.gmk:CFLAGS_REQUIRED_i586 += -fno-omit-frame-pointer -D_LITTLE_ENDIAN ./common/Defs-linux.gmk:CFLAGS_REQUIRED_ia64 += -fno-omit-frame-pointer -D_LITTLE_ENDIAN ./common/Defs-solaris.gmk: # The macro _LITTLE_ENDIAN needs to be defined the same to avoid the ./common/Defs-solaris.gmk: # Sun C compiler warning message: warning: macro redefined: _LITTLE_ENDIAN ./common/Defs-solaris.gmk: CPPFLAGS_COMMON += -DcpuIntel -D_LITTLE_ENDIAN= -D$(LIBARCH) ./common/Defs-windows.gmk:CPPFLAGS_COMMON = -DWIN32 -DIAL -D_LITTLE_ENDIAN ./netbeans/awt2d/README: D3D_OVERLOADS; UNICODE; _UNICODE; WIN32; IAL; _LITTLE_ENDIAN; WIN32; _X86_; That documents the issue -kto > > Cheers, > Mario From Roman.Kennke at Sun.COM Tue Jun 23 14:27:57 2009 From: Roman.Kennke at Sun.COM (Roman Kennke) Date: Tue, 23 Jun 2009 23:27:57 +0200 Subject: [OpenJDK 2D-Dev] _LITTLE_ENDIAN In-Reply-To: <4A413A95.2040303@sun.com> References: <4A40CB2F.6000208@aicas.com> <4A413A95.2040303@sun.com> Message-ID: <4A4148DD.9090307@sun.com> Hi, first of all, I think this is a LCMS problem, so we should think about how to fix this _upstream_, otherwise we end up maintaining a patched version of lcms *shudder*. Then I don't think it's a good idea to depend on such 'internal' defines. One OS defines or not _LITTLE_ENDIAN, others (like VxWorks) define it either as 0 or 1, depending on the systems, even others don't care and define __LITTLE_ENDIAN or whatever. IMO, a better way to solve this is to make LCMS check LCMS_LITTLE_ENDIAN, and define it somewhere. Configure based builds would figure this out when running configure. OpenJDK would set this in the files mentioned below, instead of setting _LITTLE_ENDIAN. AFAICS, this is the only way to make sure we don't conflict with any internal settings of some OS include or compiler. > For better or worse, there seems to be > ./common/Defs-linux.gmk:CFLAGS_REQUIRED_amd64 += > -fno-omit-frame-pointer -D_LITTLE_ENDIAN > ./common/Defs-linux.gmk:CFLAGS_REQUIRED_i586 += > -fno-omit-frame-pointer -D_LITTLE_ENDIAN > ./common/Defs-linux.gmk:CFLAGS_REQUIRED_ia64 += > -fno-omit-frame-pointer -D_LITTLE_ENDIAN > ./common/Defs-solaris.gmk: # The macro _LITTLE_ENDIAN needs to be > defined the same to avoid the > ./common/Defs-solaris.gmk: # Sun C compiler warning message: warning: > macro redefined: _LITTLE_ENDIAN > ./common/Defs-solaris.gmk: CPPFLAGS_COMMON += -DcpuIntel > -D_LITTLE_ENDIAN= -D$(LIBARCH) > ./common/Defs-windows.gmk:CPPFLAGS_COMMON = -DWIN32 -DIAL -D_LITTLE_ENDIAN > ./netbeans/awt2d/README: D3D_OVERLOADS; UNICODE; _UNICODE; WIN32; > IAL; _LITTLE_ENDIAN; WIN32; _X86_; /Roman From Phil.Race at Sun.COM Tue Jun 23 14:37:59 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 23 Jun 2009 14:37:59 -0700 Subject: [OpenJDK 2D-Dev] _LITTLE_ENDIAN In-Reply-To: <4A4148DD.9090307@sun.com> References: <4A40CB2F.6000208@aicas.com> <4A413A95.2040303@sun.com> <4A4148DD.9090307@sun.com> Message-ID: <4A414B37.6070009@sun.com> Roman Kennke wrote: > Hi, > > first of all, I think this is a LCMS problem, so we should think about > how to fix this _upstream_, otherwise we end up maintaining a patched > version of lcms *shudder*. But I see only that in the lcms.h file. And it is protected inside #if macintosh so I can't believe Mario is hitting this ? #if macintosh # ifndef __LITTLE_ENDIAN__ # define USE_BIG_ENDIAN 1 # endif #endif Ah, everyone must be looking at the old (1.16) lcms that we replaced quite a few builds ago. It didn't have the #if macintosh But since at some point (when lcms 2 is out), we'd enable using the platform version, then modifying this copy isn't going to help even if its needed. But in addition I see it *used* in LCMS.c (2D glue code to LCMS), where its relying on this being defined in the make files (make/common/Defs-linux.gmk etc) as cited below as are a good number of other places in the JDK sources as Mario noted. If its really just that then making that test more sophisticated (Vxworks aware) might be OK. I think its going to be painful to change all the rest and most of those as most are in medialib code, and that's from another group in Sun and I presume followed the conventions of what's in the Solaris header files. -phil. > > Then I don't think it's a good idea to depend on such 'internal' > defines. One OS defines or not _LITTLE_ENDIAN, others (like VxWorks) > define it either as 0 or 1, depending on the systems, even others don't > care and define __LITTLE_ENDIAN or whatever. IMO, a better way to solve > this is to make LCMS check LCMS_LITTLE_ENDIAN, and define it somewhere. > Configure based builds would figure this out when running configure. > OpenJDK would set this in the files mentioned below, instead of setting > _LITTLE_ENDIAN. AFAICS, this is the only way to make sure we don't > conflict with any internal settings of some OS include or compiler. > >> For better or worse, there seems to be >> ./common/Defs-linux.gmk:CFLAGS_REQUIRED_amd64 += >> -fno-omit-frame-pointer -D_LITTLE_ENDIAN >> ./common/Defs-linux.gmk:CFLAGS_REQUIRED_i586 += >> -fno-omit-frame-pointer -D_LITTLE_ENDIAN >> ./common/Defs-linux.gmk:CFLAGS_REQUIRED_ia64 += >> -fno-omit-frame-pointer -D_LITTLE_ENDIAN >> ./common/Defs-solaris.gmk: # The macro _LITTLE_ENDIAN needs to be >> defined the same to avoid the >> ./common/Defs-solaris.gmk: # Sun C compiler warning message: >> warning: macro redefined: _LITTLE_ENDIAN >> ./common/Defs-solaris.gmk: CPPFLAGS_COMMON += -DcpuIntel >> -D_LITTLE_ENDIAN= -D$(LIBARCH) >> ./common/Defs-windows.gmk:CPPFLAGS_COMMON = -DWIN32 -DIAL >> -D_LITTLE_ENDIAN >> ./netbeans/awt2d/README: D3D_OVERLOADS; UNICODE; _UNICODE; WIN32; >> IAL; _LITTLE_ENDIAN; WIN32; _X86_; > > > /Roman From Kelly.Ohair at Sun.COM Tue Jun 23 14:46:36 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 23 Jun 2009 14:46:36 -0700 Subject: [OpenJDK 2D-Dev] _LITTLE_ENDIAN In-Reply-To: <4A4148DD.9090307@sun.com> References: <4A40CB2F.6000208@aicas.com> <4A413A95.2040303@sun.com> <4A4148DD.9090307@sun.com> Message-ID: <4A414D3C.2050101@sun.com> Someone would need to make darn sure that ALL uses of the old name have been changed. I counted 362 references to this variable in the openjdk7 repositories, I assume a similar number in openjdk6. The closed jdk sources have an additional 13 references to this _LITTLE_ENDIAN name Sun would need to change too. Do you really want to change 362+ lines for this name change? -kto Roman Kennke wrote: > Hi, > > first of all, I think this is a LCMS problem, so we should think about > how to fix this _upstream_, otherwise we end up maintaining a patched > version of lcms *shudder*. > > Then I don't think it's a good idea to depend on such 'internal' > defines. One OS defines or not _LITTLE_ENDIAN, others (like VxWorks) > define it either as 0 or 1, depending on the systems, even others don't > care and define __LITTLE_ENDIAN or whatever. IMO, a better way to solve > this is to make LCMS check LCMS_LITTLE_ENDIAN, and define it somewhere. > Configure based builds would figure this out when running configure. > OpenJDK would set this in the files mentioned below, instead of setting > _LITTLE_ENDIAN. AFAICS, this is the only way to make sure we don't > conflict with any internal settings of some OS include or compiler. > >> For better or worse, there seems to be >> ./common/Defs-linux.gmk:CFLAGS_REQUIRED_amd64 += >> -fno-omit-frame-pointer -D_LITTLE_ENDIAN >> ./common/Defs-linux.gmk:CFLAGS_REQUIRED_i586 += >> -fno-omit-frame-pointer -D_LITTLE_ENDIAN >> ./common/Defs-linux.gmk:CFLAGS_REQUIRED_ia64 += >> -fno-omit-frame-pointer -D_LITTLE_ENDIAN >> ./common/Defs-solaris.gmk: # The macro _LITTLE_ENDIAN needs to be >> defined the same to avoid the >> ./common/Defs-solaris.gmk: # Sun C compiler warning message: >> warning: macro redefined: _LITTLE_ENDIAN >> ./common/Defs-solaris.gmk: CPPFLAGS_COMMON += -DcpuIntel >> -D_LITTLE_ENDIAN= -D$(LIBARCH) >> ./common/Defs-windows.gmk:CPPFLAGS_COMMON = -DWIN32 -DIAL >> -D_LITTLE_ENDIAN >> ./netbeans/awt2d/README: D3D_OVERLOADS; UNICODE; _UNICODE; WIN32; >> IAL; _LITTLE_ENDIAN; WIN32; _X86_; > > > /Roman From Roman.Kennke at Sun.COM Tue Jun 23 14:51:00 2009 From: Roman.Kennke at Sun.COM (Roman Kennke) Date: Tue, 23 Jun 2009 23:51:00 +0200 Subject: [OpenJDK 2D-Dev] _LITTLE_ENDIAN In-Reply-To: <4A414D3C.2050101@sun.com> References: <4A40CB2F.6000208@aicas.com> <4A413A95.2040303@sun.com> <4A4148DD.9090307@sun.com> <4A414D3C.2050101@sun.com> Message-ID: <4A414E44.1020007@sun.com> Hi, > Someone would need to make darn sure that ALL uses of the old > name have been changed. I counted 362 references to this variable > in the openjdk7 repositories, I assume a similar number in openjdk6. > The closed jdk sources have an additional 13 references to this > _LITTLE_ENDIAN name Sun would need to change too. > > Do you really want to change 362+ lines for this name change? Surely not. I haven't counted and I blindly assumed we talk about lcms only here. Sorry. In this case I would revert to #undef _LITTLE_ENDIAN or -U_LITTLE_ENDIAN on platforms that do crazy stuff. No code changes needed then... /Roman > > -kto > > > Roman Kennke wrote: >> Hi, >> >> first of all, I think this is a LCMS problem, so we should think about >> how to fix this _upstream_, otherwise we end up maintaining a patched >> version of lcms *shudder*. >> >> Then I don't think it's a good idea to depend on such 'internal' >> defines. One OS defines or not _LITTLE_ENDIAN, others (like VxWorks) >> define it either as 0 or 1, depending on the systems, even others >> don't care and define __LITTLE_ENDIAN or whatever. IMO, a better way >> to solve this is to make LCMS check LCMS_LITTLE_ENDIAN, and define it >> somewhere. Configure based builds would figure this out when running >> configure. OpenJDK would set this in the files mentioned below, >> instead of setting _LITTLE_ENDIAN. AFAICS, this is the only way to >> make sure we don't conflict with any internal settings of some OS >> include or compiler. >> >>> For better or worse, there seems to be >>> ./common/Defs-linux.gmk:CFLAGS_REQUIRED_amd64 += >>> -fno-omit-frame-pointer -D_LITTLE_ENDIAN >>> ./common/Defs-linux.gmk:CFLAGS_REQUIRED_i586 += >>> -fno-omit-frame-pointer -D_LITTLE_ENDIAN >>> ./common/Defs-linux.gmk:CFLAGS_REQUIRED_ia64 += >>> -fno-omit-frame-pointer -D_LITTLE_ENDIAN >>> ./common/Defs-solaris.gmk: # The macro _LITTLE_ENDIAN needs to be >>> defined the same to avoid the >>> ./common/Defs-solaris.gmk: # Sun C compiler warning message: >>> warning: macro redefined: _LITTLE_ENDIAN >>> ./common/Defs-solaris.gmk: CPPFLAGS_COMMON += -DcpuIntel >>> -D_LITTLE_ENDIAN= -D$(LIBARCH) >>> ./common/Defs-windows.gmk:CPPFLAGS_COMMON = -DWIN32 -DIAL >>> -D_LITTLE_ENDIAN >>> ./netbeans/awt2d/README: D3D_OVERLOADS; UNICODE; _UNICODE; WIN32; >>> IAL; _LITTLE_ENDIAN; WIN32; _X86_; >> >> >> /Roman From mario.torre at aicas.com Tue Jun 23 15:20:59 2009 From: mario.torre at aicas.com (Mario Torre) Date: Wed, 24 Jun 2009 00:20:59 +0200 Subject: [OpenJDK 2D-Dev] _LITTLE_ENDIAN In-Reply-To: <4A414B37.6070009@sun.com> References: <4A40CB2F.6000208@aicas.com> <4A413A95.2040303@sun.com> <4A4148DD.9090307@sun.com> <4A414B37.6070009@sun.com> Message-ID: <4A41554B.8030604@aicas.com> Il 23/06/2009 23:37, Phil Race ha scritto: > Ah, everyone must be looking at the old (1.16) lcms that we > replaced quite a few builds ago. It didn't have the #if macintosh Whoops... I admit that we depend on a slightly older OpenJDK version, and this time I didn't checked the latest code :) I just assumed it was unchanged... but... > But in addition I see it *used* in LCMS.c (2D glue code to LCMS), > where its relying on this being defined in the make files > (make/common/Defs-linux.gmk etc) as cited below as are a good number > of other places in the JDK sources as Mario noted. > If its really just that then making that test more sophisticated > (Vxworks aware) might be OK. exactly :) I would like to make this test more sophisticated. I asked for hints because of this: > I think its going to be painful to change all the rest and most > of those as most are in medialib code, and that's from another group > in Sun and I presume followed the conventions of what's in > the Solaris header files. The medialib code is more painful. I can sed it quickly (actually I already did), question is, who need to define the correct constant? I assumed the Makefile passing the define to the compiler? I hope those definitions do not depend on something "inherited" by Solaris specific headers for example. So far we use a different build machinery, so I haven't looked at the OpenJDK Makefiles yet. I would do something like this, for LCMS, I would change the use of _LITTLE_ENDIAN with __LCMS_LITTLE_ENDIAN, double underscore and LCMS seems a nice define, then I'll try to get this upstream too. To quote Kelly's mail (cross posting and cross mailing, I never did this in my life before, wow :) > Do you really want to change 362+ lines for this name change? For the 300+ occurrences in OpenJDK, I would suggest __OPENJDK_LITTLE_ENDIAN, or __JDK_LITTLE_ENDIAN. I need to fix this by the end of the week anyway :(, so if you then like the patch, you only have to take care of the internal defines. I will not target OpenJDK6 though, I'm only interested in 7 so far (speaking for my company, now). Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ From mario.torre at aicas.com Tue Jun 23 15:25:09 2009 From: mario.torre at aicas.com (Mario Torre) Date: Wed, 24 Jun 2009 00:25:09 +0200 Subject: [OpenJDK 2D-Dev] _LITTLE_ENDIAN In-Reply-To: <4A414E44.1020007@sun.com> References: <4A40CB2F.6000208@aicas.com> <4A413A95.2040303@sun.com> <4A4148DD.9090307@sun.com> <4A414D3C.2050101@sun.com> <4A414E44.1020007@sun.com> Message-ID: <4A415645.1070908@aicas.com> Il 23/06/2009 23:51, Roman Kennke ha scritto: > Hi, > >> Someone would need to make darn sure that ALL uses of the old >> name have been changed. I counted 362 references to this variable >> in the openjdk7 repositories, I assume a similar number in openjdk6. >> The closed jdk sources have an additional 13 references to this >> _LITTLE_ENDIAN name Sun would need to change too. >> >> Do you really want to change 362+ lines for this name change? > > Surely not. I haven't counted and I blindly assumed we talk about lcms > only here. Sorry. In this case I would revert to #undef _LITTLE_ENDIAN > or -U_LITTLE_ENDIAN on platforms that do crazy stuff. No code changes > needed then... -U_LITTLE_ENDIAN is not going to help, because those crazy platform define this anyway... for one reason or another, this gets in the way of those files, and causes the problem I mentioned. We have seen this already with MiniX, you remember it? Roman, maybe we should introduce some big macro instead ;) In any case, I agree this is my problem, there is nothing wrong in the JDK code, I just think it would be more portable with this refactored a bit. Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ From mario.torre at aicas.com Wed Jun 24 06:55:21 2009 From: mario.torre at aicas.com (Mario Torre) Date: Wed, 24 Jun 2009 15:55:21 +0200 Subject: [OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised In-Reply-To: <0KLN0010AZEI8L30@fe-sfbay-10.sun.com> References: <1244588287.3580.53.camel@localhost.localdomain> <0KL000LZGP7MTQ70@fe-sfbay-10.sun.com> <1244737112.3699.43.camel@localhost.localdomain> <0KLA001BHRXND3C0@fe-sfbay-09.sun.com> <1245192491.3614.558.camel@localhost.localdomain> <0KLC00G6KU1PELF0@fe-sfbay-10.sun.com> <4A3946F6.2040902@sun.com> <0KLE000ZNIRPDR90@fe-sfbay-09.sun.com> <1245278053.3658.80.camel@localhost.localdomain> <1245328755.3609.26.camel@localhost.localdomain> <0KLG008439VVTV60@fe-sfbay-10.sun.com> <4A3FE35B.3030701@aicas.com> <0KLN0010AZEI8L30@fe-sfbay-10.sun.com> Message-ID: <4A423049.8080903@aicas.com> Il 23/06/2009 01:47, Jim Graham ha scritto: > Hi Mario, > > The changes look safe, but I wanted to bring up the following issues: Hi Jim, > - There are a dozen or so fields in SG2D that are commonly accessed > everywhere in the pipelines including loops. These changes introduce an > accessor for loops, but that now looks out of place with no accessors > for any of the other fields that get accessed directly. Personally the > lack of accessors hasn't bothered me, particularly since this is > performance sensitive code and accessors can sap performance by nickels > and dimes if you don't implement them correctly - to wit: +42 :) > - Accessors can be inlined if they are final, but these aren't. As it > turns out, SG2D itself is final and so I believe that is enough for them > to be inlined, but I tend to make methods final as well to underscore > that they are intended to be inlined, and also in case we eventually > decide to make the class non-final. On the other hand, we haven't really > bothered with accessors in the first place in this code to avoid the > code bloat and the potential points of heuristic failure. > > - I agree that it would be nice to ask the pipes if they need loops, I'm > not sure why your solution didn't work, but I prefer that to making them > a side effect of getTextPipe() since it makes it harder to know when the > code you are editing needs to get the loops or not, and it makes it hard > to see where they come from when editing the many validatePipe() methods. Would you mind if I divide the patch in 2 or 3 slots? I'll give you first the accessors patch, then a patch that fixes the issue in subject with my current approach and finally a refactorisation so that the loops can ask wherever they want the loops validated or not, because this is the less trivial and because I cannot work on that much in my company time :(. I'll try to give you something already today, hopefully. Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/ From jennifer.godinez at sun.com Wed Jun 24 14:21:20 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Wed, 24 Jun 2009 21:21:20 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d: 6 new changesets Message-ID: <20090624212120.9C690EFC4@hg.openjdk.java.net> Changeset: 68836ec8bcc7 Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/68836ec8bcc7 Added tag jdk7-b61 for changeset 472c21584cfd ! .hgtags Changeset: 54d14906940b Author: jjg Date: 2009-05-20 14:02 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/54d14906940b 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/Defs-internal.gmk Changeset: 2734c0deab69 Author: tbell Date: 2009-06-11 21:09 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/2734c0deab69 Merge Changeset: e84b527d8be8 Author: tbell Date: 2009-06-21 23:49 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/e84b527d8be8 Merge Changeset: 60b818e5e4f9 Author: andrew Date: 2009-06-17 20:53 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/rev/60b818e5e4f9 6851515: awt_p.h incorporates a chunk of the XRender header Summary: Use XRender header directly rather than copying chunks locally Reviewed-by: anthony, ohair ! README-builds.html Changeset: c7ed15ab92ce Author: yan Date: 2009-06-23 23:08 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/c7ed15ab92ce Merge From jennifer.godinez at sun.com Wed Jun 24 14:25:58 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Wed, 24 Jun 2009 21:25:58 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/corba: 4 new changesets Message-ID: <20090624212601.E0065EFC9@hg.openjdk.java.net> Changeset: c73934e09f00 Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/c73934e09f00 Added tag jdk7-b61 for changeset e906b16a12a9 ! .hgtags Changeset: 2752d8bd4142 Author: jjg Date: 2009-05-20 13:41 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/2752d8bd4142 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/Makefile Changeset: 23f2c435056b Author: tbell Date: 2009-06-11 21:11 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/23f2c435056b Merge Changeset: 65b66117dbd7 Author: tbell Date: 2009-06-21 23:50 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/65b66117dbd7 Merge From jennifer.godinez at sun.com Wed Jun 24 14:32:40 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Wed, 24 Jun 2009 21:32:40 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/hotspot: 32 new changesets Message-ID: <20090624213340.077D2EFCE@hg.openjdk.java.net> Changeset: 47ffceb239d0 Author: thurka Date: 2009-05-20 09:36 +0200 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/47ffceb239d0 6839599: JVM crash while profiling Tomcat and Liferay Summary: constantPoolOopDesc::copy_cpool_bytes() - do the brute-force search search through 'tbl' when SymbolTable::lookup_only() returns NULL Reviewed-by: kamg ! src/share/vm/oops/constantPoolOop.cpp Changeset: f1f3a2719a55 Author: xlu Date: 2009-05-22 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f1f3a2719a55 6843580: JavaThread.getStackBase throws sun.jvm.hotspot.WrongTypeException invoked by jstack Reviewed-by: phh, dice, never, swamyv ! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java Changeset: 93c14e5562c4 Author: twisti Date: 2009-05-06 00:27 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/93c14e5562c4 6823354: Add intrinsics for {Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}() Summary: These methods can be instrinsified by using bit scan, bit test, and population count instructions. Reviewed-by: kvn, never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/runtime/globals.hpp + test/compiler/6823354/Test6823354.java Changeset: e85af0c0c94b Author: twisti Date: 2009-05-07 00:28 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/e85af0c0c94b Merge Changeset: f53b154d959d Author: twisti Date: 2009-05-06 08:57 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f53b154d959d 6837906: compiler tests of 6636138 fail with IllegalAccessException Summary: The compiler tests of 6636138 fail with an IllegalAccessException. Reviewed-by: kvn ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java Changeset: f2954231d190 Author: twisti Date: 2009-05-07 04:16 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f2954231d190 Merge Changeset: d0e0d6d824d8 Author: kvn Date: 2009-05-08 10:34 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/d0e0d6d824d8 Merge ! src/share/vm/runtime/globals.hpp Changeset: c96bf21b756f Author: kvn Date: 2009-05-08 10:44 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/c96bf21b756f 6788527: Server vm intermittently fails with assertion "live value must not be garbage" with fastdebug bits Summary: Cache Jvmti and DTrace flags used by Compiler. Reviewed-by: never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp Changeset: 44ccd7a9065c Author: ohair Date: 2009-05-08 15:16 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/44ccd7a9065c 6839151: Add a JPRT default test of -Xshare:dump when new hotspot is built Reviewed-by: never, kvn ! make/jprt.properties ! test/Makefile Changeset: 900e4df4b0c3 Author: ohair Date: 2009-05-08 23:00 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/900e4df4b0c3 Merge Changeset: a9e116455022 Author: kvn Date: 2009-05-11 17:59 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a9e116455022 6832293: JIT compiler got wrong result in type checking with -server Summary: Check for an object array of interface in CmpPNode::sub(). Reviewed-by: never ! src/share/vm/opto/subnode.cpp + test/compiler/6832293/Test.java Changeset: b2934faac289 Author: kvn Date: 2009-05-11 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/b2934faac289 6836054: java/util/Arrays/CopyMethods.java fails on solaris-sparc with IllegalArgumentException Summary: Do not mark an allocation as scalar replaceable if its actual type in unknown statically. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: 2056494941db Author: twisti Date: 2009-05-13 00:45 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/2056494941db 6814842: Load shortening optimizations Summary: 6797305 handles load widening but no shortening which should be covered here. Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/output_c.cpp + test/compiler/6814842/Test6814842.java Changeset: 27d660246893 Author: ohair Date: 2009-05-15 18:14 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/27d660246893 Merge ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make Changeset: aabd393cf1ee Author: kvn Date: 2009-05-21 10:05 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/aabd393cf1ee 6772683: Thread.isInterrupted() fails to return true on multiprocessor PC Summary: Set the control edge for the field _interrupted load in inline_native_isInterrupted(). Reviewed-by: never ! src/share/vm/opto/library_call.cpp + test/compiler/6772683/InterruptedTest.java Changeset: 1851e1fb420e Author: kvn Date: 2009-05-27 12:35 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/1851e1fb420e 6843752: missing code for an anti-dependent Phi in GCM Summary: Don't place a load below anti-dependent PHI. Reviewed-by: never, twisti ! src/share/vm/opto/gcm.cpp + test/compiler/6843752/Test.java Changeset: 273b2358ef1a Author: cfang Date: 2009-05-28 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/273b2358ef1a 6837146: Should perform unswitch before maximally unroll in loop transformation Summary: Move loop unswitch before maximally unroll Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp Changeset: 435f0808b826 Author: never Date: 2009-06-03 15:02 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/435f0808b826 6847305: solaris reorder mapfiles generate too many warnings Reviewed-by: kvn ! make/solaris/makefiles/reorder_COMPILER1_i486 ! make/solaris/makefiles/reorder_COMPILER1_sparc ! make/solaris/makefiles/reorder_COMPILER2_amd64 ! make/solaris/makefiles/reorder_COMPILER2_sparcv9 ! make/solaris/makefiles/reorder_TIERED_i486 ! make/solaris/makefiles/reorder_TIERED_sparc Changeset: 8b0b8998e1c3 Author: never Date: 2009-06-03 15:16 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/8b0b8998e1c3 Merge Changeset: 085dd9ee61aa Author: never Date: 2009-06-03 18:15 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/085dd9ee61aa Merge Changeset: eacd97c88873 Author: cfang Date: 2009-06-05 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/eacd97c88873 6848466: frame::frame_size() assertion failure with -XX:+DebugDeoptimization Summary: add a RegisterMap* argument to frame::frame_size() to correctly compute the sender frame Reviewed-by: never ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/vframe.cpp Changeset: 315a5d70b295 Author: iveresov Date: 2009-05-11 16:30 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/315a5d70b295 6484957: G1: parallel concurrent refinement 6826318: G1: remove traversal-based refinement code Summary: Removed traversal-based refinement code as it's no longer used. Made the concurrent refinement (queue-based) parallel. Reviewed-by: tonyp ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: 215f81b4d9b3 Author: iveresov Date: 2009-05-18 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/215f81b4d9b3 6841831: G1: assert(contains_reference(from),"We just added it!") fires Summary: During parallel rset updating we have to make sure that the worker ids of the refinement threads do not intersect with the worker ids that can be claimed by the mutator threads. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: 29e7d79232b9 Author: apetrusenko Date: 2009-05-19 04:05 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/29e7d79232b9 6819065: G1: eliminate high serial card table clearing time Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 7fd05714f579 Author: jcoomes Date: 2009-05-26 16:43 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/7fd05714f579 Merge Changeset: fe1574da39fc Author: ysr Date: 2009-06-07 00:27 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/fe1574da39fc 6848641: CMSCollector::_roots_scanning_options should be initialized Summary: The field is now initialized in the constructor. Reviewed-by: iveresov, jmasa, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp Changeset: f89cf529c3c7 Author: iveresov Date: 2009-06-08 16:14 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/f89cf529c3c7 6849122: G1: Typo introduced during implementation of the parallel refinement Summary: Typo fix Reviewed-by: jcoomes ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp Changeset: 7295839252de Author: jmasa Date: 2009-06-10 14:57 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/7295839252de Merge Changeset: cf4f487696ba Author: trims Date: 2009-06-11 17:46 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/cf4f487696ba Merge Changeset: 08f86fa55a31 Author: trims Date: 2009-06-11 17:56 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/08f86fa55a31 6850551: Bump the HS16 build number to 04 Summary: Update the HS16 build number to 04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 27b728fd1281 Author: trims Date: 2009-06-11 21:01 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/27b728fd1281 Merge Changeset: a88386380bda Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a88386380bda Added tag jdk7-b61 for changeset 27b728fd1281 ! .hgtags From jennifer.godinez at sun.com Wed Jun 24 14:44:52 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Wed, 24 Jun 2009 21:44:52 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxp: 4 new changesets Message-ID: <20090624214458.8A3C6EFD3@hg.openjdk.java.net> Changeset: db1d07f881a1 Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/db1d07f881a1 Added tag jdk7-b61 for changeset f1ac756616ea ! .hgtags Changeset: bdaf6acaf6e3 Author: jjg Date: 2009-05-20 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/bdaf6acaf6e3 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/Makefile ! make/build.properties ! make/build.xml Changeset: 97344798aaf7 Author: tbell Date: 2009-06-11 21:26 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/97344798aaf7 Merge ! make/Makefile ! make/build.properties ! make/build.xml Changeset: a97dd57a6260 Author: tbell Date: 2009-06-21 23:51 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/a97dd57a6260 Merge From jennifer.godinez at sun.com Wed Jun 24 14:49:43 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Wed, 24 Jun 2009 21:49:43 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jaxws: 4 new changesets Message-ID: <20090624214948.C7266EFD8@hg.openjdk.java.net> Changeset: 55681156ec1a Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/55681156ec1a Added tag jdk7-b61 for changeset aeabf802f2a1 ! .hgtags Changeset: 605e1cdeba48 Author: jjg Date: 2009-05-20 13:50 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/605e1cdeba48 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/Makefile ! make/build.properties ! make/build.xml Changeset: 2ec98e99e4ea Author: tbell Date: 2009-06-11 21:30 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/2ec98e99e4ea Merge ! make/Makefile ! make/build.properties ! make/build.xml Changeset: 75c801c13ea1 Author: tbell Date: 2009-06-21 23:52 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/75c801c13ea1 Merge From jennifer.godinez at sun.com Wed Jun 24 14:55:42 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Wed, 24 Jun 2009 21:55:42 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 48 new changesets Message-ID: <20090624220517.83B15EFDD@hg.openjdk.java.net> Changeset: 03f2ac812821 Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/03f2ac812821 Added tag jdk7-b61 for changeset f72c0dc047b9 ! .hgtags Changeset: 842fb12a21d7 Author: sherman Date: 2009-05-19 15:25 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/842fb12a21d7 6831794: charset EUC_TW is 12.6% of the total size of charsets.jar 6229811: Several codepoints in EUC_TW failed in roundtrip conversion Summary: Re-write EUC_TW charset to address the size and roundtrip issue. Reviewed-by: alanb ! make/java/nio/Makefile ! make/sun/Makefile ! make/sun/nio/FILES_java.gmk ! make/sun/nio/Makefile ! make/tools/CharsetMapping/Makefile ! make/tools/src/build/tools/charsetmapping/CharsetMapping.java ! make/tools/src/build/tools/charsetmapping/GenerateMapping.java ! make/tools/src/build/tools/charsetmapping/GenerateSBCS.java ! src/share/classes/sun/io/ByteToCharEUC_TW.java ! src/share/classes/sun/io/CharToByteEUC_TW.java ! src/share/classes/sun/nio/cs/ext/EUC_TW.java ! src/share/classes/sun/nio/cs/ext/ISO2022.java ! src/share/classes/sun/nio/cs/ext/ISO2022_CN.java ! src/solaris/classes/sun/awt/motif/X11CNS11643.java ! test/sun/nio/cs/TestISO2022CNDecoder.java Changeset: 72e4312ea1e0 Author: sherman Date: 2009-05-19 16:03 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/72e4312ea1e0 6843079: Putback for the new EUC_TW is not complete Summary: Putback the files missed in last putback Reviewed-by: alanb + make/tools/CharsetMapping/euc_tw.map + make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java + make/tools/src/build/tools/charsetmapping/Main.java + test/sun/nio/cs/EUC_TW_OLD.java + test/sun/nio/cs/TestEUC_TW.java + test/sun/nio/cs/TestX11CNS.java + test/sun/nio/cs/X11CNS11643.java + test/sun/nio/cs/X11CNS11643P1.java + test/sun/nio/cs/X11CNS11643P2.java + test/sun/nio/cs/X11CNS11643P3.java Changeset: 49478a651a28 Author: sherman Date: 2009-05-19 16:21 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/49478a651a28 6728376: Wrong error handling in Java_java_util_zip_Deflater_deflateBytes leads to size 0 if compress fails 6735255: ZipFile.close() does not close ZipFileInputStreams, contrary to the API document Summary: Throws OOM when malloc failed. Closes all outstanding streams when closing Reviewed-by: alanb ! src/share/classes/java/util/zip/ZipFile.java ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c Changeset: 057cc7d16812 Author: sherman Date: 2009-05-19 16:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/057cc7d16812 Merge Changeset: 02b02a886b9b Author: weijun Date: 2009-05-20 10:11 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/02b02a886b9b 6832016: {DigestMD5Base,Des3DkCrypto}.setParityBit should use Integer.bitCount Reviewed-by: weijun Contributed-by: Christian Thalinger ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java ! src/share/classes/sun/security/krb5/internal/crypto/dk/Des3DkCrypto.java Changeset: 4d607dc5cb22 Author: weijun Date: 2009-05-20 10:12 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4d607dc5cb22 6682516: SPNEGO_HTTP_AUTH/WWW_KRB and SPNEGO_HTTP_AUTH/WWW_SPNEGO failed on all non-windows platforms Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/PrincipalName.java + test/sun/security/krb5/canonicalize/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/security/krb5/canonicalize/Test.java Changeset: eb46247f6c53 Author: weijun Date: 2009-05-20 10:12 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/eb46247f6c53 6832353: Krb5LoginModule: use the KRB5CCNAME when searching for Kerberos ticket cache Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java Changeset: 1bc5be8665cc Author: jjg Date: 2009-05-20 13:55 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1bc5be8665cc 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/common/shared/Defs-control.gmk ! make/common/shared/Defs-java.gmk ! make/javax/swing/beaninfo/SwingBeans.gmk Changeset: 914c33c7de3e Author: sherman Date: 2009-05-21 23:32 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/914c33c7de3e 6843578: Re-implement IBM doublebyte charsets 6639450: IBM949C encoder modifies state of IBM949 encoder 6569191: Cp943 io converter returns U+0000 and U+FFFD for unconvertable character 6577466: Character encoder IBM970 throws a BufferOverflowException 5065777: CharsetEncoder canEncode() methods often incorrectly return false Summary: Re-write 11 IBM doublebyte charsets. Thanks Ulf.Zibis for the codereview! Reviewed-by: martin ! make/sun/nio/FILES_java.gmk ! make/sun/nio/Makefile + make/tools/CharsetMapping/DoubleByte-X.java + make/tools/CharsetMapping/IBM1381.c2b + make/tools/CharsetMapping/IBM1381.map + make/tools/CharsetMapping/IBM1383.c2b + make/tools/CharsetMapping/IBM1383.map + make/tools/CharsetMapping/IBM1383.nr + make/tools/CharsetMapping/IBM930.c2b + make/tools/CharsetMapping/IBM930.map + make/tools/CharsetMapping/IBM930.nr + make/tools/CharsetMapping/IBM933.c2b + make/tools/CharsetMapping/IBM933.map + make/tools/CharsetMapping/IBM935.c2b + make/tools/CharsetMapping/IBM935.map + make/tools/CharsetMapping/IBM935.nr + make/tools/CharsetMapping/IBM937.c2b + make/tools/CharsetMapping/IBM937.map + make/tools/CharsetMapping/IBM937.nr + make/tools/CharsetMapping/IBM939.c2b + make/tools/CharsetMapping/IBM939.map + make/tools/CharsetMapping/IBM939.nr + make/tools/CharsetMapping/IBM942.c2b + make/tools/CharsetMapping/IBM942.map + make/tools/CharsetMapping/IBM943.map + make/tools/CharsetMapping/IBM943.nr + make/tools/CharsetMapping/IBM948.c2b + make/tools/CharsetMapping/IBM948.map + make/tools/CharsetMapping/IBM949.map + make/tools/CharsetMapping/IBM950.c2b + make/tools/CharsetMapping/IBM950.map + make/tools/CharsetMapping/IBM970.c2b + make/tools/CharsetMapping/IBM970.map + make/tools/CharsetMapping/dbcs + make/tools/src/build/tools/charsetmapping/GenerateDBCS.java ! make/tools/src/build/tools/charsetmapping/Main.java ! src/share/classes/sun/io/ByteToCharCp1381.java ! src/share/classes/sun/io/ByteToCharCp1383.java ! src/share/classes/sun/io/ByteToCharCp834.java ! src/share/classes/sun/io/ByteToCharCp930.java ! src/share/classes/sun/io/ByteToCharCp933.java ! src/share/classes/sun/io/ByteToCharCp935.java ! src/share/classes/sun/io/ByteToCharCp937.java ! src/share/classes/sun/io/ByteToCharCp939.java ! src/share/classes/sun/io/ByteToCharCp942.java ! src/share/classes/sun/io/ByteToCharCp942C.java ! src/share/classes/sun/io/ByteToCharCp943.java ! src/share/classes/sun/io/ByteToCharCp943C.java ! src/share/classes/sun/io/ByteToCharCp948.java ! src/share/classes/sun/io/ByteToCharCp949.java ! src/share/classes/sun/io/ByteToCharCp949C.java ! src/share/classes/sun/io/ByteToCharCp950.java ! src/share/classes/sun/io/ByteToCharCp970.java ! src/share/classes/sun/io/ByteToCharDBCS_ASCII.java ! src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java + src/share/classes/sun/io/ByteToCharEUC2.java ! src/share/classes/sun/io/CharToByteCp1381.java ! src/share/classes/sun/io/CharToByteCp1383.java ! src/share/classes/sun/io/CharToByteCp834.java ! src/share/classes/sun/io/CharToByteCp930.java ! src/share/classes/sun/io/CharToByteCp933.java ! src/share/classes/sun/io/CharToByteCp935.java ! src/share/classes/sun/io/CharToByteCp937.java ! src/share/classes/sun/io/CharToByteCp939.java ! src/share/classes/sun/io/CharToByteCp942.java ! src/share/classes/sun/io/CharToByteCp942C.java ! src/share/classes/sun/io/CharToByteCp943.java ! src/share/classes/sun/io/CharToByteCp943C.java ! src/share/classes/sun/io/CharToByteCp948.java ! src/share/classes/sun/io/CharToByteCp949.java ! src/share/classes/sun/io/CharToByteCp949C.java ! src/share/classes/sun/io/CharToByteCp950.java ! src/share/classes/sun/io/CharToByteCp970.java ! src/share/classes/sun/io/CharToByteDBCS_ASCII.java ! src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java - src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java + src/share/classes/sun/nio/cs/ext/DoubleByte.java - src/share/classes/sun/nio/cs/ext/IBM1381.java - src/share/classes/sun/nio/cs/ext/IBM1383.java ! src/share/classes/sun/nio/cs/ext/IBM834.java - src/share/classes/sun/nio/cs/ext/IBM930.java - src/share/classes/sun/nio/cs/ext/IBM933.java - src/share/classes/sun/nio/cs/ext/IBM935.java - src/share/classes/sun/nio/cs/ext/IBM937.java - src/share/classes/sun/nio/cs/ext/IBM939.java - src/share/classes/sun/nio/cs/ext/IBM942.java ! src/share/classes/sun/nio/cs/ext/IBM942C.java - src/share/classes/sun/nio/cs/ext/IBM943.java ! src/share/classes/sun/nio/cs/ext/IBM943C.java - src/share/classes/sun/nio/cs/ext/IBM948.java - src/share/classes/sun/nio/cs/ext/IBM949.java ! src/share/classes/sun/nio/cs/ext/IBM949C.java - src/share/classes/sun/nio/cs/ext/IBM950.java - src/share/classes/sun/nio/cs/ext/IBM970.java - src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java ! test/sun/nio/cs/FindCanEncodeBugs.java ! test/sun/nio/cs/FindEncoderBugs.java + test/sun/nio/cs/OLD/DBCSDecoderMapping.java + test/sun/nio/cs/OLD/DBCS_IBM_ASCII_Decoder.java + test/sun/nio/cs/OLD/DBCS_IBM_ASCII_Encoder.java + test/sun/nio/cs/OLD/DBCS_IBM_EBCDIC_Decoder.java + test/sun/nio/cs/OLD/DBCS_IBM_EBCDIC_Encoder.java + test/sun/nio/cs/OLD/DBCS_ONLY_IBM_EBCDIC_Decoder.java + test/sun/nio/cs/OLD/IBM1381_OLD.java + test/sun/nio/cs/OLD/IBM1383_OLD.java + test/sun/nio/cs/OLD/IBM930_OLD.java + test/sun/nio/cs/OLD/IBM933_OLD.java + test/sun/nio/cs/OLD/IBM935_OLD.java + test/sun/nio/cs/OLD/IBM937_OLD.java + test/sun/nio/cs/OLD/IBM939_OLD.java + test/sun/nio/cs/OLD/IBM942C_OLD.java + test/sun/nio/cs/OLD/IBM942_OLD.java + test/sun/nio/cs/OLD/IBM943C_OLD.java + test/sun/nio/cs/OLD/IBM943_OLD.java + test/sun/nio/cs/OLD/IBM948_OLD.java + test/sun/nio/cs/OLD/IBM949C_OLD.java + test/sun/nio/cs/OLD/IBM949_OLD.java + test/sun/nio/cs/OLD/IBM950_OLD.java + test/sun/nio/cs/OLD/IBM970_OLD.java + test/sun/nio/cs/OLD/SimpleEUCDecoder.java + test/sun/nio/cs/OLD/TestIBMDB.java ! test/sun/nio/cs/TestEUC_TW.java ! test/sun/nio/cs/TestIBMBugs.java Changeset: 8d2efec31d78 Author: xlu Date: 2009-05-24 16:29 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/8d2efec31d78 6622432: RFE: Performance improvements to java.math.BigDecimal Reviewed-by: darcy ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/BigInteger.java ! src/share/classes/java/math/BitSieve.java ! src/share/classes/java/math/MathContext.java ! src/share/classes/java/math/MutableBigInteger.java ! src/share/classes/java/math/SignedMutableBigInteger.java ! test/java/math/BigDecimal/AddTests.java ! test/java/math/BigDecimal/DivideTests.java Changeset: 3994c5c669cb Author: xlu Date: 2009-05-24 16:35 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3994c5c669cb 6806261: BigDecimal.longValueExact() method throws NullPointerException Summary: add various tests to test the change to 6622432 Reviewed-by: darcy + test/java/math/BigDecimal/EqualsTests.java + test/java/math/BigDecimal/LongValueExactTests.java + test/java/math/BigDecimal/MultiplyTests.java + test/java/math/BigDecimal/PrecisionTests.java + test/java/math/BigInteger/CompareToTests.java Changeset: 206d73d299d4 Author: jccollet Date: 2009-05-25 22:27 +0200 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/206d73d299d4 6349566: java.net.CookieManager doesn't set default domain Summary: Enforce default domain in CookieManager Reviewed-by: michaelm ! src/share/classes/java/net/CookieManager.java ! test/java/net/CookieHandler/CookieManagerTest.java Changeset: dc3865883a5a Author: weijun Date: 2009-05-26 10:12 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/dc3865883a5a 6844887: NPE in TextCallbackHandler Reviewed-by: xuelei ! src/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java + test/com/sun/security/auth/callback/TextCallbackHandler/NPE.java Changeset: d93b7df1e260 Author: xuelei Date: 2009-05-26 16:19 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d93b7df1e260 6822460: support self-issued certificate Summary: checking self-issued certificate during certification path building Reviewed-by: mullan, weijun ! src/share/classes/sun/security/validator/PKIXValidator.java ! src/share/classes/sun/security/validator/SimpleValidator.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java Changeset: c3c5cc0f2a3e Author: xuelei Date: 2009-05-26 16:43 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c3c5cc0f2a3e 6720721: CRL check with circular depency support needed Summary: checking AKID of certificates and CRLs Reviewed-by: mullan, weijun ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java + test/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevel.java + test/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevelRevoked.java + test/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java + test/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java + test/java/security/cert/CertPathValidator/indirectCRL/README + test/java/security/cert/CertPathValidator/indirectCRL/generate.sh + test/java/security/cert/CertPathValidator/indirectCRL/openssl.cnf Changeset: 045aeb76b0ff Author: jccollet Date: 2009-05-26 16:03 +0200 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/045aeb76b0ff 6726695: HttpURLConnection shoul support 'Expect: 100-contimue' headers for PUT Summary: Added code triggered when 'Expect: 100-continue' header has been added Reviewed-by: chegar ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/http/HttpClient/B6726695.java Changeset: 25db260cb810 Author: xuelei Date: 2009-05-27 17:48 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/25db260cb810 6845286: Add regression test for name constraints Summary: create regression test cases on name constraints Reviewed-by: weijun + test/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithRID.java + test/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithUnexpectedRID.java + test/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithoutRID.java + test/java/security/cert/CertPathValidator/nameConstraints/generate.sh + test/java/security/cert/CertPathValidator/nameConstraints/openssl.cnf Changeset: 7772d77bd7c2 Author: mchung Date: 2009-05-26 17:47 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7772d77bd7c2 6829636: test/java/util/logging/LoggingDeadlock2.java is flaky Summary: remove @ignore Reviewed-by: swamyv ! src/share/classes/java/net/URLConnection.java ! test/Makefile ! test/java/util/logging/LoggingDeadlock2.java Changeset: 2aeaffb6c897 Author: mchung Date: 2009-05-26 17:54 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/2aeaffb6c897 6798842: TEST_BUG: ThreadStackTrace.java fails intermittently with unexpected thread status. Summary: remove @ignore Reviewed-by: swamyv ! test/java/lang/management/ThreadMXBean/ThreadStackTrace.java + test/java/lang/management/ThreadMXBean/Utils.java Changeset: fba2425da9b1 Author: mchung Date: 2009-05-26 18:02 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/fba2425da9b1 5080203: TEST_BUG: ThreadStateTest fails intermittently. Summary: Retry a few times to check thread status before reporting failure Reviewed-by: swamyv ! test/java/lang/management/ThreadMXBean/ThreadStateTest.java Changeset: a7a38e606a7a Author: mchung Date: 2009-05-26 18:07 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a7a38e606a7a 6512493: TEST_BUG: unexpected LockInfo failure in LockedSynchronizers.java Summary: Retry a few times to check thread status before reporting failure Reviewed-by: swamyv ! test/java/lang/management/ThreadMXBean/LockingThread.java ! test/java/lang/management/ThreadMXBean/MonitorDeadlock.java Changeset: fb97068670e6 Author: mchung Date: 2009-05-26 18:09 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/fb97068670e6 6535104: TEST_BUG: FindDeadlocks.java fails intermittently. Summary: Retry a few times to check thread status before reporting failure Reviewed-by: swamyv ! test/java/lang/management/ThreadMXBean/SynchronizerDeadlock.java ! test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java Changeset: 742b55c45a70 Author: mchung Date: 2009-05-27 13:02 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/742b55c45a70 Merge Changeset: 59bbb9f3f430 Author: kamg Date: 2009-05-27 13:20 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/59bbb9f3f430 6838211: jdk docs creation broken for tracing docs Summary: Fix javadoc makefile macro Reviewed-by: ohair, jjg ! make/docs/Makefile Changeset: 8e77f61508cc Author: kamg Date: 2009-05-27 15:32 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/8e77f61508cc Merge Changeset: 928e0f1043e6 Author: chegar Date: 2009-05-29 15:51 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/928e0f1043e6 6807602: Increase MAX_BUFFER_LEN and MAX_HEAP_BUFFER_LEN on 64-bit Solaris and Linux Reviewed-by: alanb ! src/solaris/native/java/net/net_util_md.h Changeset: aece9096d5cd Author: jjg Date: 2009-05-29 16:27 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/aece9096d5cd 6838199: remove support for old javap Reviewed-by: ohair, mcimadamore ! make/common/Release.gmk ! make/common/internal/Defs-langtools.gmk ! make/launchers/Makefile Changeset: d26c268597ed Author: sherman Date: 2009-05-29 16:34 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d26c268597ed 6808625: Incomplete code sample in Deflater javadoc Summary: added compresser.end() into example Reviewed-by: martin ! src/share/classes/java/util/zip/Deflater.java Changeset: 045743e0eb2d Author: xuelei Date: 2009-06-04 11:28 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/045743e0eb2d 6847459: Allow trust anchor self-issued intermediate version 1 and version 2 certificate Reviewed-by: weijun ! src/share/classes/sun/security/provider/certpath/ConstraintsChecker.java Changeset: 8f405b65ddac Author: weijun Date: 2009-06-09 14:17 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/8f405b65ddac 6578647: Undefined requesting URL in java.net.Authenticator.getPasswordAuthentication() Reviewed-by: chegar, valeriep ! src/share/classes/sun/net/www/protocol/http/AuthenticationHeader.java + src/share/classes/sun/net/www/protocol/http/HttpCallerInfo.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/share/classes/sun/net/www/protocol/http/NegotiateCallbackHandler.java ! src/share/classes/sun/net/www/protocol/http/NegotiatorImpl.java + src/share/classes/sun/security/jgss/GSSCaller.java ! src/share/classes/sun/security/jgss/GSSManagerImpl.java ! src/share/classes/sun/security/jgss/GSSUtil.java + src/share/classes/sun/security/jgss/HttpCaller.java ! src/share/classes/sun/security/jgss/LoginConfigImpl.java ! src/share/classes/sun/security/jgss/ProviderList.java ! src/share/classes/sun/security/jgss/krb5/InitialToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java ! src/share/classes/sun/security/jgss/wrapper/NativeGSSFactory.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! test/sun/security/jgss/DefaultGssConfig.java ! test/sun/security/jgss/GssNPE.java + test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor Changeset: 4da7b972b391 Author: mullan Date: 2009-06-10 09:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4da7b972b391 6845161: Bottleneck in Configuration.getConfiguration synchronized call Summary: Reduce scope of synchronized block Reviewed-by: weijun ! src/share/classes/javax/security/auth/login/Configuration.java Changeset: ffbcf1d1103c Author: xuelei Date: 2009-06-12 09:00 +0800 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ffbcf1d1103c 6570344: Invalid RSA OID in sun.security.x509.AlgorithmId Summary: change RSA OID to "2.5.8.1.1" Reviewed-by: mullan ! src/share/classes/sun/security/x509/AlgorithmId.java Changeset: 328148f45b31 Author: tbell Date: 2009-06-11 21:32 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/328148f45b31 Merge ! make/docs/Makefile - src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/IBM1381.java - src/share/classes/sun/nio/cs/ext/IBM1383.java - src/share/classes/sun/nio/cs/ext/IBM930.java - src/share/classes/sun/nio/cs/ext/IBM933.java - src/share/classes/sun/nio/cs/ext/IBM935.java - src/share/classes/sun/nio/cs/ext/IBM937.java - src/share/classes/sun/nio/cs/ext/IBM939.java - src/share/classes/sun/nio/cs/ext/IBM942.java - src/share/classes/sun/nio/cs/ext/IBM943.java - src/share/classes/sun/nio/cs/ext/IBM948.java - src/share/classes/sun/nio/cs/ext/IBM949.java - src/share/classes/sun/nio/cs/ext/IBM950.java - src/share/classes/sun/nio/cs/ext/IBM970.java - src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java ! test/Makefile Changeset: 74aefd0ab26d Author: martin Date: 2009-06-14 14:23 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/74aefd0ab26d 6850720: (process) Use clone(CLONE_VM), not fork, on Linux to avoid swap exhaustion Summary: Use clone(CLONE_VM) on Linux; Reluctantly implement execvpe. Reviewed-by: michaelm ! src/solaris/native/java/lang/UNIXProcess_md.c ! test/java/lang/ProcessBuilder/Basic.java + test/java/lang/ProcessBuilder/BigFork.java Changeset: d0de3e41426b Author: martin Date: 2009-06-14 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d0de3e41426b 6511515: poor performance of LogRecord.inferCaller depending on java.lang.Throwable.getStackTraceElement Summary: Allow random access to stack trace elements; retrieve only needed ones Reviewed-by: swamyv Contributed-by: jeremymanson at google.com ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Throwable.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/sun/misc/JavaLangAccess.java Changeset: 5a5b56904855 Author: tbell Date: 2009-06-21 12:02 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/5a5b56904855 6853336: (process) disable or remove clone-exec feature (6850720) Summary: clone-exec feature (6850720) needs more work on 32-bit Linux Reviewed-by: alanb, michaelm Contributed-by: Martin Buchholz ! src/solaris/native/java/lang/UNIXProcess_md.c Changeset: 55a584478eac Author: tbell Date: 2009-06-21 23:52 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/55a584478eac Merge Changeset: 6f1f159aed75 Author: yan Date: 2009-06-03 17:41 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/6f1f159aed75 6839645: Swing application prints message in Control Panel if language is changed Summary: just remove debug printout from production builds; ignore multicharacter-generating keys Reviewed-by: uta ! src/windows/native/sun/windows/awt_Component.cpp Changeset: a3f970a8600b Author: anthony Date: 2009-06-04 15:18 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a3f970a8600b 6832386: Fix JTreg test: java/awt/Graphics/DrawImageBG/SystemBgColorTest.java Summary: Removed unneeded System.exit(0) call. Reviewed-by: art, ohair, anthony Contributed-by: Omair Majid ! test/java/awt/Graphics/DrawImageBG/SystemBgColorTest.java Changeset: 7289003cd1c9 Author: dcherepanov Date: 2009-06-05 17:30 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7289003cd1c9 6829180: Removing focused component from a window causes a JVM crash for JDK7b50+ on WinXP/Vista Summary: access pData on the toolkit thread Reviewed-by: art, anthony, naoto ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_InputMethod.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/native/sun/windows/awtmsg.h Changeset: 70654407b626 Author: dcherepanov Date: 2009-06-15 11:15 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/70654407b626 6847584: closed/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.html fails Reviewed-by: anthony + test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.html ! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java Changeset: 0e441c781cdc Author: yan Date: 2009-06-16 00:37 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/0e441c781cdc Merge - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: 2a526ccd12e8 Author: andrew Date: 2009-06-17 21:13 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/2a526ccd12e8 6851515: awt_p.h incorporates a chunk of the XRender header Summary: Use XRender header directly rather than copying chunks locally Reviewed-by: anthony, ohair ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_p.h Changeset: 1bbbd0ef5d04 Author: peytoia Date: 2009-06-13 06:43 +0900 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/1bbbd0ef5d04 6850113: Bidi class needs to be updated to support Unicode 5.1 Reviewed-by: okutsu ! make/java/text/FILES_java.gmk ! make/sun/font/FILES_c.gmk ! make/sun/font/Makefile ! make/sun/font/mapfile-vers ! make/sun/font/mapfile-vers.openjdk ! src/share/classes/java/text/Bidi.java + src/share/classes/sun/text/bidi/BidiBase.java + src/share/classes/sun/text/bidi/BidiLine.java + src/share/classes/sun/text/bidi/BidiRun.java ! src/share/classes/sun/text/normalizer/UCharacter.java - src/share/native/sun/font/bidi/cmemory.h - src/share/native/sun/font/bidi/jbidi.c - src/share/native/sun/font/bidi/jbidi.h - src/share/native/sun/font/bidi/ubidi.c - src/share/native/sun/font/bidi/ubidi.h - src/share/native/sun/font/bidi/ubidiimp.h - src/share/native/sun/font/bidi/ubidiln.c - src/share/native/sun/font/bidi/uchardir.c - src/share/native/sun/font/bidi/uchardir.h - src/share/native/sun/font/bidi/utypes.h ! src/share/native/sun/font/layout/LETypes.h ! test/java/text/Bidi/BidiBug.java + test/java/text/Bidi/BidiConformance.java ! test/java/text/Bidi/BidiEmbeddingTest.java + test/java/text/Bidi/Bug6850113.java Changeset: 45316d7cc9dc Author: yan Date: 2009-06-17 23:27 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/45316d7cc9dc Merge - src/share/native/sun/font/bidi/cmemory.h - src/share/native/sun/font/bidi/jbidi.c - src/share/native/sun/font/bidi/jbidi.h - src/share/native/sun/font/bidi/ubidi.c - src/share/native/sun/font/bidi/ubidi.h - src/share/native/sun/font/bidi/ubidiimp.h - src/share/native/sun/font/bidi/ubidiln.c - src/share/native/sun/font/bidi/uchardir.c - src/share/native/sun/font/bidi/uchardir.h - src/share/native/sun/font/bidi/utypes.h Changeset: 12e11fab9a83 Author: yan Date: 2009-06-23 23:09 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/12e11fab9a83 Merge - src/share/native/sun/font/bidi/cmemory.h - src/share/native/sun/font/bidi/jbidi.c - src/share/native/sun/font/bidi/jbidi.h - src/share/native/sun/font/bidi/ubidi.c - src/share/native/sun/font/bidi/ubidi.h - src/share/native/sun/font/bidi/ubidiimp.h - src/share/native/sun/font/bidi/ubidiln.c - src/share/native/sun/font/bidi/uchardir.c - src/share/native/sun/font/bidi/uchardir.h - src/share/native/sun/font/bidi/utypes.h Changeset: 2886eb650801 Author: jgodinez Date: 2009-06-24 11:49 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/2886eb650801 Merge - src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/IBM1381.java - src/share/classes/sun/nio/cs/ext/IBM1383.java - src/share/classes/sun/nio/cs/ext/IBM930.java - src/share/classes/sun/nio/cs/ext/IBM933.java - src/share/classes/sun/nio/cs/ext/IBM935.java - src/share/classes/sun/nio/cs/ext/IBM937.java - src/share/classes/sun/nio/cs/ext/IBM939.java - src/share/classes/sun/nio/cs/ext/IBM942.java - src/share/classes/sun/nio/cs/ext/IBM943.java - src/share/classes/sun/nio/cs/ext/IBM948.java - src/share/classes/sun/nio/cs/ext/IBM949.java - src/share/classes/sun/nio/cs/ext/IBM950.java - src/share/classes/sun/nio/cs/ext/IBM970.java - src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java - src/share/native/sun/font/bidi/cmemory.h - src/share/native/sun/font/bidi/jbidi.c - src/share/native/sun/font/bidi/jbidi.h - src/share/native/sun/font/bidi/ubidi.c - src/share/native/sun/font/bidi/ubidi.h - src/share/native/sun/font/bidi/ubidiimp.h - src/share/native/sun/font/bidi/ubidiln.c - src/share/native/sun/font/bidi/uchardir.c - src/share/native/sun/font/bidi/uchardir.h - src/share/native/sun/font/bidi/utypes.h From jennifer.godinez at sun.com Wed Jun 24 15:22:31 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Wed, 24 Jun 2009 22:22:31 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/langtools: 15 new changesets Message-ID: <20090624222256.885C9EFE2@hg.openjdk.java.net> Changeset: 950d50e13a9e Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/950d50e13a9e Added tag jdk7-b61 for changeset 522520757dd3 ! .hgtags Changeset: b5872f0790e7 Author: jjg Date: 2009-05-19 11:27 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/b5872f0790e7 6841422: classfile: add Type visitor Reviewed-by: mcimadamore Contributed-by: kevin.t.looney at sun.com ! src/share/classes/com/sun/tools/classfile/Type.java Changeset: f838537fb1ac Author: jjg Date: 2009-05-19 11:33 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/f838537fb1ac 6841420: classfile: add new methods to ConstantClassInfo Reviewed-by: mcimadamore Contributed-by: kevin.t.looney at sun.com ! src/share/classes/com/sun/tools/classfile/ConstantPool.java Changeset: fc634a593812 Author: jjg Date: 2009-05-19 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/fc634a593812 6841419: classfile: add constant pool iterator Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java Changeset: cd0630109de5 Author: jjg Date: 2009-05-19 11:50 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/cd0630109de5 6824493: experimental support for additional info for instructions Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java ! src/share/classes/com/sun/tools/javap/BasicWriter.java ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java + src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java ! src/share/classes/com/sun/tools/javap/JavapTask.java + src/share/classes/com/sun/tools/javap/Messages.java ! src/share/classes/com/sun/tools/javap/Options.java + src/share/classes/com/sun/tools/javap/SourceWriter.java + src/share/classes/com/sun/tools/javap/StackMapWriter.java + src/share/classes/com/sun/tools/javap/TryBlockWriter.java ! src/share/classes/com/sun/tools/javap/resources/javap.properties + test/tools/javap/T6824493.java Changeset: 0c6cd88f72b9 Author: jjg Date: 2009-05-19 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/0c6cd88f72b9 6843013: missing files in fix for 6824493 Reviewed-by: darcy + src/share/classes/com/sun/tools/javap/LocalVariableTableWriter.java + src/share/classes/com/sun/tools/javap/LocalVariableTypeTableWriter.java Changeset: 4ce1c1400334 Author: jjg Date: 2009-05-19 15:07 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/4ce1c1400334 6832154: refactor Paths to be just a utility class for JavacFileManager Reviewed-by: darcy ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Changeset: 79eb8795a1de Author: jjg Date: 2009-05-20 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/79eb8795a1de 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/Makefile ! make/build.properties ! make/build.xml ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java Changeset: 44eaac2b4501 Author: jjg Date: 2009-05-20 19:10 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/44eaac2b4501 6843648: tools/javac/versions/check.sh is broken Reviewed-by: darcy ! test/tools/javac/6341866/Anno.java ! test/tools/javac/6464451/BigFinally.java ! test/tools/javac/6464451/DeepNestedFinally.java ! test/tools/javac/6464451/ManyExitsInTry.java ! test/tools/javac/ClassLit.java ! test/tools/javac/T6557865.java ! test/tools/javac/foreach/T6682380.java ! test/tools/javac/processing/6348499/A.java ! test/tools/javac/processing/6414633/A.java ! test/tools/javac/processing/6430209/b6341534.java ! test/tools/javac/processing/T6439826.java ! test/tools/javac/stackmap/T4955930.sh ! test/tools/javac/versions/check.sh Changeset: d402db1005ad Author: mcimadamore Date: 2009-05-21 10:56 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/d402db1005ad 6722234: javac diagnostics need better integration with the type-system Summary: Added RichDiagnosticFormatter which provides better formatting capabilities for javac types/symbols Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java + src/share/classes/com/sun/tools/javac/util/ForwardingDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java + src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/6304921/T6304921.java ! test/tools/javac/6304921/T6304921.out ! test/tools/javac/6491592/T6491592.out + test/tools/javac/Diagnostics/6722234/T6722234a.java + test/tools/javac/Diagnostics/6722234/T6722234a_1.out + test/tools/javac/Diagnostics/6722234/T6722234a_2.out + test/tools/javac/Diagnostics/6722234/T6722234b.java + test/tools/javac/Diagnostics/6722234/T6722234b_1.out + test/tools/javac/Diagnostics/6722234/T6722234b_2.out + test/tools/javac/Diagnostics/6722234/T6722234c.java + test/tools/javac/Diagnostics/6722234/T6722234c.out + test/tools/javac/Diagnostics/6722234/T6722234d.java + test/tools/javac/Diagnostics/6722234/T6722234d_1.out + test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/ExtendArray.java ! test/tools/javac/ExtendArray.out ! test/tools/javac/OverridePosition.java ! test/tools/javac/OverridePosition.out ! test/tools/javac/T4093617/T4093617.java ! test/tools/javac/T4093617/T4093617.out ! test/tools/javac/T5003235/T5003235c.java ! test/tools/javac/T5003235/T5003235c.out ! test/tools/javac/miranda/T4666866.java ! test/tools/javac/miranda/T4666866.out ! test/tools/javac/protectedAccess/ProtectedMemberAccess2.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess3.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess4.java Changeset: 84061bd68019 Author: darcy Date: 2009-05-27 22:34 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/84061bd68019 6843761: Update langtools tests to remove unncessary -source and -target options Reviewed-by: jjg ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testNavagation/TestNavagation.java ! test/com/sun/javadoc/testTagInheritence/TestTagInheritence.java ! test/tools/javac/5005368.java ! test/tools/javac/Ambig3.java ! test/tools/javac/ArrayCast.java ! test/tools/javac/BadCovar.java ! test/tools/javac/ClassLiterals/InitializeOuter.java ! test/tools/javac/ClassLiterals/InitializeTarget.java ! test/tools/javac/ClassToTypeParm.java ! test/tools/javac/Closure1.java ! test/tools/javac/Closure2.java ! test/tools/javac/Closure3.java ! test/tools/javac/Closure4.java ! test/tools/javac/Closure5.java ! test/tools/javac/CompoundBox.java ! test/tools/javac/ConditionalArgTypes_1.java ! test/tools/javac/ConditionalArgTypes_2.java ! test/tools/javac/DefiniteAssignment/DUAssert.java ! test/tools/javac/EarlyAssert.java ! test/tools/javac/Enum1.java ! test/tools/javac/GoodCovar.java ! test/tools/javac/HexFloatLiterals.java ! test/tools/javac/HexThree.java ! test/tools/javac/InterfaceAssert.java ! test/tools/javac/InvalidIntfCast.java ! test/tools/javac/NewGeneric.java ! test/tools/javac/ObjectMethodRefFromInterface.java ! test/tools/javac/PrivateLocalConstructor.java ! test/tools/javac/RawCrash.java ! test/tools/javac/SynthName2.java ! test/tools/javac/T5090006/compiler.sh ! test/tools/javac/T5092545.java ! test/tools/javac/T5105890.java ! test/tools/javac/annotations/default/A.java ! test/tools/javac/annotations/neg/AnnComma.java ! test/tools/javac/annotations/neg/ArrayLit.java ! test/tools/javac/annotations/neg/Constant.java ! test/tools/javac/annotations/neg/Cycle1.java ! test/tools/javac/annotations/neg/Cycle2.java ! test/tools/javac/annotations/neg/Cycle3.java ! test/tools/javac/annotations/neg/Dep.java ! test/tools/javac/annotations/neg/Dup.java ! test/tools/javac/annotations/neg/DupTarget.java ! test/tools/javac/annotations/neg/MemberOver.java ! test/tools/javac/annotations/neg/ObjectMembers.java ! test/tools/javac/annotations/neg/OverrideNo.java ! test/tools/javac/annotations/neg/Package.java ! test/tools/javac/annotations/neg/Recovery.java ! test/tools/javac/annotations/neg/Recovery1.java ! test/tools/javac/annotations/neg/Scope.java ! test/tools/javac/annotations/neg/Syntax1.java ! test/tools/javac/annotations/neg/WrongTarget.java ! test/tools/javac/annotations/neg/WrongTarget2.java ! test/tools/javac/annotations/neg/WrongValue.java ! test/tools/javac/annotations/neg/Z1.java ! test/tools/javac/annotations/neg/Z10.java ! test/tools/javac/annotations/neg/Z11.java ! test/tools/javac/annotations/neg/Z12.java ! test/tools/javac/annotations/neg/Z13.java ! test/tools/javac/annotations/neg/Z14.java ! test/tools/javac/annotations/neg/Z15.java ! test/tools/javac/annotations/neg/Z16.java ! test/tools/javac/annotations/neg/Z2.java ! test/tools/javac/annotations/neg/Z3.java ! test/tools/javac/annotations/neg/Z4.java ! test/tools/javac/annotations/neg/Z5.java ! test/tools/javac/annotations/neg/Z8.java ! test/tools/javac/annotations/neg/Z9.java ! test/tools/javac/annotations/pos/AnnoteElideBraces.java ! test/tools/javac/annotations/pos/ClassA.java ! test/tools/javac/annotations/pos/Dep.java ! test/tools/javac/annotations/pos/Enum1.java ! test/tools/javac/annotations/pos/Local.java ! test/tools/javac/annotations/pos/Members.java ! test/tools/javac/annotations/pos/NType.java ! test/tools/javac/annotations/pos/OverrideCheck.java ! test/tools/javac/annotations/pos/OverrideOK.java ! test/tools/javac/annotations/pos/Parameter.java ! test/tools/javac/annotations/pos/Primitives.java ! test/tools/javac/annotations/pos/RightTarget.java ! test/tools/javac/annotations/pos/Z1.java ! test/tools/javac/annotations/pos/Z2.java ! test/tools/javac/annotations/pos/Z3.java ! test/tools/javac/annotations/pos/Z4.java ! test/tools/javac/annotations/pos/package-info.java ! test/tools/javac/assert/Attach.java ! test/tools/javac/assert/DU1.java ! test/tools/javac/assert/DU2.java ! test/tools/javac/assert/Position.java ! test/tools/javac/boxing/BoxedForeach.java ! test/tools/javac/boxing/Boxing1.java ! test/tools/javac/boxing/Boxing2.java ! test/tools/javac/boxing/Boxing4.java ! test/tools/javac/boxing/BoxingCaching.java ! test/tools/javac/capture/Capture1.java ! test/tools/javac/capture/Capture2.java ! test/tools/javac/capture/Capture3.java ! test/tools/javac/capture/Capture5.java ! test/tools/javac/cast/BoxedArray.java ! test/tools/javac/enum/AbstractEmptyEnum.java ! test/tools/javac/enum/AbstractEnum1.java ! test/tools/javac/enum/DA1.java ! test/tools/javac/enum/DA2.java ! test/tools/javac/enum/DA3.java ! test/tools/javac/enum/Def.java ! test/tools/javac/enum/Enum1.java ! test/tools/javac/enum/Enum2.java ! test/tools/javac/enum/Enum3.java ! test/tools/javac/enum/EnumImplicitPrivateConstructor.java ! test/tools/javac/enum/EnumInit.java ! test/tools/javac/enum/EnumPrivateConstructor.java ! test/tools/javac/enum/EnumProtectedConstructor.java ! test/tools/javac/enum/EnumPublicConstructor.java ! test/tools/javac/enum/EnumSwitch1.java ! test/tools/javac/enum/EnumSwitch2.java ! test/tools/javac/enum/EnumSwitch3.java ! test/tools/javac/enum/EnumSwitch4.java ! test/tools/javac/enum/ExplicitlyAbstractEnum1.java ! test/tools/javac/enum/ExplicitlyAbstractEnum2.java ! test/tools/javac/enum/ExplicitlyFinalEnum1.java ! test/tools/javac/enum/ExplicitlyFinalEnum2.java ! test/tools/javac/enum/FauxEnum1.java ! test/tools/javac/enum/FauxEnum3.java ! test/tools/javac/enum/FauxSpecialEnum1.java ! test/tools/javac/enum/FauxSpecialEnum2.java ! test/tools/javac/enum/LocalEnum.java ! test/tools/javac/enum/NoFinal.java ! test/tools/javac/enum/NoFinal2.java ! test/tools/javac/enum/NoFinal3.java ! test/tools/javac/enum/NoFinal4.java ! test/tools/javac/enum/NoFinal5.java ! test/tools/javac/enum/OkFinal.java ! test/tools/javac/enum/SynthValues.java ! test/tools/javac/enum/T5075242.java ! test/tools/javac/enum/T5081785.java ! test/tools/javac/enum/TrailingComma.java ! test/tools/javac/enum/UserValue.java ! test/tools/javac/enum/ValueOf.java ! test/tools/javac/enum/enumSwitch/EnumSwitch.java ! test/tools/javac/foreach/Foreach.java ! test/tools/javac/foreach/GenericIterator.java ! test/tools/javac/foreach/IntersectIterator.java ! test/tools/javac/foreach/ListOfListTest.java ! test/tools/javac/foreach/SpecIterable.java ! test/tools/javac/foreach/StaticBlock.java ! test/tools/javac/foreach/SuperfluousAbstract.java ! test/tools/javac/generics/ArrayClone.java ! test/tools/javac/generics/ArrayTypearg.java ! test/tools/javac/generics/BridgeClash.java ! test/tools/javac/generics/BridgeOrder.java ! test/tools/javac/generics/CastCrash.java ! test/tools/javac/generics/Casting.java ! test/tools/javac/generics/Casting2.java ! test/tools/javac/generics/Casting3.java ! test/tools/javac/generics/Casting4.java ! test/tools/javac/generics/Conditional.java ! test/tools/javac/generics/Covar2.java ! test/tools/javac/generics/Covar3.java ! test/tools/javac/generics/Covar4.java ! test/tools/javac/generics/Crash01.java ! test/tools/javac/generics/Crash02.java ! test/tools/javac/generics/CyclicInheritance3.java ! test/tools/javac/generics/CyclicInheritance5.java ! test/tools/javac/generics/ErasureClashCrash.java ! test/tools/javac/generics/ExtendedRaw1.java ! test/tools/javac/generics/ExtendedRaw2.java ! test/tools/javac/generics/ExtendedRaw3.java ! test/tools/javac/generics/ExtendedRaw4.java ! test/tools/javac/generics/FinalBridge.java ! test/tools/javac/generics/GenLit1.java ! test/tools/javac/generics/GenLit2.java ! test/tools/javac/generics/GenericAnonCtor.java ! test/tools/javac/generics/GenericMerge.java ! test/tools/javac/generics/GenericOverride.java ! test/tools/javac/generics/GenericThrowable.java ! test/tools/javac/generics/GetClass.java ! test/tools/javac/generics/GetClass2.java ! test/tools/javac/generics/InheritanceConflict.java ! test/tools/javac/generics/InheritanceConflict2.java ! test/tools/javac/generics/InheritanceConflict3.java ! test/tools/javac/generics/InnerInterface1.java ! test/tools/javac/generics/InnerInterface2.java ! test/tools/javac/generics/InstanceOf1.java ! test/tools/javac/generics/InstanceOf2.java ! test/tools/javac/generics/InstanceOf3.java ! test/tools/javac/generics/InterfaceCast1.java ! test/tools/javac/generics/LoadOrder.java ! test/tools/javac/generics/MissingBridge.java ! test/tools/javac/generics/MissingCast.java ! test/tools/javac/generics/Multibound1.java ! test/tools/javac/generics/MultipleInheritance.java ! test/tools/javac/generics/NameOrder.java ! test/tools/javac/generics/Nonlinear.java ! test/tools/javac/generics/ParametricException.java ! test/tools/javac/generics/ParenVerify.java ! test/tools/javac/generics/PermuteBound.java ! test/tools/javac/generics/PrimitiveClass.java ! test/tools/javac/generics/PrimitiveVariant.java ! test/tools/javac/generics/RawClient.java ! test/tools/javac/generics/RefEqual.java ! test/tools/javac/generics/RelaxedArrays.java ! test/tools/javac/generics/ReverseOrder.java ! test/tools/javac/generics/SelfImplement.java ! test/tools/javac/generics/SilentUnchecked.java ! test/tools/javac/generics/SuperTypeargs.java ! test/tools/javac/generics/T4661029.java ! test/tools/javac/generics/T4683314.java ! test/tools/javac/generics/T4684378.java ! test/tools/javac/generics/T4695348.java ! test/tools/javac/generics/T4695415.java ! test/tools/javac/generics/T4695847.java ! test/tools/javac/generics/T4711570.java ! test/tools/javac/generics/T4711572.java ! test/tools/javac/generics/T4711694.java ! test/tools/javac/generics/T4738171.java ! test/tools/javac/generics/T4739399.java ! test/tools/javac/generics/T4757416.java ! test/tools/javac/generics/T4784207a.java ! test/tools/javac/generics/T4784219.java ! test/tools/javac/generics/T5011073.java ! test/tools/javac/generics/T5094318.java ! test/tools/javac/generics/TyparamLit.java ! test/tools/javac/generics/TyparamStaticScope.java ! test/tools/javac/generics/TyparamStaticScope2.java ! test/tools/javac/generics/UncheckedArray.java ! test/tools/javac/generics/UncheckedConstructor.java ! test/tools/javac/generics/UncheckedCovariance.java ! test/tools/javac/generics/UnsoundInference.java ! test/tools/javac/generics/Varargs.java ! test/tools/javac/generics/Varargs2.java ! test/tools/javac/generics/WrongNew.java ! test/tools/javac/generics/abstract/T4717181c.java ! test/tools/javac/generics/bridge1/D.java ! test/tools/javac/generics/classreader/HArrayMethod.java ! test/tools/javac/generics/compat/CovariantCompat1.java ! test/tools/javac/generics/compat/OverrideBridge1.java ! test/tools/javac/generics/forwardSeparateBound/ForwardSeparateBound2.java ! test/tools/javac/generics/genericAbstract/A.java ! test/tools/javac/generics/odersky/BadTest.java ! test/tools/javac/generics/odersky/BadTest2.java ! test/tools/javac/generics/odersky/BadTest3.java ! test/tools/javac/generics/odersky/BadTest4.java ! test/tools/javac/generics/odersky/Test.java ! test/tools/javac/generics/odersky/Test2.java ! test/tools/javac/generics/odersky/Test3.java ! test/tools/javac/generics/odersky/Test4.java ! test/tools/javac/generics/parametricException/J.java ! test/tools/javac/generics/rare/Rare1.java ! test/tools/javac/generics/rare/Rare10.java ! test/tools/javac/generics/rare/Rare11.java ! test/tools/javac/generics/rare/Rare2.java ! test/tools/javac/generics/rare/Rare3.java ! test/tools/javac/generics/rare/Rare4.java ! test/tools/javac/generics/rare/Rare5.java ! test/tools/javac/generics/rare/Rare6.java ! test/tools/javac/generics/rare/Rare7.java ! test/tools/javac/generics/rare/Rare8.java ! test/tools/javac/generics/rare/Rare9.java ! test/tools/javac/generics/rawSeparate/RetroLexer.java ! test/tools/javac/generics/typeargs/Basic.java ! test/tools/javac/generics/typeargs/Metharg1.java ! test/tools/javac/generics/typeargs/Metharg2.java ! test/tools/javac/generics/typeargs/Newarg1.java ! test/tools/javac/generics/typeargs/Newarg2.java ! test/tools/javac/generics/typeargs/Superarg1.java ! test/tools/javac/generics/typeargs/Superarg2.java ! test/tools/javac/generics/typeargs/ThisArg.java ! test/tools/javac/generics/typevars/4856983/T4856983.java ! test/tools/javac/generics/typevars/4856983/T4856983a.java ! test/tools/javac/generics/typevars/4856983/T4856983b.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes1.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes2.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes3.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes4.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes5.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes6.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes7.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes8.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes9.java ! test/tools/javac/generics/wildcards/AssignmentSameType1.java ! test/tools/javac/generics/wildcards/AssignmentSameType2.java ! test/tools/javac/generics/wildcards/AssignmentSameType3.java ! test/tools/javac/generics/wildcards/AssignmentSameType4.java ! test/tools/javac/generics/wildcards/AssignmentSameType5.java ! test/tools/javac/generics/wildcards/AssignmentSameType6.java ! test/tools/javac/generics/wildcards/AssignmentSameType7.java ! test/tools/javac/generics/wildcards/AssignmentSameType8.java ! test/tools/javac/generics/wildcards/BoundBug.java ! test/tools/javac/generics/wildcards/ContraArg.java ! test/tools/javac/generics/wildcards/T5097548.java ! test/tools/javac/generics/wildcards/T5097548b.java ! test/tools/javac/generics/wildcards/UnboundArray.java ! test/tools/javac/generics/wildcards/neg/AmbiguousCast.java ! test/tools/javac/generics/wildcards/neg/Capture.java ! test/tools/javac/generics/wildcards/neg/CastFail1.java ! test/tools/javac/generics/wildcards/neg/CastFail10.java ! test/tools/javac/generics/wildcards/neg/CastFail11.java ! test/tools/javac/generics/wildcards/neg/CastFail12.java ! test/tools/javac/generics/wildcards/neg/CastFail13.java ! test/tools/javac/generics/wildcards/neg/CastFail14.java ! test/tools/javac/generics/wildcards/neg/CastFail15.java ! test/tools/javac/generics/wildcards/neg/CastFail16.java ! test/tools/javac/generics/wildcards/neg/CastFail17.java ! test/tools/javac/generics/wildcards/neg/CastFail18.java ! test/tools/javac/generics/wildcards/neg/CastFail19.java ! test/tools/javac/generics/wildcards/neg/CastFail2.java ! test/tools/javac/generics/wildcards/neg/CastFail20.java ! test/tools/javac/generics/wildcards/neg/CastFail21.java ! test/tools/javac/generics/wildcards/neg/CastFail3.java ! test/tools/javac/generics/wildcards/neg/CastFail4.java ! test/tools/javac/generics/wildcards/neg/CastFail5.java ! test/tools/javac/generics/wildcards/neg/CastFail6.java ! test/tools/javac/generics/wildcards/neg/CastFail7.java ! test/tools/javac/generics/wildcards/neg/CastFail8.java ! test/tools/javac/generics/wildcards/neg/CastFail9.java ! test/tools/javac/generics/wildcards/neg/CastWarn10.java ! test/tools/javac/generics/wildcards/neg/CastWarn11.java ! test/tools/javac/generics/wildcards/neg/CastWarn12.java ! test/tools/javac/generics/wildcards/neg/CastWarn13.java ! test/tools/javac/generics/wildcards/neg/CastWarn14.java ! test/tools/javac/generics/wildcards/neg/CastWarn2.java ! test/tools/javac/generics/wildcards/neg/CastWarn3.java ! test/tools/javac/generics/wildcards/neg/CastWarn4.java ! test/tools/javac/generics/wildcards/neg/CastWarn5.java ! test/tools/javac/generics/wildcards/neg/CastWarn6.java ! test/tools/javac/generics/wildcards/neg/CastWarn7.java ! test/tools/javac/generics/wildcards/neg/CastWarn8.java ! test/tools/javac/generics/wildcards/neg/CastWarn9.java ! test/tools/javac/generics/wildcards/neg/ParamCast.java ! test/tools/javac/generics/wildcards/neg/Readonly.java ! test/tools/javac/generics/wildcards/neg/Unbounded.java ! test/tools/javac/generics/wildcards/pos/AmbiguousCast2.java ! test/tools/javac/generics/wildcards/pos/BoundsCollision.java ! test/tools/javac/generics/wildcards/pos/Capture.java ! test/tools/javac/generics/wildcards/pos/CastTest.java ! test/tools/javac/generics/wildcards/pos/InstanceOf.java ! test/tools/javac/generics/wildcards/pos/ParamCast.java ! test/tools/javac/generics/wildcards/pos/RvalConversion.java ! test/tools/javac/generics/wildcards/pos/UncheckedCast1.java ! test/tools/javac/importscope/A.java ! test/tools/javac/limits/FinallyNesting.java ! test/tools/javac/lint/Unchecked.java ! test/tools/javac/miranda/T4711325.java ! test/tools/javac/mixedTarget/CompatibleAbstracts1.java ! test/tools/javac/mixedTarget/ExtendCovariant2.java ! test/tools/javac/overload/T5090220.java ! test/tools/javac/processing/environment/TestSourceVersion.java ! test/tools/javac/stackmap/UninitThis.java ! test/tools/javac/staticImport/Ambig1.java ! test/tools/javac/staticImport/ImportInherit.java ! test/tools/javac/staticImport/ImportPrivate.java ! test/tools/javac/staticImport/PrivateStaticImport.java ! test/tools/javac/staticImport/Shadow.java ! test/tools/javac/staticImport/StaticImport.java ! test/tools/javac/staticImport/StaticImport2.java ! test/tools/javac/unicode/Unmappable.java ! test/tools/javac/varargs/Anon.java ! test/tools/javac/varargs/BadSyntax2.java ! test/tools/javac/varargs/Varargs1.java ! test/tools/javac/varargs/VarargsOverride.java ! test/tools/javac/varargs/Warn1.java ! test/tools/javac/varargs/Warn2.java ! test/tools/javac/varargs/warning/Warn2.java ! test/tools/javac/varargs/warning/Warn3.java ! test/tools/javadoc/LangVers.java ! test/tools/javadoc/annotations/annotateMethodsFields/Main.java ! test/tools/javadoc/annotations/annotatePackage/Main.java ! test/tools/javadoc/annotations/annotateParams/Main.java ! test/tools/javadoc/annotations/defaults/Main.java ! test/tools/javadoc/annotations/elementTypes/Main.java ! test/tools/javadoc/annotations/shortcuts/Main.java ! test/tools/javadoc/enum/docComments/Main.java ! test/tools/javadoc/enum/enumType/Main.java ! test/tools/javadoc/generics/genericClass/Main.java ! test/tools/javadoc/generics/genericInnerAndOuter/Main.java ! test/tools/javadoc/generics/genericInterface/Main.java ! test/tools/javadoc/generics/genericMethod/Main.java ! test/tools/javadoc/generics/genericSuper/Main.java ! test/tools/javadoc/generics/supertypes/Main.java ! test/tools/javadoc/generics/throwsGeneric/Main.java ! test/tools/javadoc/generics/tparamCycle/Main.java ! test/tools/javadoc/generics/tparamTagOnMethod/Main.java ! test/tools/javadoc/generics/tparamTagOnType/Main.java ! test/tools/javadoc/generics/wildcards/Main.java ! test/tools/javadoc/lib/Tester.java ! test/tools/javadoc/varArgs/Main.java Changeset: d4828eba4939 Author: jjg Date: 2009-05-28 09:49 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/d4828eba4939 6802102: unignore @ignored tests where possible Reviewed-by: mcimadamore ! test/tools/javac/T6405099.java ! test/tools/javac/api/6431257/T6431257.java ! test/tools/javac/api/TestJavacTaskScanner.java ! test/tools/javac/code/ArrayClone.java - test/tools/javac/code/ArrayClone.sh ! test/tools/javac/generics/inference/6365166/NewTest.java Changeset: 47cf04bb80c9 Author: jjg Date: 2009-05-29 16:26 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/47cf04bb80c9 6838199: remove support for old javap Reviewed-by: ohair, mcimadamore ! make/build.xml ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/Main.java ! src/share/classes/com/sun/tools/javap/resources/javap.properties - src/share/classes/sun/tools/javap/AttrData.java - src/share/classes/sun/tools/javap/CPX.java - src/share/classes/sun/tools/javap/CPX2.java - src/share/classes/sun/tools/javap/ClassData.java - src/share/classes/sun/tools/javap/Constants.java - src/share/classes/sun/tools/javap/FieldData.java - src/share/classes/sun/tools/javap/InnerClassData.java - src/share/classes/sun/tools/javap/JavapEnvironment.java - src/share/classes/sun/tools/javap/JavapPrinter.java - src/share/classes/sun/tools/javap/LineNumData.java - src/share/classes/sun/tools/javap/LocVarData.java - src/share/classes/sun/tools/javap/Main.java - src/share/classes/sun/tools/javap/MethodData.java - src/share/classes/sun/tools/javap/RuntimeConstants.java - src/share/classes/sun/tools/javap/StackMapData.java - src/share/classes/sun/tools/javap/StackMapTableData.java - src/share/classes/sun/tools/javap/Tables.java - src/share/classes/sun/tools/javap/TrapData.java - src/share/classes/sun/tools/javap/TypeSignature.java ! test/tools/javap/ExtPath.java - test/tools/javap/ListTest.java - test/tools/javap/OptionTest.java Changeset: 163f5d75f77a Author: tbell Date: 2009-06-11 21:35 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/163f5d75f77a Merge ! make/Makefile ! make/build.xml - src/share/classes/sun/tools/javap/AttrData.java - src/share/classes/sun/tools/javap/CPX.java - src/share/classes/sun/tools/javap/CPX2.java - src/share/classes/sun/tools/javap/ClassData.java - src/share/classes/sun/tools/javap/Constants.java - src/share/classes/sun/tools/javap/FieldData.java - src/share/classes/sun/tools/javap/InnerClassData.java - src/share/classes/sun/tools/javap/JavapEnvironment.java - src/share/classes/sun/tools/javap/JavapPrinter.java - src/share/classes/sun/tools/javap/LineNumData.java - src/share/classes/sun/tools/javap/LocVarData.java - src/share/classes/sun/tools/javap/Main.java - src/share/classes/sun/tools/javap/MethodData.java - src/share/classes/sun/tools/javap/RuntimeConstants.java - src/share/classes/sun/tools/javap/StackMapData.java - src/share/classes/sun/tools/javap/StackMapTableData.java - src/share/classes/sun/tools/javap/Tables.java - src/share/classes/sun/tools/javap/TrapData.java - src/share/classes/sun/tools/javap/TypeSignature.java - test/tools/javac/code/ArrayClone.sh - test/tools/javap/ListTest.java - test/tools/javap/OptionTest.java Changeset: 6855e5aa3348 Author: tbell Date: 2009-06-21 23:55 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/6855e5aa3348 Merge From kurt at intricatesoftware.com Wed Jun 24 16:35:30 2009 From: kurt at intricatesoftware.com (Kurt Miller) Date: Wed, 24 Jun 2009 19:35:30 -0400 Subject: [OpenJDK 2D-Dev] _LITTLE_ENDIAN In-Reply-To: <4A414D3C.2050101@sun.com> References: <4A40CB2F.6000208@aicas.com> <4A4148DD.9090307@sun.com> <4A414D3C.2050101@sun.com> Message-ID: <200906241935.30778.kurt@intricatesoftware.com> The BSD's also always define _LITTLE_ENDIAN. Typically something like this: #define _LITTLE_ENDIAN 1234 /* LSB first: i386, vax */ #define _BIG_ENDIAN 4321 /* MSB first: 68000, ibm, net */ #define _PDP_ENDIAN 3412 /* LSB first in word, MSW first in long */ #define _BYTE_ORDER _LITTLE_ENDIAN where byte order is checked by comparing _BYTE_ORDER to _LITTLE_ENDIAN or _BIG_ENDIAN. Renaming the _LITTLE_ENDIAN var in OpenJDK would help the BSD's port to sparc64 for example. Regards, -Kurt On Tuesday 23 June 2009 5:46:36 pm Kelly O'Hair wrote: > Someone would need to make darn sure that ALL uses of the old > name have been changed. I counted 362 references to this variable > in the openjdk7 repositories, I assume a similar number in openjdk6. > The closed jdk sources have an additional 13 references to this > _LITTLE_ENDIAN name Sun would need to change too. > > Do you really want to change 362+ lines for this name change? > > -kto > > > Roman Kennke wrote: > > Hi, > > > > first of all, I think this is a LCMS problem, so we should think about > > how to fix this _upstream_, otherwise we end up maintaining a patched > > version of lcms *shudder*. > > > > Then I don't think it's a good idea to depend on such 'internal' > > defines. One OS defines or not _LITTLE_ENDIAN, others (like VxWorks) > > define it either as 0 or 1, depending on the systems, even others don't > > care and define __LITTLE_ENDIAN or whatever. IMO, a better way to solve > > this is to make LCMS check LCMS_LITTLE_ENDIAN, and define it somewhere. > > Configure based builds would figure this out when running configure. > > OpenJDK would set this in the files mentioned below, instead of setting > > _LITTLE_ENDIAN. AFAICS, this is the only way to make sure we don't > > conflict with any internal settings of some OS include or compiler. > > > >> For better or worse, there seems to be > >> ./common/Defs-linux.gmk:CFLAGS_REQUIRED_amd64 += > >> -fno-omit-frame-pointer -D_LITTLE_ENDIAN > >> ./common/Defs-linux.gmk:CFLAGS_REQUIRED_i586 += > >> -fno-omit-frame-pointer -D_LITTLE_ENDIAN > >> ./common/Defs-linux.gmk:CFLAGS_REQUIRED_ia64 += > >> -fno-omit-frame-pointer -D_LITTLE_ENDIAN > >> ./common/Defs-solaris.gmk: # The macro _LITTLE_ENDIAN needs to be > >> defined the same to avoid the > >> ./common/Defs-solaris.gmk: # Sun C compiler warning message: > >> warning: macro redefined: _LITTLE_ENDIAN > >> ./common/Defs-solaris.gmk: CPPFLAGS_COMMON += -DcpuIntel > >> -D_LITTLE_ENDIAN= -D$(LIBARCH) > >> ./common/Defs-windows.gmk:CPPFLAGS_COMMON = -DWIN32 -DIAL > >> -D_LITTLE_ENDIAN > >> ./netbeans/awt2d/README: D3D_OVERLOADS; UNICODE; _UNICODE; WIN32; > >> IAL; _LITTLE_ENDIAN; WIN32; _X86_; > > > > > > /Roman >