robjsoftware.info

A blog about software – researching it, developing it, and contemplating its future.

Archive for 2007

Me, Manifesto, GWT2007

leave a comment »

Sigh, another two weeks gone by without a post. Still, that last post was a doozy, so cut me some slack, willya? Incidentally, my readership has increased by 50% in the last two weeks according to Feedburner. I am honored to have all of you paying attention to me, and I will try to be worthy of your eyeballs and neurons.

This post is going to be a bit of a catch-all: some about me, some about my last big-ass posting, and some about the GWT conference.

First, sorry I missed last week — I got another cold (endemic in the wintertime with two young kids in the house), and my wife kicked into moving high gear. Yes, we’re selling our house, for a wide variety of reasons I will discuss in personal email if you’re interested enough to send me some. (Not in the comments, sorry!) We’re shooting for having it on the market March 1, which means there is no time at all to waste. I’ll be doing no hacking for the next two and a half months, that’s an absolute given. I’ll keep up the blogging, but weekly may be tough; bimonthly WILL happen if it kills me!

Which is all too bad, in a way, because there’s plenty to do in hackland. My manifesto was rather well received. The comments on the post itself have a number of intriguing links. I also posted about it on Lambda the Ultimate, where it got a number of other fascinating responses. Thanks to all who engaged with it in either location. I am sorry I won’t be able to touch it until March first at the earliest, but that’s the nice thing about research — interesting ideas don’t go away!

I also wanted to give an update on the GWT conference. My talk was quite well received if the consensus speaker’s feedback was anything to go by. I appreciate the appreciation, to say the least. I did hear that there was a significant fraction (over 50%?) of the audience that felt it was too technical. Evidently a substantial quorum of GWT2007 attendees were relatively unfamiliar with GWT at any level. I apologize to anyone who wasn’t experienced enough to get the most out of my talk; I hope that you can find helpful material on the GWT site and/or any of the various GWT books. I’ve put my slides online for anyone interested. Evidently it’ll be Youtubed sooner or later, but I’ve yet to get a date on that.

The last morning of the conference, we had a participatory breakfast session where Joel Webber and I led a discussion of declarative UI and declarative data binding in GWT. One thing that was clear from my talk is that there are a lot of people doing form-like web applications, and GWT underserves that population right now. Joel spent some time going over the declarative UI work he’s doing; he specifically mentioned that various internal Google customers want him to ensure that you can write a GWT-XML document that lays out a GWT widget tree with HTML fragments mixed in almost arbitrarily. This seems like a win insofar as Joel’s talk on performance specifically mentioned that innerHTML is your friend; the DOM is faster at inserting HTML fragments than it is at handling individual DOM element insertions. So everyone keep an eye on Joel’s stuff as it hits the incubator.

I asked the table what kinds of form-data-binding approaches would be most useful to implement. The consensus seemed to be split. A number of people were familiar with the JSF-like structure of binding to backing beans and using expression language to specify the coupling from bean fields to the UI. I mentioned JSR 295 and various people expressed interst in that. There is a recent thread on the GWT contributors forum about some community work in this very area, which I look forward to investigating in depth (in early March! 😛 ). Check that thread out if you want GWT to do this. I talk at more length there about a potential GWT EL parser.

There was one gentleman (whose card I got, and subsequently lost; please contact me again, sir!) who was a forceful advocate of an XForms-like approach; evidently XForms lets you declaratively specify data dependencies within your model, and allows you to lay out interactions witihn your UI purely in your interface specification. This was pretty much news to everyone at the table. I will definitely have to look into XForms now. However, it seems to me that a JSF-like, JSR-295-like bean-binding approach covers many of the basic use cases people want, and should certainly be a near-term project.

OK, that’s it for this week. Happy, happy holidays to you all!

Advertisements

Written by robjellinghaus

2007/12/20 at 20:08

Posted in Uncategorized

A Growable Language Manifesto

with one comment

