Classes java.* do not include dots between them eg. javalangObject

[roblav96]

Recently updated to the latest generator and I'm noticing that many times java.* classes do not include periods.

I notice you create a reference outside the module declarations but most of the time they are not included:

import javaniocharsetCharset = java.nio.charset.Charset;
declare module okhttp3 {
	export class MediaType extends javalangObject { // SHOULD BE java.lang.Object
		public type(): string;
		public subtype(): string;
		public charset(): javaniocharsetCharset;
		public hashCode(): number;
		public charset(param0: javaniocharsetCharset): javaniocharsetCharset;
		public static parse(param0: string): okhttp3.MediaType;
		public equals(param0: javalangObject): boolean; // SHOULD BE java.lang.Object
		public toString(): string;
	}
}

[petekanev]

@roblav96 does this cause TypeScript compiler errors? If it doesn't , then when using it it will appear as though MediaType extends java.lang.Object (which in fact it does), it is likely that import javalangObject = java.lang.Object is written somewhere in that file at an earlier point.

This is done to work around a TypeScript limitation described here

[roblav96]

@Pip3r4o yes the import javalangObject = java.lang.Object is located elsewhere in the multiple declarations but then say I generate definitions for com.bumptech.glide I'll get duplicate declaration errors everywhere. Also I like to condense my declaration like how ios declarations are by running cat declarations/*.d.ts > combined/com.bumptech.glide.d.ts then I remove all the ref helper= because I've included the android.17.d.ts file.

It just seems that generating declarations for libraries are becoming more difficult to do.

Plus my IDE goto declaration goes to the import and not the actual declaration.

[petekanev]

@roblav96 From what I gather - you want to make the typings generation incremental, that it retains knowledge of previously generated typings, so that it won't make dupes. The generator and API used are much simpler, and do not allow this at the time. Also, instead of condensing the separate classes you could generate one file, then feel free to cat it with any other declarations, if that's an option of course.

Unfortunately at this time we are faced with a few technical limitations that I have no idea how to tackle, there will always be a trade-off, and there is no universal solution to all the problems concerning Java typings in JavaScript.

We do however appreciate suggestions, so if you've got one that can eliminate the module-hijacking one mentioned earlier, comply with TypeScript and Java standards, and be iterative, I'd love to hear it.

tl;dr - The generator is meant to help you develop, but is in no way a huge universal tool that can translate all of Java. It is a work in progress, and it should get better with all of the community's help that we can get.

[roblav96]

@Pip3r4o I must say you've done an amazing job with this so far! Please don't think I'm bashing any of your work. This is an absolutely critical tool for my development and I'm just letting you know what I've come across while using it. Thank you for this tool!

I have debated not using -generate-multiple but I really like the description helpers that android.17.d.ts offer. I might end up migrating to one condensed declaration file using android-24.jar and including my libraries with it.

I would love to help with this project. What kind of community support are you looking for?