Java TV MHP

Java在有限电视终端应用称为Java TV，主要也是线程（相当于xLet）和JMF结合，非常类似Java ME和Applet。

我一直有一个困惑，SUN将客户端框架细分得这么详细，就产生一个抽象共用的问题，比如客户端当前受到Web AJAX脚本挑战，以前客户端表现层是向Swing看齐，比如JSF，结果现在大家都是在向Web客户端看齐，那么以前的看齐思路就费了，包括JSF，我看这是SUN不得不卖掉一个原因，开始老糊涂，自大，总是以为自己领导市场，虽然它没从市场中赚到钱。

现在所有客户端向Web看齐的趋势下，Java ME 移动客户端也在发展，如Java FX可以看成JME移动在向Web看齐下的一个新方向，那么cable有限电视终端呢？好像给忘了，这就是细分的坏处，虽然都是打着Java一次编写，到处运行的旗号，但那只是底层概念，现在用户关心的是DSL，就是问题的描述工具，而不是问题的解决工具。

现在flex/AS3在对待流媒体处理上已经占据先锋，看看互联网YouTube或土豆网 56网，哪个不是采取后台flash media server，前台flash player格式，比如基于Spring的开源流媒体服务器Red5。有谁浏览器是使用SWING/Applet + JMF方式呢？

还有那个OSGI，号称服务即插即用，但是复杂程度和当初EJB有一拼，JNDI等等都是不可缺少的基础知识，其实只要是POJO，你根据Evans DDD建模就形成一个POJO服务，ＰＯＪＯ就可以穿透网络，非常简单，何必为了服务而做一个服务框架呢？这些都是学究们学院派搞的表面文章，是花瓶，企业如果把架构重心压在它上面可就危险了，这也是有时企业相信微软的原因，没有学究味，没有陷阱，都是实在的，但又不甘心为微软打工。

OSGI就是为了服务而搞的一个复杂碍事的框架，就像当初为了分布式搞个ＥＪＢ，现在都讲究组件细分化，都开始拆了，ＪＢｏｓｓ拆了，Spring也在拆，当然Jdon框架从2005年一开始就倡导拆，因为有了IOC DI，什么不能拆，OSGI因为当初没有IOC DI，所以才搞个运行分离，没有IOC的日子它很松耦合，但是有了IOC后，它为松耦合付出的复杂代价太高。真不知道为什么有那么多人去捧OSGI臭脚。

回到Java TV这个客户端上来，也该向IOC DI靠拢，至少它里面的ServiceContext场景就可以使用一个IOC容器来替代，什么年代还在用工厂，现在SUN被卖了，在忙着分家算钞票，也没有时间来更新Java TV API了，根本就是方向走错了，客户选不用这么细分，只要用脚本替代线程，Html/SVG/XML替代图形或流媒体就可以了。

http://www.interactivetvweb.org/tutorials/javatv/javatv_intro
[该贴被banq于2009-05-07 15:28修改过]
[该贴被admin于2009-05-07 15:41修改过]