Scala语法用惯了，快忘了怎么写Java了

vii779 2010-04-29

现在基本上不用Java，一直用Scala开发。
偶尔写点Java代码，突然觉得不习惯了

每一行常忘了写;
声明变量常忘了声明类型
常忘了写return
访问数组不自觉的用()
声明方法常忘了声明返回类型

也许Scala语法可以写的很简单，让自己不自觉的变懒了，不知道大家有没有这样的体会。

NumbCoder 2010-04-30

你公司是什么项目，用scala开发的？

vii779 2010-04-30

前端Flex，后端Scala +Blazeds+Spring+Hibernate
服务全部用Scala写，大部分底层也改为Scala实现。Hibernate太难用，用Scala做了一下封装，并提供DSL方式的查询语法，用起来很方便。
以后想替换掉Hibernate,暂时没有其他合适的选择，时间允许的话，想用Scala封装一套ORM，Hibernate搞的太复杂，用起来也不方便，HQL还要拼字符串，复杂的查询就别指望了，性能就更不用说了。

总的来说，Scala确实带来了开发效率的提升，就是IDE还不成熟。

kula 2010-05-01

你们将scala用在实际项目上了？太宝贵了! 能否详细介绍一下scala在实际项目上的经验？包括觉的爽的和觉的不爽的

sirxenofex 2010-05-02

scala是好东西

jamesqiu 2010-05-03

Scala，值得学习和使用；
楼主有兴趣可以把自己的实际项目使用经验写出来，一定是很有价值的资料。

vii779 2010-05-04

项目早期采用BlazeDS+Spring+Hibernate的模式开发，开发过程中写服务的时候感觉用Spring的HibernateTemplate不是很方便，虽然spring很好的替你处理了Hibernate的Session生命周期管理和事务，但是象下面这样的代码

 public void insertUser(final User user) { 
        getHibernateTemplate().execute(new HibernateCallback() { 
                public Object doInHibernate(Session session) throws HibernateException { 
                    session.saveOrUpdate(user); 
                    return null; 
                } 
            }); 
    }

写起来总觉得不爽。服务中大量使用HQL查询，但是HQL需要拼凑字符串，就算使用Hiberante的Criteria ，代码写起来可读性太差。早就想封装一套比较好用一点的DAO框架，在看过了一些第三方封装之后，这个念头就打消了，个人感觉不论再怎么封装，限于Java语言的表达能力，用起来也不是简便的。适逢scala2.7大力推广时期，有兴趣了解了一下，感觉比较适合来封装一套DAO和查询语法的DSL，便着手尝试了一下，期间经历了一些波折，主要对scala语法的不太熟悉，以及与java一些类库的相互调用不太方便，费了一些时间。最终封装出来的效果还是比较理想的，用起来也感觉比较方便，举两个列子：

更新用户信息

 val user = User(123)
  user.name = ....
  .....
  user.UPDATE

一个复杂的查询

new Q_Task {
      SELECT(*,
        status, priority, actor.name, creator.name,scheduled,
        messageBox.*, milestone.name, milestone.dueDate,
        sharePolicy.id)

      WHERE {
        actor.id === ...
        deleted === false

        if(...){
        OR {
          status === D_TaskStatus.RUNNING.id
          status isNull
        }
        }

        OR {
          scheduled === false
          AND {
            scheduleStartTime.isNotNull
            DATE_DIFF(scheduleStartTime, new Date) < 0
          }
        }

      }
      ORDER(modifyTime.desc)
    }

查询语句完全是类型安全的，字段可以语法提示，拼写错了，在编译期间就可以检测的到，WHERE里面可以写的很复杂，可以根据if条件来动态的生成WHERE条件项，这些用Java语法是很难做到和实现的。

