google / jsinterop-base Goto Github PK

Utilities for GWT and J2CL to interact with JavaScript beyond JsInterop

License: Apache License 2.0

Java 82.39% JavaScript 6.36% Shell 5.02% Starlark 6.23%

jsinterop gwt j2cl

jsinterop-base's Introduction

JsInterop Base ·

jsInterop-base contains a set of utilities that cannot be expressed with Jsinterop itself and allows GWT and J2CL projects to write certain JavaScript expressions with pure Java.

Bazel dependency

If your project uses Bazel, add this repository as an external dependency in your WORKSPACE file:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
_JSINTEROP_BASE_VERSION = "1.0.0"
http_archive(
    name = "com_google_jsinterop_base",
    strip_prefix = "jsinterop-base-%s" % _JSINTEROP_BASE_VERSION,
    url = "https://github.com/google/jsinterop-base/archive/%s.zip" % _JSINTEROP_BASE_VERSION,
)

Then add @com_google_jsinterop_base//:jsinterop-base-j2cl to your j2cl_library deps.

Maven dependency

If your project uses Maven, add the following maven dependency in your pom.xml:

<dependency>
  <groupId>com.google.jsinterop</groupId>
  <artifactId>base</artifactId>
  <version>1.0.0</version>
</dependency>

Download the jar file

You can also download manually the jar file.

GWT

If you use jsinterop-base with GWT, you need to inherit the following gwt module in your gwt.xml file:

<inherits name="jsinterop.base.Base" />

Build GWT compatible maven jar files

If you want to build the last version on your own, follow the instructions below:

Install Bazelisk:

    $ npm install -g @bazel/bazelisk
    $ alias bazel=bazelisk

Clone this git repository:

$ git clone https://github.com/google/jsinterop-base.git

Run the release script:

    $ cd jsinterop-base
    $ ./maven/release_jsinterop_base.sh --version local --no-deploy

The script will output the directory containing the generated jar files that can be used with maven.

Contributing

Please refer to the contributing document.

Licensing

Please refer to the license file.

Disclaimer

This is not an official Google product.

jsinterop-base's People

Contributors

Stargazers

Watchers

Forkers

vertispan stethd exhorder realityforge pbr2019b neuronsupport lupino3 neotim orielmaute johnthuss isabella232 anoop-qasolve mollyibot ghas-results

jsinterop-base's Issues

Docu outdated, Version 1.0.0 not compiling

When following the instructions to set it up with bazel i get the following error:

ERROR: /home/<name>/.cache/bazel/bazel<name>/8c6b2a3b7ef920759046b6771c685747/external/com_google_jsinterop_base/third_party/BUILD:25:12: no such package '@org_gwtproject_gwt//user': The repository '@org_gwtproject_gwt' could not be resolved: Repository '@org_gwtproject_gwt' is not defined and referenced by '@com_google_jsinterop_base//third_party:gwt-javaemul-internal-annotations-j2cl'

When i switch from Version '1.0.0' to 'master' it works.

PS: i edited out my name and replaced it with '<name>'

Build fails on Mac OS due to using sed in-place with symbolic link

The build step that uses sed to replace the "// J2CL_only" tokens causes the build to fail on Mac OS since it uses in-place replacement on a symbolic link.