Warning: this is by far the largest and most action-packed post I’ve ever made. Grab a cup of [insert favored beverage here], sit back, and enjoy. If you get headcramp from reading this in narrow-column blog format, there’s another full-screen version here — but please return to this post to leave your comments!

I’ve posted recently about the dynamic versus static flamewar and about recent research in extensible languages. The more I think about these ideas, the more compelling they get. It seems clear to me that these ideas are synergistic and point in the direction of a new kind of programming environment — one which could potentially offer the ease of dynamic languages, the safety of static languages, and an altogether new level of extensibility (both for enhancing the type system and for allowing safe metaprogramming.)

So I want to lay out a manifesto here for a growable programming language. Or perhaps it’s more like a toolbox for language construction. Or perhaps it’s a framework for experimenting with extensible syntax and extensible analysis. In any case, here is the vision. At the end, I include extensive references to the research that’s inspired these ideas.

  • A growable language should be opt-in. It must support a graceful spectrum of usage styles. A growable language will necessarily be multi-paradigmatic, since it will be extensible with features from various fields of programming. The language should implement a dynamically-typed core on which all static analysis is built, to allow programmers a straightforward and lightweight syntax for prototyping.
  • A growable language should be increasingly powerful. It should support a rich and expanding variety of static analyses and dynamic checking, to give maximal benefit to the programmer who wishes to leverage these features. over time, as more program analyses become possible, a growable language should gracefully integrate them. A growable language must continually increase the expressive power of the programmer, both in terms of what the programmer can say and in terms of what the environment can help the programmer prove about their program. A growable language should have a powerful analysis framework as a foundational component, such that other analyses can share that basic capability; wherever possible, additional analyses should require only incremental effort by leveraging infrastructure already created.
  • A growable language needs a declarative metalanguage. Current languages do not define inherent mechanisms for syntax extension and for type extension. The syntax and the type system are both baked into the language’s compiler. A growable language needs to lift the specification level of the language itself to be both declarative and modularly defined, so that syntax and type analytics can both be expressed and implemented as layered extensions.
  • A growable language needs partial typing. Certain analyses are necessarily incomplete or even undecidable. A growable language should permit such type systems, and should be able to fall back on dynamic typing whenever analysis is inconclusive. This lets programmers work freely without having to continually meet the demands of the type system, yet supports graceful type annotation to enhance static safety at the programmer’s discretion. (Without partial typing, the opt-in goal cannot be met.) The language should ideally provide clear feedback as to when its analyses are conclusive or inconclusive, and ideally should identify the sources of inconclusiveness so the programmer can either annotate them appropriately or deliberately ignore them.
  • A growable language needs layered types. A growable language should be able to extend itself with primitive types, dependent types (e.g. data-dependent subrange types), traits or other parametric or abstraction-based genericity mechanisms, and multiple flavors of type qualifiers. Integers should be as much of a language extension as non-null types, tainted types, or range types. A growable language requires an extensible subtype lattice.
  • A growable language needs inferrable types. To avoid drowning in explicit type declarations, the language should be able to infer types wherever possible, and the programming environment should support controllable visibility for the inferred type information. Without inferred types and environmental support for controlling analysis visibility, a growable language cannot scale for users; being able to selectively ignore some or all of the (many) analyses is critical.
  • A growable language needs explicit, optional type annotations. An extensible analysis framework will be able to infer or deduce a great deal about the actual behavior of the program. But the actual behavior of the program may or may not correspond to the programmer’s intent. The programmer’s explicit annotations express the programmer’s expectations. A programmer might look at the analyzed annotations and make some of them explicit — perhaps they reflect properties of the code that the programmer considers important after the fact, and that the programmer now wants to enforce. Or a programmer might add explicit annotations during development, such that the system can confirm they are valid and warn when they are violated. Explicit annotations at module boundaries — whether programmer-generated or system-generated — are likely to aid in separate compilation and in module documentation.
  • A growable language must be efficiently implementable. As more language features are added — more qualifiers, more types, more syntax — the language must still be efficient and usable. This applies both to programs written in the language (which should have performance competitive at least with Java or the CLR) and to programming environments for the language. The latter requires aggressive attention to analytical optimizations and to multi-threaded analysis frameworks. As the language’s analysis structure grows, the language’s programming environments must be able to leverage multicore architectures to ensure consistent responsiveness for users. Moreover, the language should be continuously analyzing in the background; incremental feedback as the user edits should be available for all language features and extensions.
  • A growable language must have a unified internal representation. Concrete syntax, abstract syntax, type and name bindings, type qualifier propagation, type parameterization, dependent range type constraints, and logical queries over the program’s alias structure should all leverage a single internal representation of the program. This maximizes the reusability of internal language implementation code and ensures consistency in analytical derivations. Where multiple representations are necessary, the derivation rules must be clear and consistent.
  • A growable language must promote static metaprogramming. Fully dynamic metaprogramming — runtime extension of classes and objects with arbitrary code, or even unrestricted dynamic reflective access to arbitrary methods — is almost impossible to analyze effectively. To give a growable language’s extended type systems maximum exposure to the actual behavior of the code, static metaprogramming techniques must be definable, extensible, and compatible with the rest of the language’s structure. One would hope that the very extensibility techniques that implement the language itself would be usable for static metaprogramming.
  • A growable language must support diverse analyses. Some analyses are most naturally expressed as systems of recursive equations over an abstract syntax tree. Others can best be expressed as logical queries over a program’s alias graph. Ideally these could both be expressed naturally in the metalanguage.
  • A growable language must be analytically composable. This is likely the single most technically ambitious goal. Traditional compiler development involves subtle and explicit scheduling tradeoffs, layering multiple analyses through manual interleavings that can be fragile or non-optimal. A growable language with a declarative metalanguage needs an analysis engine that can automatically schedule multiple, potentially interleaved analyses, leveraging parallelism where possible to optimize non-dependent analyses. Achieving this goal will be immensely difficult, but proportionately valuable. Interestingly, here is where the metalanguage itself will require many of the same extensibility properties as the language it describes; meta-level closure — implementing the metalanguage using the language itself — will be a holy grail for this language design.

