jdk1.7与jdk1.8中String.split()方法的坑

最新推荐文章于 2023-08-07 15:58:36 发布

原创最新推荐文章于 2023-08-07 15:58:36 发布 · 1.7k 阅读

0 ·

CC 4.0 BY-SA版权

本文探讨了在不同版本的Java中使用split方法处理空字符串模式时的差异，揭示了在JDK1.7和JDK1.8中，相同代码执行结果的不同，指出这一差异可能导致的索引越界风险。

在书写代码的过程中，遇到了split切割字符串的坑，会有索引越界的风险。

在jdk1.8中

public static void main(String[] args) {
    String card = "abcdefgh";
    System.out.println(card.split("").length);
}

结果：8

在jdk1.7中，同样的代码

public static void main(String[] args) {
    String card = "abcdefgh";
    System.out.println(card.split("").length);
}

结果：9

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

czw_xiaobei

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

HashMap底层原理及源码分析（详细）（jdk1.7 && jdk 1.8）

weixin_43691723的博客

03-27

1523

jdk1.8中的HashMap底层原理是在jdk1.7的基础上改进的，所以，建议先了解jdk1.7的底层原理，先熟悉jdk1.7 的源码首先大致了解一下HashMap的实现原理，1.7中HashMap是采用数组加链表的方式实现的，因为HashMap存储元素是按key和value 的形式存储，HashMap中就定义了一个Entry类来封装元素的key和value，并且实现链表，定义一个Entry类...

JDK(jdk1.7与1.8)源码剖析之 java.util.HashMap

未来工厂的博客

12-12

1009

JDK(jdk1.7与1.8)源码剖析之 java.util.HashMap

参与评论您还未登录，请先登录后发表或查看评论

jdk1.8与1.7的string.split("")

Jinx

07-26

3018

