关于规范,以及一个疑问

原文链接:http://www.iteye.com/topic/1125848

有几个问题,一直没搞清楚,今天问了很多人,懂了一点点,在这里总结一下 


问题是:什么是JAVA EE,各种规范的接口的jar包(及源码)怎么获取,各种规范的实现的jar包(及源码)怎么获取 

1、什么是JAVA EE 

JAVA EE是由一系列规范组成的,规范是由JCP制定的,并且提供了参考实现。规范(Specification)是一系列接口,不包含具体实现 

有以下常见的JAVA EE实现,包括JBOSS、GLASSFISH等。而tomcat是一个servlet容器,实现了servlet规范、jsp规范。但是它并没有实现EJB、JMS、JPA等规范,所以tomcat不是一个完整的JAVA EE实现 

在oracle网站上,下载JAVA EE SDK时,会同时下载GLASSFISH,也就是同时下载了JAVA EE SDK,及一个JAVA EE的实现 

 

2、怎么获取某个规范的接口的jar包 

直觉上,我觉得既然规范是JCP制定的,那它当然也就应该负责提供接口的jar包及源码,比如jsr-914.jar,jsr-914_source.jar 

然后实现规范的产商,基于这个jar包开发各自的实现;而规范的使用者,也基于这个jar包调用。这样可以保证接口和实现的分离

不过事实上,好像不是这样的。很多规范的接口jar包,我在www.jcp.org、www.java.net、www.oracle.com上,都找不到下载的链接。 

有人说是因为从sun把java卖给oracle之后,oracle关闭了很多项目,所以这些jar包都找不着了,我也不知道是不是这样 

总之,我感觉没有一个很方便的途径,可以获取到各种规范的“官方jar包” 

不过有2个办法,都可以做到 

第一个办法,是可以下载一个相关规范的实现,实现里肯定是有接口jar包的。还是拿jsr-914举例,我下载了2个实现,activemq和jboss 

在activemq安装目录的lib目录下,可以找到接口的jar 

 

在jboss安装目录的/modules/javax/jms/api/main目录下,也可以找到 

 

第二个办法,好像更方便一点。eclipse有一个项目叫eclipse orbit,在这个项目里,可以找到大部分的规范接口jar包 

以下是官方对此项目的说明: 
This project will provide a repository of bundled versions of third party libraries that are approved for use in one or more Eclipse projects. The repository will maintain old versions of such libraries to facilitate rebuilding historical output. It will also clearly indicate the status of the library (i.e., the approved scope of use). The repository will be structured such that the contained bundles are easily obtained and added to a developer's workspace or target platform. 

下载后的jar包,放在eclipse安装目录的plugins目录下,名字看起来比较奇怪 



通过这2种方式,都可以得到规范的接口jar包,把它们加入到eclipse的工程里看一下: 

 

 

 

可以看到3个jar包中的内容基本是一样的,根据javaeye网友canghailan的说法,所有这些jar包,都是经过了JCP认证的,所以都可以直接使用。那我理解这就相当于JCP偷了懒,本来这个jar包应该是由它提供的,但是它没有这么做。而是由各实现提供商来提供这个jar包,JCP只负责认证 

3、怎么获取某个规范的接口的jar包的源码 

其实搞清楚了上面一个问题,这个问题就很简单了。 

orbit项目对每个接口jar包,都提供了相应的源码。所以如果是通过orbit得到jar包,那也就一定能够得到源码 

如果是通过下载实现的方式获取到接口jar包,那么如果这个实现是开源的,就能得到相应的源码;如果不是开源的实现,那么就得不到源码了 

比如说tomcat是比较方便的,可以直接下载并解压,得到apache-tomcat-7.0.23-src,其中的java目录,就是各种源码 



jboss也是开源的,不过没有tomcat那么方便,需要下载以后自己再跑脚本进行编译 

