Swing generification changes in JDK 9 b24 -- swing generification refinements in JDK 9 b30

[Joe Darcy]

On 9/18/2014 10:08 AM, Jaroslav Tulach wrote:
> Dne Čt 18. září 2014 09:42:49, Joe Darcy napsal(a):
>> Hi Jarda,
>>
>> On 9/18/2014 9:22 AM, Jaroslav Tulach wrote:
>>> Dne Út 16. září 2014 21:11:31, Joe Darcy napsal(a):
>>>> Hello swing developers,
>>>>
>>>> In response to the earlier call for feedback on the initial swing
>>>> generification changes, several bugs were filed and fixed:
>>> Hello Joe,
>>> I'd heard that NetBeans could no longer be compiled after the initial
>>> swing
>>> generification changes. Can you build NetBeans after your recent fixes or
>>> anything else still remains?
>> On whether or not NetBeans builds, I was hoping you could tell me ;-)
> ;-) I may ask around. In general I don't feel responsible for testing my
> application against newest JDK when I have not changed a single line of code.
> I believe it is upstream project responsibility to not break us.

Well, I think there needs to be a balance in testing (broadly defined) 
between an upstream project like the JDK and downstream projects relying 
on it.

To a person working on Java project Foo, project Foo is very important, 
and those JDK guys shouldn't break it ;-)

However, project Foo may be relying on implementation details, like the 
specified-to-be-unspecified order of Class.getMethods which changed in 
JDK 7, so even if project Foo "breaks" with a JDK update, that doesn't 
necessarily imply the JDK should be the artifact which is changed. And 
there are many, many values of Foo.

The JDK group does do internal testing of third party Java projects 
against builds of in-progress JDK releases, but we've also been reaching 
out to other Java projects to have them try out new JDK builds in their 
own test frameworks. It is often difficult to do QA on test results of 
an unfamiliar project; the people involved in a project and often much 
better positioned to analyze what difference, if any, a new JDK build is 
making.

>> These changes in build 30 do address the primary source compatibility
>> issues from the initial round, including those found to impact the
>> NetBeans build. Many of the exemplar test programs that didn't build
>> with b24 do build again with b30.  However, I have not tried to do a
>> NetBeans build myself.
> I don't necessarily want every JDK engineer to test with NetBeans, but when it
> is known there was a problem with NetBeans build (because of changes in JDK
> code), I would expect the verification to be done by JDK engineer prior to
> announcing "something is fixed".
>
> Do I require too much? Building NetBeans is matter of three commands. Did our
> engineers forget to mention those commands when they complained about NetBeans
> build being broken? If so let me know, and I make sure they get fired.

I'm not a swing programmer myself and the generification changes (in 
support of removing warnings from the JDK build) have taken more effort 
than I anticipated. I welcome assistance from others to help refine 
these changes to swing.

>> (Some level of source incompatibility can be acceptable in a feature
>> release, but we don't want gratuitous problems on that front.)
> 100% backward source compatibility is hard to achieve in Java, so yes, we can
> accept some changes. The requirement however is to find a way to write the
> source so it compiles on JDK7, JDK8 and JDK9 at the same time. Will that be
> possible?
> -jt
>

Offhand, I don't know anything specific to these swing changes that 
would prevent that. (There can be subtleties stemming from type 
inference in language changes, API additions, etc.) In some cases, 
generating types during the build using an annotation processor can help 
resolve such version-specific compilation issues.

Cheers,

-Joe