测试代码一致： package jinx; public class StringTest { public static void main(String[] args){ String str = "686BB7C67101E54100FFE7085F35"; String[] strArr = str.split(""); S...

jdk1.7与jdk1.8中String.split()方法问题

qq_36864672的博客

08-07

419

split切割字符串的坑，会有索引越界的风险。在jdk1.7中，同样的代码。在sql中结果也不同。

String split()方法在jdk7和jdk8下面不同结果

weixin_34226706的博客

10-13

634

2019独角兽企业重金招聘Python工程师标准>>> ...

Java JDK1.8 和 1.6区别 String.split 的一个坑

weixin_34167043的博客

08-08

971

代码说明如下: String str = "abc"; String[] chars = str.split(""); // JDK 7及以下版本结果 : ["","a","b","c"] // JDK 8版本: ["a","b","c"] 这个问题太坑了，直接导致我的代码在线下有用，提交到线上就报错。因为本地使用的JDK1.8 ...

记一次jdk1.7与1.8版本切换时遇到的问题

guyan1111的博客

08-29

864

1、刚开始使用的是jdk1.8的splite("")方法截取字符串，如str="abc",截取后数组为[,a,b,c]，数组长度为4,即认为之前有一个字符，使用1.7则正常返回[a,b,c]。最后使用toCharArray(); 方法转成字符数组的方法解决。 2、使用jdk1.8实现了sha-224的加密方法，但是放在jdk1.7中报错误，报错截图为：造成原因是sha224...

JDK1.7下载

04-25

4. **改进的字符串操作**：JDK 7增加了对字符串的`split()`方法性能优化，以及`String`类中的`join()`方法，用于方便地连接字符串数组。 5. **文件系统API（NIO.2）**：Java 7引入了新的文件系统API，基于`java.nio...

jdk 1.7 绿色版

04-28

此外，`String`类还增加了`split()`方法的正则表达式优化，提高了处理复杂分隔符的速度。 JDK 1.7还引入了新的语法糖，如菱形泛型、多 catch 语句，以及动态类型。动态类型允许声明变量时只指定`Object`类型，而在...

JDK1.7和1.8的HashMap对比详解

m0_37841477的博客

03-22

468

HashMap是我们在编程中最常用的map，也是面试中经常考的问题，所以打算深入研究一下hashmap的源码，并且对比7和8中的不同。一、hashmap的数据结构 hashmap的数据结构是哈希表，核心是基于哈希值的桶和链表，而哈希桶的底层实现其实是数据，数组这种数据结构查找的时间复杂度是O(1)，所以哈希表的查找、删除、插入的平均时间复杂度就是O(1)，但是它也有一个致命的缺陷—哈希碰撞（co...

基于JDK1.8的String详解

Geffin的博客

05-16

3351

String 类的定义 public final class String implements java.io.Serializable, Comparable<String>, CharSequence {} 这是一个用 final 声明的常量类，不能被任何类所继承,而且一旦一个String对象被创建, 包含在这个对象中的字符序列是不可改变的, 包括该类后续的所有方法都是...

java字符串格式化_java字符串格式化

weixin_39856269的博客

02-12

136

常规类型的格式化String类的format()方法用于创建格式化的字符串以及连接多个字符串对象。熟悉C语言的同学应该记得C语言的sprintf()方法，两者有类似之处。format()方法有两种重载形式。format(String format, Object... args) 新字符串使用本地语言环境，制定字符串格式和参数生成格式化的新字符串。format(Locale locale, Str...

Java String.split() 总结

我爱奔跑的浮云_的博客

10-13

489

Java String.split() 总结在项目当中，我们经常需要对一些特殊的字符串进行分割解析，这个时候会用到[split()][6]这个方法，下面总结一下使用这个方法需要注意的地方。正常字符串分割时： str.split(“分隔符”) 特殊的字符串分割时：用“.”分隔时,,str.split(“\\.”)这样才正确的分隔开,String.split(“.”)是错误的; 用“|”分隔时,,s

JDK1.8新特性之peek处理字符串

havendream的博客

07-20

6086

jdk1.8出来之后split也有了新玩法了，不要在赋值给数组，再循环输出了。 package com.lxc.springboot; import org.junit.Test; import java.util.ArrayList; import java.util.List; import java.util.stream.Stream; public class Demo { ...

关于split方法，JDK1.7和JDK1.8的区别，以及问题解决方案

WatsonXh的博客

07-06

2189

JDK1.8 String aa="XYZ"; String[] aaArr=aa.split(""); //[X, Y, Z]JDK1.7 String aa="XYZ"; String[] aaArr=aa.split(""); //[, X, Y, Z]

str.split(&amp;amp;quot;&amp;amp;quot;)在JDK1.7和JDK1.8中的区别

G_66_hero的博客

03-28

935

问题描述：今天帮同门作华为的笔试题，我在自己电脑上调试好的代码上传后会报数组越界的异常，这让我非常的难受，经过认真查找问题的原因发现，我本地用的是JDK1.7，而上传后用的是JDK1.8编译运行，String.split("")在JDK1.7和JDK1.8中切割后是有差别的，具体如下代码所示。在JDK1.8中，如下所示：public class String_split { public sta...

1.8 分割字符串（spilt()）

you can you up up up的博客

10-02

745

String 类的 split() 方法可以按指定的分割符对目标字符串进行分割，分割后的内容存放在字符串数组中。该方法主要有如下两种重载形式： str.split(String sign) str.split(String sign,int limit) 其中它们的含义如下： str 为需要分割的目标字符串。 sign 为指定的分割符，可以是任意字符串。 limit 表示分割后生成的字符串的限制个数，如果不指定，则表示不限制，直到将整个目标字符串完全分割为止。使用分隔符注意如下： 1）“.”和“|

JDK1.8 HashMap源码之扩容时处理红黑树的split、 treeify系列方法分析（三）

nandao158的博客

04-13

791

上一篇分析了hashMap 扩容原理，预先参考，今天接着分析其中的split方法。首先这个方法只在HashMap进行扩容时会调用到: ((TreeNode<K,V>)e).split(this, newTab, j, oldCap); 参数详解： /** 这个方法在HashMap进行扩容时会调用到: ((TreeNode<K,V>)e).split(this, newTab, j, oldCap); * @param map 代表要扩容的HashMap * @para

JDK1.8新特性

刘树之的博客

09-09

449

JDK1.8新特性 JDK1.8新特性简介速度更快 - 优化底层源码，比如HashMap、ConcurrentHashMap 代码更少 - 添加新的语法Lambda表达式强大的Stream API 便于并行最大化减少空指针异常 - Optional Lambda表达式简介 Lambda是一个匿名函数(方法)，允许把函数作为一个方法的参数。利用Lambda表达式可以写出更简洁、更灵活的代码。作为一种更紧凑的代码风格，使Java的语言表达能力得到了提升。一般都是优化匿名内部类基础语法

jdk1.7安装后查询到的版本为Java11

最新发布

10-10

<think>我们要解决用户的问题：在安装JDK 1.7后，使用`java -version`查询到的版本却是Java 11。原因通常与系统环境变量设置有关，导致系统优先使用了已安装的其他版本（特别是Java 11）的Java。根据引用[1]中提到的现象：环境变量`PATH`中有一条`C:\Program Files (x86)\Common Files\Oracle\Java\javapath`的路径，它会自动跑到最上面，从而覆盖其他设置。尽管这个引用是针对Windows的，但我们可以推测在Linux系统下也可能有类似的环境变量优先级问题。另外，引用[2]和[3]提供了Linux下安装和管理JDK版本的方法，包括使用yum安装指定版本和卸载旧版本。因此，我们可以分析可能的原因： 1. 系统中已经安装了多个JDK（包括JDK 11），并且环境变量`PATH`的设置导致了系统优先使用了JDK 11的路径。 2. 在安装JDK 1.7之前或之后，可能安装过JDK 11，并且其路径被设置在环境变量中，且位置在JDK 1.7的路径之前。 3. 可能使用了替代系统（如Linux中的`alternatives`）设置了默认的Java版本。解决方案： 1. 检查环境变量`PATH`，确保JDK 1.7的路径在JDK 11的路径之前。 2. 在Linux中，使用`update-alternatives`来管理多个Java版本，并设置默认版本为JDK 1.7。 3. 如果不需要JDK 11，可以将其卸载，然后重新配置环境变量。具体步骤（以Linux为例）：步骤1：检查当前系统中安装的Java版本及其路径执行以下命令查看系统中所有Java安装路径： $ sudo update-alternatives --config java 如果这个命令没有列出所有安装的Java，可以尝试： $ which java $ ls -l /usr/bin/java $ ls -l /etc/alternatives/java 步骤2：使用`update-alternatives`设置默认Java版本如果已经安装了多个JDK，可以使用以下命令切换： $ sudo update-alternatives --config java 然后根据提示选择JDK 1.7对应的序号。步骤3：手动调整环境变量如果系统中没有使用`alternatives`，或者想通过环境变量控制，可以编辑用户环境变量配置文件（如`~/.bashrc`或`~/.profile`）或系统环境变量配置文件（如`/etc/profile`）： $ sudo vim /etc/profile 在文件末尾，确保JDK 1.7的路径设置在JDK 11的路径之前，例如： export JAVA_HOME=/usr/lib/jvm/jdk1.7.0_80 # 替换为实际的JDK 1.7安装路径 export PATH=$JAVA_HOME/bin:$PATH 然后使配置生效： $ source /etc/profile 步骤4：检查是否生效 $ java -version 步骤5：如果步骤3中调整环境变量后仍然不行，可能是因为在`/etc/profile.d/`目录下有其他脚本设置了Java环境变量。检查`/etc/profile.d/`目录下是否有关于Java的脚本，并调整其顺序或内容。步骤6：卸载不需要的JDK（可选，如JDK 11）根据引用[3]的方法卸载JDK 11，但注意卸载前确保不会影响其他应用程序。对于Windows系统，可以参考引用[1]的思路： 1. 检查环境变量`PATH`，将JDK 1.7的路径（如`C:\jdk1.7.0\bin`）移动到`C:\Program Files (x86)\Common Files\Oracle\Java\javapath`这一条之前（或删除该条目，因为它指向了JDK 8，但用户现在是JDK 11的问题，所以可能是类似的公共路径指向了JDK11）。 2. 或者，删除公共路径条目，然后确保JDK 1.7的路径在环境变量`PATH`中靠前。注意：在Windows中，环境变量`PATH`中的条目顺序决定了优先级。总结原因：系统中有多个JDK版本，环境变量设置导致系统优先使用了JDK 11而不是JDK 1.7。根据上述分析和步骤，我们可以为用户提供详细的解答。 </think>### 安装 JDK 1.7 后显示 Java 11 的原因及解决方案 #### **问题原因** 1. **环境变量优先级错位** 系统`PATH`变量中存在更高优先级路径指向 Java 11，如： - Windows：`C:\Program Files (x86)\Common Files\Oracle\Java\javapath`（自动置顶） - Linux：`/usr/bin/java`被链接到 Java 11 的路径即使正确设置 `JAVA_HOME` 为 JDK 1.7，系统仍优先执行路径靠前的 Java 11[^1]。 2. **多版本共存干扰** - 系统中已存在 Java 11 且注册到系统级路径（如 Linux 的 `alternatives` 系统） - JDK 1.7 安装后未正确更新系统默认 Java 链接[^2][^3]。 3. **安装过程未清除旧版本** JDK 11 残留文件未被卸载，导致环境变量冲突[^3]。 --- #### **解决方案** ##### **Windows 系统** 1. **调整 `PATH` 变量优先级** - 打开 `控制面板 > 系统 > 高级系统设置 > 环境变量` - 在 `系统变量` 中找到 `PATH`，将 `%JAVA_HOME%\bin` **上移**至 `C:\Program Files (x86)\Common Files\Oracle\javapath` 之上 - 或直接删除 `javapath` 条目（需卸载公共 JRE）[^1]。 ```powershell # 验证路径优先级 $env:Path -split ';' | Select-String 'java' ``` 2. **清理残留 JDK** - 卸载所有非必要的 Java 版本（控制面板 → 程序与功能） - 删除残留目录：`C:\Program Files\Java\jdk-11.x.x` ##### **Linux 系统** 1. **重置默认 Java 版本** ```bash # 查看所有已安装JDK路径 sudo update-alternatives --config java # 选择JDK 1.7对应的序号 ``` 2. **手动覆盖系统链接** ```bash sudo rm /usr/bin/java # 移除旧链接 sudo ln -s /path/to/jdk1.7/bin/java /usr/bin/java # 新建正确链接 ``` 3. **清除 Java 11 残留** ```bash # 卸载JDK 11（以OpenJDK为例） sudo yum remove java-11-openjdk.x86_64 # CentOS/RHEL sudo apt purge openjdk-11-jdk # Ubuntu/Debian ``` 4. **验证环境变量** 编辑 `~/.bashrc` 或 `/etc/profile`，确保： ```bash export JAVA_HOME=/usr/lib/jvm/jdk1.7.0_80 # 替换为实际路径 export PATH=$JAVA_HOME/bin:$PATH ``` 执行 `source ~/.bashrc` 生效后运行 `java -version` 检查。 --- #### **关键操作验证** ```bash # 检查当前生效的Java路径（所有系统通用） which java # 显示实际调用路径 ls -l $(which java) # 查看链接指向的真正二进制文件 ``` 若输出非 JDK 1.7 路径（如 `/usr/lib/jvm/java-11-openjdk`），说明配置未生效。 --- ### 相关问题 1. **如何在 Linux 中同时保留多个 JDK 版本并快速切换？** 2. **Windows 系统彻底卸载 Java 的正确步骤是什么？** 3. **为什么修改 `JAVA_HOME` 后 `java -version` 仍显示旧版本？** 4. **如何避免新安装的 JDK 覆盖系统默认 Java 路径？** [^1]: 环境变量路径优先级错误导致版本冲突 [^2]: 多版本共存时未正确配置系统链接 [^3]: 旧版本残留文件未彻底清除