Re: Just getting started with GWT: how to wrap a native Java library?
On Wed, Apr 8, 2009 at 8:52 AM, Arthur Kalmenson wrote:
>
> Hey Jake,
>
> I've never used the SWT Canvas, but if it's anything like the
> tag, you might want to check out the GWTCanvas in the incubator:
>
> http://code.google.com/docreader/#p=google-web-toolkit-incubator&s=google-web-toolkit-incubator&t=GWTCanvas
GWT 1.6 includes Canvas from what I recall off the top of my head (or is
that only trunk?).
>
>
>
> Also, Vitali, there's a GWT library for accessing gears:
> http://code.google.com/p/gwt-google-apis/
I never meant to imply that there wasn't - just that it's not part of GWT &
probably never will be, especially given that HTML5 is an actual W3C
standard that browsers have already started implementing.
>
>
> Regards,
> --
> Arthur Kalmenson
>
>
>
> On Tue, Apr 7, 2009 at 3:35 PM, Jake wrote:
> >
> > Isaac, thank you for the informed response, I believe that was exactly
> > what I was looking for.
> >
> > Best regards,
> >
> > Jake
> >
> > On Apr 7, 3:27 pm, Isaac Truett wrote:
> >> Jake,
> >>
> >> You would have to create a class org.eclipse.swt.widgets.Canvas such
> >> that it is GWT-compatible. That means only using emulated JRE classes
> >> (String, collections, etc.). Any class required for the Canvas class
> >> API has to be implemented in a GWT-compatible manner as well. This
> >> transitive dependency is what really kills you. If you get to a point
> >> where you have to use a non-emulated JRE class (e.g., java.io.*
> >> (almost)), you're hosed (I believe this was essentially Ian's point).
> >>
> >> Assuming you manage to implement the entire API, you create a module
> >> file (gwt.xml) that includes the source you just wrote, inherit that
> >> module in your GWT app, and enjoy.
> >>
> >> For more on JRE emulation, see:
> >>
> >> http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=goog.
> ..
> >>
> >> - Isaac
> >>
> >> On Tue, Apr 7, 2009 at 3:14 PM, Jake wrote:
> >>
> >> > I feel like I'm not expressing myself clearly. Let's just focus on the
> >> > reduced case:
> >>
> >> > import org.eclipse.swt.widgets.Canvas;
> >>
> >> > public class foo {
> >>
> >> > }
> >>
> >> > Right now, if I try to run this through GWT, it will throw an error
> >> > because it can't compile Canvas and all of its dependencies. This is
> >> > to be expected. So what I would like is to roll my own Canvas class
> >> > which extends GWT's Widget class, and have that be used instead, but
> >> > in such a way that I don't have to touch the existing program's source
> >> > code.
> >>
> >> > Ian, you seem to be suggesting that I need to hack this into the
> >> > internals of GWT itself, and try to push it upstream. I feel like
> >> > there should be a way to do this without having modify GWT internals,
> >> > because this would allow certain applications (not all of them) that
> >> > leverage native GUI toolkits to be compiled directly to a browser-
> >> > based version, without having to port them to a GWT-friendly set of
> >> > libraries. This would be a very powerful feature, but it may not
> >> > exist. If I could just get confirmation on this, I would appreciate
> >> > it.
> >>
> >> > Thanks,
> >>
> >> > Jake
> >>
> >> > On Apr 7, 2:38 pm, Ian Bambury wrote:
> >> >> GWT isn't Java. It just uses Java syntax so that Java books are
> useful, and
> >> >> things like Eclipse work for it.
> >> >> GWT code becomes JavaScript. It is never at any point Java.
> >>
> >> >> A very simple compiler might recognise '"Window.alert(" and translate
> it to
> >> >> '"document.alert("
> >>
> >> >> If you whole program consists of Window.alert("Hello"); then it will
> be OK.
> >> >> Anything else will fail.
> >>
> >> >> The Google team have emulated many other commands and structures, but
> not
> >> >> all of them: some are obscure and therefore not high enough up the
> priority
> >> >> list, and some are impossible because, like threading, JS just
> doesn't do
> >> >> that.
> >>
> >> >> It would be an impossible task to emulate every possible class in
> every Java
> >> >> library in existence. And would take for ever.
> >>
> >> >> So if it ain't emulated, it ain't gonna work because the compiler
> will issue
> >> >> a polite and rather technical version of 'WTF?'
> >>
> >> >> And just throwing any old java program into the GWT compiler is,
> pretty
> >> >> much, pointless.
> >>
> >> >> But if you really want to help Google and emulate
> rg.eclipse.swt.widgets.Canvas
> >> >> for GWT, then I'm sure they (and many others) will be eternally
> grateful for
> >> >> at least a week or two :-)
> >>
> >> >> If so, troll your little old lallies over to the very bonahttp://
> groups.google.com/group/Google-Web-Toolkit-Contributors
> > >
> >
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
googl
Re: Just getting started with GWT: how to wrap a native Java library?
Hey Jake,
I've never used the SWT Canvas, but if it's anything like the
tag, you might want to check out the GWTCanvas in the incubator:
http://code.google.com/docreader/#p=google-web-toolkit-incubator&s=google-web-toolkit-incubator&t=GWTCanvas
Also, Vitali, there's a GWT library for accessing gears:
http://code.google.com/p/gwt-google-apis/
Regards,
--
Arthur Kalmenson
On Tue, Apr 7, 2009 at 3:35 PM, Jake wrote:
>
> Isaac, thank you for the informed response, I believe that was exactly
> what I was looking for.
>
> Best regards,
>
> Jake
>
> On Apr 7, 3:27 pm, Isaac Truett wrote:
>> Jake,
>>
>> You would have to create a class org.eclipse.swt.widgets.Canvas such
>> that it is GWT-compatible. That means only using emulated JRE classes
>> (String, collections, etc.). Any class required for the Canvas class
>> API has to be implemented in a GWT-compatible manner as well. This
>> transitive dependency is what really kills you. If you get to a point
>> where you have to use a non-emulated JRE class (e.g., java.io.*
>> (almost)), you're hosed (I believe this was essentially Ian's point).
>>
>> Assuming you manage to implement the entire API, you create a module
>> file (gwt.xml) that includes the source you just wrote, inherit that
>> module in your GWT app, and enjoy.
>>
>> For more on JRE emulation, see:
>>
>> http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=goog...
>>
>> - Isaac
>>
>> On Tue, Apr 7, 2009 at 3:14 PM, Jake wrote:
>>
>> > I feel like I'm not expressing myself clearly. Let's just focus on the
>> > reduced case:
>>
>> > import org.eclipse.swt.widgets.Canvas;
>>
>> > public class foo {
>>
>> > }
>>
>> > Right now, if I try to run this through GWT, it will throw an error
>> > because it can't compile Canvas and all of its dependencies. This is
>> > to be expected. So what I would like is to roll my own Canvas class
>> > which extends GWT's Widget class, and have that be used instead, but
>> > in such a way that I don't have to touch the existing program's source
>> > code.
>>
>> > Ian, you seem to be suggesting that I need to hack this into the
>> > internals of GWT itself, and try to push it upstream. I feel like
>> > there should be a way to do this without having modify GWT internals,
>> > because this would allow certain applications (not all of them) that
>> > leverage native GUI toolkits to be compiled directly to a browser-
>> > based version, without having to port them to a GWT-friendly set of
>> > libraries. This would be a very powerful feature, but it may not
>> > exist. If I could just get confirmation on this, I would appreciate
>> > it.
>>
>> > Thanks,
>>
>> > Jake
>>
>> > On Apr 7, 2:38 pm, Ian Bambury wrote:
>> >> GWT isn't Java. It just uses Java syntax so that Java books are useful,
>> >> and
>> >> things like Eclipse work for it.
>> >> GWT code becomes JavaScript. It is never at any point Java.
>>
>> >> A very simple compiler might recognise '"Window.alert(" and translate it
>> >> to
>> >> '"document.alert("
>>
>> >> If you whole program consists of Window.alert("Hello"); then it will be
>> >> OK.
>> >> Anything else will fail.
>>
>> >> The Google team have emulated many other commands and structures, but not
>> >> all of them: some are obscure and therefore not high enough up the
>> >> priority
>> >> list, and some are impossible because, like threading, JS just doesn't do
>> >> that.
>>
>> >> It would be an impossible task to emulate every possible class in every
>> >> Java
>> >> library in existence. And would take for ever.
>>
>> >> So if it ain't emulated, it ain't gonna work because the compiler will
>> >> issue
>> >> a polite and rather technical version of 'WTF?'
>>
>> >> And just throwing any old java program into the GWT compiler is, pretty
>> >> much, pointless.
>>
>> >> But if you really want to help Google and emulate
>> >> rg.eclipse.swt.widgets.Canvas
>> >> for GWT, then I'm sure they (and many others) will be eternally grateful
>> >> for
>> >> at least a week or two :-)
>>
>> >> If so, troll your little old lallies over to the very
>> >> bonahttp://groups.google.com/group/Google-Web-Toolkit-Contributors
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Just getting started with GWT: how to wrap a native Java library?
On Tue, Apr 7, 2009 at 9:52 PM, Ian Bambury wrote: > Well, I've learnt a couple of things, thanks! >> >> >> Any code you have that access browser stuff (i.e. DOM, events, etc) then >> at some point sends that stuff to the javascript stub which performs the >> actual execution (I believe that's how it goes - although I'm not 100% sure >> on the Java->javascript path). The javascript->java path is always the way >> your Java code executes in hosted mode. >> > > Hosted mode might well do that in part, but not for all of it. Regular > expressions for example seem to work on Java principles in hosted mode and > JS if compiled so I've always tried to keep to expressions which work in > both. > Precisely. That's what I'm saying. In HostedMode the Java code is executed in a regular JVM, so everything is going to have Java semantics. In fact, reflection works in HostedMode like regular Java, which might throw some people when they go to compile their code. One way you could do it is through deferred binding (Java class with your regexps as static strings & then in your gwt.xml simplydo an unconditional class replacement with the Javascript equivalent). This may not be necessary now, but it certainly was in older versions in my > experience - and it's only my experience and what I've picked up on the list > that I'm going by - I haven't delved any deeper. > It's still this way (and will remain so) AFAIK. I learnt a lot just from the off-hand comments the GWT designers make. > > Cheers, > > Ian > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Just getting started with GWT: how to wrap a native Java library?
Well, I've learnt a couple of things, thanks! > > > Any code you have that access browser stuff (i.e. DOM, events, etc) then at > some point sends that stuff to the javascript stub which performs the actual > execution (I believe that's how it goes - although I'm not 100% sure on the > Java->javascript path). The javascript->java path is always the way your > Java code executes in hosted mode. > Hosted mode might well do that in part, but not for all of it. Regular expressions for example seem to work on Java principles in hosted mode and JS if compiled so I've always tried to keep to expressions which work in both. This may not be necessary now, but it certainly was in older versions in my experience - and it's only my experience and what I've picked up on the list that I'm going by - I haven't delved any deeper. Cheers, Ian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Just getting started with GWT: how to wrap a native Java library?
On Tue, Apr 7, 2009 at 4:08 PM, Ian Bambury wrote: > 2009/4/7 Vitali Lovich > >> >> >> On Tue, Apr 7, 2009 at 2:38 PM, Ian Bambury wrote: >> >>> GWT isn't Java. It just uses Java syntax so that Java books are useful, >>> and things like Eclipse work for it. >> >> I believe the main goal was that you could do a lot of optimization at >> compile-time that just aren't possible at runtime (i.e. browser checks for >> compatability disappear) & the generated code can be smaller. >> > > Maybe, but that could be done using the syntax of any language. I doesn't > explain why Java syntax was chosen. > Well there's a lot of development experience & tools surrounding Java yes. But I have a feeling that it has also to do with the compiling Java into Javascript not introducing significant limitations on the language syntax that can be used & not changing the expected semantics of your Java code. Yes, you could do the same thing with C++ - but you'd find that writing the compiler is very difficult and you've all of a sudden gotten harder development because most C++ constructs cannot be used (pointers, pass by ref for example, any kind of memory deallocation, non-new memory allocation) which means that your developers are going to be using a heavily restricted version of C++ anyways. Also, debugging that C++ in an equivalent hosted mode would be slightly more difficult to implement in that a C++ garbage compiler would be needed. Whereas with Java, there's already a VM to run your code in debug mode for you. The syntax maps naturally & the only restriction was on the full use of reflections. Then there's also that, from what I've heard, Java is a pretty popular language for development at Google (maybe C++ for some of the core search stuff & maybe Python for scripting). So it might also have been a business decision. > > >> >> >>> GWT code becomes JavaScript. It is never at any point Java. >>> >> Well, technically, in HostedMode, it is Java with some minor Javascript >> code acting as a communication interface. >> > > Nowhere is there a GWT-Java-JavaScript chain > When you run in hosted mode it goes as follows: Browser loads page -> executes some javascript which connects to the VM -> executes your onModuleLoad Any code you have that access browser stuff (i.e. DOM, events, etc) then at some point sends that stuff to the javascript stub which performs the actual execution (I believe that's how it goes - although I'm not 100% sure on the Java->javascript path). The javascript->java path is always the way your Java code executes in hosted mode. > > If you compile GWT code it does *not* become Java at any point. > Correct. But in HostedMode your code isn't compiled by the GWT compiler, but rather the Java compiler. > > Hosted mode is not an intermediate stage on the way to JavaScript: it is a > useful dead-end. > Correct. > > >> Threading is possible (or rather will be). Gears & HTML5 browsers >> introduce the concept of worker threads. >> > > Is threading possible right now? No. I wasn't trying to make statements > that a US lawyer would think were bomb-proof, I was just generalising things > for the present moment (not any time in the future) and assuming that we > were talking about GWT. Gears is not GWT any more than Java applets or Flash > are. > But it is possible. Use Safari 4 or FF3.5. Or install gears into your browser. It's not part of GWT, but it definitely is possible using native Javascript (which was your original statement - that threading is impossible in javascript right now). As for Gears, it's not part of GWT, but it's what major parts of HTML5 were based off of, so you can think of it as HTML5-like support for non-HTML5 browsers. It is accessed in the browser via javascript (and at some point jumps out of the browser into a native dll for the functionality that is not available as part of the browser). > >> It would be an impossible task to emulate every possible class in every >>> Java library in existence. And would take for ever. >>> >> Not to mention that some are simply not possible due to browser >> restrictions (i.e. most of the java.io. stuff). >> > > > I would have thought that "...and some are impossible..." had that > covered. No? > Yup... just wanted to clarify why :D. Not that it's too large a task, rather that it is not possible because that behaviour is not permitted by the browser's javascript sandbox. > > Ian > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Just getting started with GWT: how to wrap a native Java library?
You can write a class to do anything within the current limitations, of
course. And if you name the package exactly the same as the original and
don't include the original in the classpath, you will be OK.
It does, however, rather go against the principles of package-naming.
If you *don't* name it the same as the original package, then (again, of
course) it won't work because you stipulated it had to be done "in such a
way that I don't have to touch the existing program's source code" and
"without changing its import statement".
Ian
http://examples.roughian.com
2009/4/7 Jake
>
> Isaac, thank you for the informed response, I believe that was exactly
> what I was looking for.
>
> Best regards,
>
> Jake
>
> On Apr 7, 3:27 pm, Isaac Truett wrote:
> > Jake,
> >
> > You would have to create a class org.eclipse.swt.widgets.Canvas such
> > that it is GWT-compatible. That means only using emulated JRE classes
> > (String, collections, etc.). Any class required for the Canvas class
> > API has to be implemented in a GWT-compatible manner as well. This
> > transitive dependency is what really kills you. If you get to a point
> > where you have to use a non-emulated JRE class (e.g., java.io.*
> > (almost)), you're hosed (I believe this was essentially Ian's point).
> >
> > Assuming you manage to implement the entire API, you create a module
> > file (gwt.xml) that includes the source you just wrote, inherit that
> > module in your GWT app, and enjoy.
> >
> > For more on JRE emulation, see:
> >
> > http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=goog...
> >
> > - Isaac
> >
> > On Tue, Apr 7, 2009 at 3:14 PM, Jake wrote:
> >
> > > I feel like I'm not expressing myself clearly. Let's just focus on the
> > > reduced case:
> >
> > > import org.eclipse.swt.widgets.Canvas;
> >
> > > public class foo {
> >
> > > }
> >
> > > Right now, if I try to run this through GWT, it will throw an error
> > > because it can't compile Canvas and all of its dependencies. This is
> > > to be expected. So what I would like is to roll my own Canvas class
> > > which extends GWT's Widget class, and have that be used instead, but
> > > in such a way that I don't have to touch the existing program's source
> > > code.
> >
> > > Ian, you seem to be suggesting that I need to hack this into the
> > > internals of GWT itself, and try to push it upstream. I feel like
> > > there should be a way to do this without having modify GWT internals,
> > > because this would allow certain applications (not all of them) that
> > > leverage native GUI toolkits to be compiled directly to a browser-
> > > based version, without having to port them to a GWT-friendly set of
> > > libraries. This would be a very powerful feature, but it may not
> > > exist. If I could just get confirmation on this, I would appreciate
> > > it.
> >
> > > Thanks,
> >
> > > Jake
> >
> > > On Apr 7, 2:38 pm, Ian Bambury wrote:
> > >> GWT isn't Java. It just uses Java syntax so that Java books are
> useful, and
> > >> things like Eclipse work for it.
> > >> GWT code becomes JavaScript. It is never at any point Java.
> >
> > >> A very simple compiler might recognise '"Window.alert(" and translate
> it to
> > >> '"document.alert("
> >
> > >> If you whole program consists of Window.alert("Hello"); then it will
> be OK.
> > >> Anything else will fail.
> >
> > >> The Google team have emulated many other commands and structures, but
> not
> > >> all of them: some are obscure and therefore not high enough up the
> priority
> > >> list, and some are impossible because, like threading, JS just doesn't
> do
> > >> that.
> >
> > >> It would be an impossible task to emulate every possible class in
> every Java
> > >> library in existence. And would take for ever.
> >
> > >> So if it ain't emulated, it ain't gonna work because the compiler will
> issue
> > >> a polite and rather technical version of 'WTF?'
> >
> > >> And just throwing any old java program into the GWT compiler is,
> pretty
> > >> much, pointless.
> >
> > >> But if you really want to help Google and emulate
> rg.eclipse.swt.widgets.Canvas
> > >> for GWT, then I'm sure they (and many others) will be eternally
> grateful for
> > >> at least a week or two :-)
> >
> > >> If so, troll your little old lallies over to the very bonahttp://
> groups.google.com/group/Google-Web-Toolkit-Contributors
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Just getting started with GWT: how to wrap a native Java library?
2009/4/7 Vitali Lovich > > > On Tue, Apr 7, 2009 at 2:38 PM, Ian Bambury wrote: > >> GWT isn't Java. It just uses Java syntax so that Java books are useful, >> and things like Eclipse work for it. > > I believe the main goal was that you could do a lot of optimization at > compile-time that just aren't possible at runtime (i.e. browser checks for > compatability disappear) & the generated code can be smaller. > Maybe, but that could be done using the syntax of any language. I doesn't explain why Java syntax was chosen. > > >> GWT code becomes JavaScript. It is never at any point Java. >> > Well, technically, in HostedMode, it is Java with some minor Javascript > code acting as a communication interface. > Nowhere is there a GWT-Java-JavaScript chain If you compile GWT code it does *not* become Java at any point. Hosted mode is not an intermediate stage on the way to JavaScript: it is a useful dead-end. > Threading is possible (or rather will be). Gears & HTML5 browsers > introduce the concept of worker threads. > Is threading possible right now? No. I wasn't trying to make statements that a US lawyer would think were bomb-proof, I was just generalising things for the present moment (not any time in the future) and assuming that we were talking about GWT. Gears is not GWT any more than Java applets or Flash are. > It would be an impossible task to emulate every possible class in every >> Java library in existence. And would take for ever. >> > Not to mention that some are simply not possible due to browser > restrictions (i.e. most of the java.io. stuff). > I would have thought that "...and some are impossible..." had that covered. No? Ian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Just getting started with GWT: how to wrap a native Java library?
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 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 > > > > > 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 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 Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Just getting started with GWT: how to wrap a native Java library?
Jake,
You would have to create a class org.eclipse.swt.widgets.Canvas such
that it is GWT-compatible. That means only using emulated JRE classes
(String, collections, etc.). Any class required for the Canvas class
API has to be implemented in a GWT-compatible manner as well. This
transitive dependency is what really kills you. If you get to a point
where you have to use a non-emulated JRE class (e.g., java.io.*
(almost)), you're hosed (I believe this was essentially Ian's point).
Assuming you manage to implement the entire API, you create a module
file (gwt.xml) that includes the source you just wrote, inherit that
module in your GWT app, and enjoy.
For more on JRE emulation, see:
http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=google-web-toolkit-doc-1-5&t=RefJreEmulation
- Isaac
On Tue, Apr 7, 2009 at 3:14 PM, Jake wrote:
>
> I feel like I'm not expressing myself clearly. Let's just focus on the
> reduced case:
>
> import org.eclipse.swt.widgets.Canvas;
>
> public class foo {
>
> }
>
> Right now, if I try to run this through GWT, it will throw an error
> because it can't compile Canvas and all of its dependencies. This is
> to be expected. So what I would like is to roll my own Canvas class
> which extends GWT's Widget class, and have that be used instead, but
> in such a way that I don't have to touch the existing program's source
> code.
>
> Ian, you seem to be suggesting that I need to hack this into the
> internals of GWT itself, and try to push it upstream. I feel like
> there should be a way to do this without having modify GWT internals,
> because this would allow certain applications (not all of them) that
> leverage native GUI toolkits to be compiled directly to a browser-
> based version, without having to port them to a GWT-friendly set of
> libraries. This would be a very powerful feature, but it may not
> exist. If I could just get confirmation on this, I would appreciate
> it.
>
> Thanks,
>
> Jake
>
> On Apr 7, 2:38 pm, Ian Bambury wrote:
>> GWT isn't Java. It just uses Java syntax so that Java books are useful, and
>> things like Eclipse work for it.
>> GWT code becomes JavaScript. It is never at any point Java.
>>
>> A very simple compiler might recognise '"Window.alert(" and translate it to
>> '"document.alert("
>>
>> If you whole program consists of Window.alert("Hello"); then it will be OK.
>> Anything else will fail.
>>
>> The Google team have emulated many other commands and structures, but not
>> all of them: some are obscure and therefore not high enough up the priority
>> list, and some are impossible because, like threading, JS just doesn't do
>> that.
>>
>> It would be an impossible task to emulate every possible class in every Java
>> library in existence. And would take for ever.
>>
>> So if it ain't emulated, it ain't gonna work because the compiler will issue
>> a polite and rather technical version of 'WTF?'
>>
>> And just throwing any old java program into the GWT compiler is, pretty
>> much, pointless.
>>
>> But if you really want to help Google and emulate
>> rg.eclipse.swt.widgets.Canvas
>> for GWT, then I'm sure they (and many others) will be eternally grateful for
>> at least a week or two :-)
>>
>> If so, troll your little old lallies over to the very
>> bonahttp://groups.google.com/group/Google-Web-Toolkit-Contributors
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Just getting started with GWT: how to wrap a native Java library?
Isaac, thank you for the informed response, I believe that was exactly
what I was looking for.
Best regards,
Jake
On Apr 7, 3:27 pm, Isaac Truett wrote:
> Jake,
>
> You would have to create a class org.eclipse.swt.widgets.Canvas such
> that it is GWT-compatible. That means only using emulated JRE classes
> (String, collections, etc.). Any class required for the Canvas class
> API has to be implemented in a GWT-compatible manner as well. This
> transitive dependency is what really kills you. If you get to a point
> where you have to use a non-emulated JRE class (e.g., java.io.*
> (almost)), you're hosed (I believe this was essentially Ian's point).
>
> Assuming you manage to implement the entire API, you create a module
> file (gwt.xml) that includes the source you just wrote, inherit that
> module in your GWT app, and enjoy.
>
> For more on JRE emulation, see:
>
> http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=goog...
>
> - Isaac
>
> On Tue, Apr 7, 2009 at 3:14 PM, Jake wrote:
>
> > I feel like I'm not expressing myself clearly. Let's just focus on the
> > reduced case:
>
> > import org.eclipse.swt.widgets.Canvas;
>
> > public class foo {
>
> > }
>
> > Right now, if I try to run this through GWT, it will throw an error
> > because it can't compile Canvas and all of its dependencies. This is
> > to be expected. So what I would like is to roll my own Canvas class
> > which extends GWT's Widget class, and have that be used instead, but
> > in such a way that I don't have to touch the existing program's source
> > code.
>
> > Ian, you seem to be suggesting that I need to hack this into the
> > internals of GWT itself, and try to push it upstream. I feel like
> > there should be a way to do this without having modify GWT internals,
> > because this would allow certain applications (not all of them) that
> > leverage native GUI toolkits to be compiled directly to a browser-
> > based version, without having to port them to a GWT-friendly set of
> > libraries. This would be a very powerful feature, but it may not
> > exist. If I could just get confirmation on this, I would appreciate
> > it.
>
> > Thanks,
>
> > Jake
>
> > On Apr 7, 2:38 pm, Ian Bambury wrote:
> >> GWT isn't Java. It just uses Java syntax so that Java books are useful, and
> >> things like Eclipse work for it.
> >> GWT code becomes JavaScript. It is never at any point Java.
>
> >> A very simple compiler might recognise '"Window.alert(" and translate it to
> >> '"document.alert("
>
> >> If you whole program consists of Window.alert("Hello"); then it will be OK.
> >> Anything else will fail.
>
> >> The Google team have emulated many other commands and structures, but not
> >> all of them: some are obscure and therefore not high enough up the priority
> >> list, and some are impossible because, like threading, JS just doesn't do
> >> that.
>
> >> It would be an impossible task to emulate every possible class in every
> >> Java
> >> library in existence. And would take for ever.
>
> >> So if it ain't emulated, it ain't gonna work because the compiler will
> >> issue
> >> a polite and rather technical version of 'WTF?'
>
> >> And just throwing any old java program into the GWT compiler is, pretty
> >> much, pointless.
>
> >> But if you really want to help Google and emulate
> >> rg.eclipse.swt.widgets.Canvas
> >> for GWT, then I'm sure they (and many others) will be eternally grateful
> >> for
> >> at least a week or two :-)
>
> >> If so, troll your little old lallies over to the very
> >> bonahttp://groups.google.com/group/Google-Web-Toolkit-Contributors
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Just getting started with GWT: how to wrap a native Java library?
On Tue, Apr 7, 2009 at 2:38 PM, Ian Bambury wrote:
> GWT isn't Java. It just uses Java syntax so that Java books are useful, and
> things like Eclipse work for it.
I believe the main goal was that you could do a lot of optimization at
compile-time that just aren't possible at runtime (i.e. browser checks for
compatability disappear) & the generated code can be smaller.
>
> GWT code becomes JavaScript. It is never at any point Java.
>
Well, technically, in HostedMode, it is Java with some minor Javascript code
acting as a communication interface.
>
> A very simple compiler might recognise '"Window.alert(" and translate it to
> '"document.alert("
>
> If you whole program consists of Window.alert("Hello"); then it will be OK.
> Anything else will fail.
>
> The Google team have emulated many other commands and structures, but not
> all of them: some are obscure and therefore not high enough up the priority
> list, and some are impossible because, like threading, JS just doesn't do
> that.
>
Threading is possible (or rather will be). Gears & HTML5 browsers introduce
the concept of worker threads.
>
> It would be an impossible task to emulate every possible class in every
> Java library in existence. And would take for ever.
>
Not to mention that some are simply not possible due to browser restrictions
(i.e. most of the java.io. stuff).
>
> So if it ain't emulated, it ain't gonna work because the compiler will
> issue a polite and rather technical version of 'WTF?'
>
> And just throwing any old java program into the GWT compiler is, pretty
> much, pointless.
>
> But if you really want to help Google and emulate
> rg.eclipse.swt.widgets.Canvas
> for GWT, then I'm sure they (and many others) will be eternally grateful for
> at least a week or two :-)
>
> If so, troll your little old lallies over to the very bona
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Just getting started with GWT: how to wrap a native Java library?
I feel like I'm not expressing myself clearly. Let's just focus on the
reduced case:
import org.eclipse.swt.widgets.Canvas;
public class foo {
}
Right now, if I try to run this through GWT, it will throw an error
because it can't compile Canvas and all of its dependencies. This is
to be expected. So what I would like is to roll my own Canvas class
which extends GWT's Widget class, and have that be used instead, but
in such a way that I don't have to touch the existing program's source
code.
Ian, you seem to be suggesting that I need to hack this into the
internals of GWT itself, and try to push it upstream. I feel like
there should be a way to do this without having modify GWT internals,
because this would allow certain applications (not all of them) that
leverage native GUI toolkits to be compiled directly to a browser-
based version, without having to port them to a GWT-friendly set of
libraries. This would be a very powerful feature, but it may not
exist. If I could just get confirmation on this, I would appreciate
it.
Thanks,
Jake
On Apr 7, 2:38 pm, Ian Bambury wrote:
> GWT isn't Java. It just uses Java syntax so that Java books are useful, and
> things like Eclipse work for it.
> GWT code becomes JavaScript. It is never at any point Java.
>
> A very simple compiler might recognise '"Window.alert(" and translate it to
> '"document.alert("
>
> If you whole program consists of Window.alert("Hello"); then it will be OK.
> Anything else will fail.
>
> The Google team have emulated many other commands and structures, but not
> all of them: some are obscure and therefore not high enough up the priority
> list, and some are impossible because, like threading, JS just doesn't do
> that.
>
> It would be an impossible task to emulate every possible class in every Java
> library in existence. And would take for ever.
>
> So if it ain't emulated, it ain't gonna work because the compiler will issue
> a polite and rather technical version of 'WTF?'
>
> And just throwing any old java program into the GWT compiler is, pretty
> much, pointless.
>
> But if you really want to help Google and emulate
> rg.eclipse.swt.widgets.Canvas
> for GWT, then I'm sure they (and many others) will be eternally grateful for
> at least a week or two :-)
>
> If so, troll your little old lallies over to the very
> bonahttp://groups.google.com/group/Google-Web-Toolkit-Contributors
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Just getting started with GWT: how to wrap a native Java library?
GWT isn't Java. It just uses Java syntax so that Java books are useful, and
things like Eclipse work for it.
GWT code becomes JavaScript. It is never at any point Java.
A very simple compiler might recognise '"Window.alert(" and translate it to
'"document.alert("
If you whole program consists of Window.alert("Hello"); then it will be OK.
Anything else will fail.
The Google team have emulated many other commands and structures, but not
all of them: some are obscure and therefore not high enough up the priority
list, and some are impossible because, like threading, JS just doesn't do
that.
It would be an impossible task to emulate every possible class in every Java
library in existence. And would take for ever.
So if it ain't emulated, it ain't gonna work because the compiler will issue
a polite and rather technical version of 'WTF?'
And just throwing any old java program into the GWT compiler is, pretty
much, pointless.
But if you really want to help Google and emulate rg.eclipse.swt.widgets.Canvas
for GWT, then I'm sure they (and many others) will be eternally grateful for
at least a week or two :-)
If so, troll your little old lallies over to the very bona
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Just getting started with GWT: how to wrap a native Java library?
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 > > 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 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 Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Just getting started with GWT: how to wrap a native Java library?
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 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 Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Just getting started with GWT: how to wrap a native Java library?
otakuj462 wrote: > 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 Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Just getting started with GWT: how to wrap a native Java library?
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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
