Issue 5790 - Get ready for integration into Chromium

libadblockplus-android/src/org/adblockplus/libadblockplus/FilterEngine.java

 /*
  * This file is part of Adblock Plus <https://adblockplus.org/>,
  * Copyright (C) 2006-present eyeo GmbH
  *
  * Adblock Plus is free software: you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 3 as
  * published by the Free Software Foundation.
  *
  * Adblock Plus is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ skipping 180 matching lines @@
    * @param subscriptionUrl may contain query parameters, only the beginning of the string is used
    *                       to find a corresponding subscription.
    */
   public void updateFiltersAsync(String subscriptionUrl)
   {
     updateFiltersAsync(this.ptr, subscriptionUrl);
   }
 
   /**
    * Get FilterEngine pointer
-   * @return C++ FilterEngine instance pointer
+   * @return C++ FilterEngine instance pointer (AdblockPlus::FilterEngine*)
    */
-  public long getFilterEnginePtr() {

[sergei, 2017/09/26 12:04:29]

Maybe call it `getNativePtr`?

[anton, 2017/09/26 12:18:40]

Does not make sense for me, we can call it `getNativePtr `

[sergei, 2017/09/28 08:29:03]

I don't insist, it's just my expectations of an API. This method is rather for
some internal and very advanced usages and it's a common practice to have a
convention that such methods like `getNative`, `getHandle`, etc, providing the
access to an internal structure and they should not duplicate the name of the
class. So if there is a need to expose the underlying handle from JsValue,
Platform or some another class wrapping a native resource one can always get it
through such method.

http://en.cppreference.com/w/cpp/thread/thread/native_handle
http://www.boost.org/doc/libs/1_64_0/doc/html/thread/thread_management.html#t...

-    return getFilterEnginePtr(this.ptr);
+  public long getNativePtr() {
+    return getNativePtr(this.ptr);
   }

[diegocarloslima, 2017/09/28 11:55:30]

Well, this ain't a good practice to expose/share native pointers through our
Java API. But if it's currently the only way to integrate our lib into Chromium
we can leave it and should revisit this in the future to see if something has
changed, allowing us to integrate without exposing native pointers

 
   private final static native void registerNatives();
 
   private final static native boolean isFirstRun(long ptr);
 
   private final static native Filter getFilter(long ptr, String text);
 
   private final static native List<Filter> getListedFilters(long ptr);
 
   private final static native Subscription getSubscription(long ptr, String url);
@@ skipping 39 matching lines @@
   private final static native String getAllowedConnectionType(long ptr);
 
   private final static native void setAcceptableAdsEnabled(long ptr, boolean enabled);
 
   private final static native boolean isAcceptableAdsEnabled(long ptr);
 
   private final static native String getAcceptableAdsSubscriptionURL(long ptr);
 
   private final static native void updateFiltersAsync(long ptr, String subscriptionUrl);
 
-  private final static native long getFilterEnginePtr(long ptr);
+  private final static native long getNativePtr(long ptr);
 }