Proposal: Deprecate Builders
Richard Bair
richard.bair at oracle.com
Mon Apr 29 11:58:13 PDT 2013
I think we also need to test when a middle guy is not abstract but also concrete -- that is, for cases such as Parent where it is both concrete and also subclassed?
Richard
On Apr 6, 2013, at 11:17 AM, Tom Eugelink <tbee at tbee.org> wrote:
>
> I see the attachment got removed from the email, so here is a download link:
>
> http://www.softworks.nl/stuff/withertest.zip
>
> Tom
>
>
> On 2013-04-06 09:14, Tom Eugelink wrote:
>> On 2013-03-26 08:07, Richard Bair wrote:
>>> The way to try out the compatibility issues is to just have two projects -- one with a minimal hierarchy (A and B is sufficient where B extends A). The other project just has a main method which creates an instance of B and initializes it. Then make various changes to the A / B API and try running the main project unmodified (i.e.: not recompiled) and see what happens! Richard
>>
>>
>> Ok, attached is exactly such a project. Project JavaApplication1 contains LeafNode -> AbstractNodeA<T> -> AbstractNodeB<T>. Each one has get/set/withName, where only one should be commented in.
>> The setter prints the class name where it is in so it is clear with setter is being used.
>> LeafNode also has a special method that is called on the return value of the wither, to test it is LeafNode that is returned.
>>
>> The second project JavaApplication2 holds only a main which:
>> - creates LeafNode,
>> - calls withName,
>> - call the LeafNode method on the returned value
>>
>> Just for test JavaApplication1 has exactly the same main.
>>
>> In the directory root there is a test.cmd with sets the classpath and calls the mains in both applications. You can now easily comment in/out the get/set/with and only rebuild JavaApplication1. JavaApplication2 keeps on running without problems.
>>
>> I also have tried to see if the wither can be moved out to an interface (using default) but that is giving me troubles. I need to figure out why it doesn't accept the default body.
>>
>> So far so good.
>>
>> Tom
>
>
More information about the openjfx-dev
mailing list