error TS2339: Property 'openStream' does not exist on type 'URL'.

[xeccgtt]

We are getting the following errors. With transpiler: 2.3.7, jsweet.core.version: 602. We are using the URL definition in the JSweet j4ts GIT Repo. It has openStream function defined on the URL class. It is unclear why we are getting this error. I do not have access to Stack Over flow forums from my firm. I would appreciate any suggestions to work around this issue.

Error:
2020-05-29 08:27:16.016 INFO TypeScript2JavaScriptWithTscTranspiler:90 - EspBus.ts(264,58): error TS2339: Property 'openStream' does not exist on type 'URL'.
2020-05-29 08:27:16.016 ERROR output:55 - property 'openStream' does not exist on type 'URL' at EspBus.java(455)

EspBus.ts
262 let urlStr : string = this.root.toString();
263 let url : URL = new URL(urlStr);
264 let inStream : java.io.InputStream = url.openStream();
265 this.loop(inStream);

EspBus.java
450 String urlStr = this.root.toString();
451 final URL url = new URL( urlStr );
455 InputStream inStream = url.openStream ();
456 loop ( inStream );

j4ts Code
public InputStream openStream() {
XMLHttpRequest request = makeConnection();

    switch (request.responseType) {
        case "arraybuffer":
            return new ByteArrayInputStream(any(new Int8Array((ArrayBuffer) request.response)));
        case "blob":
            Function fileReaderSyncConstructor = self.$get("FileReaderSync");
            if (typeof(fileReaderSyncConstructor).equals("function")) {
                return new ByteArrayInputStream(((Function) fileReaderSyncConstructor.$get("readAsArrayBuffer")).$apply((Blob) request.response));
            }
            // TODO find a way to handle BLOB at main thread synchronously
            return new ByteArrayInputStream(createObjectURL(request.response).getBytes());
        default:
            return new ByteArrayInputStream(request.response.toString().getBytes());
    }
}

[xeccgtt]

Any suggestion on how to proceed. We are stuck and do not know how to resolve the issue.

[renaudpawlak]

Umm... That is intriguing. I am trying it out.

[renaudpawlak]

After a closer look, it seems that the generated code is wrong. It should use the URL's full qualified name:

let urlStr : string = this.root.toString();
let url : java.net.URL = new java.net.URL(urlStr); // <<<<<< fully qualified name

Looks like a unwanted type mapping... did you add any adapter or extra configuration (extension)? I will take a deeper look ASAP.

[xeccgtt]

I did not add any mappings or any extra extensions. By the way I could only get the J4TS to compile
<jsweet.transpiler.version>2.3.6-SNAPSHOT</jsweet.transpiler.version>
<jsweet.core.version>6.0.3</jsweet.core.version>

It fails when I use the transpiler 2.3.6 and 2.37.

[renaudpawlak]

Ok. I have good news. I have managed to reproduce the problem. Looks like a type mapping legacy issue... A real bug anyway.

Less good news is that I need some time to replay the tests and make a release because such a fix might have side effects...

If you are in a hurry and would like to apply the fix yourself (at your own risks), you may want to try the following steps:

• clone the jsweet project
• in /jsweet-transpiler/src/main/java/org/jsweet/transpiler/extension/Java2TypeScriptAdapter.java, comment line 205 - //addTypeMapping(URL.class.getName(), "URL");
• go to directory jsweet/transpiler, and run mvn install -DskipTests=true -DskipSigning=true
• update your project to use the 2.3.8-SNAPSHOT version
• re-run the transpilation and it should work (at least with your local Maven repo)

[xeccgtt]

the getHosts method also has the same problem.

[renaudpawlak]

Yes, of course. All the methods in java.net.URL will have the same problem because what JSweet generates is a JavaScript URL type (not a java.net.URL). You can see the JavaScript URL object there: https://developer.mozilla.org/en-US/docs/Web/API/URL/URL

I know it is confusing, because they have the same name and represent the same thing, but a URL type is not the same as a java.net.URL type.

The fix I have provided will remove the mapping of java.net.URL to URL so that all the methods defined in java.net.URL will be accessible fine.

[xeccgtt]

Where is the source located?

[lgrignon]

Hello @xeccgtt I think you got it all here:
#593

Do you miss something else?