[ 
https://issues.apache.org/jira/browse/MINIFICPP-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16781962#comment-16781962
 ] 

Mr TheSegfault edited comment on MINIFICPP-751 at 3/1/19 6:42 PM:
------------------------------------------------------------------

I would be in favor of such a class if it copied the string into a local 
string, and released the jnistring reference immediately. In most cases we do 
something like that any way. This way we don't have any concern about ownership 
of the env or memory. Would also help to avoid global references. 

We would then have to make it a standard that we don't access UTF chars 
directly w/o the use of this object. That would help localize the issue. It 
would increase memory but c++ mem, and not java memory. I'm on board with that. 


was (Author: phrocker):
I would be in favor of such a class if it copied the string into a local 
string, and released the jnistring reference immediately. In most cases we do 
something like that any way. This way we don't have any concern about ownership 
of the env or memory. Would also help to avoid global references. 

> Discussion: RAII over JNI UTF strings
> -------------------------------------
>
>                 Key: MINIFICPP-751
>                 URL: https://issues.apache.org/jira/browse/MINIFICPP-751
>             Project: NiFi MiNiFi C++
>          Issue Type: Improvement
>            Reporter: Arpad Boda
>            Assignee: Arpad Boda
>            Priority: Minor
>
> In this PR #489 I've noticed that JNI UTF string usage is error-prone as 
> releasing can be easily missed by the developer or simply get skipped because 
> of an exception. 
> To avoid this my idea was to create a wrapper object that can be used as an 
> std::string and handles get/release calls.
> As [~phrocker] pointed out, this object has to be kept in a small block to 
> avoid storing ref on both the string itself and the JNI env. 
> This can partly be achieved by blocking copy/move construction/assigment and 
> new, but still leaves some possibility to allocate this object on heap. 
> In my opinion the restrictions above with some comments in the class would 
> help and make it safer, although I'm not sure it worth the effort.
>  
> [~phrocker], [~aldrin], what's your opinion?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to