Is the above language even possible? Is it too much of a stretch — particularly the “unified internal representation” and “analytically composable” goals? Maybe so. I’m definitely not an expert at programming language implementation; the only compiler I ever wrote was back in high school. So this may be ridiculously unrealistic in whole or in part. I welcome feedback on which areas of this manifesto are more or less plausible.

Overall, consider this my stab at answering Paul Graham’s challenge to ponder the hundred-year language. Given current trends in programming language development, it seems that languages of the future will transcend being “languages” as we know them and will become more like unified environments for language creation and extension. Arguably, this vision has a lot in common with intentional programming, which doesn’t bode well, since the intentional guys have been in stealth mode for almost fifteen years and nothing has publicly come of it. But that doesn’t mean the general direction isn’t interesting, any more than the slow progress of Chandler means that a unified and flexible personal information manager isn’t worth pursuing.

I promised references. Here they are:

  • opt-in — Gilad Bracha’s pluggable type systems paper is the origin of this goal. Bracha forcefully posits that static type systems are all necessarily incomplete and that dynamically typed languages have necessary flexibility. Meijer makes a similar point in his static where possible, dynamic where necessary paper. I’m not clear that Bracha’s extreme view — that all static analysis must be kept out of the language kernel — is the correct one, given the potential performance cost, but I suppose RPython provides an encouraging counterpoint.
  • increasingly powerful — There are increasingly many varieties of static analysis being developed primarily for Java. One recent paper on http://www.cs.umd.edu/~jfoster/papers/oopsla07-uno.pdf points out that its framework could straightforwardly be implemented on top of other analyses with similar intraprocedural resolution. The BDDBDDB framework has already been used for implementing taint analysis, and the JastAdd system for non-null Java type inference. In general it seems there is a lot of opportunity for shared infrastructure here. Also note that support for excellent error messages and great visibility into analysis results (and analysis failures) will be critical for usability. See Grimm’s paper titled Systems Need Languages Need Systems for some forceful advocacy here.
  • a defining metalanguage — Some good examples of metalanguages for syntactic language description are the OMeta pattern-matching language for executable grammars, Gilad’s executable grammars in NewSpeak, and the Rats! extensible parsing system. A good example of an extensible language for static analysis is the JastAdd extensible Java compiler with its support for defining rewritable circular reference-attributed grammars… they implemented Java 1.5 generics as a modular declarative compiler extension, which proves their point to me, anyway!
  • partial typing — The two best examples of this that I know of are the gradual typing work of Siek and Taha, and the hybrid typing for undecidable type systems work of Flanagan, Freund, et al. In both cases, a static type system is enhanced with a generalized type (named Dynamic or “?”), which is inferred to be a more specific static type where possible, and otherwise cast at runtime to preserve dynamic type safety.
  • layered types — The already-mentioned JastAdd system is perhaps the best example of a structure which permits layering additional analyses. The extensible Java compiler Polyglot is another.
  • inferrable types — My original thinking about this entire line of research originated in a blog post from a couple of months ago where I realized that some implementations of type qualifiers — for example, a “tainted” type qualifier in C++ — would ripple through the whole program due to mandatory explicit static typing everywhere. It’s noteworthy that many type qualifier analyses for Java are not based on explicit syntax. For example, the taint analysis based on the BDDBDDB framework does not require explicit propagation of tainted or untainted declarations, yet it derives such information throughout the program’s structure. An environment which made the results of that analysis visible — and traceable — at every program point would let the programmer see the flow of tainted values without having to explicitly declare them.
  • explicit, optional type annotations — Programmers must also be able to add explicit qualifiers, since the programmer’s intent may or may not match the analysis; the analysis may be incomplete and the programmer needs to provide more information, or the analysis may be consistent and the programmer wants to declare that they confirm it and want it to be enforced at that location (e.g. if the program changes such that the property is no longer true there, the language would signal an error). The programmer’s explicit intent and the analyser’s implicit understanding should be able to be flexibly cross-checked. I’m not aware of any inference systems that support this fully; they seem to be either purely inference-based (e.g. JQual) or purely annotation-based (e.g. a C++-based type qualifier system discussed in the “Extending Type Systems in a Library” paper from LCSD ’06).
  • efficiently implementable — This is obviously enormously difficult, insofar as analyses can in general be interdependent. There is a great tension between layering analyses (for separability) and weaving them (for mutual dependence and synergy). See the “analytically composable” goal below. In general, I wouldn’t be surprised if aggressive parallelization of a language analysis / compilation framework required software transactions to support optimistic and incremental analysis by multiple threads.
  • a unified internal representation — I mean something along the lines of Grimm’s declarative extensible syntax trees, a concept proven by his weaving of Java and C typechecking into a single system. The JastAdd framework is another example; there is no separate symbol table in JastAdd, since name bindings become reference links in the abstract syntax tree (which is really more of an abstract syntax graph). Note that JastAdd’s own declarative language for extending the syntax tree is fundamentally similar to open classes, in that subsequent extensions can directly modify the structure of already-defined syntax node classes. This seems to inhibit modular development of language extensions, but modular language extension development is really hard anyway.
  • promote static metaprogramming — This goal is about ensuring the entire program text remains analyzable, and about permitting domain-specific languages to be implemented in the same structure used for extending the base language. See OMeta’s SQL extensions or C# 2.0’s language-integrated queries which reify some expressions as syntax trees visible to the runtime system. The Google Web Toolkit’s support for extensible code generation is another example, as is the RapidMind system for creating parallel compute kernels from C++ code. Finally, there’s the RPython system which creates a “metaprogramming startup phase” for Python programs, followed by a static compilation phase yielding 100x speedups. Interestingly, this whole goal contradicts Paul Graham’s 2001-era view that “true macro systems aren’t compatible with static type systems.”
  • support diverse analyses — The best two already-cited examples here are the JastADD grammars formalism and the BDDBDDB Datalog-based analysis specification. These are radically different but potentially very synergistic. I’d be fascinated to see whether there’s some deeper commonality between them….
  • analytically composable — The JastADD framework seems the best example of a declarative structure that supports automatic weaving of multiple analyses. For evidence to this effect, consider that the JastADD folks claim that the Polyglot team is reimplementing their framework in JastADD to avoid the difficulties of scheduling dozens of analysis passes.