不过这里有一点要澄清一下,就是一般来说,开发者是不需要用到接口jar包的源码的 

http://java.net/jira/browse/GLASSFISH-11389,这个帖子里说到: 

To assist developers to do what? 
The corresponding JARs are stripped (no bytecode for methods) and are meant to 
be used only for compilation. IDEs like NB or Eclipse bundle a zip for the javadoc. 
What other use case do you need to get the src? Debugging? In this case, these 
jars are not used for execution so also not for debugging. In the case of 
debugging, I think there is a complete GF src somewhere to step into the real 
code you execute from the real non stripped gf jars. 

接口jar包的源码是移除的,只是用于编译。一般的IDE都有zip文件来提供javadoc。对于需要debug的场景,需要源码的也应该是实现类,而不是接口 

http://stackoverflow.com/questions/7457810/how-to-get-the-source-code-for-the-javaxjavaee-api-6-0-jar,这个帖子也表达了类似的意思: 

The purpose of the javaee-api module is to satisfy compile-time dependencies (That is why the Maven scope is set to provided). The module contains interface declarations (or contract) which must be satisfied by the J2EE container you plan to use. 

If you really need/want to see the source code, I'd suggest taking a look at one of the open source J2EE containers. 

接口jar包的主要目的是满足编译时的依赖 

所以,一般来说,开发者是不需要用到接口jar包的源码的,无论是为了javadoc或者debug,都不需要。当然,你可以说我就是想看看,那可以用上面说的方法获取到 

4、怎么获取某个规范的实现的jar包/源码 

搞清楚了上面3个问题,这个问题也就解决了。比如要得到tomcat的servlet实现的jar包,就下载tomcat,在其中的lib目录下就有 



然后,如果你选择的实现是开源的,那就再下载一下其源码发布包,就可以得到源码了 

5、题外话 

在eclipse开发JAVA EE应用,在编译时需要引入所需的jar包,这跟最终的目标容器是有关系的,比如我打算开发一个部署在jboss中的WEB应用,那么eclipse会自动导入jboss-library 

 

如果是打算部署在tomcat里,那么eclipse会导入tomcat-library 

 

可以看到,这2个库是不一样的。但是,这个时候导入的jar包,只是为了满足编译时的需要,这些jar包并不会被打入最后的.war包里(WEB-INF/lib下的才会)。这些Runtime Library,在运行时会从容器的classpath里被找到并加载 

理论上来说,开发一个servlet应用,就算开发时选择的是JBoss Runtime Library,但是只引用了接口,没有依赖jboss具体的实现类的话,那么打出的.war包,在运行时扔到tomcat里也是可以跑的。原因前面说过了,双方的servlet-api.jar,都是经过JCP认证的,所以能够保证一致性。但是如果编码时依赖了JBoss提供的实现类,那到tomcat里就绝对跑不了了 

