From Yuri.Nesterenko at Sun.COM Mon May 4 08:06:19 2009 From: Yuri.Nesterenko at Sun.COM (Yuri Nesterenko) Date: Mon, 04 May 2009 19:06:19 +0400 Subject: No changes so far for jdk7 b59 Message-ID: <49FF046B.7010406@sun.com> Dear colleagues, I don't see any changes in Awt and Swing forests of jdk7 since the last pre-integration build. It was for b57. Normally, we allow a week for pre-integration testing, so tomorrow is a deadline for fixes targeted for b59. The next our turn will be b61 scheduled on May 26-27 with a deadline on May 19-th. Thanks, -yan From fbrunnerlist at gmx.ch Mon May 4 08:14:53 2009 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Mon, 04 May 2009 17:14:53 +0200 Subject: [PATCH] 6179357: Generics: JList In-Reply-To: <49E4AFF3.20706@sun.com> References: <200903222003.05081.fbrunnerlist@gmx.ch> <200903281145.32982.fbrunnerlist@gmx.ch> <49D0B01A.1070508@sun.com> <200904132306.27599.fbrunnerlist@gmx.ch> <49E48E16.8060706@sun.com> <49E49456.9090203@gmx.ch> <49E497D0.7010704@sun.com> <49E4AE80.8060407@gmx.ch> <49E4AFF3.20706@sun.com> Message-ID: <49FF066D.6000200@gmx.ch> Hi Pavel, hi Alexander, I'm back from holiday. What is the status of this patch? Any news? -Florian Alexander Potochkin schrieb: > Hello Florian > >> Great! :-) >> >> In the case of other issues please note that I'm on holiday until the >> end of next week. > > Have a nice holiday! > > (I am reviewing the fix right now) > > Thanks > alexp > >> >> -Florian >> >> Pavel Porvatov schrieb: >>> Hi Florian, >>> >>>> Hi Pavel, >>>> >>>> I agree that we should avoid to mix several different fixes in one >>>> fix, but since in this fix we change >>>> >>>> AbstractListModel to AbstractListModel >>>> and >>>> JList(ListModel dataModel) to JList(ListModel dataModel) >>>> >>>> I think we should also change usages of AbstractListModel such as >>>> "this (new AbstractListModel()...)" to "this (new >>>> AbstractListModel()...)" to avoid warnings. >>> Ok, then it will not be a problem. Let's include this change in your >>> fix. Therefore all my comments are gone and I'm going to start our >>> internal process to commit your fix. >>> >>> Thanks, Pavel. >>> >>>> >>>> If you don't agree: >>>> There are several places where I changed the usage of now >>>> generified classes to the generic variant. Which ones should I >>>> change back? Only this case? >>> >> > From Alexander.Potochkin at Sun.COM Mon May 4 08:30:16 2009 From: Alexander.Potochkin at Sun.COM (Alexander Potochkin) Date: Mon, 04 May 2009 19:30:16 +0400 Subject: [PATCH] 6179357: Generics: JList In-Reply-To: <49FF066D.6000200@gmx.ch> References: <200903222003.05081.fbrunnerlist@gmx.ch> <200903281145.32982.fbrunnerlist@gmx.ch> <49D0B01A.1070508@sun.com> <200904132306.27599.fbrunnerlist@gmx.ch> <49E48E16.8060706@sun.com> <49E49456.9090203@gmx.ch> <49E497D0.7010704@sun.com> <49E4AE80.8060407@gmx.ch> <49E4AFF3.20706@sun.com> <49FF066D.6000200@gmx.ch> Message-ID: <49FF0A08.4020007@sun.com> Hello Florian > Hi Pavel, hi Alexander, > > I'm back from holiday. Wow, how was the vacation? > > What is the status of this patch? Any news? I sent some comments about your recent patch to Pavel Tomorrow, we'll come back to this issue again. He is going to send an update to you. Thanks alexp > > -Florian > > Alexander Potochkin schrieb: >> Hello Florian >> >>> Great! :-) >>> >>> In the case of other issues please note that I'm on holiday until the >>> end of next week. >> >> Have a nice holiday! >> >> (I am reviewing the fix right now) >> >> Thanks >> alexp >> >>> >>> -Florian >>> >>> Pavel Porvatov schrieb: >>>> Hi Florian, >>>> >>>>> Hi Pavel, >>>>> >>>>> I agree that we should avoid to mix several different fixes in one >>>>> fix, but since in this fix we change >>>>> >>>>> AbstractListModel to AbstractListModel >>>>> and >>>>> JList(ListModel dataModel) to JList(ListModel dataModel) >>>>> >>>>> I think we should also change usages of AbstractListModel such as >>>>> "this (new AbstractListModel()...)" to "this (new >>>>> AbstractListModel()...)" to avoid warnings. >>>> Ok, then it will not be a problem. Let's include this change in your >>>> fix. Therefore all my comments are gone and I'm going to start our >>>> internal process to commit your fix. >>>> >>>> Thanks, Pavel. >>>> >>>>> >>>>> If you don't agree: >>>>> There are several places where I changed the usage of now >>>>> generified classes to the generic variant. Which ones should I >>>>> change back? Only this case? >>>> >>> >> > From fbrunnerlist at gmx.ch Mon May 4 11:51:56 2009 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Mon, 04 May 2009 20:51:56 +0200 Subject: [PATCH] 6179357: Generics: JList In-Reply-To: <49FF0A08.4020007@sun.com> References: <200903222003.05081.fbrunnerlist@gmx.ch> <200903281145.32982.fbrunnerlist@gmx.ch> <49D0B01A.1070508@sun.com> <200904132306.27599.fbrunnerlist@gmx.ch> <49E48E16.8060706@sun.com> <49E49456.9090203@gmx.ch> <49E497D0.7010704@sun.com> <49E4AE80.8060407@gmx.ch> <49E4AFF3.20706@sun.com> <49FF066D.6000200@gmx.ch> <49FF0A08.4020007@sun.com> Message-ID: <49FF394C.1020304@gmx.ch> Hi Alexander, > Hello Florian > >> Hi Pavel, hi Alexander, >> >> I'm back from holiday. > > Wow, how was the vacation? Thanks for asking, I spent some nice days in Poland. :-) > >> >> What is the status of this patch? Any news? > > I sent some comments about your recent patch to Pavel > > Tomorrow, we'll come back to this issue again. > He is going to send an update to you. Great. Thanks. -Florian > > Thanks > alexp > >> >> -Florian >> >> Alexander Potochkin schrieb: >>> Hello Florian >>> >>>> Great! :-) >>>> >>>> In the case of other issues please note that I'm on holiday until >>>> the end of next week. >>> >>> Have a nice holiday! >>> >>> (I am reviewing the fix right now) >>> >>> Thanks >>> alexp >>> >>>> >>>> -Florian >>>> >>>> Pavel Porvatov schrieb: >>>>> Hi Florian, >>>>> >>>>>> Hi Pavel, >>>>>> >>>>>> I agree that we should avoid to mix several different fixes in >>>>>> one fix, but since in this fix we change >>>>>> >>>>>> AbstractListModel to AbstractListModel >>>>>> and >>>>>> JList(ListModel dataModel) to JList(ListModel dataModel) >>>>>> >>>>>> I think we should also change usages of AbstractListModel such >>>>>> as "this (new AbstractListModel()...)" to "this (new >>>>>> AbstractListModel()...)" to avoid warnings. >>>>> Ok, then it will not be a problem. Let's include this change in >>>>> your fix. Therefore all my comments are gone and I'm going to >>>>> start our internal process to commit your fix. >>>>> >>>>> Thanks, Pavel. >>>>> >>>>>> >>>>>> If you don't agree: >>>>>> There are several places where I changed the usage of now >>>>>> generified classes to the generic variant. Which ones should I >>>>>> change back? Only this case? >>>>> >>>> >>> >> > From Pavel.Porvatov at Sun.COM Tue May 5 09:17:22 2009 From: Pavel.Porvatov at Sun.COM (Pavel Porvatov) Date: Tue, 05 May 2009 20:17:22 +0400 Subject: [PATCH] 6179357: Generics: JList In-Reply-To: <49FF394C.1020304@gmx.ch> References: <200903222003.05081.fbrunnerlist@gmx.ch> <200903281145.32982.fbrunnerlist@gmx.ch> <49D0B01A.1070508@sun.com> <200904132306.27599.fbrunnerlist@gmx.ch> <49E48E16.8060706@sun.com> <49E49456.9090203@gmx.ch> <49E497D0.7010704@sun.com> <49E4AE80.8060407@gmx.ch> <49E4AFF3.20706@sun.com> <49FF066D.6000200@gmx.ch> <49FF0A08.4020007@sun.com> <49FF394C.1020304@gmx.ch> Message-ID: <4A006692.1070103@sun.com> Hi Florian, > Hi Alexander, > >> Hello Florian >> >>> Hi Pavel, hi Alexander, >>> >>> I'm back from holiday. >> >> Wow, how was the vacation? > > Thanks for asking, I spent some nice days in Poland. :-) >> >>> >>> What is the status of this patch? Any news? >> >> I sent some comments about your recent patch to Pavel >> >> Tomorrow, we'll come back to this issue again. >> He is going to send an update to you. > > Great. I got response from Alexander about your fix and now I'm investigating possible problems and mistakes that Alexander found out. Regards, Pavel > > Thanks. > -Florian > >> >> Thanks >> alexp >> >>> >>> -Florian >>> >>> Alexander Potochkin schrieb: >>>> Hello Florian >>>> >>>>> Great! :-) >>>>> >>>>> In the case of other issues please note that I'm on holiday until >>>>> the end of next week. >>>> >>>> Have a nice holiday! >>>> >>>> (I am reviewing the fix right now) >>>> >>>> Thanks >>>> alexp >>>> >>>>> >>>>> -Florian >>>>> >>>>> Pavel Porvatov schrieb: >>>>>> Hi Florian, >>>>>> >>>>>>> Hi Pavel, >>>>>>> >>>>>>> I agree that we should avoid to mix several different fixes in >>>>>>> one fix, but since in this fix we change >>>>>>> >>>>>>> AbstractListModel to AbstractListModel >>>>>>> and >>>>>>> JList(ListModel dataModel) to JList(ListModel dataModel) >>>>>>> >>>>>>> I think we should also change usages of AbstractListModel such >>>>>>> as "this (new AbstractListModel()...)" to "this (new >>>>>>> AbstractListModel()...)" to avoid warnings. >>>>>> Ok, then it will not be a problem. Let's include this change in >>>>>> your fix. Therefore all my comments are gone and I'm going to >>>>>> start our internal process to commit your fix. >>>>>> >>>>>> Thanks, Pavel. >>>>>> >>>>>>> >>>>>>> If you don't agree: >>>>>>> There are several places where I changed the usage of now >>>>>>> generified classes to the generic variant. Which ones should I >>>>>>> change back? Only this case? >>>>>> >>>>> >>>> >>> >> > From yuka.kamiya at sun.com Mon May 11 23:38:02 2009 From: yuka.kamiya at sun.com (yuka.kamiya at sun.com) Date: Tue, 12 May 2009 06:38:02 +0000 Subject: hg: jdk7/swing/jdk: 6834474: (tz) Support tzdata2009g Message-ID: <20090512063836.500DCEA6E@hg.openjdk.java.net> Changeset: f29cd35647b1 Author: peytoia Date: 2009-05-12 15:21 +0900 URL: http://hg.openjdk.java.net/jdk7/swing/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 From yuri.nesterenko at sun.com Thu May 14 01:57:12 2009 From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com) Date: Thu, 14 May 2009 08:57:12 +0000 Subject: hg: jdk7/swing: 2 new changesets Message-ID: <20090514085712.B32DFED58@hg.openjdk.java.net> Changeset: 59b497130f82 Author: xdono Date: 2009-04-30 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/rev/59b497130f82 Added tag jdk7-b57 for changeset ffd09e767dfa ! .hgtags Changeset: 030142474602 Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/rev/030142474602 Added tag jdk7-b58 for changeset 59b497130f82 ! .hgtags From yuri.nesterenko at sun.com Thu May 14 02:01:05 2009 From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com) Date: Thu, 14 May 2009 09:01:05 +0000 Subject: hg: jdk7/swing/corba: 4 new changesets Message-ID: <20090514090108.D9B13ED5D@hg.openjdk.java.net> Changeset: 080ecdea3020 Author: xdono Date: 2009-04-30 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/corba/rev/080ecdea3020 Added tag jdk7-b57 for changeset 972c6157fae5 ! .hgtags Changeset: e149090eb21a Author: tbell Date: 2009-05-04 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/corba/rev/e149090eb21a 6529590: flaw in com.sun.corba.se.impl.presentation.rmi.IDLNameTranslatorImpl Reviewed-by: darcy ! make/com/sun/corba/se/sources/Makefile ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java ! src/share/classes/com/sun/tools/corba/se/idl/first.set ! src/share/classes/com/sun/tools/corba/se/idl/follow.set ! src/share/classes/com/sun/tools/corba/se/idl/grammar.idl ! src/share/classes/com/sun/tools/corba/se/idl/grammar3.idl ! src/share/classes/com/sun/tools/corba/se/idl/idl.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp Changeset: 2e3b8edab3ef Author: tbell Date: 2009-05-04 22:12 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/corba/rev/2e3b8edab3ef Merge Changeset: 7e6b2b55c00c Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/corba/rev/7e6b2b55c00c Added tag jdk7-b58 for changeset 2e3b8edab3ef ! .hgtags From yuri.nesterenko at sun.com Thu May 14 02:07:37 2009 From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com) Date: Thu, 14 May 2009 09:07:37 +0000 Subject: hg: jdk7/swing/hotspot: 28 new changesets Message-ID: <20090514090829.1B781ED62@hg.openjdk.java.net> Changeset: 53d9bf689e80 Author: xdono Date: 2009-04-30 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/53d9bf689e80 Added tag jdk7-b57 for changeset f4cbf78110c7 ! .hgtags Changeset: 313b56165de7 Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/313b56165de7 Added tag jdk7-b58 for changeset 53d9bf689e80 ! .hgtags Changeset: c8379544879a Author: ohair Date: 2009-04-29 17:30 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/c8379544879a 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Reviewed-by: kvn - make/jprt.config ! make/jprt.properties Changeset: 61c5604c8422 Author: jcoomes Date: 2009-04-30 09:53 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/61c5604c8422 Merge - make/jprt.config Changeset: 45463a04ca27 Author: kvn Date: 2009-04-29 12:58 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/45463a04ca27 6834177: Running jsynprog on Solaris Nevada can cause JVM crash Summary: Use CodeCache buffer blob instead of static buffer in AdapterHandlerLibrary. Reviewed-by: never ! src/share/vm/runtime/dtraceJSDT.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: f36f12d01311 Author: kvn Date: 2009-04-30 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/f36f12d01311 Merge Changeset: af5d39ca39a3 Author: kvn Date: 2009-04-30 15:57 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/af5d39ca39a3 6835796: Fedora 9 linux_i586-fastdebug-c2-runThese_Xcomp times out Summary: Switch off GCC 4.3.0 optimized compilation for mulnode.o. Reviewed-by: johnc ! make/jprt.properties ! make/linux/makefiles/gcc.make Changeset: 2b6c55e36143 Author: tonyp Date: 2009-04-23 16:58 -0400 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/2b6c55e36143 6829013: G1: set the default value of G1VerifyConcMarkPrintRechable to false Summary: Turn off G1VerifyConcMarkPrintReachable by default to minimize the amount of verbose output we generate by default. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 4753e4079a5a Author: apetrusenko Date: 2009-04-27 12:33 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/4753e4079a5a Merge Changeset: b803b1b9e206 Author: iveresov Date: 2009-04-27 16:52 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/b803b1b9e206 6819098: G1: reduce RSet scanning times Summary: Added a feedback-driven exponential skipping for parallel RSet scanning. Reviewed-by: tonyp, apetrusenko ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 51285b431bb2 Author: apetrusenko Date: 2009-05-04 02:57 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/51285b431bb2 Merge Changeset: 81a249214991 Author: poonam Date: 2009-05-04 17:58 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/81a249214991 6829234: Refix 6822407 and 6812971 Summary: Fixes two SA issues 6822407 and 6812971 Reviewed-by: swamyv, acorn, kvn, coleenp ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java Changeset: c8f1f4de26c9 Author: kamg Date: 2009-05-07 11:44 -0400 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/c8f1f4de26c9 Merge Changeset: 20c6f43950b5 Author: johnc Date: 2009-04-30 15:07 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/20c6f43950b5 6490395: G1: Tidy up command line flags. Summary: Change G1 flag names to be more consistent and disable some in 'product' mode. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a2957df801a1 Author: johnc Date: 2009-05-05 22:15 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/a2957df801a1 6833576: G1: assert illegal index, growableArray.hpp:186 Summary: The code that calculates the heap region index for an object address incorrectly used signed arithmetic. Reviewed-by: jcoomes, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp Changeset: a58ad611cc63 Author: jcoomes Date: 2009-05-07 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/a58ad611cc63 Merge Changeset: 2b25645dab33 Author: never Date: 2009-05-04 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/2b25645dab33 6837224: libsaproc.so on linux needs version of 6799141 Reviewed-by: kvn ! agent/src/os/linux/Makefile Changeset: 36ee9b69616e Author: cfang Date: 2009-05-05 11:02 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/36ee9b69616e 6833879: Assigning positive zero is ignored when old value is negative zero Summary: Don't perform CMOVE identity optimization for floating point types Reviewed-by: kvn, never ! src/share/vm/opto/connode.cpp Changeset: cecd04fc6f93 Author: twisti Date: 2009-05-06 12:04 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/cecd04fc6f93 6837011: SIGSEGV in PhaseIdealLoop in 32bit jvm Summary: The CR's test crashes with SIGSEGV when running with "-server -Xcomp" using using 32bit jvm. Reviewed-by: kvn, never, rasbold ! src/share/vm/opto/divnode.cpp + test/compiler/6837011/Test6837011.java Changeset: f96f285ed3dd Author: never Date: 2009-05-06 17:52 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/f96f285ed3dd 6838154: make/linux/makefiles/sa.make needs hash-style fix Reviewed-by: kvn, jrose ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make Changeset: 9b3a41ccc927 Author: kvn Date: 2009-05-07 17:09 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/9b3a41ccc927 Merge Changeset: 8078631685e4 Author: trims Date: 2009-05-07 21:33 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/8078631685e4 Merge - make/jprt.config Changeset: fede134842ab Author: trims Date: 2009-05-07 21:35 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/fede134842ab 6838819: Bump the HS16 build number to 03 Summary: Update the HS16 build number to 03 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 622212a69394 Author: iveresov Date: 2009-05-08 15:20 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/622212a69394 6838842: NUMA allocator: Segfault during startup on Linux Summary: Restored os::free_memory() semantics Reviewed-by: apetrusenko ! src/os/linux/vm/os_linux.cpp Changeset: 7e1dbef51011 Author: trims Date: 2009-05-08 19:50 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/7e1dbef51011 Merge Changeset: cf71f149d7ae Author: iveresov Date: 2009-05-12 15:55 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/cf71f149d7ae 6840196: NUMA allocator: crash in fastdebug during startup on Linux Summary: With libnuma >1.2 explicity use 1.1 symbols Reviewed-by: ysr ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 07c1c01e0315 Author: trims Date: 2009-05-13 08:40 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/07c1c01e0315 Merge Changeset: c55be0c7bd32 Author: trims Date: 2009-05-13 08:46 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/hotspot/rev/c55be0c7bd32 Merge From yuri.nesterenko at sun.com Thu May 14 02:18:39 2009 From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com) Date: Thu, 14 May 2009 09:18:39 +0000 Subject: hg: jdk7/swing/jaxp: 4 new changesets Message-ID: <20090514091845.35882ED6B@hg.openjdk.java.net> Changeset: fb846b3f9450 Author: xdono Date: 2009-04-30 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jaxp/rev/fb846b3f9450 Added tag jdk7-b57 for changeset e4851e9f7be2 ! .hgtags Changeset: 3abf80631f99 Author: tbell Date: 2009-05-04 21:10 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jaxp/rev/3abf80631f99 6588002: XSLTProcessorApplet still allows reading from forbidden URLs Reviewed-by: darcy - 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: 13bf67d8c634 Author: tbell Date: 2009-05-04 22:13 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jaxp/rev/13bf67d8c634 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: 75113d7ce083 Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jaxp/rev/75113d7ce083 Added tag jdk7-b58 for changeset 13bf67d8c634 ! .hgtags From yuri.nesterenko at sun.com Thu May 14 02:22:37 2009 From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com) Date: Thu, 14 May 2009 09:22:37 +0000 Subject: hg: jdk7/swing/jaxws: 4 new changesets Message-ID: <20090514092242.46F71ED70@hg.openjdk.java.net> Changeset: c2d622fe401b Author: xdono Date: 2009-04-30 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jaxws/rev/c2d622fe401b Added tag jdk7-b57 for changeset 68257a5eb19a ! .hgtags Changeset: 42dfec6871f6 Author: tbell Date: 2009-05-04 21:10 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jaxws/rev/42dfec6871f6 6658158: Mutable statics in SAAJ (findbugs) 6658163: txw2.DatatypeWriter.BUILDIN is a mutable static (findbugs) Reviewed-by: darcy ! src/share/classes/com/sun/codemodel/internal/JClassContainer.java ! src/share/classes/com/sun/codemodel/internal/JDefinedClass.java ! src/share/classes/com/sun/codemodel/internal/JForEach.java ! src/share/classes/com/sun/codemodel/internal/JMethod.java ! src/share/classes/com/sun/codemodel/internal/JMods.java ! src/share/classes/com/sun/codemodel/internal/util/SingleByteEncoder.java ! src/share/classes/com/sun/codemodel/internal/util/Surrogate.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnection.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/EnvelopeFactory.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ImageDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SAAJMetaFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPPartImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CDATAImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CommentImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/TextImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/name/NameImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Fault1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Header1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/HeaderElement1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Message1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPPart1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Body1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Detail1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Envelope1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Fault1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Header1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/HeaderElement1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPPart1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/RejectDoctypeSaxFilter.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/transform/EfficientStreamingTransformer.java ! src/share/classes/com/sun/xml/internal/txw2/DatatypeWriter.java ! src/share/classes/com/sun/xml/internal/txw2/Document.java Changeset: 5fb4fbea81c3 Author: tbell Date: 2009-05-04 22:14 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jaxws/rev/5fb4fbea81c3 Merge Changeset: f64566bf4c2b Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jaxws/rev/f64566bf4c2b Added tag jdk7-b58 for changeset 5fb4fbea81c3 ! .hgtags From yuri.nesterenko at sun.com Thu May 14 02:28:01 2009 From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com) Date: Thu, 14 May 2009 09:28:01 +0000 Subject: hg: jdk7/swing/jdk: 28 new changesets Message-ID: <20090514093334.296BDED77@hg.openjdk.java.net> Changeset: 6c7c0bccab55 Author: xdono Date: 2009-04-30 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/6c7c0bccab55 Added tag jdk7-b57 for changeset d5a1223e9618 ! .hgtags Changeset: b056c42ea5b4 Author: tbell Date: 2009-05-04 18:28 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/b056c42ea5b4 6837214: Update JDK7 man pages Reviewed-by: darcy, bpatel, tbell Contributed-by: jacob.royal at sun.com ! src/linux/doc/man/appletviewer.1 ! src/linux/doc/man/apt.1 ! src/linux/doc/man/extcheck.1 ! src/linux/doc/man/idlj.1 ! src/linux/doc/man/ja/appletviewer.1 ! src/linux/doc/man/ja/apt.1 ! src/linux/doc/man/ja/extcheck.1 ! src/linux/doc/man/ja/idlj.1 ! src/linux/doc/man/ja/jar.1 ! src/linux/doc/man/ja/jarsigner.1 ! src/linux/doc/man/ja/java.1 ! src/linux/doc/man/ja/javac.1 ! src/linux/doc/man/ja/javadoc.1 ! src/linux/doc/man/ja/javah.1 ! src/linux/doc/man/ja/javap.1 ! src/linux/doc/man/ja/javaws.1 ! src/linux/doc/man/ja/jconsole.1 ! src/linux/doc/man/ja/jdb.1 ! src/linux/doc/man/ja/jhat.1 ! src/linux/doc/man/ja/jinfo.1 ! src/linux/doc/man/ja/jmap.1 ! src/linux/doc/man/ja/jps.1 ! src/linux/doc/man/ja/jrunscript.1 ! src/linux/doc/man/ja/jsadebugd.1 ! src/linux/doc/man/ja/jstack.1 ! src/linux/doc/man/ja/jstat.1 ! src/linux/doc/man/ja/jstatd.1 ! src/linux/doc/man/ja/keytool.1 ! src/linux/doc/man/ja/native2ascii.1 ! src/linux/doc/man/ja/orbd.1 ! src/linux/doc/man/ja/pack200.1 ! src/linux/doc/man/ja/policytool.1 ! src/linux/doc/man/ja/rmic.1 ! src/linux/doc/man/ja/rmid.1 ! src/linux/doc/man/ja/rmiregistry.1 ! src/linux/doc/man/ja/schemagen.1 ! src/linux/doc/man/ja/serialver.1 ! src/linux/doc/man/ja/servertool.1 ! src/linux/doc/man/ja/tnameserv.1 ! src/linux/doc/man/ja/unpack200.1 ! src/linux/doc/man/ja/wsgen.1 ! src/linux/doc/man/ja/wsimport.1 ! src/linux/doc/man/ja/xjc.1 ! src/linux/doc/man/jar.1 ! src/linux/doc/man/jarsigner.1 ! src/linux/doc/man/java.1 ! src/linux/doc/man/javac.1 ! src/linux/doc/man/javadoc.1 ! src/linux/doc/man/javah.1 ! src/linux/doc/man/javap.1 ! src/linux/doc/man/javaws.1 ! src/linux/doc/man/jconsole.1 ! src/linux/doc/man/jdb.1 ! src/linux/doc/man/jhat.1 ! src/linux/doc/man/jinfo.1 ! src/linux/doc/man/jmap.1 ! src/linux/doc/man/jps.1 ! src/linux/doc/man/jrunscript.1 ! src/linux/doc/man/jsadebugd.1 ! src/linux/doc/man/jstack.1 ! src/linux/doc/man/jstat.1 ! src/linux/doc/man/jstatd.1 ! src/linux/doc/man/keytool.1 ! src/linux/doc/man/native2ascii.1 ! src/linux/doc/man/orbd.1 ! src/linux/doc/man/pack200.1 ! src/linux/doc/man/policytool.1 ! src/linux/doc/man/rmic.1 ! src/linux/doc/man/rmid.1 ! src/linux/doc/man/rmiregistry.1 ! src/linux/doc/man/schemagen.1 ! src/linux/doc/man/serialver.1 ! src/linux/doc/man/servertool.1 ! src/linux/doc/man/tnameserv.1 ! src/linux/doc/man/unpack200.1 ! src/linux/doc/man/wsgen.1 ! src/linux/doc/man/wsimport.1 ! src/linux/doc/man/xjc.1 ! src/solaris/doc/sun/man/man1/appletviewer.1 ! src/solaris/doc/sun/man/man1/apt.1 ! src/solaris/doc/sun/man/man1/extcheck.1 ! src/solaris/doc/sun/man/man1/idlj.1 ! src/solaris/doc/sun/man/man1/ja/appletviewer.1 ! src/solaris/doc/sun/man/man1/ja/apt.1 ! src/solaris/doc/sun/man/man1/ja/extcheck.1 ! src/solaris/doc/sun/man/man1/ja/idlj.1 ! src/solaris/doc/sun/man/man1/ja/jar.1 ! src/solaris/doc/sun/man/man1/ja/jarsigner.1 ! src/solaris/doc/sun/man/man1/ja/java.1 ! src/solaris/doc/sun/man/man1/ja/javac.1 ! src/solaris/doc/sun/man/man1/ja/javadoc.1 ! src/solaris/doc/sun/man/man1/ja/javah.1 ! src/solaris/doc/sun/man/man1/ja/javap.1 ! src/solaris/doc/sun/man/man1/ja/javaws.1 ! src/solaris/doc/sun/man/man1/ja/jconsole.1 ! src/solaris/doc/sun/man/man1/ja/jdb.1 ! src/solaris/doc/sun/man/man1/ja/jhat.1 ! src/solaris/doc/sun/man/man1/ja/jinfo.1 ! src/solaris/doc/sun/man/man1/ja/jmap.1 ! src/solaris/doc/sun/man/man1/ja/jps.1 ! src/solaris/doc/sun/man/man1/ja/jrunscript.1 ! src/solaris/doc/sun/man/man1/ja/jsadebugd.1 ! src/solaris/doc/sun/man/man1/ja/jstack.1 ! src/solaris/doc/sun/man/man1/ja/jstat.1 ! src/solaris/doc/sun/man/man1/ja/jstatd.1 ! src/solaris/doc/sun/man/man1/ja/keytool.1 ! src/solaris/doc/sun/man/man1/ja/native2ascii.1 ! src/solaris/doc/sun/man/man1/ja/orbd.1 ! src/solaris/doc/sun/man/man1/ja/pack200.1 ! src/solaris/doc/sun/man/man1/ja/policytool.1 ! src/solaris/doc/sun/man/man1/ja/rmic.1 ! src/solaris/doc/sun/man/man1/ja/rmid.1 ! src/solaris/doc/sun/man/man1/ja/rmiregistry.1 ! src/solaris/doc/sun/man/man1/ja/schemagen.1 ! src/solaris/doc/sun/man/man1/ja/serialver.1 ! src/solaris/doc/sun/man/man1/ja/servertool.1 ! src/solaris/doc/sun/man/man1/ja/tnameserv.1 ! src/solaris/doc/sun/man/man1/ja/unpack200.1 ! src/solaris/doc/sun/man/man1/ja/wsgen.1 ! src/solaris/doc/sun/man/man1/ja/wsimport.1 ! src/solaris/doc/sun/man/man1/ja/xjc.1 ! src/solaris/doc/sun/man/man1/jar.1 ! src/solaris/doc/sun/man/man1/jarsigner.1 ! src/solaris/doc/sun/man/man1/java.1 ! src/solaris/doc/sun/man/man1/javac.1 ! src/solaris/doc/sun/man/man1/javadoc.1 ! src/solaris/doc/sun/man/man1/javah.1 ! src/solaris/doc/sun/man/man1/javap.1 ! src/solaris/doc/sun/man/man1/javaws.1 ! src/solaris/doc/sun/man/man1/jconsole.1 ! src/solaris/doc/sun/man/man1/jdb.1 ! src/solaris/doc/sun/man/man1/jhat.1 ! src/solaris/doc/sun/man/man1/jinfo.1 ! src/solaris/doc/sun/man/man1/jmap.1 ! src/solaris/doc/sun/man/man1/jps.1 ! src/solaris/doc/sun/man/man1/jrunscript.1 ! src/solaris/doc/sun/man/man1/jsadebugd.1 ! src/solaris/doc/sun/man/man1/jstack.1 ! src/solaris/doc/sun/man/man1/jstat.1 ! src/solaris/doc/sun/man/man1/jstatd.1 ! src/solaris/doc/sun/man/man1/keytool.1 ! src/solaris/doc/sun/man/man1/native2ascii.1 ! src/solaris/doc/sun/man/man1/orbd.1 ! src/solaris/doc/sun/man/man1/pack200.1 ! src/solaris/doc/sun/man/man1/policytool.1 ! src/solaris/doc/sun/man/man1/rmic.1 ! src/solaris/doc/sun/man/man1/rmid.1 ! src/solaris/doc/sun/man/man1/rmiregistry.1 ! src/solaris/doc/sun/man/man1/schemagen.1 ! src/solaris/doc/sun/man/man1/serialver.1 ! src/solaris/doc/sun/man/man1/servertool.1 ! src/solaris/doc/sun/man/man1/tnameserv.1 ! src/solaris/doc/sun/man/man1/unpack200.1 ! src/solaris/doc/sun/man/man1/wsgen.1 ! src/solaris/doc/sun/man/man1/wsimport.1 ! src/solaris/doc/sun/man/man1/xjc.1 Changeset: a33222e53611 Author: prr Date: 2009-04-02 10:16 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/a33222e53611 6753173: No need to read all the TrueType 'post' table to get underline info Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/TrueTypeFont.java Changeset: e3b4eb55a696 Author: lana Date: 2009-04-08 15:40 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/e3b4eb55a696 Merge - make/common/shared/Compiler.gmk - make/jprt.config - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java Changeset: e61d93fc8ed1 Author: mchung Date: 2009-04-14 17:43 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/e61d93fc8ed1 6818072: Load Ductus using Class.forName if exist instead of using the service loader Summary: First attempt Class.forName to load Ductus class before using service loader Reviewed-by: flar, prr ! src/share/classes/sun/java2d/pipe/RenderingEngine.java Changeset: d609ae2faac2 Author: jgodinez Date: 2009-04-15 08:47 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/d609ae2faac2 6827989: Use Unsafe.copyMemory for array->Unsafe copy operations in RenderBuffer Reviewed-by: campbell, flar Contributed-by: linuxhippy ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! src/share/classes/sun/java2d/pipe/RenderBuffer.java - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: c3aaa11e4eb6 Author: jgodinez Date: 2009-04-20 12:31 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/c3aaa11e4eb6 6821495: test/java/awt/print/PrinterJob/PrtException.java fails Reviewed-by: igor, prr ! test/java/awt/PrintJob/EdgeTest/EdgeTest.java ! test/java/awt/PrintJob/MultipleEnd/MultipleEnd.java + test/java/awt/print/PrinterJob/Collate2DPrintingTest.java + test/java/awt/print/PrinterJob/PrtException.java ! test/javax/print/CheckDupFlavor.java + test/javax/print/LookupServices.java ! test/javax/print/TestRaceCond.java + test/javax/print/attribute/Chroma.java + test/javax/print/attribute/ChromaticityValues.java + test/javax/print/attribute/GetCopiesSupported.java ! test/javax/print/attribute/PSCopiesFlavorTest.java + test/javax/print/attribute/SidesPageRangesTest.java + test/javax/print/attribute/SupportedPrintableAreas.java + test/javax/print/attribute/autosense/PrintAutoSenseData.java Changeset: 53ca5822bdfe Author: jgodinez Date: 2009-04-21 09:43 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/53ca5822bdfe 6829678: StrokeShapeTest: createStrokedShape() behaves differently Reviewed-by: igor, flar Contributed-by: rkennke ! src/share/classes/sun/java2d/pisces/Stroker.java + test/sun/pisces/StrokeShapeTest.java Changeset: b4450e6de8a3 Author: jgodinez Date: 2009-04-28 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/b4450e6de8a3 Merge ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/mapfile-vers-linux ! src/share/classes/sun/font/TrueTypeFont.java - src/share/classes/sun/text/normalizer/UProperty.java - src/share/native/java/util/zip/ZipEntry.c - src/windows/native/sun/windows/awt_KeyboardFocusManager.h Changeset: 662a327cfe1d Author: jgodinez Date: 2009-04-29 12:27 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/662a327cfe1d Merge - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: f8b061ea131c Author: jgodinez Date: 2009-05-05 09:09 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/f8b061ea131c Merge - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: 057e4afcf978 Author: alanb Date: 2009-04-23 19:44 +0100 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/057e4afcf978 6832557: TEST_BUG: java/lang/Class/getEnclosingConstructor/EnclosingConstructorTests.java fails to compile Reviewed-by: darcy, mcimadamore ! test/java/lang/Class/getEnclosingConstructor/EnclosingConstructorTests.java Changeset: 164ce9ff8b58 Author: mchung Date: 2009-04-27 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/164ce9ff8b58 6829503: addShutdownHook fails if called after shutdown has commenced. Summary: allow shutdown hook to be added during shutdown and handle properly if it fails to add Reviewed-by: alanb, dholmes, martin ! src/share/classes/java/io/Console.java ! src/share/classes/java/io/DeleteOnExitHook.java ! src/share/classes/java/lang/ApplicationShutdownHooks.java ! src/share/classes/java/lang/Shutdown.java ! src/share/classes/java/lang/System.java ! src/share/classes/sun/misc/JavaLangAccess.java + test/java/lang/Runtime/shutdown/ShutdownHooks.java + test/java/lang/Runtime/shutdown/ShutdownHooks.sh Changeset: d2114c1adb2d Author: sherman Date: 2009-05-01 12:06 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/d2114c1adb2d 6836489: Incorrect @link usage in java.util.zip API doc Summary: correct the wrong @link tag Reviewed-by: alanb ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/classes/java/util/zip/ZipOutputStream.java Changeset: e1a713f0361f Author: alanb Date: 2009-05-04 19:25 +0100 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/e1a713f0361f 6834246: (ch) AsynchronousSocketChannel#write completes with wrong number of bytes written under load (win) Reviewed-by: sherman ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c + test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java Changeset: b3720710a4ba Author: tbell Date: 2009-05-04 22:16 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/b3720710a4ba Merge Changeset: d201987cb76c Author: jrose Date: 2009-05-05 22:40 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/d201987cb76c 6829144: JSR 292 JVM features need a provisional Java API Summary: JDK API and runtime (partial) for anonk, meth, indy Reviewed-by: mr ! make/docs/CORE_PKGS.gmk ! make/java/Makefile + make/java/dyn/Makefile + src/share/classes/java/dyn/CallSite.java + src/share/classes/java/dyn/InvokeDynamic.java + src/share/classes/java/dyn/InvokeDynamicBootstrapError.java + src/share/classes/java/dyn/JavaMethodHandle.java + src/share/classes/java/dyn/Linkage.java + src/share/classes/java/dyn/LinkagePermission.java + src/share/classes/java/dyn/MethodHandle.java + src/share/classes/java/dyn/MethodHandles.java + src/share/classes/java/dyn/MethodType.java + src/share/classes/java/dyn/MethodTypeForm.java + src/share/classes/java/dyn/NoAccessException.java + src/share/classes/java/dyn/WrongMethodTypeException.java + src/share/classes/java/dyn/package-info.java + src/share/classes/sun/dyn/Access.java + src/share/classes/sun/dyn/AdapterMethodHandle.java + src/share/classes/sun/dyn/BoundMethodHandle.java + src/share/classes/sun/dyn/CallSiteImpl.java + src/share/classes/sun/dyn/DirectMethodHandle.java + src/share/classes/sun/dyn/FilterGeneric.java + src/share/classes/sun/dyn/FilterOneArgument.java + src/share/classes/sun/dyn/FromGeneric.java + src/share/classes/sun/dyn/Invokers.java + src/share/classes/sun/dyn/MemberName.java + src/share/classes/sun/dyn/MethodHandleImpl.java + src/share/classes/sun/dyn/MethodHandleNatives.java + src/share/classes/sun/dyn/MethodTypeImpl.java + src/share/classes/sun/dyn/ToGeneric.java + src/share/classes/sun/dyn/anon/AnonymousClassLoader.java + src/share/classes/sun/dyn/anon/ConstantPoolParser.java + src/share/classes/sun/dyn/anon/ConstantPoolPatch.java + src/share/classes/sun/dyn/anon/ConstantPoolVisitor.java + src/share/classes/sun/dyn/anon/InvalidConstantPoolFormatException.java + src/share/classes/sun/dyn/empty/Empty.java + src/share/classes/sun/dyn/package-info.java + src/share/classes/sun/dyn/util/BytecodeName.java + src/share/classes/sun/dyn/util/BytecodeSignature.java + src/share/classes/sun/dyn/util/ValueConversions.java + src/share/classes/sun/dyn/util/VerifyAccess.java + src/share/classes/sun/dyn/util/VerifyType.java + src/share/classes/sun/dyn/util/Wrapper.java + src/share/classes/sun/dyn/util/package-info.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/javavm/export/classfile_constants.h ! src/share/native/common/check_code.c ! src/share/native/common/opcodes.in_out Changeset: 9ba256e2e5c1 Author: tbell Date: 2009-05-05 23:12 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/9ba256e2e5c1 Merge Changeset: 878863c9072d Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/878863c9072d Added tag jdk7-b58 for changeset 9ba256e2e5c1 ! .hgtags Changeset: 2007e3d9c195 Author: anthony Date: 2009-05-05 14:45 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/2007e3d9c195 6762511: Translucency is not working on Linux using Metacity Summary: Introduced additional blits and new X11 surface types (ARGB, ABGR) Reviewed-by: art, avu ! 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: ba95c9101e50 Author: art Date: 2009-05-06 12:39 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/ba95c9101e50 6837004: java.awt.GraphicsDevice.setFullScreenWindow throws NPE for windows with background color not set Reviewed-by: yan, dcherepanov ! src/share/classes/java/awt/GraphicsDevice.java + test/java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java Changeset: b28b073e72b6 Author: anthony Date: 2009-05-06 20:06 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/b28b073e72b6 6838046: Rollback 6762511 due to build failure (6838003) Reviewed-by: yan ! 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: 2b86dbc51d11 Author: yan Date: 2009-05-06 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/2b86dbc51d11 Merge Changeset: 0c6f5f1c58fd Author: yan Date: 2009-05-12 00:40 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/0c6f5f1c58fd Merge Changeset: 2387e3b1994e Author: jrose Date: 2009-05-11 21:09 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/2387e3b1994e 6839802: java.dyn needs to be on the CORE_PKGS list Summary: fix makefile to expose the new APIs in the core list; edit some javadocs for correctness Reviewed-by: mr ! make/common/Release.gmk ! make/docs/CORE_PKGS.gmk ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/dyn/Linkage.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java Changeset: 29180ef374c8 Author: jrose Date: 2009-05-12 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/29180ef374c8 6839839: access checking logic is wrong at three points in MethodHandles Summary: point fixes to access checking logic Reviewed-by: mr ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/sun/dyn/DirectMethodHandle.java ! src/share/classes/sun/dyn/MemberName.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/classes/sun/dyn/util/VerifyAccess.java Changeset: 2a5a1b269e89 Author: xdono Date: 2009-05-12 14:05 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/2a5a1b269e89 Merge Changeset: 62bfe2674e48 Author: yan Date: 2009-05-14 00:17 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/62bfe2674e48 Merge - src/share/native/sun/java2d/pipe/RenderBuffer.c From yuri.nesterenko at sun.com Thu May 14 02:45:45 2009 From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com) Date: Thu, 14 May 2009 09:45:45 +0000 Subject: hg: jdk7/swing/langtools: 4 new changesets Message-ID: <20090514094552.634A0ED7C@hg.openjdk.java.net> Changeset: 8a2424db1a14 Author: xdono Date: 2009-04-30 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/langtools/rev/8a2424db1a14 Added tag jdk7-b57 for changeset 4030cc469205 ! .hgtags Changeset: e2722bd43f3a Author: jrose Date: 2009-05-04 21:04 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/langtools/rev/e2722bd43f3a 6829189: Java programming with JSR 292 needs language support Summary: Language changes documented in http://wikis.sun.com/display/mlvm/ProjectCoinProposal Reviewed-by: jjg, darcy, mcimadamore ! src/share/classes/com/sun/tools/classfile/Opcode.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ByteCodes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java ! src/share/classes/sun/tools/javap/JavapPrinter.java ! src/share/classes/sun/tools/javap/RuntimeConstants.java + test/tools/javac/meth/InvokeDyn.java + test/tools/javac/meth/InvokeMH.java + test/tools/javac/meth/MakeNegTests.sh + test/tools/javac/quid/MakeNegTests.sh + test/tools/javac/quid/QuotedIdent.java + test/tools/javac/quid/QuotedIdent2.java Changeset: 5bcac54d408b Author: tbell Date: 2009-05-04 22:16 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/langtools/rev/5bcac54d408b Merge Changeset: 88bcb6772159 Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/swing/langtools/rev/88bcb6772159 Added tag jdk7-b58 for changeset 5bcac54d408b ! .hgtags From Pavel.Porvatov at Sun.COM Thu May 14 02:58:54 2009 From: Pavel.Porvatov at Sun.COM (Pavel Porvatov) Date: Thu, 14 May 2009 13:58:54 +0400 Subject: [PATCH] 6179357: Generics: JList In-Reply-To: <49FF066D.6000200@gmx.ch> References: <200903222003.05081.fbrunnerlist@gmx.ch> <200903281145.32982.fbrunnerlist@gmx.ch> <49D0B01A.1070508@sun.com> <200904132306.27599.fbrunnerlist@gmx.ch> <49E48E16.8060706@sun.com> <49E49456.9090203@gmx.ch> <49E497D0.7010704@sun.com> <49E4AE80.8060407@gmx.ch> <49E4AFF3.20706@sun.com> <49FF066D.6000200@gmx.ch> Message-ID: <4A0BEB5E.1090401@sun.com> Hi Florian, I have a question about the DefaultListCellRenderer class. Can we modify it to use generics? Thanks, Pavel > Hi Pavel, hi Alexander, > > I'm back from holiday. > > What is the status of this patch? Any news? > > -Florian > > Alexander Potochkin schrieb: >> Hello Florian >> >>> Great! :-) >>> >>> In the case of other issues please note that I'm on holiday until the >>> end of next week. >> >> Have a nice holiday! >> >> (I am reviewing the fix right now) >> >> Thanks >> alexp >> >>> >>> -Florian >>> >>> Pavel Porvatov schrieb: >>>> Hi Florian, >>>> >>>>> Hi Pavel, >>>>> >>>>> I agree that we should avoid to mix several different fixes in one >>>>> fix, but since in this fix we change >>>>> >>>>> AbstractListModel to AbstractListModel >>>>> and >>>>> JList(ListModel dataModel) to JList(ListModel dataModel) >>>>> >>>>> I think we should also change usages of AbstractListModel such as >>>>> "this (new AbstractListModel()...)" to "this (new >>>>> AbstractListModel()...)" to avoid warnings. >>>> Ok, then it will not be a problem. Let's include this change in your >>>> fix. Therefore all my comments are gone and I'm going to start our >>>> internal process to commit your fix. >>>> >>>> Thanks, Pavel. >>>> >>>>> >>>>> If you don't agree: >>>>> There are several places where I changed the usage of now >>>>> generified classes to the generic variant. Which ones should I >>>>> change back? Only this case? >>>> >>> >> > From fbrunnerlist at gmx.ch Thu May 14 04:36:28 2009 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Thu, 14 May 2009 13:36:28 +0200 Subject: [PATCH] 6179357: Generics: JList In-Reply-To: <4A0BEB5E.1090401@sun.com> References: <200903222003.05081.fbrunnerlist@gmx.ch> <200903281145.32982.fbrunnerlist@gmx.ch> <49D0B01A.1070508@sun.com> <200904132306.27599.fbrunnerlist@gmx.ch> <49E48E16.8060706@sun.com> <49E49456.9090203@gmx.ch> <49E497D0.7010704@sun.com> <49E4AE80.8060407@gmx.ch> <49E4AFF3.20706@sun.com> <49FF066D.6000200@gmx.ch> <4A0BEB5E.1090401@sun.com> Message-ID: <4A0C023C.8050002@gmx.ch> Hi Pavel, I don't understand, what exactly you want to do. DefaultListCellRender implements ListCellRenderer, which means it is an implementation, which can be savely (without risking a ClassCastException) be used with ANY object. That is due the fact, that it checks if it is an instance of Icon or else calls Object.toString, which is defined for any Object: if (value instanceof Icon) { setIcon((Icon)value); setText(""); } else { setIcon(null); setText((value == null) ? "" : value.toString()); } There is no gain in calling eg.: new DefaultListCellRender() because the existing implementation (DefaultListCellRender implements ListCellRenderer) already handles Foo. The only limitation is with sub-classing: Subclasses cannot change the parameter type. But this can be solved with using composition instead of inheritance, eg: public class FooRenderer implements ListCellRenderer{ private DefaultListCellRender defaultRenderer = new DefaultListCellRender(); public Component getListCellRendererComponent( JList list, Foo value, int index, boolean isSelected, boolean cellHasFocus) { doSomethingWithFoo(foo); return defaultRenderer.getListCellRendererComponent(list, value, index, isSelected, cellHasFocus); } private void doSomethingWithFoo(Foo foo){ // do something } } So, I think the answer is yes, it could be changed, but I see no real benefit and more, client code needs then to specify a parameter, which currently it doesn't. -Florian Pavel Porvatov schrieb: > Hi Florian, > > I have a question about the DefaultListCellRenderer class. Can we > modify it to use generics? > > Thanks, Pavel > >> Hi Pavel, hi Alexander, >> >> I'm back from holiday. >> >> What is the status of this patch? Any news? >> >> -Florian >> >> Alexander Potochkin schrieb: >>> Hello Florian >>> >>>> Great! :-) >>>> >>>> In the case of other issues please note that I'm on holiday until >>>> the end of next week. >>> >>> Have a nice holiday! >>> >>> (I am reviewing the fix right now) >>> >>> Thanks >>> alexp >>> >>>> >>>> -Florian >>>> >>>> Pavel Porvatov schrieb: >>>>> Hi Florian, >>>>> >>>>>> Hi Pavel, >>>>>> >>>>>> I agree that we should avoid to mix several different fixes in >>>>>> one fix, but since in this fix we change >>>>>> >>>>>> AbstractListModel to AbstractListModel >>>>>> and >>>>>> JList(ListModel dataModel) to JList(ListModel dataModel) >>>>>> >>>>>> I think we should also change usages of AbstractListModel such >>>>>> as "this (new AbstractListModel()...)" to "this (new >>>>>> AbstractListModel()...)" to avoid warnings. >>>>> Ok, then it will not be a problem. Let's include this change in >>>>> your fix. Therefore all my comments are gone and I'm going to >>>>> start our internal process to commit your fix. >>>>> >>>>> Thanks, Pavel. >>>>> >>>>>> >>>>>> If you don't agree: >>>>>> There are several places where I changed the usage of now >>>>>> generified classes to the generic variant. Which ones should I >>>>>> change back? Only this case? >>>>> >>>> >>> >> > From Pavel.Porvatov at Sun.COM Thu May 14 05:52:49 2009 From: Pavel.Porvatov at Sun.COM (Pavel Porvatov) Date: Thu, 14 May 2009 16:52:49 +0400 Subject: [PATCH] 6179357: Generics: JList In-Reply-To: <4A0C023C.8050002@gmx.ch> References: <200903222003.05081.fbrunnerlist@gmx.ch> <200903281145.32982.fbrunnerlist@gmx.ch> <49D0B01A.1070508@sun.com> <200904132306.27599.fbrunnerlist@gmx.ch> <49E48E16.8060706@sun.com> <49E49456.9090203@gmx.ch> <49E497D0.7010704@sun.com> <49E4AE80.8060407@gmx.ch> <49E4AFF3.20706@sun.com> <49FF066D.6000200@gmx.ch> <4A0BEB5E.1090401@sun.com> <4A0C023C.8050002@gmx.ch> Message-ID: <4A0C1421.3010005@sun.com> Hi Florian, > Hi Pavel, > > I don't understand, what exactly you want to do. DefaultListCellRender > implements ListCellRenderer, which means it is an > implementation, which can be savely (without risking a > ClassCastException) be used with ANY object. That is due the fact, that > it checks if it is an instance of Icon or else calls Object.toString, > which is defined for any Object: > > if (value instanceof Icon) { > setIcon((Icon)value); > setText(""); > } > else { > setIcon(null); > setText((value == null) ? "" : value.toString()); > } Ok, that code actually prevents to use generics in the DefaultListCellRender class. Thanks, Pavel > > There is no gain in calling eg.: > new DefaultListCellRender() > > because the existing implementation (DefaultListCellRender implements > ListCellRenderer) already handles Foo. > > The only limitation is with sub-classing: Subclasses cannot change the > parameter type. > But this can be solved with using composition instead of inheritance, eg: > > public class FooRenderer implements ListCellRenderer{ > private DefaultListCellRender defaultRenderer = new > DefaultListCellRender(); > > public Component getListCellRendererComponent( > JList list, > Foo value, > int index, > boolean isSelected, > boolean cellHasFocus) > { > doSomethingWithFoo(foo); > return defaultRenderer.getListCellRendererComponent(list, value, > index, isSelected, cellHasFocus); > } > > private void doSomethingWithFoo(Foo foo){ > // do something > } > } > > So, I think the answer is yes, it could be changed, but I see no real > benefit and more, client code needs then to specify a parameter, which > currently it doesn't. > > -Florian > > Pavel Porvatov schrieb: >> Hi Florian, >> >> I have a question about the DefaultListCellRenderer class. Can we >> modify it to use generics? >> >> Thanks, Pavel >> >>> Hi Pavel, hi Alexander, >>> >>> I'm back from holiday. >>> >>> What is the status of this patch? Any news? >>> >>> -Florian >>> >>> Alexander Potochkin schrieb: >>>> Hello Florian >>>> >>>>> Great! :-) >>>>> >>>>> In the case of other issues please note that I'm on holiday until >>>>> the end of next week. >>>> >>>> Have a nice holiday! >>>> >>>> (I am reviewing the fix right now) >>>> >>>> Thanks >>>> alexp >>>> >>>>> >>>>> -Florian >>>>> >>>>> Pavel Porvatov schrieb: >>>>>> Hi Florian, >>>>>> >>>>>>> Hi Pavel, >>>>>>> >>>>>>> I agree that we should avoid to mix several different fixes in >>>>>>> one fix, but since in this fix we change >>>>>>> >>>>>>> AbstractListModel to AbstractListModel >>>>>>> and >>>>>>> JList(ListModel dataModel) to JList(ListModel dataModel) >>>>>>> >>>>>>> I think we should also change usages of AbstractListModel such >>>>>>> as "this (new AbstractListModel()...)" to "this (new >>>>>>> AbstractListModel()...)" to avoid warnings. >>>>>> Ok, then it will not be a problem. Let's include this change in >>>>>> your fix. Therefore all my comments are gone and I'm going to >>>>>> start our internal process to commit your fix. >>>>>> >>>>>> Thanks, Pavel. >>>>>> >>>>>>> >>>>>>> If you don't agree: >>>>>>> There are several places where I changed the usage of now >>>>>>> generified classes to the generic variant. Which ones should I >>>>>>> change back? Only this case? >>>>>> >>>>> >>>> >>> >> > From Pavel.Porvatov at Sun.COM Thu May 14 06:39:32 2009 From: Pavel.Porvatov at Sun.COM (Pavel Porvatov) Date: Thu, 14 May 2009 17:39:32 +0400 Subject: [PATCH] 6179357: Generics: JList In-Reply-To: <49FF066D.6000200@gmx.ch> References: <200903222003.05081.fbrunnerlist@gmx.ch> <200903281145.32982.fbrunnerlist@gmx.ch> <49D0B01A.1070508@sun.com> <200904132306.27599.fbrunnerlist@gmx.ch> <49E48E16.8060706@sun.com> <49E49456.9090203@gmx.ch> <49E497D0.7010704@sun.com> <49E4AE80.8060407@gmx.ch> <49E4AFF3.20706@sun.com> <49FF066D.6000200@gmx.ch> Message-ID: <4A0C1F14.6070307@sun.com> Hi Florian, Some time ago we discussed two different ways to add the new method "getSelectedValuesList()". The first one is the current implementation in your fix: 1. public List getSelectedValuesList() Benefits: a. easy to use b. Collection framework is very flexible The second way is: 2. public E[] getSelectedValues(E[] a) Benefits: a. The same pattern used in the java.util.Collection#toArray(T[] a) method b. a little bit easer to port an old code Also a lot of people noticed that there is no need to deprecate the javax.swing.JList#getSelectedValues method because it still can be useful. Any ideas? Regards, Pavel > Hi Pavel, hi Alexander, > > I'm back from holiday. > > What is the status of this patch? Any news? > > -Florian > > Alexander Potochkin schrieb: >> Hello Florian >> >>> Great! :-) >>> >>> In the case of other issues please note that I'm on holiday until the >>> end of next week. >> >> Have a nice holiday! >> >> (I am reviewing the fix right now) >> >> Thanks >> alexp >> >>> >>> -Florian >>> >>> Pavel Porvatov schrieb: >>>> Hi Florian, >>>> >>>>> Hi Pavel, >>>>> >>>>> I agree that we should avoid to mix several different fixes in one >>>>> fix, but since in this fix we change >>>>> >>>>> AbstractListModel to AbstractListModel >>>>> and >>>>> JList(ListModel dataModel) to JList(ListModel dataModel) >>>>> >>>>> I think we should also change usages of AbstractListModel such as >>>>> "this (new AbstractListModel()...)" to "this (new >>>>> AbstractListModel()...)" to avoid warnings. >>>> Ok, then it will not be a problem. Let's include this change in your >>>> fix. Therefore all my comments are gone and I'm going to start our >>>> internal process to commit your fix. >>>> >>>> Thanks, Pavel. >>>> >>>>> >>>>> If you don't agree: >>>>> There are several places where I changed the usage of now >>>>> generified classes to the generic variant. Which ones should I >>>>> change back? Only this case? >>>> >>> >> > From fbrunnerlist at gmx.ch Thu May 14 06:59:27 2009 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Thu, 14 May 2009 15:59:27 +0200 Subject: [PATCH] 6179357: Generics: JList In-Reply-To: <4A0C1421.3010005@sun.com> References: <200903222003.05081.fbrunnerlist@gmx.ch> <200903281145.32982.fbrunnerlist@gmx.ch> <49D0B01A.1070508@sun.com> <200904132306.27599.fbrunnerlist@gmx.ch> <49E48E16.8060706@sun.com> <49E49456.9090203@gmx.ch> <49E497D0.7010704@sun.com> <49E4AE80.8060407@gmx.ch> <49E4AFF3.20706@sun.com> <49FF066D.6000200@gmx.ch> <4A0BEB5E.1090401@sun.com> <4A0C023C.8050002@gmx.ch> <4A0C1421.3010005@sun.com> Message-ID: <4A0C23BF.8010006@gmx.ch> Hi Pavel, > Hi Florian, > >> Hi Pavel, >> >> I don't understand, what exactly you want to do. >> DefaultListCellRender implements ListCellRenderer, which >> means it is an implementation, which can be savely (without risking a >> ClassCastException) be used with ANY object. That is due the fact, >> that it checks if it is an instance of Icon or else calls >> Object.toString, which is defined for any Object: >> >> if (value instanceof Icon) { >> setIcon((Icon)value); >> setText(""); >> } >> else { >> setIcon(null); >> setText((value == null) ? "" : value.toString()); >> } > Ok, that code actually prevents to use generics in the > DefaultListCellRender class. Well, it depends what you mean with "prevents". I guess something like the following would still compile (did not test): public class DefaultListCellRender implements ListCellRenderer{ public Component getListCellRendererComponent( JList list, // or JList ? E value, int index, boolean isSelected, boolean cellHasFocus) { .... if (value instanceof Icon) { setIcon((Icon)value); setText(""); } else { setIcon(null); setText((value == null) ? "" : value.toString()); } ... } } But since: - renderers are consumers (-> "super" keyword is used with wildcards) and Object is the super type of all types - generics are only used at compile time - the only generic method is already implemented without casting (except in the case of Icon, which cannot be prevented with generics either) it "prevents" us from the need of introducing a generic type parameter here. (If you can live with the subclassing issue I mentioned before.) If later someone really finds a scenario, which needs that generic parameter here (what I doubt), I think it should still be possible to change from: DefaultListCellRender implements ListCellRenderer to DefaultListCellRender implements ListCellRenderer without breaking backwards compatibility. Correct? So we don't risk anything by not introducing that parameter right now, if we don't see any benefit. What do you think? -Florian > > Thanks, Pavel > >> >> There is no gain in calling eg.: >> new DefaultListCellRender() >> >> because the existing implementation (DefaultListCellRender implements >> ListCellRenderer) already handles Foo. >> >> The only limitation is with sub-classing: Subclasses cannot change >> the parameter type. >> But this can be solved with using composition instead of inheritance, >> eg: >> >> public class FooRenderer implements ListCellRenderer{ >> private DefaultListCellRender defaultRenderer = new >> DefaultListCellRender(); >> >> public Component getListCellRendererComponent( >> JList list, >> Foo value, >> int index, >> boolean isSelected, >> boolean cellHasFocus) >> { >> doSomethingWithFoo(foo); >> return defaultRenderer.getListCellRendererComponent(list, >> value, index, isSelected, cellHasFocus); >> } >> >> private void doSomethingWithFoo(Foo foo){ >> // do something >> } >> } >> >> So, I think the answer is yes, it could be changed, but I see no real >> benefit and more, client code needs then to specify a parameter, >> which currently it doesn't. >> >> -Florian >> >> Pavel Porvatov schrieb: >>> Hi Florian, >>> >>> I have a question about the DefaultListCellRenderer class. Can we >>> modify it to use generics? >>> >>> Thanks, Pavel From peter.zhelezniakov at sun.com Thu May 14 07:16:19 2009 From: peter.zhelezniakov at sun.com (peter.zhelezniakov at sun.com) Date: Thu, 14 May 2009 14:16:19 +0000 Subject: hg: jdk7/swing/jdk: 6741426: ClassCastException from ComboBoxEditableState (Nimbus LaF) in JDK 1.6.0_10 RC Message-ID: <20090514141631.2BAE8ED9D@hg.openjdk.java.net> Changeset: 455b357442c7 Author: peterz Date: 2009-05-14 18:12 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/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 From gnu_andrew at member.fsf.org Thu May 14 14:20:53 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 14 May 2009 22:20:53 +0100 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional Message-ID: <17c6771e0905141420o5b1c3453sb2c78888f2b2efcf@mail.gmail.com> HI all, I have a simple patch that allows the building of the Nimbus L'n'F (which has a dependency on a specific version of JIBX, 1.1.5) to be turned off so the user can trade build simplicity for a lack of Nimbus support and curved buttons in Swing. The bug report is here: https://bugs.openjdk.java.net/show_bug.cgi?id=100054 And the webrev is here: http://fuseyism.com/100054/webrev.00/ (still having some issues getting access to cr.openjdk.java.net) Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Phil.Race at Sun.COM Thu May 14 14:33:19 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Thu, 14 May 2009 14:33:19 -0700 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <17c6771e0905141420o5b1c3453sb2c78888f2b2efcf@mail.gmail.com> References: <17c6771e0905141420o5b1c3453sb2c78888f2b2efcf@mail.gmail.com> Message-ID: <4A0C8E1F.5070700@sun.com> There's public API associated with Nimbus in javax.swing.plaf.nimbus so I don't think many people will want to use that facility and it doesn't seem appropriate to have it in the jdk7 source train. -phil. Andrew John Hughes wrote: > HI all, > > I have a simple patch that allows the building of the Nimbus L'n'F > (which has a dependency on a specific version of JIBX, 1.1.5) to be > turned off so the user can trade build simplicity for a lack of Nimbus > support and curved buttons in Swing. > > The bug report is here: https://bugs.openjdk.java.net/show_bug.cgi?id=100054 > > And the webrev is here: http://fuseyism.com/100054/webrev.00/ (still > having some issues getting access to cr.openjdk.java.net) > > Thanks, From gnu_andrew at member.fsf.org Thu May 14 15:01:14 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 14 May 2009 23:01:14 +0100 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <4A0C8E1F.5070700@sun.com> References: <17c6771e0905141420o5b1c3453sb2c78888f2b2efcf@mail.gmail.com> <4A0C8E1F.5070700@sun.com> Message-ID: <17c6771e0905141501o258f8342od6a2aa4f354f9979@mail.gmail.com> 2009/5/14 Phil Race : > There's public API associated with Nimbus in javax.swing.plaf.nimbus > so I don't think many people will want to use that facility and it doesn't > seem appropriate to have it in the jdk7 source train. > > -phil. > > > Andrew John Hughes wrote: >> >> HI all, >> >> I have a simple patch that allows the building of the Nimbus L'n'F >> (which has a dependency on a specific version of JIBX, 1.1.5) to be >> turned off so the user can trade build simplicity for a lack of Nimbus >> support and curved buttons in Swing. >> >> The bug report is here: >> https://bugs.openjdk.java.net/show_bug.cgi?id=100054 >> >> And the webrev is here: http://fuseyism.com/100054/webrev.00/ (still >> having some issues getting access to cr.openjdk.java.net) >> >> Thanks, > In my experience, it's usually a bad idea to pre-judge what people want. I created and posted this patch because a number of us working on OpenJDK have already had issues trying to build with this enabled. I'm not suggesting by any means that you'd want this enabled in a production build. But it helps reduce the build requirements of completing an OpenJDK build and, to my mind, allowing more people to build OpenJDK allows more people to make worthwhile contributions. I've already added this to IcedTea for this reason and I don't see what harm it does to have the option available upstream. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Phil.Race at Sun.COM Thu May 14 15:04:34 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Thu, 14 May 2009 15:04:34 -0700 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <17c6771e0905141501o258f8342od6a2aa4f354f9979@mail.gmail.com> References: <17c6771e0905141420o5b1c3453sb2c78888f2b2efcf@mail.gmail.com> <4A0C8E1F.5070700@sun.com> <17c6771e0905141501o258f8342od6a2aa4f354f9979@mail.gmail.com> Message-ID: <4A0C9572.8020304@sun.com> I do think I know what you want. But I consider its a slippery slope as you have no way of knowing or keeping track of the consequences of not building a particular component. I suggest its better to fix the local build problem than push workarounds upstream. -phil. Andrew John Hughes wrote: > 2009/5/14 Phil Race : >> There's public API associated with Nimbus in javax.swing.plaf.nimbus >> so I don't think many people will want to use that facility and it doesn't >> seem appropriate to have it in the jdk7 source train. >> >> -phil. >> >> >> Andrew John Hughes wrote: >>> HI all, >>> >>> I have a simple patch that allows the building of the Nimbus L'n'F >>> (which has a dependency on a specific version of JIBX, 1.1.5) to be >>> turned off so the user can trade build simplicity for a lack of Nimbus >>> support and curved buttons in Swing. >>> >>> The bug report is here: >>> https://bugs.openjdk.java.net/show_bug.cgi?id=100054 >>> >>> And the webrev is here: http://fuseyism.com/100054/webrev.00/ (still >>> having some issues getting access to cr.openjdk.java.net) >>> >>> Thanks, > > In my experience, it's usually a bad idea to pre-judge what people want. > > I created and posted this patch because a number of us working on > OpenJDK have already had issues trying to build with this enabled. > I'm not suggesting by any means that you'd want this enabled in a > production build. But it helps reduce the build requirements of > completing an OpenJDK build and, to my mind, allowing more people to > build OpenJDK allows more people to make worthwhile contributions. > > I've already added this to IcedTea for this reason and I don't see > what harm it does to have the option available upstream. From Kelly.Ohair at Sun.COM Thu May 14 14:55:30 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 14 May 2009 14:55:30 -0700 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <4A0C8E1F.5070700@sun.com> References: <17c6771e0905141420o5b1c3453sb2c78888f2b2efcf@mail.gmail.com> <4A0C8E1F.5070700@sun.com> Message-ID: <4A0C9352.7070200@sun.com> Is that a 'seems ok'? --- The makefiles changes seem fine to me. -kto Phil Race wrote: > There's public API associated with Nimbus in javax.swing.plaf.nimbus > so I don't think many people will want to use that facility and it doesn't > seem appropriate to have it in the jdk7 source train. > > -phil. > > > Andrew John Hughes wrote: >> HI all, >> >> I have a simple patch that allows the building of the Nimbus L'n'F >> (which has a dependency on a specific version of JIBX, 1.1.5) to be >> turned off so the user can trade build simplicity for a lack of Nimbus >> support and curved buttons in Swing. >> >> The bug report is here: >> https://bugs.openjdk.java.net/show_bug.cgi?id=100054 >> >> And the webrev is here: http://fuseyism.com/100054/webrev.00/ (still >> having some issues getting access to cr.openjdk.java.net) >> >> Thanks, From gnu_andrew at member.fsf.org Thu May 14 15:31:58 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 14 May 2009 23:31:58 +0100 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <4A0C9572.8020304@sun.com> References: <17c6771e0905141420o5b1c3453sb2c78888f2b2efcf@mail.gmail.com> <4A0C8E1F.5070700@sun.com> <17c6771e0905141501o258f8342od6a2aa4f354f9979@mail.gmail.com> <4A0C9572.8020304@sun.com> Message-ID: <17c6771e0905141531y335ae147l3d50a1afd150af7c@mail.gmail.com> 2009/5/14 Phil Race : > I do think I know what you want. But I consider its a slippery slope as > you have no way of knowing or keeping track of the consequences of > not building a particular component. Sure, but if someone chooses to set DISABLE_NIMBUS then they take that risk. It's much the same as if they turn on insane mode or don't build the docs. It's a tradeoff of having an incomplete build at the end against simplifying the process, and one it is down to the user to make. For example, if someone wants to build OpenJDK as a precursor to hacking on HotSpot, then they are probably more concerned about just completing the build than finding an additional set of dependencies for a look and feel they probably won't use. I don't see how arbitrarily restricting choice helps anyone. > I suggest its better to fix the local build problem than push workarounds > upstream. My fear is we will run over this problem again and again. If people working on OpenJDK day in and day out are having issues with this, then newbies are going to fare even worse. > > -phil. > > Andrew John Hughes wrote: >> >> 2009/5/14 Phil Race : >>> >>> There's public API associated with Nimbus in javax.swing.plaf.nimbus >>> so I don't think many people will want to use that facility and it >>> doesn't >>> seem appropriate to have it in the jdk7 source train. >>> >>> -phil. >>> >>> >>> Andrew John Hughes wrote: >>>> >>>> HI all, >>>> >>>> I have a simple patch that allows the building of the Nimbus L'n'F >>>> (which has a dependency on a specific version of JIBX, 1.1.5) to be >>>> turned off so the user can trade build simplicity for a lack of Nimbus >>>> support and curved buttons in Swing. >>>> >>>> The bug report is here: >>>> https://bugs.openjdk.java.net/show_bug.cgi?id=100054 >>>> >>>> And the webrev is here: http://fuseyism.com/100054/webrev.00/ (still >>>> having some issues getting access to cr.openjdk.java.net) >>>> >>>> Thanks, >> >> In my experience, it's usually a bad idea to pre-judge what people want. >> >> I created and posted this patch because a number of us working on >> OpenJDK have already had issues trying to build with this enabled. >> I'm not suggesting by any means that you'd want this enabled in a >> production build. ?But it helps reduce the build requirements of >> completing an OpenJDK build and, to my mind, allowing more people to >> build OpenJDK allows more people to make worthwhile contributions. >> >> I've already added this to IcedTea for this reason and I don't see >> what harm it does to have the option available upstream. > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Thu May 14 15:45:30 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 14 May 2009 15:45:30 -0700 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <17c6771e0905141531y335ae147l3d50a1afd150af7c@mail.gmail.com> References: <17c6771e0905141420o5b1c3453sb2c78888f2b2efcf@mail.gmail.com> <4A0C8E1F.5070700@sun.com> <17c6771e0905141501o258f8342od6a2aa4f354f9979@mail.gmail.com> <4A0C9572.8020304@sun.com> <17c6771e0905141531y335ae147l3d50a1afd150af7c@mail.gmail.com> Message-ID: <4A0C9F0A.4090007@sun.com> If the OpenJDK was able to build with jibx 1.1.6 or 1.2.1, or in general was able to build with more of the jibx versions (I don't know how hard that would be) does that change things? -kto Andrew John Hughes wrote: > 2009/5/14 Phil Race : >> I do think I know what you want. But I consider its a slippery slope as >> you have no way of knowing or keeping track of the consequences of >> not building a particular component. > > Sure, but if someone chooses to set DISABLE_NIMBUS then they take that > risk. It's much the same as if they turn on insane mode or don't > build the docs. It's a tradeoff of having an incomplete build at the > end against simplifying the process, and one it is down to the user to > make. For example, if someone wants to build OpenJDK as a precursor > to hacking on HotSpot, then they are probably more concerned about > just completing the build than finding an additional set of > dependencies for a look and feel they probably won't use. I don't see > how arbitrarily restricting choice helps anyone. > >> I suggest its better to fix the local build problem than push workarounds >> upstream. > > My fear is we will run over this problem again and again. If people > working on OpenJDK day in and day out are having issues with this, > then newbies are going to fare even worse. > >> -phil. >> >> Andrew John Hughes wrote: >>> 2009/5/14 Phil Race : >>>> There's public API associated with Nimbus in javax.swing.plaf.nimbus >>>> so I don't think many people will want to use that facility and it >>>> doesn't >>>> seem appropriate to have it in the jdk7 source train. >>>> >>>> -phil. >>>> >>>> >>>> Andrew John Hughes wrote: >>>>> HI all, >>>>> >>>>> I have a simple patch that allows the building of the Nimbus L'n'F >>>>> (which has a dependency on a specific version of JIBX, 1.1.5) to be >>>>> turned off so the user can trade build simplicity for a lack of Nimbus >>>>> support and curved buttons in Swing. >>>>> >>>>> The bug report is here: >>>>> https://bugs.openjdk.java.net/show_bug.cgi?id=100054 >>>>> >>>>> And the webrev is here: http://fuseyism.com/100054/webrev.00/ (still >>>>> having some issues getting access to cr.openjdk.java.net) >>>>> >>>>> Thanks, >>> In my experience, it's usually a bad idea to pre-judge what people want. >>> >>> I created and posted this patch because a number of us working on >>> OpenJDK have already had issues trying to build with this enabled. >>> I'm not suggesting by any means that you'd want this enabled in a >>> production build. But it helps reduce the build requirements of >>> completing an OpenJDK build and, to my mind, allowing more people to >>> build OpenJDK allows more people to make worthwhile contributions. >>> >>> I've already added this to IcedTea for this reason and I don't see >>> what harm it does to have the option available upstream. > > > From gnu_andrew at member.fsf.org Thu May 14 16:02:39 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 15 May 2009 00:02:39 +0100 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <4A0C9F0A.4090007@sun.com> References: <17c6771e0905141420o5b1c3453sb2c78888f2b2efcf@mail.gmail.com> <4A0C8E1F.5070700@sun.com> <17c6771e0905141501o258f8342od6a2aa4f354f9979@mail.gmail.com> <4A0C9572.8020304@sun.com> <17c6771e0905141531y335ae147l3d50a1afd150af7c@mail.gmail.com> <4A0C9F0A.4090007@sun.com> Message-ID: <17c6771e0905141602vc8e6b5ck2244f590971ad5de@mail.gmail.com> 2009/5/14 Kelly O'Hair : > If the OpenJDK was able to build with jibx 1.1.6 or 1.2.1, > or in general was able to build with more of the jibx versions > (I don't know how hard that would be) does that change things? > > -kto > > Andrew John Hughes wrote: >> >> 2009/5/14 Phil Race : >>> >>> I do think I know what you want. But I consider its a slippery slope as >>> you have no way of knowing or keeping track of the consequences of >>> not building a particular component. >> >> Sure, but if someone chooses to set DISABLE_NIMBUS then they take that >> risk. ?It's much the same as if they turn on insane mode or don't >> build the docs. ?It's a tradeoff of having an incomplete build at the >> end against simplifying the process, and one it is down to the user to >> make. ?For example, if someone wants to build OpenJDK as a precursor >> to hacking on HotSpot, then they are probably more concerned about >> just completing the build than finding an additional set of >> dependencies for a look and feel they probably won't use. ?I don't see >> how arbitrarily restricting choice helps anyone. >> >>> I suggest its better to fix the local build problem than push workarounds >>> upstream. >> >> My fear is we will run over this problem again and again. ?If people >> working on OpenJDK day in and day out are having issues with this, >> then newbies are going to fare even worse. >> >>> -phil. >>> >>> Andrew John Hughes wrote: >>>> >>>> 2009/5/14 Phil Race : >>>>> >>>>> There's public API associated with Nimbus in javax.swing.plaf.nimbus >>>>> so I don't think many people will want to use that facility and it >>>>> doesn't >>>>> seem appropriate to have it in the jdk7 source train. >>>>> >>>>> -phil. >>>>> >>>>> >>>>> Andrew John Hughes wrote: >>>>>> >>>>>> HI all, >>>>>> >>>>>> I have a simple patch that allows the building of the Nimbus L'n'F >>>>>> (which has a dependency on a specific version of JIBX, 1.1.5) to be >>>>>> turned off so the user can trade build simplicity for a lack of Nimbus >>>>>> support and curved buttons in Swing. >>>>>> >>>>>> The bug report is here: >>>>>> https://bugs.openjdk.java.net/show_bug.cgi?id=100054 >>>>>> >>>>>> And the webrev is here: http://fuseyism.com/100054/webrev.00/ (still >>>>>> having some issues getting access to cr.openjdk.java.net) >>>>>> >>>>>> Thanks, >>>> >>>> In my experience, it's usually a bad idea to pre-judge what people want. >>>> >>>> I created and posted this patch because a number of us working on >>>> OpenJDK have already had issues trying to build with this enabled. >>>> I'm not suggesting by any means that you'd want this enabled in a >>>> production build. ?But it helps reduce the build requirements of >>>> completing an OpenJDK build and, to my mind, allowing more people to >>>> build OpenJDK allows more people to make worthwhile contributions. >>>> >>>> I've already added this to IcedTea for this reason and I don't see >>>> what harm it does to have the option available upstream. >> >> >> > It would simplify things a little, yes. I'm not sure it's possible, given builds with both older and newer versions fail for different reasons. It seems the package doesn't attempt any kind of stable API. I'm still think it's better to give people the option rather than forcing a dependency when it's not critical to the build. I recall seeing discussion on the OpenJDK lists and IRC channel in the past about being able to disable some of the graphical stuff, which is more tricky to contemplate but again there is some demand for it. However, I guess this is contrary to the way OpenJDK works, which very much seems to take an all-or-nothing approach :( I hope JDK7's module system will improve on this! -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Dmitri.Trembovetski at Sun.COM Thu May 14 17:42:48 2009 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Thu, 14 May 2009 17:42:48 -0700 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <17c6771e0905141531y335ae147l3d50a1afd150af7c@mail.gmail.com> References: <17c6771e0905141420o5b1c3453sb2c78888f2b2efcf@mail.gmail.com> <4A0C8E1F.5070700@sun.com> <17c6771e0905141501o258f8342od6a2aa4f354f9979@mail.gmail.com> <4A0C9572.8020304@sun.com> <17c6771e0905141531y335ae147l3d50a1afd150af7c@mail.gmail.com> Message-ID: <4A0CBA88.3030203@Sun.COM> Andrew John Hughes wrote: > 2009/5/14 Phil Race : >> I do think I know what you want. But I consider its a slippery slope as >> you have no way of knowing or keeping track of the consequences of >> not building a particular component. > > Sure, but if someone chooses to set DISABLE_NIMBUS then they take that > risk. It's much the same as if they turn on insane mode or don't Right. Until one day they stuff it into their .bashrc and forget about it, and risk breaking the build inadvertently later or spending time trying to figure out why their changes don't have any effect.. But that may be just me =) Thanks, Dmitri > build the docs. It's a tradeoff of having an incomplete build at the > end against simplifying the process, and one it is down to the user to > make. For example, if someone wants to build OpenJDK as a precursor > to hacking on HotSpot, then they are probably more concerned about > just completing the build than finding an additional set of > dependencies for a look and feel they probably won't use. I don't see > how arbitrarily restricting choice helps anyone. > >> I suggest its better to fix the local build problem than push workarounds >> upstream. > > My fear is we will run over this problem again and again. If people > working on OpenJDK day in and day out are having issues with this, > then newbies are going to fare even worse. > >> -phil. >> >> Andrew John Hughes wrote: >>> 2009/5/14 Phil Race : >>>> There's public API associated with Nimbus in javax.swing.plaf.nimbus >>>> so I don't think many people will want to use that facility and it >>>> doesn't >>>> seem appropriate to have it in the jdk7 source train. >>>> >>>> -phil. >>>> >>>> >>>> Andrew John Hughes wrote: >>>>> HI all, >>>>> >>>>> I have a simple patch that allows the building of the Nimbus L'n'F >>>>> (which has a dependency on a specific version of JIBX, 1.1.5) to be >>>>> turned off so the user can trade build simplicity for a lack of Nimbus >>>>> support and curved buttons in Swing. >>>>> >>>>> The bug report is here: >>>>> https://bugs.openjdk.java.net/show_bug.cgi?id=100054 >>>>> >>>>> And the webrev is here: http://fuseyism.com/100054/webrev.00/ (still >>>>> having some issues getting access to cr.openjdk.java.net) >>>>> >>>>> Thanks, >>> In my experience, it's usually a bad idea to pre-judge what people want. >>> >>> I created and posted this patch because a number of us working on >>> OpenJDK have already had issues trying to build with this enabled. >>> I'm not suggesting by any means that you'd want this enabled in a >>> production build. But it helps reduce the build requirements of >>> completing an OpenJDK build and, to my mind, allowing more people to >>> build OpenJDK allows more people to make worthwhile contributions. >>> >>> I've already added this to IcedTea for this reason and I don't see >>> what harm it does to have the option available upstream. > > > From mr at sun.com Thu May 14 21:05:05 2009 From: mr at sun.com (Mark Reinhold) Date: Thu, 14 May 2009 21:05:05 -0700 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: gnu_andrew@member.fsf.org; Thu, 14 May 2009 23:31:58 BST; <17c6771e0905141531y335ae147l3d50a1afd150af7c@mail.gmail.com> Message-ID: <20090515040505.97F34913F@callebaut.niobe.net> > Date: Thu, 14 May 2009 23:31:58 +0100 > From: Andrew John Hughes > 2009/5/14 phil.race at sun.com: >> I do think I know what you want. But I consider its a slippery slope as >> you have no way of knowing or keeping track of the consequences of >> not building a particular component. > > Sure, but if someone chooses to set DISABLE_NIMBUS then they take that > risk. It's much the same as if they turn on insane mode or don't > build the docs. It's a tradeoff of having an incomplete build at the > end against simplifying the process, and one it is down to the user to > make. For example, if someone wants to build OpenJDK as a precursor > to hacking on HotSpot, then they are probably more concerned about > just completing the build than finding an additional set of > dependencies for a look and feel they probably won't use. I don't see > how arbitrarily restricting choice helps anyone. > >> I suggest its better to fix the local build problem than push workarounds >> upstream. > > My fear is we will run over this problem again and again. If people > working on OpenJDK day in and day out are having issues with this, > then newbies are going to fare even worse. I have to agree with Andrew on this one. Engineers working on the JDK routinely skip building various components, yet somehow we've survived. When was the last time, e.g., you built HotSpot, or javac, or the Windows installer, or generated rpm packages on Linux? There are already lots of ways to disable various components of the build. The better ones take care to issue a warning during the sanity check so that people who carelessly set build variables in their shell environment don't get tripped up too badly, as long as they make sure to read the sanity log. That these happen to be "platform" classes doesn't mean much. The chance that a Nimbus-disabled build would be mistaken for a product build is pretty well near zero, given all the testing that we do. If this tiny change makes it easier for people to work with our code, then I'm all for it. My only comment on Andrew's actual patch is that Sanity.gmk should be extended to print a warning when Nimbus is disabled. It otherwise looks fine to me. Oh, and if we have somehow become dependent upon a third-party tool (JIBX) that's so difficult to locate and has such a low commitment to interface stability, then perhaps we should reconsider that and use a different tool. - Mark From kirillcool at yahoo.com Thu May 14 21:35:50 2009 From: kirillcool at yahoo.com (Kirill Grouchnikov) Date: Thu, 14 May 2009 21:35:50 -0700 (PDT) Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <20090515040505.97F34913F@callebaut.niobe.net> References: <20090515040505.97F34913F@callebaut.niobe.net> Message-ID: <945853.12842.qm@web110804.mail.gq1.yahoo.com> > Oh, and if we have somehow become dependent upon a third-party tool > (JIBX) that's so difficult to locate and has such a low commitment to > interface stability, then perhaps we should reconsider that and use a > different tool. The decision to remove this tool from the version control, yet still to continue depending on it during the build time is indeed a little puzzling. Obviously the time is scarce and the tasks are many, but how difficult would it be to remove the dependency on JiBX altogether? Unless Nimbus designer is very close to public release *and* it heavily depends on JiBX, what's the compelling reason to keep having this dependency. And if i understand correctly (from either Richard or Jasper), the XMLs generated by Nimbus designer were tweaked manually afterwards. Thanks Kirill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20090514/420d5d37/attachment.html From peter.zhelezniakov at sun.com Fri May 15 01:10:26 2009 From: peter.zhelezniakov at sun.com (peter.zhelezniakov at sun.com) Date: Fri, 15 May 2009 08:10:26 +0000 Subject: hg: jdk7/swing/jdk: 6827581: Contextkey does not work in Nimbus Message-ID: <20090515081038.87BB3EF1B@hg.openjdk.java.net> Changeset: af491a9b7c1d Author: peterz Date: 2009-05-15 12:06 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/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 From Peter.Zhelezniakov at Sun.COM Fri May 15 01:16:02 2009 From: Peter.Zhelezniakov at Sun.COM (Peter Zhelezniakov) Date: Fri, 15 May 2009 12:16:02 +0400 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <945853.12842.qm@web110804.mail.gq1.yahoo.com> References: <20090515040505.97F34913F@callebaut.niobe.net> <945853.12842.qm@web110804.mail.gq1.yahoo.com> Message-ID: <4A0D24C2.7030804@Sun.com> Kirill Grouchnikov wrote: > > Oh, and if we have somehow become dependent upon a third-party tool > > (JIBX) that's so difficult to locate and has such a low commitment to > > interface stability, then perhaps we should reconsider that and use a > > different tool. > > The decision to remove this tool from the version control, yet still to > continue depending on it during the build time is indeed a little > puzzling. Obviously the time is scarce and the tasks are many, but how > difficult would it be to remove the dependency on JiBX altogether? > Unless Nimbus designer is very close to public release *and* it heavily > depends on JiBX, what's the compelling reason to keep having this > dependency. And if i understand correctly (from either Richard or > Jasper), the XMLs generated by Nimbus designer were tweaked manually > afterwards. I agree. I'll look into this, but don't expect a fix anytime soon ;) -- Peter From aph at redhat.com Fri May 15 01:53:49 2009 From: aph at redhat.com (Andrew Haley) Date: Fri, 15 May 2009 09:53:49 +0100 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <17c6771e0905141602vc8e6b5ck2244f590971ad5de@mail.gmail.com> References: <17c6771e0905141420o5b1c3453sb2c78888f2b2efcf@mail.gmail.com> <4A0C8E1F.5070700@sun.com> <17c6771e0905141501o258f8342od6a2aa4f354f9979@mail.gmail.com> <4A0C9572.8020304@sun.com> <17c6771e0905141531y335ae147l3d50a1afd150af7c@mail.gmail.com> <4A0C9F0A.4090007@sun.com> <17c6771e0905141602vc8e6b5ck2244f590971ad5de@mail.gmail.com> Message-ID: <4A0D2D9D.6080208@redhat.com> Andrew John Hughes wrote: > 2009/5/14 Kelly O'Hair : >> If the OpenJDK was able to build with jibx 1.1.6 or 1.2.1, >> or in general was able to build with more of the jibx versions >> (I don't know how hard that would be) does that change things? > > It would simplify things a little, yes. I'm not sure it's possible, > given builds with both older and newer versions fail for different > reasons. It seems the package doesn't attempt any kind of stable API. That surely is the key point. It doesn't matter how much we might want a specific version of JIBX, it isn't going to happen for Linux distributions. Distros generally pick a particular version of Package X, and if Package Y needs some other version of Package X then Package Y must be patched or dropped from the distribution. We are not in a position to dictate to a user exactly which version of JIBX will be installed on their system. Therefore, if JIBX is now a dependency of OpenJDK we'll have to find a way to make OpenJDK work with whatever versions of JIBX people choose. Andrew. From mario.torre at aicas.com Fri May 15 03:46:23 2009 From: mario.torre at aicas.com (Mario Torre) Date: Fri, 15 May 2009 12:46:23 +0200 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <4A0D2D9D.6080208@redhat.com> References: <17c6771e0905141420o5b1c3453sb2c78888f2b2efcf@mail.gmail.com> <4A0C8E1F.5070700@sun.com> <17c6771e0905141501o258f8342od6a2aa4f354f9979@mail.gmail.com> <4A0C9572.8020304@sun.com> <17c6771e0905141531y335ae147l3d50a1afd150af7c@mail.gmail.com> <4A0C9F0A.4090007@sun.com> <17c6771e0905141602vc8e6b5ck2244f590971ad5de@mail.gmail.com> <4A0D2D9D.6080208@redhat.com> Message-ID: <1242384383.3633.28.camel@localhost.localdomain> Il giorno ven, 15/05/2009 alle 09.53 +0100, Andrew Haley ha scritto: > Andrew John Hughes wrote: > > 2009/5/14 Kelly O'Hair : > >> If the OpenJDK was able to build with jibx 1.1.6 or 1.2.1, > >> or in general was able to build with more of the jibx versions > >> (I don't know how hard that would be) does that change things? > > > > It would simplify things a little, yes. I'm not sure it's possible, > > given builds with both older and newer versions fail for different > > reasons. It seems the package doesn't attempt any kind of stable API. > > That surely is the key point. > > It doesn't matter how much we might want a specific version of JIBX, > it isn't going to happen for Linux distributions. Distros generally > pick a particular version of Package X, and if Package Y needs some > other version of Package X then Package Y must be patched or dropped > from the distribution. > > We are not in a position to dictate to a user exactly which version of > JIBX will be installed on their system. Therefore, if JIBX is now a > dependency of OpenJDK we'll have to find a way to make OpenJDK work > with whatever versions of JIBX people choose. > > Andrew. I second that, and don't like the idea of being able to disable Nimbus because of this dependency. 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 Pavel.Porvatov at Sun.COM Fri May 15 03:44:55 2009 From: Pavel.Porvatov at Sun.COM (Pavel Porvatov) Date: Fri, 15 May 2009 14:44:55 +0400 Subject: [PATCH] 6179357: Generics: JList In-Reply-To: <4A0C23BF.8010006@gmx.ch> References: <200903222003.05081.fbrunnerlist@gmx.ch> <200903281145.32982.fbrunnerlist@gmx.ch> <49D0B01A.1070508@sun.com> <200904132306.27599.fbrunnerlist@gmx.ch> <49E48E16.8060706@sun.com> <49E49456.9090203@gmx.ch> <49E497D0.7010704@sun.com> <49E4AE80.8060407@gmx.ch> <49E4AFF3.20706@sun.com> <49FF066D.6000200@gmx.ch> <4A0BEB5E.1090401@sun.com> <4A0C023C.8050002@gmx.ch> <4A0C1421.3010005@sun.com> <4A0C23BF.8010006@gmx.ch> Message-ID: <4A0D47A7.5040202@sun.com> Hi Florian, > Hi Pavel, >> Hi Florian, >> >>> Hi Pavel, >>> >>> I don't understand, what exactly you want to do. >>> DefaultListCellRender implements ListCellRenderer, which >>> means it is an implementation, which can be savely (without risking a >>> ClassCastException) be used with ANY object. That is due the fact, >>> that it checks if it is an instance of Icon or else calls >>> Object.toString, which is defined for any Object: >>> >>> if (value instanceof Icon) { >>> setIcon((Icon)value); >>> setText(""); >>> } >>> else { >>> setIcon(null); >>> setText((value == null) ? "" : value.toString()); >>> } >> Ok, that code actually prevents to use generics in the >> DefaultListCellRender class. > Well, it depends what you mean with "prevents". I guess something like > the following would still compile (did not test): > > public class DefaultListCellRender implements ListCellRenderer{ > public Component getListCellRendererComponent( > JList list, // or JList ? > E value, > int index, > boolean isSelected, > boolean cellHasFocus) > { > .... > if (value instanceof Icon) { > setIcon((Icon)value); > setText(""); > } > else { > setIcon(null); > setText((value == null) ? "" : value.toString()); > } > ... > } > } > > But since: > - renderers are consumers (-> "super" keyword is used with wildcards) > and Object is the super type of all types > - generics are only used at compile time > - the only generic method is already implemented without casting (except > in the case of Icon, which cannot be prevented with generics either) > > it "prevents" us from the need of introducing a generic type parameter > here. (If you can live with the subclassing issue I mentioned before.) > > If later someone really finds a scenario, which needs that generic > parameter here (what I doubt), I think it should still be possible to > change from: > > DefaultListCellRender implements ListCellRenderer > > to > > DefaultListCellRender implements ListCellRenderer > > without breaking backwards compatibility. Correct? I think the same way. > So we don't risk anything by not introducing that parameter right now, > if we don't see any benefit. > > What do you think? I agree that we can introduce that parameter later if needed. Regards, Pavel. > > -Florian >> >> Thanks, Pavel >> >>> >>> There is no gain in calling eg.: >>> new DefaultListCellRender() >>> >>> because the existing implementation (DefaultListCellRender implements >>> ListCellRenderer) already handles Foo. >>> >>> The only limitation is with sub-classing: Subclasses cannot change >>> the parameter type. >>> But this can be solved with using composition instead of inheritance, >>> eg: >>> >>> public class FooRenderer implements ListCellRenderer{ >>> private DefaultListCellRender defaultRenderer = new >>> DefaultListCellRender(); >>> >>> public Component getListCellRendererComponent( >>> JList list, >>> Foo value, >>> int index, >>> boolean isSelected, >>> boolean cellHasFocus) >>> { >>> doSomethingWithFoo(foo); >>> return defaultRenderer.getListCellRendererComponent(list, >>> value, index, isSelected, cellHasFocus); >>> } >>> >>> private void doSomethingWithFoo(Foo foo){ >>> // do something >>> } >>> } >>> >>> So, I think the answer is yes, it could be changed, but I see no real >>> benefit and more, client code needs then to specify a parameter, >>> which currently it doesn't. >>> >>> -Florian >>> >>> Pavel Porvatov schrieb: >>>> Hi Florian, >>>> >>>> I have a question about the DefaultListCellRenderer class. Can we >>>> modify it to use generics? >>>> >>>> Thanks, Pavel > From iman_shani at hotmail.com Fri May 15 03:47:18 2009 From: iman_shani at hotmail.com (iman_shani at hotmail.com) Date: Fri, 15 May 2009 03:47:18 -0700 Subject: Vacation reply In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20090515/18087215/attachment.html From Peter.Zhelezniakov at Sun.COM Fri May 15 06:30:52 2009 From: Peter.Zhelezniakov at Sun.COM (Peter Zhelezniakov) Date: Fri, 15 May 2009 17:30:52 +0400 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <4A0D2D9D.6080208@redhat.com> References: <17c6771e0905141420o5b1c3453sb2c78888f2b2efcf@mail.gmail.com> <4A0C8E1F.5070700@sun.com> <17c6771e0905141501o258f8342od6a2aa4f354f9979@mail.gmail.com> <4A0C9572.8020304@sun.com> <17c6771e0905141531y335ae147l3d50a1afd150af7c@mail.gmail.com> <4A0C9F0A.4090007@sun.com> <17c6771e0905141602vc8e6b5ck2244f590971ad5de@mail.gmail.com> <4A0D2D9D.6080208@redhat.com> Message-ID: <4A0D6E8C.6020904@Sun.com> Andrew Haley wrote: > We are not in a position to dictate to a user exactly which version of > JIBX will be installed on their system. Therefore, if JIBX is now a > dependency of OpenJDK we'll have to find a way to make OpenJDK work > with whatever versions of JIBX people choose. To make it clear: JIBX is not a runtime dependency. It is used at build time only. OpenJDK does work regardless of JIBX presence. -- Peter | x33066 | location: SPB04 | timezone: GMT+03 From pavel.porvatov at sun.com Fri May 15 06:33:18 2009 From: pavel.porvatov at sun.com (pavel.porvatov at sun.com) Date: Fri, 15 May 2009 13:33:18 +0000 Subject: hg: jdk7/swing/jdk: 6713352: Deadlock in JFileChooser with synchronized custom FileSystemView Message-ID: <20090515133330.29B91EF29@hg.openjdk.java.net> Changeset: 993a5f0fe2e0 Author: rupashka Date: 2009-05-15 17:26 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/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 From roman.kennke at aicas.com Fri May 15 06:33:40 2009 From: roman.kennke at aicas.com (Roman Kennke) Date: Fri, 15 May 2009 15:33:40 +0200 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <1242384383.3633.28.camel@localhost.localdomain> References: <17c6771e0905141420o5b1c3453sb2c78888f2b2efcf@mail.gmail.com> <4A0C8E1F.5070700@sun.com> <17c6771e0905141501o258f8342od6a2aa4f354f9979@mail.gmail.com> <4A0C9572.8020304@sun.com> <17c6771e0905141531y335ae147l3d50a1afd150af7c@mail.gmail.com> <4A0C9F0A.4090007@sun.com> <17c6771e0905141602vc8e6b5ck2244f590971ad5de@mail.gmail.com> <4A0D2D9D.6080208@redhat.com> <1242384383.3633.28.camel@localhost.localdomain> Message-ID: <1242394420.4666.6.camel@saturn> Hi, > and don't like the idea of being able to disable Nimbus > because of this dependency. Too many negations and ablebables for my parser... Oops. ;-) /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From mario.torre at aicas.com Fri May 15 06:54:04 2009 From: mario.torre at aicas.com (Mario Torre) Date: Fri, 15 May 2009 15:54:04 +0200 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <1242394420.4666.6.camel@saturn> References: <17c6771e0905141420o5b1c3453sb2c78888f2b2efcf@mail.gmail.com> <4A0C8E1F.5070700@sun.com> <17c6771e0905141501o258f8342od6a2aa4f354f9979@mail.gmail.com> <4A0C9572.8020304@sun.com> <17c6771e0905141531y335ae147l3d50a1afd150af7c@mail.gmail.com> <4A0C9F0A.4090007@sun.com> <17c6771e0905141602vc8e6b5ck2244f590971ad5de@mail.gmail.com> <4A0D2D9D.6080208@redhat.com> <1242384383.3633.28.camel@localhost.localdomain> <1242394420.4666.6.camel@saturn> Message-ID: <1242395644.3633.52.camel@localhost.localdomain> Il giorno ven, 15/05/2009 alle 15.33 +0200, Roman Kennke ha scritto: > Hi, > > > and don't like the idea of being able to disable Nimbus > > because of this dependency. > > Too many negations and ablebables for my parser... Oops. ;-) > > /Roman Argh :) I mean, disabling it for testing is one thing, but I fear that we will end up making it disabled by default just because JIBX is borked. The problem with the current code is that JIBX doesn't really compile, it just compile "enough" to create the jars that openjdk needs. Honestly, I see that this is not a very clean approach, and makes hard for distributions to have this package in (I personally don't care, I have secured the 4 magics jars and this is all I need :) 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 Fri May 15 06:39:18 2009 From: aph at redhat.com (Andrew Haley) Date: Fri, 15 May 2009 14:39:18 +0100 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <4A0D6E8C.6020904@Sun.com> References: <17c6771e0905141420o5b1c3453sb2c78888f2b2efcf@mail.gmail.com> <4A0C8E1F.5070700@sun.com> <17c6771e0905141501o258f8342od6a2aa4f354f9979@mail.gmail.com> <4A0C9572.8020304@sun.com> <17c6771e0905141531y335ae147l3d50a1afd150af7c@mail.gmail.com> <4A0C9F0A.4090007@sun.com> <17c6771e0905141602vc8e6b5ck2244f590971ad5de@mail.gmail.com> <4A0D2D9D.6080208@redhat.com> <4A0D6E8C.6020904@Sun.com> Message-ID: <4A0D7086.2060901@redhat.com> Peter Zhelezniakov wrote: > Andrew Haley wrote: >> We are not in a position to dictate to a user exactly which version of >> JIBX will be installed on their system. Therefore, if JIBX is now a >> dependency of OpenJDK we'll have to find a way to make OpenJDK work >> with whatever versions of JIBX people choose. > > To make it clear: JIBX is not a runtime dependency. It is used at build > time only. > > OpenJDK does work regardless of JIBX presence. Sure, thanks for clarifying, but it makes no difference to the real situation: we are not in a position to dictate to someone building OpenJDK exactly which version of JIBX will be installed on their system. The build systems used by distros aren't guaranteed to have exactly Version X of JIBX. Andrew. From gnu_andrew at member.fsf.org Fri May 15 08:30:04 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 15 May 2009 16:30:04 +0100 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <20090515040505.97F34913F@callebaut.niobe.net> References: <17c6771e0905141531y335ae147l3d50a1afd150af7c@mail.gmail.com> <20090515040505.97F34913F@callebaut.niobe.net> Message-ID: <17c6771e0905150830x6b7be66m4c4dbb7360ed09b0@mail.gmail.com> 2009/5/15 Mark Reinhold : >> Date: Thu, 14 May 2009 23:31:58 +0100 >> From: Andrew John Hughes > >> 2009/5/14 phil.race at sun.com: >>> I do think I know what you want. But I consider its a slippery slope as >>> you have no way of knowing or keeping track of the consequences of >>> not building a particular component. >> >> Sure, but if someone chooses to set DISABLE_NIMBUS then they take that >> risk. ?It's much the same as if they turn on insane mode or don't >> build the docs. ?It's a tradeoff of having an incomplete build at the >> end against simplifying the process, and one it is down to the user to >> make. ?For example, if someone wants to build OpenJDK as a precursor >> to hacking on HotSpot, then they are probably more concerned about >> just completing the build than finding an additional set of >> dependencies for a look and feel they probably won't use. ?I don't see >> how arbitrarily restricting choice helps anyone. >> >>> I suggest its better to fix the local build problem than push workarounds >>> upstream. >> >> My fear is we will run over this problem again and again. ?If people >> working on OpenJDK day in and day out are having issues with this, >> then newbies are going to fare even worse. > > I have to agree with Andrew on this one. > > Engineers working on the JDK routinely skip building various components, > yet somehow we've survived. ?When was the last time, e.g., you built > HotSpot, or javac, or the Windows installer, or generated rpm packages on > Linux? > > There are already lots of ways to disable various components of the > build. ?The better ones take care to issue a warning during the sanity > check so that people who carelessly set build variables in their shell > environment don't get tripped up too badly, as long as they make sure to > read the sanity log. > > That these happen to be "platform" classes doesn't mean much. ?The chance > that a Nimbus-disabled build would be mistaken for a product build is > pretty well near zero, given all the testing that we do. > > If this tiny change makes it easier for people to work with our code, > then I'm all for it. > > My only comment on Andrew's actual patch is that Sanity.gmk should be > extended to print a warning when Nimbus is disabled. ?It otherwise looks > fine to me. > I was thinking this as I read your mail. It should be easy enough to add this as an #else clause to the existing patch in Sanity.gmk. What's the best way to handle updating the patch, given that the existing patch is a committed changeset? Do I need to somehow revert the changeset or is a pair of changesets feasible? > Oh, and if we have somehow become dependent upon a third-party tool > (JIBX) that's so difficult to locate and has such a low commitment to > interface stability, then perhaps we should reconsider that and use a > different tool. > > - Mark > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From mr at sun.com Fri May 15 09:00:05 2009 From: mr at sun.com (Mark Reinhold) Date: Fri, 15 May 2009 09:00:05 -0700 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: gnu_andrew@member.fsf.org; Fri, 15 May 2009 16:30:04 BST; <17c6771e0905150830x6b7be66m4c4dbb7360ed09b0@mail.gmail.com> Message-ID: <20090515160005.44B735E97@eggemoggin.niobe.net> > Date: Fri, 15 May 2009 16:30:04 +0100 > From: Andrew John Hughes > I was thinking this as I read your mail. It should be easy enough to > add this as an #else clause to the existing patch in Sanity.gmk. > What's the best way to handle updating the patch, given that the > existing patch is a committed changeset? Do I need to somehow revert > the changeset or is a pair of changesets feasible? One changeset is best. You need somehow to revert the changeset anyway since it'd need a proper comment, with a Sun bug id, before being pushed upstream. (I just created one for you: 6841728.) (I can't resist pointing out that if you were using Mercurial patch queues you could just pop to that patch, edit, re-test, finalize, and then push the resulting changeset upstream.) - Mark From Jonathan.Gibbons at Sun.COM Fri May 15 09:08:39 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 15 May 2009 09:08:39 -0700 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <20090515160005.44B735E97@eggemoggin.niobe.net> References: <20090515160005.44B735E97@eggemoggin.niobe.net> Message-ID: <9A20D775-152F-4E56-A8F0-AB8BEDE0E535@sun.com> On May 15, 2009, at 9:00 AM, Mark Reinhold wrote: >> Date: Fri, 15 May 2009 16:30:04 +0100 >> From: Andrew John Hughes > >> I was thinking this as I read your mail. It should be easy enough to >> add this as an #else clause to the existing patch in Sanity.gmk. >> What's the best way to handle updating the patch, given that the >> existing patch is a committed changeset? Do I need to somehow revert >> the changeset or is a pair of changesets feasible? > > One changeset is best. You need somehow to revert the changeset > anyway since it'd need a proper comment, with a Sun bug id, before > being pushed upstream. (I just created one for you: 6841728.) > > (I can't resist pointing out that if you were using Mercurial patch > queues you could just pop to that patch, edit, re-test, finalize, > and then push the resulting changeset upstream.) > > - Mark Mark, What is your experience with the combination of mq and jcheck? I like having jcheck enabled as a preextension hook, but that didn't work well with mq. -- Jon From gnu_andrew at member.fsf.org Fri May 15 10:32:14 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 15 May 2009 18:32:14 +0100 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <20090515160005.44B735E97@eggemoggin.niobe.net> References: <17c6771e0905150830x6b7be66m4c4dbb7360ed09b0@mail.gmail.com> <20090515160005.44B735E97@eggemoggin.niobe.net> Message-ID: <17c6771e0905151032o63fee239vaf35dfbf2f1342b6@mail.gmail.com> 2009/5/15 Mark Reinhold : >> Date: Fri, 15 May 2009 16:30:04 +0100 >> From: Andrew John Hughes > >> I was thinking this as I read your mail. ?It should be easy enough to >> add this as an #else clause to the existing patch in Sanity.gmk. >> What's the best way to handle updating the patch, given that the >> existing patch is a committed changeset? ?Do I need to somehow revert >> the changeset or is a pair of changesets feasible? > > One changeset is best. ?You need somehow to revert the changeset > Somehow I thought that's what you were going to say.. :) Looks like I can do a hg backout to revert the last changeset, and then create a new one. What's the preferred repo to work against? jdk7/jdk7? I commit the changes because OpenJDK's documentation seems to suggest that this is prefered (patch submission says hg export -g is preferable, webrev does an (f)outgoing search first). Do Sun engineers usually just have their patches as uncommitted changes? > anyway since it'd need a proper comment, with a Sun bug id, before > being pushed upstream. (I just created one for you: 6841728.) It had a bug ID, just a Bugzilla one... Is the standard format for such messages documented somewhere? > (I can't resist pointing out that if you were using Mercurial patch > ?queues you could just pop to that patch, edit, re-test, finalize, > ?and then push the resulting changeset upstream.) > Yeah, but can webrev use patch queues yet? ;) > - Mark > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From mr at sun.com Fri May 15 20:57:19 2009 From: mr at sun.com (Mark Reinhold) Date: Fri, 15 May 2009 20:57:19 -0700 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: gnu_andrew@member.fsf.org; Fri, 15 May 2009 18:32:14 BST; <17c6771e0905151032o63fee239vaf35dfbf2f1342b6@mail.gmail.com> Message-ID: <20090516035719.1C927913F@callebaut.niobe.net> > Date: Fri, 15 May 2009 18:32:14 +0100 > From: Andrew John Hughes > 2009/5/15 Mark Reinhold : >> One changeset is best. ??You need somehow to revert the changeset > > Somehow I thought that's what you were going to say.. :) > Looks like I can do a hg backout to revert the last changeset, and > then create a new one. What's the preferred repo to work against? > jdk7/jdk7? The preferred repo is the one into which your change will be pushed. In this case I'd suggest jdk7/build so that Xiomara's build testing, which runs in the context of the release-engineering system that does our product builds, has a chance to catch any problems (which seems extremely unlikely in this case). > I commit the changes because OpenJDK's documentation seems to suggest > that this is prefered (patch submission says hg export -g is > preferable, webrev does an (f)outgoing search first). Ah, I was assuming you were going to push the change in yourself. If you'd rather just submit a patch that's fine too; whichever you prefer. > Do Sun > engineers usually just have their > patches as uncommitted changes? No. My impression (which may be incorrect) is that many Sun engineers still aren't all that comfortable slinging patches, so instead they tend to work on several different repos/forests, one per change in progress, which was a common practice with the old internal TeamWare SCM. >> anyway since it'd need a proper comment, with a Sun bug id, before >> being pushed upstream. (I just created one for you: 6841728.) > > It had a bug ID, just a Bugzilla one... At the moment we're assigning inbound patches a Sun bug id for tracking purposes, and still using Sun bug ids uniformly in changeset comments. That will change, in time, as part of the Bugzilla migration project. > Is the standard format for such messages documented somewhere? http://openjdk.java.net/guide/producingChangeset.html#changesetComment >> (I can't resist pointing out that if you were using Mercurial patch >> ??queues you could just pop to that patch, edit, re-test, finalize, >> ??and then push the resulting changeset upstream.) > > Yeah, but can webrev use patch queues yet? ;) There are no mq-specific features in webrev, but since an mq-managed patch shows up as a regular changeset there's no reason you couldn't create a webrev comparing that changeset to some other one using the exicting capabilities of the webrev script. - Mark From fbrunnerlist at gmx.ch Sun May 17 09:16:37 2009 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Sun, 17 May 2009 18:16:37 +0200 Subject: [PATCH] 6179357: Generics: JList In-Reply-To: <4A0C1F14.6070307@sun.com> References: <200903222003.05081.fbrunnerlist@gmx.ch> <49FF066D.6000200@gmx.ch> <4A0C1F14.6070307@sun.com> Message-ID: <200905171816.37657.fbrunnerlist@gmx.ch> Hi Pavel, as far as I remember, the problem with E[] getSelectedValues() was, that it is not possible to create a generic array. As for: public E[] getSelectedValues(E[] a) you can get this array already with getSelectedValuesList().toArray(array) Of course, the other way around would work, too, but since lists should generally be preferred to arrays for various reasons (see item 25 of Joshua Bloch's book "Effective Java", 2nd edition, for some of them), I think we should prefer List getSelectedValuesList() over E[] getSelectedValues(E[] a) As for deprecating the original getSelectedValues() method: It's not absolutly needed, but then we would have 2 methods, which would do pretty much the same. This could confuse users, which one to use. By deprecating the old one, we tell users that for new code, lists and generics are preferred. They still can get an array when needed without getting a deprecated warning, by calling one of the toArray-methods. And since people are complaining, that the Swing API is already bloated (eg. see the Swing 2.0 discussions at http://kenai.com/projects/swing2/lists ), I think it's a good thing to reduce the API by deprecating methods, if there are other methods which should be preferred. -Florian > Hi Florian, > > Some time ago we discussed two different ways to add the new method > "getSelectedValuesList()". The first one is the current implementation > in your fix: > > 1. public List getSelectedValuesList() > Benefits: > a. easy to use > b. Collection framework is very flexible > > The second way is: > > 2. public E[] getSelectedValues(E[] a) > Benefits: > a. The same pattern used in the java.util.Collection#toArray(T[] a) > method > b. a little bit easer to port an old code > > Also a lot of people noticed that there is no need to deprecate the > javax.swing.JList#getSelectedValues method because it still can be useful. > > Any ideas? > > Regards, Pavel > > > Hi Pavel, hi Alexander, > > > > I'm back from holiday. > > > > What is the status of this patch? Any news? > > > > -Florian > > > > Alexander Potochkin schrieb: > >> Hello Florian > >> > >>> Great! :-) > >>> > >>> In the case of other issues please note that I'm on holiday until the > >>> end of next week. > >> > >> Have a nice holiday! > >> > >> (I am reviewing the fix right now) > >> > >> Thanks > >> alexp > >> > >>> -Florian > >>> > >>> Pavel Porvatov schrieb: > >>>> Hi Florian, > >>>> > >>>>> Hi Pavel, > >>>>> > >>>>> I agree that we should avoid to mix several different fixes in one > >>>>> fix, but since in this fix we change > >>>>> > >>>>> AbstractListModel to AbstractListModel > >>>>> and > >>>>> JList(ListModel dataModel) to JList(ListModel dataModel) > >>>>> > >>>>> I think we should also change usages of AbstractListModel such as > >>>>> "this (new AbstractListModel()...)" to "this (new > >>>>> AbstractListModel()...)" to avoid warnings. > >>>> > >>>> Ok, then it will not be a problem. Let's include this change in your > >>>> fix. Therefore all my comments are gone and I'm going to start our > >>>> internal process to commit your fix. > >>>> > >>>> Thanks, Pavel. > >>>> > >>>>> If you don't agree: > >>>>> There are several places where I changed the usage of now > >>>>> generified classes to the generic variant. Which ones should I > >>>>> change back? Only this case? From Kelly.Ohair at Sun.COM Sun May 17 10:03:41 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sun, 17 May 2009 10:03:41 -0700 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <20090516035719.1C927913F@callebaut.niobe.net> References: <20090516035719.1C927913F@callebaut.niobe.net> Message-ID: <4A10436D.2060701@sun.com> Mark Reinhold wrote: >> Date: Fri, 15 May 2009 18:32:14 +0100 >> From: Andrew John Hughes > [...snip...] >>> (I can't resist pointing out that if you were using Mercurial patch >>> ? queues you could just pop to that patch, edit, re-test, finalize, >>> ? and then push the resulting changeset upstream.) >> Yeah, but can webrev use patch queues yet? ;) > > There are no mq-specific features in webrev, but since an mq-managed > patch shows up as a regular changeset there's no reason you couldn't > create a webrev comparing that changeset to some other one using the > exicting capabilities of the webrev script. > Try the webrev -N option, it will create a webrev of the edited working set files against the current tip. -kto From gnu_andrew at member.fsf.org Mon May 18 11:17:21 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 18 May 2009 19:17:21 +0100 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <20090516035719.1C927913F@callebaut.niobe.net> References: <17c6771e0905151032o63fee239vaf35dfbf2f1342b6@mail.gmail.com> <20090516035719.1C927913F@callebaut.niobe.net> Message-ID: <17c6771e0905181117r78305af9u2f36049af8798754@mail.gmail.com> 2009/5/16 Mark Reinhold : >> Date: Fri, 15 May 2009 18:32:14 +0100 >> From: Andrew John Hughes > >> 2009/5/15 Mark Reinhold : >>> One changeset is best. ??You need somehow to revert the changeset >> >> Somehow I thought that's what you were going to say.. :) >> Looks like I can do a hg backout to revert the last changeset, and >> then create a new one. ?What's the preferred repo to work against? >> jdk7/jdk7? > > The preferred repo is the one into which your change will be pushed. > In this case I'd suggest jdk7/build so that Xiomara's build testing, > which runs in the context of the release-engineering system that does > our product builds, has a chance to catch any problems (which seems > extremely unlikely in this case). > Ok, new webrev created against jdk7/build: http://fuseyism.com/6841728/webrev.01/ I presume I need to wait a bit due to the current block on pushes though. >> I commit the changes because OpenJDK's documentation seems to suggest >> that this is preferred (patch submission says hg export -g is >> preferable, webrev does an (f)outgoing search first). > > Ah, I was assuming you were going to push the change in yourself. ?If > you'd rather just submit a patch that's fine too; whichever you prefer. > You're right, I do plan to push the change myself. I was just using that as an example of the assumption that the changes would have been committed prior to patch creation, rather than being local uncommitted changes. >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Do Sun >> engineers usually just have their >> patches as uncommitted changes? > > No. ?My impression (which may be incorrect) is that many Sun engineers > still aren't all that comfortable slinging patches, so instead they tend > to work on several different repos/forests, one per change in progress, > which was a common practice with the old internal TeamWare SCM. > Ah, right -- now it makes sense :) >>> anyway since it'd need a proper comment, with a Sun bug id, before >>> being pushed upstream. ?(I just created one for you: 6841728.) >> >> It had a bug ID, just a Bugzilla one... > > At the moment we're assigning inbound patches a Sun bug id for tracking > purposes, and still using Sun bug ids uniformly in changeset comments. > That will change, in time, as part of the Bugzilla migration project. > Understood. It will be better all round when we we fully migrate. >> Is the standard format for such messages documented somewhere? > > http://openjdk.java.net/guide/producingChangeset.html#changesetComment > Thanks. I'd forgotten about the developer guide. It was been discussed for a while, but then things seemed to go quiet. Is it now complete? >>> (I can't resist pointing out that if you were using Mercurial patch >>> ??queues you could just pop to that patch, edit, re-test, finalize, >>> ??and then push the resulting changeset upstream.) >> >> Yeah, but can webrev use patch queues yet? ;) > > There are no mq-specific features in webrev, but since an mq-managed > patch shows up as a regular changeset there's no reason you couldn't > create a webrev comparing that changeset to some other one using the > exicting capabilities of the webrev script. > > - Mark > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From mr at sun.com Thu May 21 07:47:49 2009 From: mr at sun.com (Mark Reinhold) Date: Thu, 21 May 2009 07:47:49 -0700 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: gnu_andrew@member.fsf.org; Mon, 18 May 2009 19:17:21 BST; <17c6771e0905181117r78305af9u2f36049af8798754@mail.gmail.com> Message-ID: <20090521144749.A04AE5E96@eggemoggin.niobe.net> > Date: Mon, 18 May 2009 19:17:21 +0100 > From: Andrew John Hughes > Ok, new webrev created against jdk7/build: > > http://fuseyism.com/6841728/webrev.01/ Looks good to me -- go ahead and push when ready. > I presume I need to wait a bit due to the current block on pushes though. No, the group integration areas are already open for M4. >>> Is the standard format for such messages documented somewhere? >> >> http://openjdk.java.net/guide/producingChangeset.html#changesetComment > > Thanks. I'd forgotten about the developer guide. It was been > discussed for a while, but then things seemed to go quiet. Is it now > complete? No, unfortunately no one's had time to work on it, except for minor changes, since the first version. What's there is still relatively accurate. - Mark From gnu_andrew at member.fsf.org Thu May 21 08:51:24 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 21 May 2009 16:51:24 +0100 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <20090521144749.A04AE5E96@eggemoggin.niobe.net> References: <17c6771e0905181117r78305af9u2f36049af8798754@mail.gmail.com> <20090521144749.A04AE5E96@eggemoggin.niobe.net> Message-ID: <17c6771e0905210851x18668fd5r8289b71b48e310fc@mail.gmail.com> 2009/5/21 Mark Reinhold : >> Date: Mon, 18 May 2009 19:17:21 +0100 >> From: Andrew John Hughes > >> Ok, new webrev created against jdk7/build: >> >> http://fuseyism.com/6841728/webrev.01/ > > Looks good to me -- go ahead and push when ready. > Pushed: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c06d30bd8c69 >> I presume I need to wait a bit due to the current block on pushes though. > > No, the group integration areas are already open for M4. > >>>> Is the standard format for such messages documented somewhere? >>> >>> http://openjdk.java.net/guide/producingChangeset.html#changesetComment >> >> Thanks. ?I'd forgotten about the developer guide. ?It was been >> discussed for a while, but then things seemed to go quiet. ?Is it now >> complete? > > No, unfortunately no one's had time to work on it, except for minor > changes, since the first version. ?What's there is still relatively > accurate. > Looks like the Contributed-by info is wrong. I tried adding the line as in the example and jcheck choked: remote: > Contributed-by: Andrew John Hughes remote: remote: Invalid contributor attribution remote: remote: abort: pretxnchangegroup.0.jcheck hook failed The example is Contributed-by: Ben Bitdiddle > - Mark > Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Jonathan.Gibbons at Sun.COM Thu May 21 09:55:57 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Thu, 21 May 2009 09:55:57 -0700 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <17c6771e0905210851x18668fd5r8289b71b48e310fc@mail.gmail.com> References: <17c6771e0905181117r78305af9u2f36049af8798754@mail.gmail.com> <20090521144749.A04AE5E96@eggemoggin.niobe.net> <17c6771e0905210851x18668fd5r8289b71b48e310fc@mail.gmail.com> Message-ID: <5FD40471-9D95-4E0A-A87E-0CD49A5B0650@sun.com> Andrew, Yes, Contributed-by: just takes a simple email address. It'll be munged (@ -> " at ") automatiocally on web pages. -- Jon On May 21, 2009, at 8:51 AM, Andrew John Hughes wrote: > 2009/5/21 Mark Reinhold : >>> Date: Mon, 18 May 2009 19:17:21 +0100 >>> From: Andrew John Hughes >> >>> Ok, new webrev created against jdk7/build: >>> >>> http://fuseyism.com/6841728/webrev.01/ >> >> Looks good to me -- go ahead and push when ready. >> > > Pushed: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c06d30bd8c69 > >>> I presume I need to wait a bit due to the current block on pushes >>> though. >> >> No, the group integration areas are already open for M4. >> >>>>> Is the standard format for such messages documented somewhere? >>>> >>>> http://openjdk.java.net/guide/producingChangeset.html#changesetComment >>> >>> Thanks. I'd forgotten about the developer guide. It was been >>> discussed for a while, but then things seemed to go quiet. Is it >>> now >>> complete? >> >> No, unfortunately no one's had time to work on it, except for minor >> changes, since the first version. What's there is still relatively >> accurate. >> > > Looks like the Contributed-by info is wrong. I tried adding the line > as in the example and jcheck choked: > > remote: > Contributed-by: Andrew John Hughes > remote: > remote: Invalid contributor attribution > remote: > remote: abort: pretxnchangegroup.0.jcheck hook failed > > The example is Contributed-by: Ben Bitdiddle > >> - Mark >> > > Thanks, > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Thu May 21 10:15:11 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 21 May 2009 18:15:11 +0100 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <5FD40471-9D95-4E0A-A87E-0CD49A5B0650@sun.com> References: <17c6771e0905181117r78305af9u2f36049af8798754@mail.gmail.com> <20090521144749.A04AE5E96@eggemoggin.niobe.net> <17c6771e0905210851x18668fd5r8289b71b48e310fc@mail.gmail.com> <5FD40471-9D95-4E0A-A87E-0CD49A5B0650@sun.com> Message-ID: <17c6771e0905211015n7f38664ap2de8f9e386e526d7@mail.gmail.com> 2009/5/21 Jonathan Gibbons : > Andrew, > > Yes, Contributed-by: just takes a simple email address. ? It'll be munged (@ > -> " at ") automatically on web pages. > > -- Jon > Ugh, should have thought of that. It's confusing having an example that doesn't work as given :( > > On May 21, 2009, at 8:51 AM, Andrew John Hughes wrote: > >> 2009/5/21 Mark Reinhold : >>>> >>>> Date: Mon, 18 May 2009 19:17:21 +0100 >>>> From: Andrew John Hughes >>> >>>> Ok, new webrev created against jdk7/build: >>>> >>>> http://fuseyism.com/6841728/webrev.01/ >>> >>> Looks good to me -- go ahead and push when ready. >>> >> >> Pushed: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c06d30bd8c69 >> >>>> I presume I need to wait a bit due to the current block on pushes >>>> though. >>> >>> No, the group integration areas are already open for M4. >>> >>>>>> Is the standard format for such messages documented somewhere? >>>>> >>>>> http://openjdk.java.net/guide/producingChangeset.html#changesetComment >>>> >>>> Thanks. ?I'd forgotten about the developer guide. ?It was been >>>> discussed for a while, but then things seemed to go quiet. ?Is it now >>>> complete? >>> >>> No, unfortunately no one's had time to work on it, except for minor >>> changes, since the first version. ?What's there is still relatively >>> accurate. >>> >> >> Looks like the Contributed-by info is wrong. ?I tried adding the line >> as in the example and jcheck choked: >> >> remote: > Contributed-by: Andrew John Hughes >> remote: >> remote: Invalid contributor attribution >> remote: >> remote: abort: pretxnchangegroup.0.jcheck hook failed >> >> The example is Contributed-by: Ben Bitdiddle >> >>> - Mark >>> >> >> Thanks, >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Jonathan.Gibbons at Sun.COM Thu May 21 10:18:04 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Thu, 21 May 2009 10:18:04 -0700 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <17c6771e0905211015n7f38664ap2de8f9e386e526d7@mail.gmail.com> References: <17c6771e0905181117r78305af9u2f36049af8798754@mail.gmail.com> <20090521144749.A04AE5E96@eggemoggin.niobe.net> <17c6771e0905210851x18668fd5r8289b71b48e310fc@mail.gmail.com> <5FD40471-9D95-4E0A-A87E-0CD49A5B0650@sun.com> <17c6771e0905211015n7f38664ap2de8f9e386e526d7@mail.gmail.com> Message-ID: <9E056ED9-6B3A-4EA2-BE89-06642F80EFE4@Sun.COM> I'll try and get the example fixed. -- Jon On May 21, 2009, at 10:15 AM, Andrew John Hughes wrote: > 2009/5/21 Jonathan Gibbons : >> Andrew, >> >> Yes, Contributed-by: just takes a simple email address. It'll be >> munged (@ >> -> " at ") automatically on web pages. >> >> -- Jon >> > > Ugh, should have thought of that. It's confusing having an example > that doesn't work as given :( > >> >> On May 21, 2009, at 8:51 AM, Andrew John Hughes wrote: >> >>> 2009/5/21 Mark Reinhold : >>>>> >>>>> Date: Mon, 18 May 2009 19:17:21 +0100 >>>>> From: Andrew John Hughes >>>> >>>>> Ok, new webrev created against jdk7/build: >>>>> >>>>> http://fuseyism.com/6841728/webrev.01/ >>>> >>>> Looks good to me -- go ahead and push when ready. >>>> >>> >>> Pushed: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c06d30bd8c69 >>> >>>>> I presume I need to wait a bit due to the current block on pushes >>>>> though. >>>> >>>> No, the group integration areas are already open for M4. >>>> >>>>>>> Is the standard format for such messages documented somewhere? >>>>>> >>>>>> http://openjdk.java.net/guide/producingChangeset.html#changesetComment >>>>> >>>>> Thanks. I'd forgotten about the developer guide. It was been >>>>> discussed for a while, but then things seemed to go quiet. Is >>>>> it now >>>>> complete? >>>> >>>> No, unfortunately no one's had time to work on it, except for minor >>>> changes, since the first version. What's there is still relatively >>>> accurate. >>>> >>> >>> Looks like the Contributed-by info is wrong. I tried adding the >>> line >>> as in the example and jcheck choked: >>> >>> remote: > Contributed-by: Andrew John Hughes >>> remote: >>> remote: Invalid contributor attribution >>> remote: >>> remote: abort: pretxnchangegroup.0.jcheck hook failed >>> >>> The example is Contributed-by: Ben Bitdiddle >>> >>>> - Mark >>>> >>> >>> Thanks, >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> >> > > > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Pavel.Porvatov at Sun.COM Fri May 22 01:27:42 2009 From: Pavel.Porvatov at Sun.COM (Pavel Porvatov) Date: Fri, 22 May 2009 12:27:42 +0400 Subject: [PATCH] 6179357: Generics: JList In-Reply-To: <200905171816.37657.fbrunnerlist@gmx.ch> References: <200903222003.05081.fbrunnerlist@gmx.ch> <49FF066D.6000200@gmx.ch> <4A0C1F14.6070307@sun.com> <200905171816.37657.fbrunnerlist@gmx.ch> Message-ID: <4A1661FE.40901@sun.com> Hi Florian, > Hi Pavel, > > as far as I remember, the problem with > E[] getSelectedValues() > > was, that it is not possible to create a generic array. > > As for: > public E[] getSelectedValues(E[] a) > > you can get this array already with > getSelectedValuesList().toArray(array) > > Of course, the other way around would work, too, but since lists should generally be preferred to > arrays for various reasons (see item 25 of Joshua Bloch's book "Effective Java", 2nd edition, for > some of them), I think we should prefer > > List getSelectedValuesList() > > over > > E[] getSelectedValues(E[] a) > > As for deprecating the original getSelectedValues() method: > It's not absolutly needed, but then we would have 2 methods, which would do pretty much the same. > This could confuse users, which one to use. By deprecating the old one, we tell users that for new > code, lists and generics are preferred. They still can get an array when needed without getting a > deprecated warning, by calling one of the toArray-methods. > > And since people are complaining, that the Swing API is already bloated (eg. see the Swing 2.0 > discussions at http://kenai.com/projects/swing2/lists ), I think it's a good thing to reduce the API > by deprecating methods, if there are other methods which should be preferred. I absolutely agree with you. Does anybody have an another opinion? Note that after this fix will be committed we will not be able to revert any changes in API... Regards, Pavel. > -Florian > >> Hi Florian, >> >> Some time ago we discussed two different ways to add the new method >> "getSelectedValuesList()". The first one is the current implementation >> in your fix: >> >> 1. public List getSelectedValuesList() >> Benefits: >> a. easy to use >> b. Collection framework is very flexible >> >> The second way is: >> >> 2. public E[] getSelectedValues(E[] a) >> Benefits: >> a. The same pattern used in the java.util.Collection#toArray(T[] a) >> method >> b. a little bit easer to port an old code >> >> Also a lot of people noticed that there is no need to deprecate the >> javax.swing.JList#getSelectedValues method because it still can be useful. >> >> Any ideas? >> >> Regards, Pavel >> >>> Hi Pavel, hi Alexander, >>> >>> I'm back from holiday. >>> >>> What is the status of this patch? Any news? >>> >>> -Florian >>> >>> Alexander Potochkin schrieb: >>>> Hello Florian >>>> >>>>> Great! :-) >>>>> >>>>> In the case of other issues please note that I'm on holiday until the >>>>> end of next week. >>>> Have a nice holiday! >>>> >>>> (I am reviewing the fix right now) >>>> >>>> Thanks >>>> alexp >>>> >>>>> -Florian >>>>> >>>>> Pavel Porvatov schrieb: >>>>>> Hi Florian, >>>>>> >>>>>>> Hi Pavel, >>>>>>> >>>>>>> I agree that we should avoid to mix several different fixes in one >>>>>>> fix, but since in this fix we change >>>>>>> >>>>>>> AbstractListModel to AbstractListModel >>>>>>> and >>>>>>> JList(ListModel dataModel) to JList(ListModel dataModel) >>>>>>> >>>>>>> I think we should also change usages of AbstractListModel such as >>>>>>> "this (new AbstractListModel()...)" to "this (new >>>>>>> AbstractListModel()...)" to avoid warnings. >>>>>> Ok, then it will not be a problem. Let's include this change in your >>>>>> fix. Therefore all my comments are gone and I'm going to start our >>>>>> internal process to commit your fix. >>>>>> >>>>>> Thanks, Pavel. >>>>>> >>>>>>> If you don't agree: >>>>>>> There are several places where I changed the usage of now >>>>>>> generified classes to the generic variant. Which ones should I >>>>>>> change back? Only this case? > > From enh at jessies.org Mon May 25 16:04:25 2009 From: enh at jessies.org (Elliott Hughes) Date: Mon, 25 May 2009 16:04:25 -0700 (PDT) Subject: JColorChooser on GTK (GTKColorChooserPanel) Message-ID: <43951.76.193.119.39.1243292665.squirrel@webmail.jessies.org> I just had a quick look at the native GTK+ color dialog next to a Swing JColorChooser. A number of problems stand out: [*] Transferring focus out of the "Color name:" field should update the color. [*] The "Color name:" field should accept X11 color names. [*] "Color Name:" should be "Color name:". [*] "R_ed:" should be "_Red:" (mnemonic index). [*] The absence of a preview panel (i.e. a zero-sized preview panel, since a null preview panel is not allowed) should imply no separator. Since the preview panel is non-GTK anyway, I think the GTK panel shouldn't have that separator. Advanced users are going to remove the preview panel, and naive users won't notice (and have no real right to complain it's "wrong", because it isn't). (Sun bug 6417110.) [*] Labels and fields should be aligned on their baselines, not against the tops of their GridBagLayout cells. [*] Spinner labels should be left-aligned. (Sun bug 4943902.) [*] Spacing between columns of spinners is wrong. (Sun bug 4943902; actually an optical illusion caused by the wrong alignment.) * Spacing above and below the separator between the spinners and the "Color name:" field is wrong. * Focus cycle is H,R,S,G,V,B but should be H,S,V,R,G,B. * The swatch is missing a border. * "Dropper" button is missing (Sun bug 4869100). * H,S,V seem to be percentages in the native dialog, not 0-360, 0-255, 0-255. * The focus indicator on the circle/triangle component is wrong (should be a dotted square border; is a solid circle). * The rendering of the circle/triangle component is horribly aliased; should be smooth. At a higher level, JColorChooser itself should: * Use an empty preview panel with GTK+. (Sun bug 6417110.) * Not have a "Reset" button with GTK+. (Sun bug 6417110, 4943902.) * Order the other buttons "Cancel", "OK" (instead of the wrong way round). (Sun bug 6417110.) * Have the "Cancel" and "OK" buttons the same size. (Sun bugs 6417110, 5012459.) * Use standard GTK+ "Cancel" and "OK" icons. (Sun bug 6417110.) * Use standard GTK+ "_Cancel" and "_OK" mnemonics. (Sun bug 6417110, 4943902.) (A lot of these suggest to me that JColorChooser should use JOptionPane, which has already been fixed to get a lot of these things right. In my own code, I only use JColorChooser as an embeddable panel for these reasons, which is why I've separated these bugs out: I don't really care about them.) Anyway, I have fixes for the first four (marked "[*]" rather than "*"), and wondered if there's any interest. Should I raise one bug for the stuff I've? Lots of extra bugs for the problems that don't already have bugs? One big bug for the stuff I've fixed and lots of little bugs for the stuff I've yet to look at? Or is the GTK JColorChooser going to be replaced with native code? Oh, and do I need to sort out the SCA before I show patches, or just before they can be submitted? (I've deliberately not attached anything here in case you don't want to see code not covered by an SCA. I haven't filled out the SCA yet because, not living in the 1980s, I don't have easy access to either a fax machine or a scanner.) -- Elliott Hughes, http://www.jessies.org/~enh/ From Alexander.Potochkin at Sun.COM Wed May 27 06:57:47 2009 From: Alexander.Potochkin at Sun.COM (ap153225) Date: Wed, 27 May 2009 17:57:47 +0400 Subject: JColorChooser on GTK (GTKColorChooserPanel) In-Reply-To: <43951.76.193.119.39.1243292665.squirrel@webmail.jessies.org> References: <43951.76.193.119.39.1243292665.squirrel@webmail.jessies.org> Message-ID: <4A1D46DB.3040401@sun.com> Hello Elliott > Anyway, I have fixes for the first four (marked "[*]" rather than "*"), > and wondered if there's any interest. We certainly interested in fixing all that problems > Should I raise one bug for the stuff > I've? Lots of extra bugs for the problems that don't already have bugs? > One big bug for the stuff I've fixed and lots of little bugs for the stuff > I've yet to look at? > One bug for all that stuff is okay, I can file it for you if you send the description > Or is the GTK JColorChooser going to be replaced with native code? > We might add native dialog support in JDK 7, but JColorChooser is not gonna be replaced anyway > Oh, and do I need to sort out the SCA before I show patches, or just > before they can be submitted? (I've deliberately not attached anything > here in case you don't want to see code not covered by an SCA. That's right, we don't want to see code not covered by a SCA :-) > I haven't > filled out the SCA yet because, not living in the 1980s, I don't have easy > access to either a fax machine or a scanner.) > > I do hope it won't be a big problem for you to find a scanner, please find all the information about the SCA here: https://sca.dev.java.net/ Keep in touch Thanks alexp From Dalibor.Topic at Sun.COM Wed May 27 09:10:53 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Wed, 27 May 2009 09:10:53 -0700 Subject: JColorChooser on GTK (GTKColorChooserPanel) In-Reply-To: <43951.76.193.119.39.1243292665.squirrel@webmail.jessies.org> References: <43951.76.193.119.39.1243292665.squirrel@webmail.jessies.org> Message-ID: <4A1D660D.8030702@sun.com> Elliott Hughes wrote: > Oh, and do I need to sort out the SCA before I show patches, or just > before they can be submitted? (I've deliberately not attached anything > here in case you don't want to see code not covered by an SCA. I haven't > filled out the SCA yet because, not living in the 1980s, I don't have easy > access to either a fax machine or a scanner.) Regular mail is fine, too - the address is on http://sca.dev.java.net cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin H?ring From pavel.porvatov at sun.com Thu May 28 07:18:07 2009 From: pavel.porvatov at sun.com (pavel.porvatov at sun.com) Date: Thu, 28 May 2009 14:18:07 +0000 Subject: hg: jdk7/swing/jdk: 6845805: Test for CR 6713352 is failed under Linux Message-ID: <20090528141819.A8914EB67@hg.openjdk.java.net> Changeset: 019908df0313 Author: rupashka Date: 2009-05-28 18:11 +0400 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/019908df0313 6845805: Test for CR 6713352 is failed under Linux Reviewed-by: malenkov ! test/javax/swing/JFileChooser/6713352/bug6713352.java From mr at sun.com Fri May 29 09:15:19 2009 From: mr at sun.com (Mark Reinhold) Date: Fri, 29 May 2009 09:15:19 -0700 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: gnu_andrew@member.fsf.org; Thu, 21 May 2009 16:51:24 BST; <17c6771e0905210851x18668fd5r8289b71b48e310fc@mail.gmail.com> Message-ID: <20090529161519.913585E98@eggemoggin.niobe.net> > Date: Thu, 21 May 2009 16:51:24 +0100 > From: Andrew John Hughes > ... > > Looks like the Contributed-by info is wrong. I tried adding the line > as in the example and jcheck choked: > > remote: > Contributed-by: Andrew John Hughes > remote: > remote: Invalid contributor attribution > remote: > remote: abort: pretxnchangegroup.0.jcheck hook failed > > The example is Contributed-by: Ben Bitdiddle Right -- as Jon already pointed out, this is a bug in the example. More the the point, however, you didn't need a Contributed-by line in your comment since you are the author. That line is meant to be used only when the author of the changeset (in hg terms) is not the sole author of the actual patch. - Mark From gnu_andrew at member.fsf.org Fri May 29 09:20:08 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 29 May 2009 17:20:08 +0100 Subject: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional In-Reply-To: <20090529161519.913585E98@eggemoggin.niobe.net> References: <17c6771e0905210851x18668fd5r8289b71b48e310fc@mail.gmail.com> <20090529161519.913585E98@eggemoggin.niobe.net> Message-ID: <17c6771e0905290920n5fd7cbe4t1f411356263c77a6@mail.gmail.com> 2009/5/29 Mark Reinhold : >> Date: Thu, 21 May 2009 16:51:24 +0100 >> From: Andrew John Hughes > >> ... >> >> Looks like the Contributed-by info is wrong. ?I tried adding the line >> as in the example and jcheck choked: >> >> remote: > Contributed-by: Andrew John Hughes >> remote: >> remote: Invalid contributor attribution >> remote: >> remote: abort: pretxnchangegroup.0.jcheck hook failed >> >> The example is Contributed-by: Ben Bitdiddle > > Right -- as Jon already pointed out, this is a bug in the example. > > More the the point, however, you didn't need a Contributed-by line in > your comment since you are the author. ?That line is meant to be used > only when the author of the changeset (in hg terms) is not the sole > author of the actual patch. > > - Mark > That's good to hear. Thanks for the clarification as it doesn't seem obvious from the guide. BTW, I also noticed that the -m Merge trick is missing or at least I can't see it on http://openjdk.java.net/guide/repositories.html or http://openjdk.java.net/guide/producingChangeset.html And now I can't find the mail either :( Thanks again, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8