I plan to start experimenting with some prototypes of an Eclipse plugin for an extensible language framework along these lines, likely starting with something much like OMeta and extending it with a JastADD-like rewritable grammar formalism. This will be open source all the way. I would enthusiastically welcome all pointers to similar projects, all interest in helping with such a framework, and all critical comments on all or part of this manifesto!

(Disclaimer: our family will also be moving out of our house in the next three months, so progress may well be slow 🙂

Written by robjellinghaus

2007/12/04 at 19:11

GWT presentation tomorrow!

leave a comment »

I’ve been working on a truly monster blog post, nothing short of a manifesto for a growable programming language. It’s about four pages long now and roughly 90% complete. All I have to do is Google up the two dozen reference links.

But I can’t quite get to it tonight, because tomorrow is my presentation at the GWT conference and I’ve been tweaking my slides semi-compulsively.

So, hopefully I’ll see several of you tomorrow at the conference, and stay tuned later this week for my Big Fat Language Rant! Your patience is very deeply appreciated.

Written by robjellinghaus

2007/12/04 at 05:33

Posted in Uncategorized

Gaming, Turkey, and Burnout

leave a comment »

(Warning: relatively low technical content ahead!)

Rats, missed another blog-posting week here. A week ago I finally got my GWT conference presentation done. I was rather nervous about whether I was hitting the right technical level, so I mailed it to a few GWT team members, and Bruce Johnson (the team lead) wrote back and said, basically, “It’s perfect.” Thanks, Bruce! Eased my mind tremendously. The conference is coming up next week.

Then on Tuesday, Mass Effect shipped, and I was instantly lost in space. I’ve gone back and forth on whether to talk about gaming here, but this title pushed me over the edge. I’ve been a computer gamer ever since I’ve been a computer user — my very first experience with a computer was playing Spacewar on a PLATO timesharing terminal at my friend’s father’s college. And gaming has become a true lifelong hobby. Mass Effect is a great example of why that is.

Programmers inherently love systems. A truly intrinsically motivated programmer will spend hours thinking about how something fits together, and more hours tinkering with it and seeing what happens. A great game also has a systemic internal structure that rewards tinkering and exploration. So it’s natural that so many programmers are gamers.

Moreover, many programmers are thrilled by advances in technology. The more powerful our computers become, the more we can do with them. And computer games are definitely the most widely visible hardware-pushing applications. Just take a look at some of these screenshots. A $280 XBox 360 can now do real-time facial animation that looks a lot better than ANYTHING being done five years ago (real-time or pre-rendered). And it qualitatively changes the nature of the game, when your character and the zany aliens they’re talking to both have facial emotions and lip-syncing that are so much closer to realistic that you can almost lose yourself in the illusion. I’m not claiming that Bioware’s crossed the uncanny valley just yet, but they’ve definitely taken huge strides in that direction, and they’ve hooked me but good.

I expect to be a gamer for the rest of my life, since games just keep getting cooler and cooler as hardware gets more and more powerful and we learn more about what to do with it. It’s a perfect hobby for a systems-oriented, game-addicted technophile.

So Mass Effect took over my after-the-family’s-asleep life, and stole my blogging cycles last week. Thanksgiving was also pretty hectic — we cooked an 18-pound turkey for our church get-together, which took me all day while my wife juggled our three-month-old and our (almost-)three-year-old. That left us pretty wrecked and we laid low the rest of the weekend.

Meanwhile, on the hacking front, I have continued to feel blocked by the whole Seam 2 broke my code issue. Actually, technically, it’s that Seam 2 broke the G4JSF code. That code was originally written by the Ajax4JSF team, but they have abandoned it. So the question for me is, how motivated am I to fix it? (And, potentially, to continue fixing it as Seam, JSF, and GWT continue to evolve?)

I originally started on this whole Seam / GWT / JSF project because I had ambitions to create a peer-to-peer distributed blogging system. I made a lot of progress on that system (at least as far as creating a Seam-based model for representing version trees with Java persistence, a la Mercurial). Then I wanted to start on the UI. Which led me to GWT, and the realization that the existing G4JSF library didn’t couple gracefully with GWT RPC. So I patched GWT, and then G4JSF, and that led me to presenting to the GWT team at JavaOne last year, which then got me the opportunity to speak at the GWT conference next week. All of that was quite unexpected and quite appreciated — particularly the speaking opportunity!

BUT, going back to my original project, the peer-to-peer distributed object system lost its mojo somewhere over the last year. It led me down the GWT / Seam / JSF path, which was really interesting and connected me to the open source world like never before… but somehow the journey became the destination, and the original goal no longer feels as interesting. Frankly, I’m not feeling very enthusiastic about being the sole owner of the G4JSF code base, given the evident cost of keeping it current and given the lack of other support from the JSF community. Maybe having a second baby also cut my energy level.

In order to avoid burnout I need to work on the projects that are most interesting to me, which right now is looking like prototyping some extensible programming language ideas that have been burning a hole in my brain for the last two months.

So, I’m going to set aside the G4JSF work and I’m going to leave the Seam/GWT/JSF integration project in its current state. I am more than willing to work with anyone (at Red Hat or elsewhere) who wants to pick it up again and fix it up to work with Seam 2 (and JSF 2 when it comes along), but I can’t drive it further on my own. Anyone who was using that integration library and who is interested in fixing it, feel free to email me (rjellinghaus at gmail dot com).

This blog will shift focus away from Seam/JSF and towards programming language research and the experiments I’m doing. Hopefully that’ll still be interesting to my loyal readers — I’ll do my damnedest to make it so! Because I’ll tell you one thing, it’s pretty fascinating to me 🙂

Written by robjellinghaus

2007/11/27 at 05:45

Posted in Uncategorized

Android hits the fan

leave a comment »

Unless you’ve been buried under a boulder, you’ve heard about Android. It’s nice to know what my secretive Google mobile JVM guru friend has been working on all this time 🙂

The Android forum is awash in C / C++ developers ranting about how lame Android is because it doesn’t support raw access to the hardware. It’s too bad, really. I feel for them, and I agree: Android apps are going to be slow and clunky compared to native apps.

But Google’s making a play to build a whole new kind of mobile ecosystem here. Google’s betting on increasing mobile CPU power (certainly an excellent bet), and Google knows that if Android develops a personal-computer-like reputation for flakiness, it will fail and fail bigtime. I would argue that a big reason no mobile platform has really taken off yet (besides crazy licensing costs) is that native apps are simply flaky, and the more of them you run, the flakier your hardware gets. Since Android is trying to greatly increase the hardware diversity of Android devices, allowing raw native access combined with open developer access would rapidly drive the stability of the system to zero.

Native developers hate to hear this, because they spend their lives tuning for performance and chasing crash bugs. I’m sure many of them do write good solid apps. But I’m also sure that making native code crash-proof, especially across a wide spectrum of hardware, is very, very hard to do. And if you want to throw your platform open to anyone who wants to ship an app for it, you’re guaranteed that many if not most of those people will lack the uber native skillz to achieve that kind of cross-platform stability.

So HOORAY GOOGLE! for making Android a fully managed platform! Note also that Microsoft sees the writing on the wall; they’re working on a fully managed operating system, for crying out loud.

End rant. The most interesting thing I’ve yet learned about Android is that it is fundamentally trying to end-run around Sun’s IP restrictions on Java ME. Stefano Mazzocchi breaks it down in exemplary fashion. Super cool! It’s going to be really strange to see Sun and Google at each other’s throats, but given how close the two companies are, and given how heavily Android leverages Java-the-language while totally subverting Java-the-runtime, AND given how anti-patent-war Sun is trying to be, I hope for some kind of peaceful reconciliation there. Microsoft, on the other hand, will go apeshit. Let the fireworks begin!

Written by robjellinghaus

2007/11/14 at 01:14

Posted in Uncategorized

GWTJSF broken with Seam 2, sorry folks!

leave a comment »

So I’ve gotten past a number of the issues I blogged about previously, and I now have a Tomcat-only no-EJB3 version of the Seam blogging example. I’ve tried rolling the GWTJSF code from my original example back into it, and it looks like Seam 2 has thrown another wrench in the works.

As Chris Alfonso at JBoss warned me, Seam 2 installs the SeamPhaseListener by default. The Seam/GWTJSF integration as it previously existed needed its own phase listener, as explained in my article on the topic. This delegating-PhaseListener technique seems to be impossible in Seam 2. (Unless I’m missing something.)

With the GWT conference breathing down my neck, I may need to sideline this for a while until I get a fallback presentation together — I was hoping to be able to demo GWT 1.5 (if it gets done in time!) with JSF 1.2 and Seam 2, but I can’t count on that at this point, there are only four weeks to go and I don’t have the hacking time I’d need. So it’s Plan B time. I’ll take a week or so and get the presentation together with the previous version of the code, and then I can pound on Seam 2 some more.

Also, it looks like the GWTJSF code has officially been left behind in the Ajax4JSF 1.1.1 code tree, which has been rolled into the RichFaces project — except for GWTJSF, which is nowhere to be found in the RichFaces code tree. GWT can definitely be considered a competitor to RichFaces, so I guess I see why JBoss isn’t supporting GWTJSF, but still it’s a shame. It’d be great to see some more synergy there, but I’m not sure how to bring it about. (other than blog about it and rock the boat a little 😉

Anyway, sorry to those who’ve been wanting to use GWTJSF with Seam 2 — it’s going to be a longish road. All help very much appreciated if anyone else has cycles to hack on this with me!!!

Written by robjellinghaus

2007/11/08 at 06:08

Posted in GWT, Java, JSF, Seam

Friendship and fraternal aid

leave a comment »

Last week I griped about some hassles I was having with Seam 2, Java 6, Tomcat, and JBoss Embedded. I grumpily grouched about the grim gloom of an open source world where things break and people don’t get along very well, and how non-fun it is.

And hey presto, what should happen but two Red Hatters read my kvetching and chimed in with some downright helpfulness. First, Jason Greene mentioned this workaround for the bizarre Java 6 ClassNotFoundException I mentioned. Seems there is a magic JVM flag you can provide to revert to the Java 5 classloading behavior if it causes you too much trouble. That’s good to know, and I appreciated the clue.

Second, Chris Alfonso — who’s been asking me when I’m going to get around to fixing my GWT/JSF/Seam demo to work with Seam 2 — said that he’s got a Maven 2 version of the GWTJSF demo building as an EAR that runs under JBoss with EJB3. Which is cool, because I now have a plain old Hibernate version of the Seam 2 blogging demo that deploys under vanilla Tomcat, so it’s nice to have both flavors. (Chris, can you send me your version? I’d like to poke at it some — I won’t post it without your say-so.)

So that’s the great thing about the open source community — it is a community, and people offer each other helping hands. Thanks for brightening my week, guys! You put the fun back in 🙂

Written by robjellinghaus

2007/11/06 at 04:19

Posted in Java, Maven, open source, Seam