java程序员为什么使用Groovy

Groovy是一门基于JVM的脚本语言。它在兼容Java语法的同时，借鉴了Ruby、Python等语言的特性，有自己一套简洁而灵活的语法。同时，运行在JVM上也意味着它也可以使用Java语言编写的库。这两点结合，让Groovy极其适合编写Java代码的测试脚本。

选择Groovy作为测试脚本的语言的原因：

Groovy基于JVM，这使我能够调用产品的Java代码，也能够调用Java标准库里的代码。除些之外，还可以通过Maven或Gradle使用大量的第三方Java库。

Groovy是动态语言，扩展了Java的容器类，提供了完善的函数式编程和元编程支持。这让我们可以写出简洁而富有表现力的代码。

Groovy提供了大量的语法糖。与Java自身繁冗的代码相比，这些语法糖大大节约了我们编写脚本的时间，减少了我的脚本的代码量。

然而，Groovy在带来上述三个优点的同时，也会带来有相应的缺点：

效率问题。Groovy作为运行在JVM上的动态语言，运行效率是低于Java的。虽然可以用@CompileStatic注解来静态编译一些类以提高效率，但这样又会失去Groovy的一些动态语言的特性。

语法过于灵活，运用不当会降低可读性与可维护性。Groovy支持元编程特性，可以在运行时动态添加方法。这一点自然可以简化代码，但也有很大的可能会降低可维护性。函数式编程与大量的语法糖会让不熟悉Groovy的人读起来一头雾水，反而降低了可读性。

Groovy的动态特性允许对象和类都能够在运行期动态地添加方法和属性，在复杂的应用场景，我们很难判断一个具体的对象是否有某个方法。

也有这么一个应用场景，是我所经历到的，Groovy脚本代码被不同的Java应用系统加载，脚本依赖于各个应用系统提供的java环境运行，这个环境

包括当前应用的classpath中有哪些jar包，jar包版本等等，以及由具体应用系统通过bingding对象向脚本中注入的一系列的作为技术服务的bean，

比如获取数据的接口bean。有时候我们各个性用系统的这些环境不一致，导致运行同一个Groovy脚本出现错误，很多由于jar包版本的原因，出现找不到

方法，找不到属性的情况。这就要求我们这在运行时动态判断对象的属性和方法是否存在。好在Groovy在1.1之后就提供了这样的判定支持。具体来看

首先，我们声明了Foo类，包含了一个name属性和一个方法。

通过对象的MetaClass的hasProperty方法我们可以判定并获得该属性对象的引用，

通过MetaClass的respondsTo我们可以判定并获得该方法的引用

application.properties配置文件中value后面有空格。

让人感到疑惑的是，SpringBoot居然没有对application.properties配置文件value末端作空格trim处理。

配置内容：

报错日志：

涉及报错的源码在org.springframework.util.ResourceUtils

通过源码，我们可以看出spring配置文件里这个locations是uri表示，也就是说我们写的logback-dev.xml是当前相对路径。

spring配置文件里这个locations是相对路径，要访问classpath，要使用相对路径：

SpringBoot集成日志logback.groovy报错： Groovy classes are not available on the class path. ABORTING INITIALIZATION.

logback.groovy配置文件内容如下：

详细日志如下：

在类路径中没有Groovy类。

项目中添加groovy依赖：

---