SWT API for another lanugage (ie Dojo): This exists. For example, the D language uses SWT API and is a port of the existing desktop Java code. An SWT binding for JavaScript (Dojo), Flex and Silverlight while interesting, wouldn't provide any sort of portability due to the implementation languages (JavaScript, ActionScript and C#/.NET) and would require you to code you UI three times if you wanted to run on all three. If you just wanted to run on one, why wouldn't you just code natively and use native user-interface technology? On the desktop for example, if you decided that you were only ever running on Windows, you would choose win32 (or WPF) and C (or C++ or C#).
Java is declining/Problem being solved: The imediate problem that is being solved is component portability between the desktop and the web (Note: not application portability because desktop and web apps are fundamentally different). If you have only a web presence and never intend to run on the desktop, then web technologies should just be used directly. There is a weaker argument that says, "Java is a good language, so it should be used" but we both know, from our experience with Smalltalk, that "good" doesn't matter. Finally, don't assume the idea is to take over the world. We need an advanced Java editor that can run both on the desktop and the web. That's all. Patrick Mueller <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/19/2008 01:33 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 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
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
