Re: JsInterop and indexed types

[Alexey Andreev]

>
>
> Sorry for by bad english. 
> I meant a different thing.
>
> Oh, now I see. Well, making Java array equal to JavaScript array is not an 
only solution for passing direct reference to an array. TeaVM could have a 
method to "unwrap" array, giving a native code reference to `data` field. 
There is one, but it is like "unsafe" in Oracle JDK: it is not documented 
and it's not guaranteed to remain its API in future versions. It should 
look like this:

public static Int8Array unwrapArray(byte[] array) {
return Platform.getPlatformObject(array);
}
@JSBody(params = "wrapper", script = "return wrapper.data;")
private static native Int8Array doUnwrap(JSObject wrapper);

The magic is in undocumented Platform class, getPlatformObject particulary. 
It gets a Java object and returns it as JSObject. But do it on your own 
risk. Also, it's possible to corrupt application by assigning to the array 
something that does not fit in byte type (a floating point number or a 
string) or by changing the length of the array.

As for avoiding wrapper class. It's nearly impossible in general, since 
Java arrays are Java objects as well. Consider the following:

void foo(Object obj) {
System.out.println(obj.toString());
}
void bar() {
foo(new int[] { 1, 2, 3 });
}

How could TeaVM implement it without wrapper?

It is possible though to avoid negative effects of wrappers in certains 
cases, first, as I said, by eliminating unwrap operations when possible, 
and, second, performing some kind of escape analysis.

Note that the reverse operation (converting JavaScript array to Java array) 
is impossible in TeaVM by design. TeaVM performs global analysis of your 
code and for each variable (in terms of SSA) determines its possible types. 
It's impossible in general case to predict in compile time what actual type 
method like this may return:

Object wrapPlatformObject(JSObject obj);

I'm not sure how GWT actually works, but I suppose it does something 
similar, therefore it most likely you will fail with GWT as well. However, 
it's possible to hardcode additional methods to Platform class that convert 
JSArray to primitive arrays. You can open an issue if you really are going 
to use TeaVM for such purpose.

There are JSO wrappers in TeaVM and JSNI wrappers in GWT for TypedArrays. 
Why don't you use them directly to boost performance?

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: JsInterop and indexed types

[Alexey Andreev]

>
>
> Famous TeaVM also can`t do that, unfortunately. 
>
 You are wrong. You can do that via @JSIndexer 

 
annotation. 

TeaVM java array class has a field "data" with the underlying native array, 
> so that each access requires to read that field which dramatically hurts 
> real-time performance.
>
Not really. TeaVM's IR has separate instructions for accessing data field 
(unwrap) and getting element by an index (get). When converting from JVM 
bytecodes, every occurrence of AALOAD/IALOAD/... is represented by these 
conseqential instructions. Now consider this Java code:

int a = array[x];
int b = array[y];

We get the following IR:

array1 = unwrap(array);
a = get(array1, x);
array2 = unwrap(array);
b = get(array2, y);

When GVN scans this sequence, it realizes that array1 and array2 are really 
the same and eliminates array2:

array1 = unwrap(array);
a = get(array1, x);
b = get(array1, y);

Unfortunately, GVN is incapable of handling loops. TeaVM does not perform 
LICM yet, but it is possible to implement. LICM should solve the issue.

Also, did you try to write benchmarks before claiming that wrapper slows 
down performance? V8 performs sophisticated performance optimizations. 
There is a great chance that V8 is capable to recognize an eliminate 
unnecessary access to data field.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[Alexey Andreev]

> Since the end result is JS, can i use cordova to cook up a mobile app 
> using TeaVM?
>
You can try to. I'm not sure I've cleaned up any browser-specific APIs from 
TeaVM runtime. Please, report me if you have some success with cordova. 
However, I don't think it's a good idea. There is Android which supports 
subset of Java natively, iOS with RoboVM. I'd look for Java frameworks that 
support both. There is CodenameOne with its own implementation of Java for 
different platforms and experimental JavaScript target that uses TeaVM. 
There is dukescript wich supports Android, RoboVM and TeaVM, though I don't 
really like the idea of wrapping Java around Knockout or similar framework. 
Choose which one fits you needs better.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[Alexey Andreev]

>
>  - virtually this is one pony show - except Alexey there are no major 
> contributors (nothing against Alexey of course he is brilliant guy)
>
Yes, this is the worst problem of TeaVM. I wonder how do projects become 
popular? If a project is maintaned by a big and rich company, this company 
likely has enough resources and reputation to make project popular. What if 
a project is made by enthusiasts? I can see two general ways:

   - the project becomes popular enough to draw money;
   - some big and rich company is interested in the project and starts to 
   support it.

As for the first one. TeaVM does not have a big community, since people 
don't trust a project maintained by one developer, so I get into vicious 
circle. As for the second one. I believe, most major companies have heard 
of TeaVM. So why don't they communicate me and try to support my project? 
Do they feel that a project like TeaVM has no future, that cominuty needs 
things like Dart and TypeScript?

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Teavm

[Alexey Andreev]

>
> Not sure if TeaVM serves different need than GWT. Seems like both want to 
> provide a better alternative to JavaScript.
> Now TeaVM does not have anything equivalent to GWT widgets but then  it 
> seems, after watching the GWT Create session videos, the recommendation, 
> for newer apps, is not to use the GWT widgets anyway.
> Instead of GWT widgets the direction seems to be to use more HTML5 based 
> components like web components polymer etc which technology like the newer 
> GWT JSInterop could make it easier to consume.
> Like GWT JSInterop , TeaVM has something called JSO which also propose to 
> make consuming java script libraries easier.
> I haven't used JSInterop or JSO so can't compare the two.
>
Besides JSO wich provides interop with JS libraries, there is forthcoming 
project called TeaVM Flavour . 
It's a framework similar to Angular, but written entirely in Java. I have a 
lot of disappointing experience with GWT widgets (but still use it, as it's 
still 10 times better than maintaining megabytes of JS code), since it's 
virtually impossible to create good widget-based abstraction over HTML 
technoligies. A better approach is a thin layer of abstraction, wich allows 
easy interaction with underlying nature of HTML.

I could take experience of dukescript  guys (BTW, 
TeaVM can be used as dukescript backend) and wrap existing libraries like 
Angular and Knockout. However, I don't think it is a good approach, since I 
ask myself: what makes me use Java on front-end? My answer is: it's static 
typing. When I refactor code, I get errors displayed immediately in Eclipse 
and have a chance to fix them before I even run application. Consider I 
wrap angular and pass Java method name to ng-click directive. If later I 
refactor my Java code and this method got renamed, I won't get any feedback 
from IDE. And so on. I took many cases and figured out that pure Java-based 
approach is far superior than JavaScript wrappers, except for complexity.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.