I don't think it's "pure lazyness" that there are many Java web frameworks, but rather that the official stuff sucks (yes JSF, I'm looking at you) and it's just plain hard and time-consuming to track down and evaluate existing stuff. Wicket and Stripes would be considered superior de-facto standards today but that's an entirely different situation than 3-4 years ago. The "just use Ruby" argument is odd too, I recall Ruby and Rails being dismissed and ridiculed in the podcast around that same time frame.
Microsoft does use and ship a lot of applications based on .NET: IIS7, Visual Studio, Media Center, Expression, Blend, Dynamics CRM, Axapta/ Navision, Silverlight, Exchange 2007, BizTalk Server, SQL Server etc. What's important to note though is that .NET is very much about interoperability with the native platform, so calling a shared library .dll or .so is as easy as declaring an import in Java. This is in stark contrast to Java's "thou shall do everything in Java" which doesn't really hold water anyway. Look no further than NetBeans which ships with native stuff just because we don't have a System.restart (Class mainclass). Also, I'm not sure if Tor got the point about loosely coupled events Bruce and Joe were trying to explain. A component can be considered a super-object, encapsulating a problem area but without context. It's up to the developer to hook up data and messaging to have it do its job in some specific context. While you can kinda simulate that abstraction in Java, what you won't get is the composability and toolability between components. That's primarily due to the fact that events are interface based and often needs adapters, so two partners needs to agree on an intrinsic contract (observer wire up) whereas in C# all you need is signature compatibility. Think of it as a lamp: In Java you can ONLY plug in the exact same 25W incandescent bulb with E27 socket. In C#, you can plug in whichever matches the E27 socket which includes newer 11W fluorescent or 7W LED bulbs and probably the OLED bulbs of tomorrow. One may also simply choose to listen in on certain types of event being fired globally, in a message bus fashion and grab only what's interesting. Think of it as being able to write an AWTEventListener but not just being restricted to trap only window/mouse events. On the actual JavaFX topic. Does ANYONE see a potential to expand JavaFX beyond the (IMHO narrow, risky and uninteresting) RIA DSL level? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
