Java基础(一):初识Java——发展历程、技术体系与JDK环境搭建

Java基础(一):初识Java——发展历程、技术体系与JDK环境搭建

Java基础系列文章

Java基础(一):发展史、技术体系与JDK环境配置详解

目录


一、Java发展史

Java最初由Sun公司的“Green”项目组开发,用于智能家电设备,最初名为Oak。因商标问题,1995年更名为“Java”(灵感源于印尼爪哇岛的咖啡)。

发行版本发行时间发行的各版本及其特征
Java1995年Java语言诞生
Java 1.01996年首个正式版本,包含基础类库和Applet支持
Java 1.11997年引入内部类(Inner Class)、Java Beans、JDBC(数据库连接)和反射API
Java 1.21998年JDK 1.2发布,更名为Java 2,分为三个平台:J2SE(标准版)、J2EE(企业版)、J2ME(微型版)
Java 1.32000年引入HotSpot JVM、JNDI(Java命名与目录接口)
Java 1.42002年新增正则表达式、断言(Assert)、NIO(非阻塞I/O)和日志API
Java 5.02004年引入泛型、注解、枚举等革命性特性,为强调版本重要性,Sun将内部版本号1.5公开命名为5.0,此后版本号逐渐简化
Java 6.02006年Sun将产品线更名为Java SE/EE/ME,终结“J2”前缀,并宣布开源(OpenJDK)
2009年Oracle以74亿美元收购财务困境的Sun公司,Java正式归属Oracle
Java 7.02011年Oracle首个大版本,支持菱形语法、多异常捕获,但因收购过渡期特性较少
Java 8.02014年继JDK 5后最大更新,引入Lambda表达式、Stream API、新日期时间库。LTS(长期支持)版本
Java 9.02017年发布周期改为每半年发布一次版本,每三年推出LTS(长期支持)版本
Java 10.02018年废弃“1.x”格式,直接使用主版本号(如JDK 10而非JDK 1.10)
Java EE移交Eclipse基金会,重命名为Jakarta EE(如包名从javax.*改为jakarta.*
Java 11.02018年新增HTTP客户端API、局部变量类型推断(var)并移除部分过时功能。LTS(长期支持)版本
Java21.02023年被视为继Java 8后的新一代主流版本,生态支持(如框架适配率)快速提升。LTS(长期支持)版本

二、Java技术体系平台

1、JavaSE

  • JavaSE 的全称是 Java Platform Standard Edition(Java 平台标准版
  • 面向桌面级应用(如Windows下的应用程序),提供完整的Java核心API,是其他平台(JavaEE、JavaME)的基础
  • JavaSE和JDK的关系
    • JavaSE(规范):定义接口、抽象类、具体类以及JVM的行为和约束(定义语言和API应该是什么样)
      • 例:JavaSE规范要求必须有一个ArrayList类,它实现List接口,支持动态扩容
    • JDK(实现):提供这些接口和类的具体代码实现(按照规则实现并提供开发工具和运行环境)
      • 例1:OracleJDK的ArrayList源码中,具体实现了扩容机制(如默认扩容1.5倍)
      • 例2:OpenJDK的ArrayList可能实现相同的逻辑,但代码细节可能有细微差异(如注释、内部优化)
  • 历史名称:早期称为J2SE(JDK 6之前)

2、JavaEE

  • JavaEE 的全称是 Java Platform Enterprise Edition(Java 平台企业版
  • 在Java SE基础上扩展了大量企业级API(如Servlet、JSP、EJB),提供分布式计算、事务管理、安全性等企业级功能
  • JavaEE接口由官方规范定义,具体实现由应用服务器(Tomcat、WildFly)或第三方库(Hibernate、ActiveMQ)提供
  • 自JDK 10起由Oracle移交Eclipse基金会管理,更名为Jakarta EE
  • 历史名称:曾用名J2EE(JDK 6之前)

3、JavaME

  • JavaME 的全称是 Java Platform Micro Edition(Java 平台微型版
  • 针对移动终端(手机、PDA等)的轻量级平台,精简了Java SE的API并加入移动设备支持
  • 随着 Android 和 iOS 的普及,JavaME 的使用逐渐减少
  • 历史名称:曾用名J2ME

4、三者关系

  • JavaSE 是基础:JavaEE 和 JavaME 均基于 JavaSE 的核心功能构建
  • JavaEE 是扩展:在 JavaSE 基础上增加企业级服务规范(如 Servlet、JPA、EJB)
  • JavaME 是精简:仅保留 JavaSE 部分功能,并添加针对微型设备的特性
在这里插入图片描述


在这里插入图片描述

三、Java程序运行机制及运行过程

1、Java的跨平台性

在这里插入图片描述

2、Java虚拟机(核心机制)

  • JVM 是一个虚拟的计算机,具有指令集并使用不同的存储区域。负责执行指令,管理数据、内存、寄存器,包含在JDK 中
  • 对于不同的平台,有不同的虚拟机
  • Java 虚拟机机制屏蔽了底层运行平台的差别,实现了“一次编译,到处运行”
在这里插入图片描述

四、Java语言环境搭建

1、JDK(Java开发工具包)

  • 定义:JDK是用于开发Java应用程序的完整工具包,包含编译、调试、文档生成等开发工具以及运行环境
  • 组成部分
    • JRE:JDK中内置了JRE(包含核心类库),确保开发时可以直接运行程序
    • 开发工具:如编译器javac(将Java源代码编译为字节码)、调试器jdb、文档工具javadoc
    • JDK特有的工具类库:如:tools.jar,支持编译器(javac)、调试器(jdb)等工具的运行(位于JDK的lib目录下)
  • 用途:开发者必须安装JDK,才能编写、编译和调试Java程序
在这里插入图片描述

2、JRE(Java运行时环境)

  • 定义:JRE是运行已编译Java程序所需的最小环境,无需开发功能
  • 组成部分
    • JVM(Java虚拟机) :负责执行字节码,实现跨平台特性
    • JRE中的核心类库:以java.*包的形式存在,例如rt.jar、resource.jar下java.lang、java.util等(位于JRE的lib目录下,并由BootstrapClassLoader自动加载)
    • JRE中的扩展类库:以javax.*包的形式组织,例如javax.sql等(JRE的lib/ext目录下,由ExtensionClassLoader加载)
  • 用途:普通用户只需安装JRE即可运行Java程序(如.jar.class文件),无需开发工具

3、环境变量及作用

3.1、JAVA_HOME

  • 该环境变量的值是Java的安装路径,一些Java版本的软件和工具需要用到该变量

例如,当Windows平台上JDK的安装目录为“C:\java\jdk8”时,设置如下所示

JAVA_HOME=C:\java\jdk8 

3.2、CLASSPATH

  • 该环境变量用于指明Java字节码文件(.class文件)的位置
  • 默认情况下,如果未设置CLASSPATH,Java启动JVM后,会在当前目录下寻找字节码文件,一旦设置了CLASSPATH,JVM会在指定目录下查找字节码文件
    • “.”表示当前目录,因为设置CLASSPATH会覆盖JVM的默认操作(查找当前目录),所以这里需要加上“.”
    • dt.jar是 Java 开发工具包(JDK)中用于为 IDE 提供 Swing/AWT 组件的设计时元数据(如属性、事件描述),支持通过拖拽和图形化界面进行可视化开发的核心类库文件
    • tools.jar的作用:包含编译工具(如javac)所需的类库
  • Java5之前,若用户未显式配置CLASSPATH环境变量JVM不会在当前目录查询.class文件,所以需要配置CLASSPATH
  • 但从Java 5(2004年发布)开始,默认情况,无需显式配置CLASSPATH,JVM会自动搜索当前目录和核心类库

环境变量CLASSPATH的值一般为一个以分号“;”作为分隔符的路径列表,设置如下

CLASSPATH=.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar;

3.3、PATH

  • 该环境变量指定一个路径列表,用于搜索可执行文件
  • 不建议在PATH环境变量中添加当前目录"."的主要原因:
    • 如果当前目录"."被加入PATH,当用户进入公共可写目录/tmp时,攻击者可能在该目录下放置与系统命令同名的恶意程序
    • 例如:黑客在/tmp目录下创建名为ls的木马文件,当用户(尤其是root用户)执行ls命令时,会优先执行当前目录下的恶意程序而非系统标准的/bin/ls,导致权限泄露或数据被破坏

这样可以在命令行中直接使用java和javac命令,而不需要指定完整路径,否则就会出现以下错误:

在这里插入图片描述

执行一个可执行文件时,如果该文件不能在当前路径下找到,则依次寻找PATH中的每一个路径,直至找到。例如:

PATH=.;%JAVA_HOME%\bin;

Read more

Flutter 组件 short_uuids 适配鸿蒙 HarmonyOS 实战:唯一标识微缩技术,构建高性能短 ID 生成与分布式索引架构

Flutter 组件 short_uuids 适配鸿蒙 HarmonyOS 实战:唯一标识微缩技术,构建高性能短 ID 生成与分布式索引架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 short_uuids 适配鸿蒙 HarmonyOS 实战:唯一标识微缩技术,构建高性能短 ID 生成与分布式索引架构 前言 在鸿蒙(OpenHarmony)生态迈向万物互联、涉及海量离线资源标识、蓝牙广播载荷(BLE Payload)及二维码数据极限压缩的背景下,如何生成既能保留 UUID 强随机性、又能极大缩减字符长度的唯一标识符,已成为优化存储与通讯效率的“空间必修课”。在鸿蒙设备这类强调分布式软总线传输与每一字节功耗敏感的环境下,如果应用依然直接传输长度达 36 字符的标准 UUID,由于由于有效载荷溢出,极易由于由于传输协议限制导致数据截断或多次分包带来的延迟。 我们需要一种能够实现高进制转换、支持双向编解码且具备低碰撞概率的短 ID 生成方案。 short_uuids 为 Flutter 开发者引入了将标准 UUID 转化为短格式字符串的高性能算法。它利用

By Ne0inhk
Flutter 组件 fletch 的适配 鸿蒙Harmony 实战 - 驾驭高性能网络爬虫、实现鸿蒙端多并发与自定义拦截器的资产自动化抓取方案

Flutter 组件 fletch 的适配 鸿蒙Harmony 实战 - 驾驭高性能网络爬虫、实现鸿蒙端多并发与自定义拦截器的资产自动化抓取方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 fletch 的适配 鸿蒙Harmony 实战 - 驾驭高性能网络爬虫、实现鸿蒙端多并发与自定义拦截器的资产自动化抓取方案 前言 在数据驱动的鸿蒙(OpenHarmony)应用开发中,很多时候我们需要从外部网络环境大规模采集实时资讯、获取海量资源路径或者是进行自动化的接口探测。传统的 http 库虽然简单,但在面对数十路并发下载、复杂的 Cookie 状态维持以及多级的请求拦截(Interceptor)时,往往显得捉襟见肘。 fletch 正是一款专为高性能、工业级抓取任务设计的 Dart 网络增强库。它不仅支持极致的并发限流,更提供了一套类似拦截器管线的强大插件化能力。 适配到鸿蒙系统后,配合鸿蒙底层的网络切片和能效策略,fletch 能让你的数据采集应用在保持低功耗的同时,展现出前所未有的吞吐力。本文将为你深入剖析 fletch 在鸿蒙实战环境下的深度集成与优化。 一、原理解析 / 概念介绍 1.1

By Ne0inhk
【MySQL】三大范式

【MySQL】三大范式

下面我们来聊聊表的设计,如何设计一张比较合理,冗余性低且IO次数比较少,效率高的表。 我们需要先认识一下范式 什么是范式? 范式是⼀组规则。在设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式。 范式有哪些? 关系数据库有六种范式:第⼀范式(1NF)、第⼆范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,⼜称完美范式),越高的范式数据库冗余越小。然而,普遍认为范式越高虽然对数据关系有更好的约束性,但也可能导致数据库IO更繁忙,因此在实际应用中,数据库设计通常只需满足第三范式即可,如果在想提高效率,再去增加某个字段的冗余性 为啥越高的范式数据库冗余越小,IO效率越忙呢?继续看 第一范式 第一范式即:数据库表的每⼀列都是不可分割的原子数据项,而不能是集合,数组,对象等非原子数据 在关系型数据库的设计中,满足第⼀范式是对关系模式的基本要求。

By Ne0inhk
直击复杂 SQL 瓶颈:基于代价的连接条件下推技术落地

直击复杂 SQL 瓶颈:基于代价的连接条件下推技术落地

一、引言 在数据库理论的学习过程中,我们常常接触到简洁优美的SQL示例——单表查询、简单连接、基础过滤,这些案例清晰地展示了关系代数的基本原理。然而,当我们步入真实的业务系统,面对的SQL语句往往如同缠绕的线团:公用表表达式(CTE)层层嵌套,子查询彼此交织,窗口函数与聚集计算随处可见。 这种复杂性并非开发人员的炫技,而是业务逻辑的自然映射。遗憾的是,这种为提升可读性而组织的SQL结构,却给查询优化器带来了严峻考验。在众多性能瓶颈中,有一个问题尤为突出:高选择性的连接条件无法穿透复杂的子查询结构,导致数据过滤发生在错误的时间点。本文将深入探讨这一问题的本质,并介绍一种基于代价模型的连接条件下推解决方案,展示如何让优化器既懂“安全”,又知“成本”。 二、性能困境:过滤迟到的代价 2.1 真实场景的切面分析 在大量客户业务系统中,一种常见的SQL编写模式反复出现:开发人员习惯先在子查询或CTE中完成复杂的预处理逻辑——去重、排序、窗口计算,然后再将这些预处理结果与其它表进行连接,最后施加过滤条件。从业务语义角度看,这种写法清晰自然;但从执行效率角度看,却暗藏危机。 考虑

By Ne0inhk