Needed to allow deallocator for factory pattern

[GoogleCodeExporter]

In our little project we were using the factory pattern for allocating the 
objects. The problem was that the deallocator was only generated when the when 
the allocator was added. While researching that we realized that anything built 
by the factory pattern was not getting assigned a deallocator in the first 
place.

Since going through the code, we couldn't find a way to allow that, we made the 
attached modification. Using a new annotation "FactoryBuilder" we flag the 
functions which are in the factory pattern so that the they attach the 
deallocator properly.

Attached in the patched Generator.java file and the new annotation.

Original issue reported on code.google.com by bid...@gmail.com on 8 Sep 2011 at 3:33

Attachments:

• Generator.java.patch
• FactoryBuilder.java

[GoogleCodeExporter]

For cases like that, I made it so we need to provide a Pointer.Deallocator 
manually on the Java side... I had to do something like that for the C API of 
OpenCV, for IplImage, for example:
http://code.google.com/p/javacv/source/browse/trunk/javacv/src/com/googlecode/ja
vacv/cpp/opencv_core.java#398

Let me know if you are able (or not) to successfully implement something like 
that for your classes and needs, thank you.

Or is the point that you want to use the `delete` operator of C++? Although I 
am not sure this is good C++ design, as the runtime library of the `new` and 
`delete` operators may differ resulting in potential crashes.. AFAIK, it is 
usually a good idea to provide a method to destroy objects that gets linked to 
the same runtime as the factory. Let me know what you think

Original comment by samuel.a...@gmail.com on 9 Sep 2011 at 1:58

[GoogleCodeExporter]

I haven't thought of that. Thank you for pointing that out. Sounds like adding 
a destroy to the factory pattern sounds safer.

Original comment by bid...@gmail.com on 10 Sep 2011 at 2:49

[GoogleCodeExporter]

To have them garbage collected on the Java side when the Java Pointer reference 
becomes unreachable however, we may register on creation a Pointer.Deallocator 
(which you design to have it call your destroy function in C++) by passing it 
to the Pointer.deallocator() setter method...

Original comment by samuel.a...@gmail.com on 10 Sep 2011 at 3:44

[GoogleCodeExporter]

I guess we can mark this issue as resolved, but let me know if this is not the 
case, thank you.

Original comment by samuel.a...@gmail.com on 6 Oct 2011 at 12:45

• Changed state: Done

[GoogleCodeExporter]

It appears some popular projects out there (e.g.: 
http://code.google.com/p/skia/ ) require objects to be created with the `new` 
operator, but prohibits deallocation with the `delete` operator, so I am 
proposing a new @NoDeallocator annotation to be used on the `allocate()` 
methods for that purpose. Let me know if the attached `Generator.java` and 
`NoDeallocator.java` get the job done properly, thank you

Original comment by samuel.a...@gmail.com on 23 Feb 2012 at 7:49

• Changed state: Started

Attachments:

• Generator.java
• NoDeallocator.java

[GoogleCodeExporter]

Included these changes in the latest release.

Original comment by samuel.a...@gmail.com on 3 Mar 2012 at 4:47

• Changed state: Fixed