So I'm reading between the lines that the intention is to take
existing running Java code using SWT, and transmute that, in toto, to
Flex. Just like what (I understand) GWT does.
*Devil's Advocates positioning below!!!*
As I said, it's not clear that "SWT in JavaScript" makes much sense,
but it none-the-less sounds like an interesting take on the issue.
It's impossible for me to gauge the "usefulness" of such things
without a concrete implementation to play with, and often not even
then; there are long term issues to deal with as well, besides just
getting some simple examples going.
As for "what does this solve" ... let me play devil's advocate here.
I love the shape of SWT, I don't care much about the actual bindings
to Java. Even though that's the only SWT story - I look at it in a
more idealized form. Similarities to Cw / Cg perhaps :-) Take that
as my "pro-SWT" stand. Extending the "SWT interface" story out across
other languages in no way seems like a stretch to me. Useful?
Dunno. But as a concept - works for me.
Now, let's look at the actual language issues here. In my,
particularly slanted, view of the world, the value of Java is
declining against the value of "scripting" languages. Bear with me, I
admit I may not be right there, but just pretend. JavaScript will
just never go away, it would seem. And I mean literally. As such, by
forcing everyone who wants to use SWT to first learn Java, you are
going up against a smaller set of developers every year. YOUR
POTENTIAL MARKET IS DECREASING.
Alternatively, by exposing SWT in JavaScript, your potential market
over time is increasing. And there's already a story for running
JavaScript code in Java, called Rhino or JDK 1.6 javax.scripting (or
whatever), so Java folks are also potential customers here. You've
got both markets.
Another way of looking at this problem is "what problem are you trying
to solve". I'm guessing the problem is: "I've got a lot of pre-
existing Java/SWT code and/or Java/SWT experience I want to reuse".
If you can do a 100% translation from those reusable assets into
runnable JavaScript/Flex/Silverlight/whatever assets, then you've
solved your problem. If you can't do 100%, then you have a cost/
benefit issue on your hands. My experience here is colored by the
"Smalltalk on the Web" experiences from a decade ago; we didn't even
try to go down the transparent route because we knew it wouldn't be
100% and the cost/benefit didn't seem to work out in "transparency"'s
favor. You might well argue the web has radically changed in a
decade, pushing the potential for 100% transparency back in the web's
favor, but I'd argue it hasn't. DHTML and XHR are almost that old
anyway, we certainly had some JS back then, and the big issues are UI
rendering anyway but "event handling" and ui transitions. Flex is on
a better footing for SWT than 'html' (obviously), but has it's own
"not of the web issues" like - how do I bookmark a spot in a Flex
app? You might do a bang-up job porting SWT to Flex, but that doesn't
mean you've solved the web UI story. Frankly, I'm pretty bullish on
Flex/Silverlight/etal here, but don't think they will displace HTML/
CSS/JS either. You are forever relegated to that sliver of the web
that caters to those UIs.
I could of course be much meaner in my argument and say something
like: "I certainly expect a bunch of Java heads to assume that Java is
the answer to every problem. Are there 'web people' involved in the
discussion here? I don't think any 'web people' ever consider Java to
be part of the answer when it comes to 'web UI'". But I'm not a mean
guy so I won't say that. :-) And I don't consider myself a
knowledgeable 'web person', more of an enthusiast, prosumer. And rock
thrower.
On Sep 19, 2008, at 12:30 PM, Steve Northover wrote:
Sorry Pat, I didn't intend the URL slap.
What problem would providing the spirit of SWT on top of Flex and
Dojo solve? What language would you program in? JavaScript or
ActionScript? Not useful I think. If you are using "native"
technologies and don't intend portability, then just use them.
SWT for Dojo for Rhino: This would be programming SWT in
JavaScript, right? I'm not sure what this would solve either.
Patrick Mueller <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
09/18/2008 05:58 PM
Please respond to
E4 developer list <[email protected]>
To
E4 developer list <[email protected]>
cc
Subject
Re: [eclipse-incubator-e4-dev] SWT port to Flex
Trying to wrap my head around what this even means. Is there a
write-up somewhere? You can't use a Java JCL directly with Flex, so
I assume you want to start with GWT or Harmony and transmute the
required classes to ActionScript.
My first take would have been to try to provide the spirit of SWT on
top of existing Flex (and for Dojo, dojo) infrastructure, as much as
you can. But that's a different styled kind of result, and it's not
clear that it would be all that useful anyway.
Here's an interesting thought: SWT for Dojo for Rhino. Which would
of course use the "real" SWT in the end. Giving you some kind of
"portability" story for JS across SWT/Java and SWT/Dojo/browser.
Unless that's what SWT for Dojo already is ...
On Sep 18, 2008, at 1:45 PM, Steve Northover wrote:
One of the big issues when porting SWT to a platform where Java
isn't running is that Java isn't running. For the Flex port, a
cross-compiler was written that converts Java to ActionScript, but
there's more than just syntax translation involved when running Java
without a JVM. Java programs need a Java Class Library (JCL) to
code against. For the Flex prototype, a small CLDC-like"Java Class
Library was written. This was done to get off the ground but in the
long run, maintaining this JCL is not attractive.
For the SWT Dojo port, GWT was used for both the cross-compiler and
JCL. Moving forward, I can see two obvious candidates for a JCL for
Flex: GWT or Harmony. I believe that the obvious approach (ie. use
Sun's) isn't on the table for licensing reasons.
I'm proposing that we (e4) investigate GWT and Harmony. Does anyone
else have any other ideas?
Patrick Mueller
http://muellerware.org/
Patrick Mueller
http://muellerware.org/
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
