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