maven项目出现数组越界异常

maven项目出现数组越界异常

解决方案:3.5的会出现这个问题,更换maven版本位3.3.9就ok了 感觉是maven自己的plexus-utils包有问题 我也有如上问题,我是再pom中添加了activiti的jar就会报数组越界,去掉activiti的jar就正常。 但是我必须用activiti,也不知道究竟是什么原因。

卫语句

卫语句

大量的嵌套条件分支是很容易让人望而却步的代码,我们应该极力避免这种代码的出现。尽管结构化原则一直在说一个函数只能有一个出口,但是在大量的嵌套条件分支下,让我们忘了这所谓的规则吧。 有一个专业名词叫卫语句,可以治疗这种恐怖的嵌套条件语句。它的核心思想是,将不满足某些条件的情况放在方法前面,并及时跳出方法,以免对后面的判断造成影响,经过这项手术的代码看起来会非常的清晰。 1.使用卫语句取代嵌套表达式 2.卫语句就是把复杂的条件表达式拆分成多个条件表达式,比如一个很复杂的表达式,嵌套了好几层的if – then-else语句,转换为多个if语句,实现它的逻辑,这多条的if语句就是卫语句. 3有时候条件式可能出现在嵌套n

利用PostMan开发调试Restful API

利用PostMan开发调试Restful API

利用PostMan开发调试Restful API 下边的图片是postman发送不同类型的请求,注意url和参数的变化: 利用spring mvc实现restful api ,需要修改的部分: @RestController 还有就是要注意参数获取的方式, 参考后端代码:

Java内存泄露

Java内存泄露

问题的提出 Java的一个重要优点就是通过垃圾收集器(Garbage Collection,GC)自动管理内存的回收,程序员不需要通过调用函数来释放内存。因此,很多程序员认为Java不存在内存泄漏问题,或者认为即使有内存泄漏也不是程序的责任,而是GC或JVM的问题。其实,这种想法是不正确的,因为Java也存在内存泄露,但它的表现与C++不同。 随着越来越多的服务器程序采用Java技术,例如JSP,Servlet, EJB等,服务器程序往往长期运行。另外,在很多嵌入式系统中,内存的总量非常有限。内存泄露问题也就变得十分关键,即使每次运行少量泄漏,长期运行之后,系统也是面临崩溃的危险。 Java是如何管理内存 为了判断Java中是否有内存泄露,我们首先必须了解Java是

Java和云计算的关系

Java和云计算的关系

Java是一种程序设计语言,云计算是一种新的商业计算模型和服务模式。他们实际上是没有直接关系的,但是由于Java 技术具有卓越的通用性、高效性、平台移植性和安全性,并且广泛应用于个人PC、数据中心、游戏控制台、科学超级计算机、智能手机、物联网和互联网,同时拥有全球最大的开发者专业社群。在全球云计算和移动互联网的产业环境下,Java更具备了显著优势和广阔前景,Java已经成为一个庞大而复杂的技术平台。 hadoop Java与云计算的关系主要体现在以下几个方面: Java在云计算中的优势: Java使云计算更简单,Java具有简单性、兼容性、简易性、安全性、动态性、高性能、解释性、健壮性 Java与分布式计算: 基于JAVA的分布式程序设计: 基

java竖线分割字符串的问题

java竖线分割字符串的问题

使用String.split方法时要注意的问题
在使用String.split方法分隔字符串时,分隔符如果用到一些特殊字符,可能会得不到我们预期的结果。
我们看jdk doc中说明
public String[] split(String regex)
Splits this string around matches of the given regular expression.
参数regex是一个 regular-expression的匹配模式而不是一个简单的String,他对一些特殊的字符可能会出现你预想不到的结果

Java系统程序员修炼之道

Java系统程序员修炼之道

从2002开始接触Java学会HelloWorld这么经典的程序到如今不知不觉已经十年啦,十年中亲耳听到过不少大牛的演讲,见到过项目中的神人在键盘上运指如飞的编程速度,当时就被震撼了。当编程越来越成体力活,我们还能有自己的思想,还能修炼为Java系统级别的程序员嘛?

由一个漏洞引发的思考

由一个漏洞引发的思考

由一个漏洞引发的思考

最近项目比较紧,没时间来写博客,意味着思考少了。两件事:

1、struts2最近爆出了一个漏洞,线上版本必须修补。但是线上的版本源代码已经不可恢复了,新版本代码又没开发、测试完成,代码版本管理没有做好,即使是自己一个人做项目也应该管理好代码。版本控制非常重要,虽说上一个版本不一定好!

2、新版程序发现一个问题,这个问题是在开发过程中很容易忽略掉的,而且必须放在并发访问中才能出现的问题。另外,由于日志输出没做好,导致调试很费劲。简单描述下该问题:

Java开发者不一定最适合Hadoop

Java开发者不一定最适合Hadoop

JNAN DASH的一位(IBM数据仓库BI)专家朋友几周前参加了在圣何塞举行的Hadoop会议。两年前也是这个时间,他参加了当时在纽约的Hadoop会议,但当时仅有200人,而这次不仅有2000多人参加,并且门票早已销售一空。显然,这很直观地证明了Hadoop会议引发了业内高度的兴趣。不止如此,他发现每一个主题演讲的PPT中有关Hadoop技术的幻灯片中都提到“我们正在招聘(we are hiring)”。