因为scala是新生事物，不敢贸然大规模使用，开始尝试一两个小服务用scala来写，借助于scala语法的便利性，原来java 十句话可以完成的逻辑，scala三四句就可以搞定了。初期是java服务和scala服务共存的方式，运行过一段时间后，感觉scala写的服务也比较稳定，不存在系能上的问题，开始大面积用scala来写服务，包括把原有的一些用java写的服务重构为Scala实现（用scala写的比较精简，便于以后维护）。现在，几乎不愿意用java来写服务代码了，语法太罗嗦，开发效率也不高。包括一些底层的框架，能不用java就尽量用scala来写，写起来还是比较省心的。

说一些scala使用过程的碰到的问题以及一些可能解决办法

1 比较高的学习曲线，没有接触过函数式编程概念一上来很容易被scala那些怪异的操作符和语法搞晕，而且又多出来很多新概念，消化吸收需要花费一段时间。语法太过灵活，用好了事半功倍，用烂了祸患无穷。个人感觉值的投入精力学一下，用好了，会带来开发效率的提升。

2 与原有的java类库不象宣传中的那样可以完全方便的互操作，scala中的集合框架自成一套体系，当访问java集合类的时候需要转换一下才能方便使用，因为大量的java第三方库都是使用的java的集合框架，这一点用起来还是比较麻烦的，不过scala2.8通过隐式转换已经很好的解决了这个问题，使用2.7的话，自己封装一下做一下隐式转换也是可以解决这个问题。

3 序列化支持的不好，在远程服务调用模式下，需要把服务端的一些模型类序列化到客户端，标准的javabean没有任何问题，用scala写模型的话，会用到一些scala的集合类，这些都不太好序列化。在和BlazeDS集成的时候，通过扩展BlazeDS的序列化能力，碰到scala集合类，转换为java的标准集合类可以解决这个问题。

4 编译器的编译速度还有待提升，做一个小项目，写几十个scala类还感觉不到编译速度慢的问题，如果是上百上千个scala类，编译速度就成大问题了，可以把项目按依赖关系拆成几小块，单独编译，只编译变化的部分。

5 ide的开发环境还不是很成熟，官网推荐的那三个ide各有所长，但总的来说离成熟的标准还有一段距离。早期用eclipse很长一段时间，后因内存耗用和频繁的界面卡死等问题，改用IDEA Community版，代码提示没有eclipse的全，但比较稳定，可以自动导入，重构，格式化，这些都是eclipse欠缺的。对netbean不太感冒，没有正经用过，代码提示，重构等做的也可以，因项目比较大，scala类比较多，netbean用ant脚本来编译，改动一处，所有的类都要重新编译一遍（也可能是对netbean不熟，或许有选项可以支持增量编译吧），速度实在不能忍受。

6 scala中大量使用闭包，而scala闭包是通过java内部匿名类的方式来实现的，由于java虚拟机的限制，内部匿名类的名称是根据代码行号变化的。开发期间如果想通过字节码热部署的方式，来不重启虚拟机，实现快速开发是不太可能了，除非你的逻辑里面不使用闭包，这几乎是不可能的。

7 scala 和 spring的集成还是比较顺畅的，scala写的服务类中，通过@autowire方式可以方便的注入java的服务类，需要spring3.0版本

8 scala 中还没找到比较好用orm框架，目前还是依赖hibernate，又对其做了一下封装。lift略了解了一点，感觉作者封装orm的思路和自己想法相去甚远，也就没有在深入了解下去，有实际用过的可以发表一下感受。

9 因为scala过于灵活，对于同一个项目组来说，最好约定一个通用的规范，否则真会天下大乱了。

10 scala还没有完全实现内置的反射机制，想利用反射来做一些高级特性方面的应用，还比较困难。

11 scala2.8 不兼容2.7编译后的字节码，即便2.7的代码想用2.8来编译一下，由于语法上的一些差异，有些地方还需要做一些重构，现在想把2.7的代码升级的2.8就比较头疼。

12 如果做一个新项目，建议还是完全用scala来做，java+scala混合编程的方式感觉还是不太方便，java能做的，scala完全都可以做到。用scala会牺牲一点性能，但差距不是太大，况且性能的问题，需要的是合理的系统架构，有效的利用缓存机制，而不仅仅只靠语言本身的执行速度。