• Post Reply Bookmark Topic Watch Topic
  • New Topic

Protecting native calls

 
grigoris philippoussis
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

Does anyone know of any conventions concerning protecting native calls / have any thoughts concerning this?
I'm trying to make sure that our tests cover all native method calls, but a lot of the native methods are public. It occurred to me that it might be better if they were made private, and then accessed via a public method:

instead of

I'd have


Does this seem a good idea / does anyone have a better way of doing this?

Thanks,
 
Maneesh Godbole
Bartender
Posts: 11445
18
Android Eclipse IDE Google Web Toolkit Java Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by grigoris philippoussis:
It occurred to me that it might be better if they were made private, and then accessed via a public method:


What do you hope to gain by doing this?
Usually you hide the data. From your code, the public method is just transferring the call to the private method.
 
grigoris philippoussis
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just to aid the developer really:

1) Makes it easier to debug (you can't set a breakpoint on a native method)
2) Easier to read (if you know straight away that there is a native call)
3) Easier to see if tests cover native calls (e.g. when using a coverage tool)
 
Rob Spoor
Sheriff
Posts: 20822
68
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Maneesh. It only makes sense if you let the Java code do some initial checking to make sure that all pre-conditions of the native call are met, or if the native code is part of a bigger method.

For example:

From java.lang.Thread:

The native start0 and stop0 methods are both private and only perform a small step of the entire process.
 
grigoris philippoussis
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Fair enough. I'm just a tad surprised that there isn't a naming convention (as far as I know) for a native method - you are, after all, doing something potentially quite risky.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24213
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by grigoris philippoussis:
Fair enough. I'm just a tad surprised that there isn't a naming convention (as far as I know) for a native method


java.lang.Object.nativeHashCode(), java.lang.Object.nativeWait(), java.lang.Object.nativeNotify(), java.lang.Thread.nativePracticallyEverything()... it would get kind of annoying, don't you think?

Seriously, as far as naming conventions go, the caller shouldn't know that a method is native. Next week, it might not be, and conversely, a method that isn't, might become one. And of course native methods can override non-native ones.

As far as the breakpoints, code coverage, etc: in specific environments, with specific tools, perhaps the wrapper methods might be necessary, and if they are, then it might make sense. But it certainly isn't needed for all tools or environments, so I can't recommend the extra wrapper methods as a general practice, only as a crude workaround when nothing better is available.
 
grigoris philippoussis
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, thanks. A useful discussion.
We found that a lot of the problems in our code were the result of native calls, but I agree that this shouldn't apply to everyone!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!