I'm not sure I understand what you mean by "emulated" in this context.
The point of my inquiry is that I would like to take a number of fairly vanilla Java classes that leverage SWTCanvas and use GWT to compile them to JavaScript. I imagine this is only possible by building a GWT widget that implements the same API as SWTCanvas, which is fine, but I would like to be able to compile the original Java classes without changing its import statement (from org.eclipse.swt.widgets.Canvas, to foo.bar.MyGWTSWTCanvas, for example). I would like to instruct the compiler so that it knows that whenever it encounters org.eclipse.swt.widgets.Canvas, it should really be importing foo.bar.MyGWTSWTCanvas, so I don't have to change the original source code. Or some mechanism like that. Please let me know what you think. Thanks, Jake On Apr 7, 1:35 pm, Ian Bambury <[email protected]> wrote: > If all the classes are emulated and the source available, then it will just > work. > If it isn't, then it just won't work. > > Even if the first case is true, since it doesn't use any GWT widgets, then > it is unlikely to do anything useful. > > What is the point of your enquiry? (That is not a rhetorical question :-)) > > Ian > > http://examples.roughian.com > > 2009/4/7 Jake <[email protected]> > > > > > Hi Paul, > > > Thanks for the reply. I agree, these would all be issues when > > compiling arbitrary apps. But for the reduced case, I think it still > > makes sense to ask the question, how would you solve the problem of > > transparently importing alternative libraries? > > > I'd appreciate it if anyone could let me know. Thanks, > > > Jake > > > On Apr 7, 1:15 pm, Paul Robinson <[email protected]> wrote: > > > otakuj462wrote: > > > > Hi all, > > > > > I'm just getting started with GWT, and I'm wondering whether or not a > > > > particular scenario is possible. I would like to take an application > > > > that has been written on top of a native Java GUI library like SWT, > > > > and throw the unmodified source code (without even changing the import > > > > statements) into GWT, and have it return a working JavaScript web > > > > application. Now, obviously GWT doesn't support SWT on its own, and it > > > > also cannot compile SWT down to JavaScript. So, what I would imagine > > > > doing is creating a SWT-compatible library on top of GWT, mapping API > > > > calls onto either GWT widget API's, or some native JavaScript widget > > > > library (like ExtJS or Dijit) using JSNI. But I imagine this SWT- > > > > compatible library would need to live in its own package, distinct > > > > from the SWT package, and thus, in order to use the SWT-compatible > > > > classes from this library, you would at least need to change the > > > > import statements when you compile the application's source code. Does > > > > GWT provide a mechanism for this, so that you can substitute custom > > > > libraries for native ones, without changing the import statements in > > > > the source? > > > > > If I were programming in C or C++, I believe this would be > > > > accomplished using ifdef macro preprocessing and sending flags to the > > > > compiler (#ifdef GWT import foo; #ifndef GWT import bar;). Perhaps GWT > > > > has a mechanism for this kind of pattern? > > > > > Please let me know. Thanks, > > > > > Jake > > > > Even if all SWT widgets had GWT equivalents (or if you made > > > equivalents), you'd still have problems because native java apps behave > > > differently from GWT apps. For example: > > > - GWT runs in a browser and so is single threaded whereas your native > > > java app is in general multithreaded > > > - java apps have full access to the local (client) file system, but > > > browsers do not. > > > - java apps may use other java libs, each of which will have javascript > > > translation issues (eg JDBC) > > > > Paul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
