|
锁定老贴子 主题:[转]没落的JAVA社区
精华帖 (0) :: 良好帖 (0) :: 灌水帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
最后更新时间:2007-04-20 关键字: 没落的JAVA社区
刚刚看到一篇文章,觉得可以更加深入地去探讨一下,特地转过来,借用JAVAEYE的人气,大家各抒己见一下,希望不会被隐。
作者:Cherami 原文地址:http://www.jiehoo.com/%e6%b2%a1%e8%90%bd%e7%9a%84java%e7%a4%be%e5%8c%ba.htm 引用 感觉原来的几个Java社区日益没落,当然这个和Java世界的消沉有很大关系,这两年已经看不到什么大的Java新闻了,特别是对于Java开发人员而言的大新闻,原来Spring带来的各种火热的讨论也已经沉寂下来,Java世界似乎已经毫无新意了,现有的任何Java开源产品或者组件所能够带来的开发效率的提升都无法和新的脚本语言匹敌(我想这也是为什么JavaEye会使用RoR重写的一个重要原因,同时也是Robin转向研究Ruby的重要原因),在可以预见的一段时间以内,都不太可能出现一颗真正的银弹。但是我对于Java并没有丧失信心,因为Java依然拥有广大的开发人员以及丰富的开源产品和组件,现在所缺少的是一个真正简单并且易用的快速开发框架,提供Java Web开发所必备的大部分功能,开发人员所需要关注的仅仅是创建数据库和业务逻辑代码(不需要开发常见的CRUD操作代码),当然开发人员也不需要太多的配置就能够让整个系统跑起来(不需要Spring的Bean配置、Struts的Action配置、Hibernate的配置)。 就我个人感觉,完成这样的一个框架并不是很难,困难在于Java世界应该引入更多的规则而不是可配置,最起码可配置是第二位的需求,但是Java世界的人似乎已经习惯了配置,习惯了对象间的关系是在运行时通过读取配置文件来确定,也习惯了通过读取配置文件来组装系统。 对于多人并行开发的系统而言,Java的强类型约束无疑对于代码的可维护性和可读性更加有利,但是基础设施的严重缺失使得代码的开发难度加大,代码的重复性也因此加大(对于一个简单功能,由于Java本身没有提供,只能自己写、寻找其它的开源组件或者公司自己的框架提供,但是很多新来的人不知道已经有那样的功能,即使知道也是拷贝一份代码稍加修改)。 我相信现在有很多人都有和我一样的想法,也有很多人在做,包括EasyJF(简易Java框架),问题是他们并不能真正的普及,他们的设计者和维护者并不能得到大部分人的认可,而像AppFuse,SpringSide, JdonFramework这样拼凑起来的快速开发框架也不能解决问题(还是需要大量的配置),我期望中的真正的Java快速开发框架是完全重写的基于规则的框架,不需要配置或者只需要极少的配置(例如数据库配置),具有强大的Model和View的转换能力,可以很容易的将POJO或者POJO集合转换为各种页面组件(表格、树),不需要POJO和数据库的映射配置,不需要写CRUD代码,URL请求自动映射到Action。。。。。。 声明:JavaEye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
|
|
| 返回顶楼 | |
|
最后更新时间:2007-04-20
海天版人气更旺
|
|
| 返回顶楼 | |
|
最后更新时间:2007-04-20
引用 但是基础设施的严重缺失使得代码的开发难度加大,代码的重复性也因此加大(对于一个简单功能,由于Java本身没有提供,只能自己写、寻找其它的开源组件或者公司自己的框架提供,但是很多新来的人不知道已经有那样的功能,即使知道也是拷贝一份代码稍加修改)。 |
|
| 返回顶楼 | |
|
最后更新时间:2007-04-20
引用 具有强大的Model和View 的转换能力,可以很容易的将POJO或者POJO集合转换为各种页面组件(表格、树),不需要POJO和数据库的映射配置,不需要写CRUD代码,URL 请求自动映射到Action。。。。。。 至少这个如今的java应用已经可以实现了,虽然很大程度上是靠ria的助力。 |
|
| 返回顶楼 | |
|
最后更新时间:2007-04-20
引用 具有强大的Model和View 的转换能力,可以很容易的将POJO或者POJO集合转换为各种页面组件(表格、树),不需要POJO和数据库的映射配置,不需要写CRUD代码,URL 请求自动映射到Action。。。。。。 像这样的页面组件,已经有一些开源的WEB框架提供了,就像JSF(虽然被大家批得比较差),Tapestry,Click Framework,其实现在借助于Spring,在开发一些中小型系统时,速度已经快了不少,使用Spring的DAO支持,使用Spring的事务控制等,而这些,基本上写过一次之后,稍微改动就可以了,程序员关照的,也基本上是关注是业务层。 |
|
| 返回顶楼 | |
|
最后更新时间:2007-04-20
我习惯配置文件是因为:找寻配置文件快于找寻java文件。
|
|
| 返回顶楼 | |
|
最后更新时间:2007-04-20
dada 写道 引用 但是基础设施的严重缺失使得代码的开发难度加大,代码的重复性也因此加大(对于一个简单功能,由于Java本身没有提供,只能自己写、寻找其它的开源组件或者公司自己的框架提供,但是很多新来的人不知道已经有那样的功能,即使知道也是拷贝一份代码稍加修改)。 呵呵,“新来的人”,问题就在这里啊,为什么他们会“不知道已经有那样的功能”呢?如何能让他们都知道已经有那样的功能呢?如果他们都很快就可以了解的话,团队的开发效率会提高吗?代码会比之前有更好的规范吗?很多存在一定时间的软件公司都应该已经积累了一些经验、原始代码、规范、现成的做法,这些累积的知识可以在团队内有效的传播吗? 似乎,为这些问题寻找答案,已经和这个团队使用java或ruby, python或是whatever language都没有关系了,这几乎纯粹的关乎团队管理、沟通方式以及知识传递的效率。 |
|
| 返回顶楼 | |
|
最后更新时间:2007-04-20
Java社区还说不上没落,JavaEye不用Java开发并不意味着JavaEye不是Java社区了。除非JavaEye改名称,把“Java”字样去掉。
Java编程语言的设计出发点和Ruby是截然不同的: Java从工业应用的角度出发,处处添加限制,极力避免程序员误用导致的应用程序问题; ruby是从程序员人本角度出发,处处添加便利,极力让程序员找到编程的乐趣。 Java在web开发领域,从单纯的技术角度来说,没有什么希望拼过ruby,不光是因为编程语言的先天不足,也因为Java社区太商业化,出不了完全摆脱现有框架束缚的类似DHH的天才。 当然,我也说过企业应用开发主流还是Java,ruby不会成为主流。 |
|
| 返回顶楼 | |
|
最后更新时间:2007-04-20
还是有人投了隐藏帖哦,看来JAVAEYE不适合转载,哪怕是好文章哦,呵呵。还是robbin一句话点破了
引用 编程语言的先天不足 由于JAVA不是一种动态语言(尽管已经加入了动态语言支持),所以由于语言的特性,不大可能做到像ROR那样的快速,天才是有的,但天才也是站在前人的肩膀上的。 引用 我也说过企业应用开发主流还是Java,ruby不会成为主流 JAVA不会没落,但已不再如日中天了吧。 |
|
| 返回顶楼 | |
|
最后更新时间:2007-04-20
rainlife 写道 JAVA不会没落,但已不再如日中天了吧。 要看从什么角度来看了,从技术角度?从商业角度? 不同的行业不同的角度你都会得出截然不同的答案。 |
|
| 返回顶楼 | |












