Ask TSS: if GWT's open source, where's the source?

Discussions

News: Ask TSS: if GWT's open source, where's the source?

  1. A reader asked if TSS could advocate the release of GWT's test cases to Google (as requested in this bug report.) TSS won't, but the request raises an interesting point: what sort of thing should be released in a toolkit in order for the toolkit to really be useful? GWT isn't open source (see the terms and conditions), so there's no real burden on Google's part to open up the compiler and its test cases, but there's little doubt that it would be very useful for developers planning on extending or fixing certain problems in the compiler or runtime libraries. In this case, the reader pointed out that the tests would apply to the portions of GWT that have been open sourced, so there'd be nothing needing more visibility from a licensing perspective. GWT's purpose is fairly unique, but its situation might not be. So the question stands: what would you like to see in a release like this?

    Threaded Messages (13)

  2. Keep the code, open the process[ Go to top ]

    GWT is probably the best ajax framework for java developers. Major problem (even bigger than the need to Drag&Drop) is that it is not scalable for enterprise applications. Why? A single entry point must be controlled by google. Google is best for the low level, but it doesn't let other technologies do the higher level modeling / coding. Some projects try to solve it. Most notably GWanTed or G4Jsf. They do fine job but got a major limitation: If they can extract GWT to the complex widget writing level, putting 10 such GWT widgets on a page will cause the bring the entired GWT library compiled to JS 10 times to the browser. I think google should not limit GWT's developers to work with GWT only but open itself to JSF/JSP/Whatever integration. JSF/GWT looks like the best of two worlds. (@see: check Atlas/Script# integration) I think google should open the process how the complier is working in order to help such frameworks. This is the future. GWT cannot control the web by itself. Such knowledge could give a chance for the duplicated js code problem. Cheers, Lior
  3. Re: Keep the code, open the process[ Go to top ]

    "Major problem is that it is not scalable for enterprise applications." I think you will find that nearly all Ajax frameworks have the potential to overload a back end. It is extremely important that application designers and developers continuously test the client-to-server and server-to-backend (jdbc, jms, jca) execution patterns when introducing or modifying aspects of the Ajax framework and runtime configuration. A team must carefully deliberate over the ease of use (and coolness) of Ajax introductions in light of resulting resource (threads, connections) consumption patterns. Improvements in the effectiveness of performance and capacity modeling is extremely important with such rollouts. I recently wrote a blog entry that touches on this on a small scale. http://blog.jinspired.com/?p=30 I hope over the next few days and weeks to explore this in greater detail as well as expanding the scope of the analysis to include resource transaction analysis patterns (hint: transaction chopping). William Louth JXInsight Product Architect JInspired "Java EE tuning, testing, tracing, and monitoring with JXInsight" http://www.jinspired.com
  4. Re: Keep the code, open the process[ Go to top ]

    A team must carefully deliberate over the...
    JUNInspired noise. You wascal you!
  5. Re: Keep the code, open the process[ Go to top ]

    "Major problem is that it is not scalable for enterprise applications."

    I think you will find that nearly all Ajax frameworks have the potential to overload a back end.
    I've found Ajax to do quite the opposite in most cases: the back-end is under less load, due to the fact that "micro-requests" mean that it only needs to process what will actually be updated, rather than process a whole page. Obviously, it probably depends on your usage scenario: something like populating a textfield with dropdown values based on the entry text might do more damage than good in terms of server load.
  6. Re: Keep the code, open the process[ Go to top ]

    I've found Ajax to do quite the opposite in most cases: the back-end is under less load, due to the fact that "micro-requests" mean that it only needs to process what will actually be updated, rather than process a whole page.
    Under certain circumstances (or implementation) this could be the case that is why I qualified my statement with "potential" and stated the importance of improved performance and capacity modeling. With Ajax a development team clearly needs visibility into the implications of a particular interaction style as earlier as is possible especially when the costs both in terms of network latency (chop versus batch) and resource consumption (thread and connection pool capacities) can greatly impact all. Regards, William
  7. Of course AJAX is better than normal HTTP/server-side generation overhead if you have competent programmers. Come on, if a bunch of people don't like a technique because it threatens their sacred cows/careers, you don't assume it's going to be competently programmed, you assume the worst case. Somewhere in the raw discrimination is a point though: Javascript is a terrible language to program in, and lends itself towards poor implementation. I have no idea what this single point of entry is that they are referring to. I don't see what would stop clustering using the usual distribution workloads. GWT seems to eliminate the necessity of server-side sessions (still looking into this), which increases scalability and reduces/eliminates most of the web tier, and would simplify clustering and failover (no sessions to clone).
  8. Hi Carl, Whether Ajax gets widespread adoption is of little concern to me today as all of the client side development I do today is Swing based. I am just more aware of the potential issues with the "blind" adoption of a particular rich client platform by less experienced enterprise development teams. Last year I was involved in a performance investigation at one of the biggest software management companies in the world were a single execution of a particular use case within a Swing application had managed to generate more than 20,000 remote calls and resource transactions at a beta customer site all because the ill conceived workflow-like programming model used in this application managed to completely hide the nature of the distributed processing from the junior developer who was tasked with wiring up views and event handlers. regards, William
  9. Huh?[ Go to top ]

    A single entry point must be controlled by [GWT?]. Google is best for the low level, but it doesn't let other technologies do the higher level modeling / coding.
    I don't, frankly, see this as a drawback. I still don't think the whole JSF model is a good one for applications from the get go. Anything that attempts to change the nature of the underlying platform is doomed to complexity problems, and I am not sure stacking more on top of it (Seam) is the way to go. It seems to me at a fundamental level, GWT encourages much better software practices than any of the other methodologies out there -- and I won't call GWT a framework, but I expect to see frameworks evolve from it. And seriously, what does this have to do with scalability? It might be a process issue in terms of moving from legacy/divergent systems, but those are standard issues anyway with any technology. I find GWT's development model and distribution methods superior to any of the other current systems anyway. More to the point, I think open sourcing the compiler -- or at least some more of the individual pieces would be good. I have found myself already wanting to manipulate the type oracle for some custom serialization behavior and opening up the core would allow people to extend the portions of the Java API implemented. I have classes now that mirror the java.beans.*PropertyChange* classes, but being able to add those to the compile environment would be great.
  10. Re: Huh?[ Go to top ]

    It seems to me at a fundamental level, GWT encourages much better software practices than any of the other methodologies out there ....
    Hmm, I do not think so. I think that the best scenario is when all the UI aspects are handled by client, client calls server for data mostly, and client code is auto or on-demand updatable. Therefore I consider Java Web Start based applications to be the most sane technology available today. - If JWS really supported Applets then it would be even closer to ideal; - and if JNLP allowed specifying trusted artifact repositories to avoid duplicate downloads of common stuff then it would be perfect solution;
  11. Re: Huh?[ Go to top ]

    A single entry point must be controlled by [GWT?].
    Google is best for the low level, but it doesn't let other technologies do the higher level modeling / coding.

    I don't, frankly, see this as a drawback. I still don't think the whole JSF model is a good one for applications from the get go. Anything that attempts to change the nature of the underlying platform is doomed to complexity problems, and I am not sure stacking more on top of it (Seam) is the way to go.
    JSF and seam exist for a reason, the html action -> form -> action metaphor is inherently broken by design once it comes to user interfaces. The status quo since the early 70s is, that vt200 terminal like interaction does not scale it simply does not work once user interfaces become more complex. You need componentization, an event system and if things should not get out of hand encapsulation on component level via oo, to handle complex user interfaces, also those uis should be stateful. What we had with the early 90s was that suddenly all the working design patterns were thrown overboard and the broken terminal / vt220 methodology was revived and to the works in a less working way than it used to be thanks to missing control elements and a sane form handling and now we have to deal with abstraction frameworks to hide and cover the deficits. Yes JSF and seam should be unnecessary, but please fix the broken html form standards then we can talk about it! The main problem i see is, that two generations of developers have now been grown up which have to inherently unlearn the bad design principles and practices which html enforced onto them!
  12. Re: Huh?[ Go to top ]

    hear, hear.
  13. Re: Keep the code, open the process[ Go to top ]

    A single entry point must be controlled by google.
    Eh, that's why it is not scalable? You are talking about the entry point classes, right? I fail to see why you couldn't deploy your client application on multiple backends and let a load balancer send client requests to each entry point. That would scale just fine. GWT (like most client-side AJAX frameworks) can scale much better than most server-controlled technologies for the simple reason that you can store state on the client. Which gets rid of the entire clustering state problem, the server affinity problem, etc. You just have to figure out a good way to keep the security checks sane.
  14. Java2Script[ Go to top ]

    Check Java2Script: http://j2s.sourceforge.net/ It's Eclipse Public License 1.0 based. Java2Script (J2S) Pacemaker provides an Eclipse Java to JavaScript compiler plugin and an implementation of JavaScript version of Eclipse Standard Widget Toolkit (SWT) with other common utilities, such as java.lang.* and java.util.*. You can convert your SWT-base Rich Client Platform (RCP) into Rich Internet Application (RIA) by Java2Script Pacemaker.