sed -i.bak '''s|// J2CL_ONLY ||g'

The error given is:
sed: java/jsinterop/base/Any.java: in-place editing only works for regular files

You can workaround it by using "gsed" (gnu-sed) instead, which is available from homebrew: "brew install gnu-sed".

build.log

Distribute native.js files.

Presently, the RC1 distribution does not contain any native.js files.

This makes life difficult for (external) j2cl plugin developers. If possible, could these files be included in an available archive on the next release? If you don't want to put them in the main jar, perhaps a jar/zip w/ a classifier like j2cl would suffice (/ be optimal). We already have to do some unpacking, so the file extension is not relevant to us (at least for gradle; not sure what maven team is doing in this regard).

Create a cookbook for jsinterop-base

We can follow something similar to auto-value "how do I" page:
https://github.com/google/auto/blob/master/value/userguide/index.md#how-do-i

Running tests?

Hey guys, I'm looking at getting these tests running in open source, as I have a few changes I'd like to propose, and thought it might make sense to submit tests to help make my case. I nearly have the tests compiling, but one class is eluding me: com.google.common.annotations.UsedReflectively. I haven't found any trace of it on the internet - except for google/guava#1617, which says (as of 2013) that it could get put somewhere more general for others to see it.

In context (and from the linked issue above), it might just be the equivalent of @SuppressWarnings("unused"), but considering how it is used, it could also have specific meaning to something like GWT->Closure or J2CL->Closure, in that the method name shouldn't be obfuscated. @JsMethod (with exports turned on during tests) would be enough to ensure that for GWT2 at least, but this annotation might have other work to do in cases involving closure.

Removing all trace of this annotation seems to at least get tests to compile (though I'm still missing a few stray dependencies). Is this something that can be made more general, so I could propose a patch to get tests running?

@DoNotAutobox is absent from several Js methods - why?

I am just trying to understand why several of the methods in the Js class do not have the @DoNotAutobox annotation on their object parameters when presumably they should. Examples include the "as" methods and supporting infrastructure. i.e. Js.asBoolean(obj) and thus InternalJsUtil.asBoolean(obj), as well as Js.coerceToDouble(obj).

Is it just because it is assumed that humans invoking this are smart enough to not misuse them and the code is unlikely to be used in code generators? What would be the penalty of adding them?

Maven regards the current POM as invalid

The POM generated by this project is invalid and generates warning such as the following when run through modern version of maven (3.5.3):

[WARNING] The POM for com.google.jsinterop:base:jar:1.0.0-RC1 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details

The problem is that the transitive dependency needs to be manually specified. Investigation seems to indicate that the problem is actually in the parent pom and simply updating to the latest parent pom fixes this.

The way to fix this is to change the pom output according to the following diff.

--- tmp/base-1.0.0-RC1.pom	2018-03-22 14:30:51.000000000 +1100
+++ /Users/peter/.m2/repository/com/google/jsinterop/base/1.0.0-RC1/base-1.0.0-RC1.pom	2018-03-22 14:30:54.000000000 +1100
@@ -6,7 +6,7 @@
   <parent>
     <groupId>org.sonatype.oss</groupId>
     <artifactId>oss-parent</artifactId>
-    <version>7</version>
+    <version>8</version>
   </parent>
 
   <groupId>com.google.jsinterop</groupId>

I am unfamiliar with the build system otherwise I would suggest the fix and assume that this should be a trivial fix for someone who is familiar.

If this is not the case then kick me and I can dive into it.

Add support for JsPropertyMap.keys()

Would you consider an addition of a method like JsArrayLike<T> keys() added to the JsPropertyMap<T> class?

I was looking through our projects, and a lot of them only use the elemental2-core library to make use of the JsObject.keys() method. It looks like it would be possible to remove the elemental2-core with this small addition to JsPropertyMap and it seems to make sense.

Translating between native and java errors?

Is there a "standard" way of translating back and forth between native and java errors/throwables? It is unclear to me where this would belong. i.e. here or Elemental2 or maybe tucked away in the JRE emulation layer.

At the moment in our GWT code I am doing the equivalent of JsError error = Js.uncheckedCast(Js.asPropertyMap( e ).nestedGet( "backingJsObject" )) but this feels like it is prone to breakage when moving to J2cl where backingJsObject is potentially renamed.

Is there a location where this could be added that would be accepted?

Support for multiple window contexts for globals

This is sort of obscure, but it would be nice to have support for the same classes existing in different global window contexts. For example, if you have an iframe, it will have its own set of global system classes in its own window object. Sometimes, you need to construct objects from this separate context or do weird comparisons etc.

// Example JS code of different system classes
// How can this be done in JsInterop?
a = new iframe.contentWindow.Date()
b = new Date()
a.constructor === b.constructor   // returns false

Whatever pattern you come up with for that might also be useful when running JavaScript code inside Java because in that case, you might have multiple JavaScript contexts, and you need to specify which JS context you are constructing objects in.

JSInterpreter jsInterpreter1 = new JSInterpreter();
JSInterpreter jsInterpreter2 = new JSInterpreter();
jsInterpreter2.create(Int8Array.class, 10);

deploy.sh uses mispelt variable __ARTIFICAT_ID__

The deploy.sh script replaces the string __ARTIFICAT_ID__ in pom.xml files during deploy but the variable should be spelt __ARTIFIACT_ID__. However given that this target is used in downstream projects it would need to be fixed across several repositories. So it may be best to leave it as is until work is done in this area again.

JsPropertyMap.getAny() -> .getAsAny()

Hi,
The release candidate 1 of jsinterop-base has a method JsPropertyMap.getAny(). But 11 months ago this method was renamed .getAsAny().

Since the API changed a while ago, would it be possible to get a RC2 of this essential library with the new API? Much code is being written around RC1, and it would be best to get RC2 out with the new API sooner rather than later so that less code will need to be changed later on. What do you think?

Many thanks,
Rob