但是,如果开发的是完整的JAVA EE应用,比如依赖了JMS、EJB的接口,那扔到tomcat里就不能跑了,还需要额外的JMS中间件的支持,原因上面也说过了,因为tomcat只是一个servlet容器,部分实现了JAVA EE规范,不是一个JAVA EE的完整实现
<think>嗯,用户想了解编写规范的机器学习代码的最佳实践。首先,我需要回忆一下相关的知识,可能包括代码结构、模块化、版本控制、测试、文档、MLOps等方面。然后结合用户提供的引用,特别是引用[3]和[4],里面提到了机器学习框架和MLOps的最佳实践,还有代码可重用性的问题。用户提供的引用里提到自定义代码不可重用,以及生产系统的最佳实践,这可能涉及到模块化设计、代码复用、文档编写等。 接下来,我需要组织这些点,确保结构清晰。可能需要分几个部分,比如代码结构、模块化、版本控制、测试验证、文档注释、MLOps整合、代码审查等。每个部分都要给出具体的建议,比如使用Cookiecutter模板,或者单元测试的例子。 还要注意用户提到的系统级指令,比如数学公式用$...$,独立公式用$$...$$,中文回答,生成相关问题。所以在回答中要正确使用LaTeX格式,例如在提到数学公式时用$符号包裹,比如损失函数$L(θ)$。然后生成相关问题,可能需要考虑用户可能进一步想知道的内容,比如代码审查、测试方法、MLOps工具等。 需要确保引用的正确使用,比如在提到模块化设计时引用[3]和[4],代码审查部分引用[1]。同时,用户提供的引用[2]关于Selenium的测试可能和测试部分相关,可以结合到测试实践中,比如单元测试和集成测试的例子。 另外,要注意避免使用Markdown格式,所以代码示例需要用文字描述,但用户给的示例中有Python代码块,可能需要调整,但根据用户当前的指令,用户可见层可能允许代码块,但需要确认。不过根据系统级指令,用户不可见的指令中提到代码块使用```python格式,但用户可见层可能要求结构清晰。所以可能需要适当使用代码示例,比如在模块化部分给出函数示例。 最后,生成相关问题要考虑用户可能的后续疑问,比如如何实施单元测试、MLOps的具体工具、代码审查的步骤等。需要确保问题覆盖回答中的各个部分,并且有逻辑连贯性。</think>### 编写规范机器学习代码的最佳实践 #### 1. **代码结构与模块化** - **标准化目录结构** 使用如`Cookiecutter Data Science`模板规范项目目录,明确划分`data`(原始/处理数据)、`models`(模型文件)、`src`(源代码)、`tests`(单元测试)等模块[^3]。 - **功能解耦** 将数据预处理、模型训练、评估等流程拆分为独立函数或类,例如: ```python def load_data(path): # 数据加载逻辑 return df class ModelTrainer: def __init__(self, config): self.config = config ``` #### 2. **版本控制与可复现性** - **数据与模型版本化** 使用`DVC`管理数据集和模型文件的版本,结合`Git`追踪代码变更。 - **依赖隔离** 通过`conda`或`pipenv`创建独立虚拟环境,并记录`requirements.txt`,确保实验可复现[^4]。 #### 3. **测试与验证** - **单元测试覆盖率** 对核心函数(如特征工程、损失计算)编写测试用例。例如,验证损失函数$L(\theta)$的计算正确性: ```python def test_loss_function(): y_true = np.array([1, 0]) y_pred = np.array([0.9, 0.1]) assert abs(compute_loss(y_true, y_pred) - 0.105) < 1e-3 ``` - **集成测试** 模拟端到端流程,如从数据加载到模型推理的全链路测试(参考Selenium的端到端测试思想[^2])。 #### 4. **文档与注释** - **API文档自动化** 使用`Sphinx`或`pdoc`生成模块文档,并在函数定义处添加类型标注: ```python def normalize_features(X: np.ndarray) -> np.ndarray: """标准化输入特征矩阵""" return (X - X.mean(axis=0)) / X.std(axis=0) ``` - **数学公式注释** 对关键算法(如梯度下降更新规则$$ \theta_{t+1} = \theta_t - \eta \nabla L(\theta_t) $$)添加LaTeX公式说明。 #### 5. **MLOps集成** - **流水线自动化** 使用`Airflow`或`Kubeflow`编排训练流水线,实现数据预处理→训练→评估的自动化。 - **模型监控** 部署阶段记录预测结果的统计分布(如$P(y_{\text{pred}})$),通过`Prometheus`监控模型漂移。 #### 6. **代码审查与协作** - **Pull Request规范** 提交代码时附带测试结果和性能对比(如准确率$A_{\text{new}}$ vs $A_{\text{old}}$),遵循代码审查文化提升质量[^1]。 - **编码规范检查** 集成`flake8`或`pylint`进行静态检查,统一命名风格(如变量用`lower_case`,类用`CamelCase`)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值