predicate is not usable by but exposed to JavaScript.

[wowoName]

Type of parameter 'predicate' in 'RowResult[] DataTable.Select(Predicate predicate)' is not usable by but exposed to JavaScript.

public RowResult[] Select(Predicate predicate){
return rows.stream().filter(predicate).toArray(RowResult[]::new);
}

[rluble]

That seems correct, the class java.util.Predicate is opaque to JavaScript (it is not marked @JsType nor has any @JsMethod)

I assume the the class DataTable is either marked @JsType or its method Select(Predicate) is declared as @JsMethod and that is why the warning is emitted. The method is declared to be callable directly from user written JavaScript code but takes a parameter that is opaque.

Difficult to tell with certainty since it is an incomplete snippet.

[rluble]

Closing the issue as WAI.

[wowoName]

thanks！
This is my code:
@jstype(isNative = true,namespace = JsPackage.GLOBAL)
public class DataTable {

@JsMethod
public native  RowResult[] Select(Predicate<RowResult> predicate);

}。
I am trying to rewrite the DataTable class in js as an overridden java class. So the above problem occurred when I was packing. (When I typed the complete java code, I found that the size of the package was too large, almost 90M, so I rewrote some java classes in js to reduce the size of the package). If the current issue does not work out well, is there any way to reduce the package size (currently my configured compilationLevel: SIMPLE_OPTIMIZATIONS).
thanks~

[rluble]

IMHO, migrating classes to JS but keeping the same design is unlikely to result in much reduction in the code size. If you want to reduce the codesize you should first use a more aggressive compilation level ("ADVANCED") and if that proves to be insufficient it is probably best to look in the application design for inefficiencies.

Those are my 2 cents.

[niloc132]

Understanding why the size matters might help to answer too - 90M of JS is "big", but esp when it hasn't been optimized at all, it is far from unheard of. If the size matters for an individual bundled file (before optimizing), more smaller libraries might make more sense, to split one big 90M file into many files that sum up to roughly 90M - at least in theory not all use cases need the entire library, so only referencing the smaller pieces will improve total loaded size for a given application (plus, j2cl seems to perform better compiling two smaller modules than one big one, all else equal).

---

Another tool theoretically at your disposal that should improve SIMPLE_OPTIMIZATIONS or WHITESPACE_ONLY is the j2cl minifier, so as to minifiy more than just locals also exposed calls on namespaces/classes (and gets rid of comments while it is running). Note however that bazel doesn't have support for using this, and to my knowledge there is no documentation on using this even outside of bazel.

j2cl/tools/java/com/google/j2cl/tools/minifier/J2clMinifier.java

Lines 41 to 59 in f683c82

	/**
	* A thread-safe, fast and pretty minifier/comment stripper for J2CL generated code.
	*
	* <p>Converts mangled J2CL names to minified (but still pretty and unique) versions and strips
	* block comments (doing both these things while doing no AST construction and respecting the
	* sanctity of strings).
	*
	* <p>The imagined use case for this minifier is to be part of fast concatenating uncompiled JS
	* servers used as part of the development cycle. There is an expectation that because uncompiled
	* and non-@JsType J2CL output is mangled that it might be large enough to slow down the browser as
	* well as be difficult to directly read and this minifier addresses that problem. Callers should
	* reuse the same minifier instance across multiple files to get consistent minification.
	*
	* <p>It is expected that minification opportunities will only be found in J2CL generated files
	* (files ending in .java.js) since only such files should contain references to mangled J2CL names.
	* So if some caller wants to optimize their minifier usage they might consider invoking it only on
	* .java.js files.
	*/
	public class J2clMinifier {

Conversely, I believe the RTA tool is intended to be usable in bazel (though only tests use it, and they can't be run in open source) and has no non-bazel way to run it. The minifier can use rta output as I understand it, to simply identify "java" members and types that can be pruned, so that the minifier strips out code that presently can't be called. This should in effect perform the same sorts of "just remove code that cannot be called" as something like SIMPLE_OPTIMIZATIONS, but you might find it does it faster and with more awareness of what can be changed than closure-compiler itself? Again: giant caveat that to my knowledge there are currently no examples of how to use these in open source.