目前,我有以下代码(而且我不喜欢):
private RenderedImage getChartImage (GanttChartModel model, String title,
Integer width, Integer height,
String xAxisLabel, String yAxisLabel,
Boolean showLegend) {
if (title == null) {
title = "";
}
if (xAxisLabel == null) {
xAxisLabel = "";
}
if (yAxisLabel == null) {
yAxisLabel = "";
}
if (showLegend == null) {
showLegend = true;
}
if (width == null) {
width = DEFAULT_WIDTH;
}
if (height == null) {
height = DEFAULT_HEIGHT;
}
...
}
Run Code Online (Sandbox Code Playgroud)
我该如何改善?
我对引入一个包含所有这些参数作为字段的对象有一些想法,然后也许可以应用构建器模式。但是仍然不清楚如何实现该目标,我不确定是否值得这样做。还有其他想法吗?
我有一个带有Spring IoC容器的Java EE项目.
我刚刚在Utils类静态方法中找到了sendMail(long list of params).我不知道为什么,但我觉得如果我们有单独的类(具有单例范围的Spring bean)将负责发送电子邮件会更好看.但我找不到任何可以证明我立场的论据.
那么,在这种(相当普遍的)情况下使用DI有任何优点(或缺点)吗?
我有一些哲学上的直觉,即添加未映射到DB的字段会破坏实体类,并且是解决问题的错误方法.
但是,是否存在使用@Transient字段导致隐式和硬性修复问题的具体情况?
例如,当@Transient我们的实体中有字段时,添加或删除二级缓存是否可能会破坏我们的应用程序?
相当大的更新:在对@Transient字段进行一些思考之后,在我看来,@Transient字段应该以正确的方式使用.
通过"正确的方式",我的意思是实体总是应该具有相同的行为.这意味着当getter null不时返回时,这是一个非常容易出错的行为,具体取决于@Transient字段值.这意味着应始终初始化@Transient字段.
我只看到2例正确使用:
@Transient字段应该在object的构造函数中初始化:
@Entity
public class SomeEntity
@Id
private long id;
@Transient
private String transientField;
public SomeEntity () {
transientField = "some string";
}
...
}
Run Code Online (Sandbox Code Playgroud)@Transient字段可以延迟初始化:
@Entity
public class SomeEntity
@Id
private long id;
@Transient
private String transientField;
public String getTransientField () {
synchronized (lock) {
if (transientField == null) {
transientField = "some string";
}
}
return transientField;
}
...
} …Run Code Online (Sandbox Code Playgroud)我想知道应该使用线程池的边缘在哪里.我可以在不使用线程池的情况下每秒创建多少个新线程,仍然可以避免明显的性能损失?
是否有任何可观察的开源线程池实现?
我正在开发一种新的魔力。它只有一个目标,因此不强制用户添加executions部分似乎合乎逻辑(如果他们不想更改 default phase)。
这应该是可能的,因为当我添加一个非常简单的surefire插件描述时,maven 明白test应该运行它的单一目标,即:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.4.3</version>
</plugin>
Run Code Online (Sandbox Code Playgroud)
这足以运行插件。
如何为我的插件实现类似的小配置?
这是我现在拥有的(并且没有executions部分就无法工作):
/**
*
* @goal test
* @phase test
*/
public class MyMojoPlugin extends AbstractMojo {
... (implementation details)
}
Run Code Online (Sandbox Code Playgroud)
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.somegroup</groupId>
<artifactId>mymojo-maven-plugin</artifactId>
<packaging>maven-plugin</packaging>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-plugin-api</artifactId>
<version>2.0</version>
</dependency>
.... (other dependencies)
</dependencies>
<build>
<plugins>
... (some plugins)
</plugins>
</build>
</project>
Run Code Online (Sandbox Code Playgroud) 如果我需要为tomcat实例中部署的所有应用程序设置相同的编码,我可以编辑server.xml并添加如下所示的部分:
<Connector port="8081" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
URIEncoding="UTF-8"/>
Run Code Online (Sandbox Code Playgroud)
有没有办法为某个应用程序指定编码?(也许在它web.xml或其他地方)?
我查看了Controller.groovy源代码,看起来CRUD操作不是事务性的(至少是显式的).
如果我是对的,是否意味着不应该在生产中使用动态脚手架?有没有办法使它成为事务性的(即我可以修改Controller.groovy或其他什么?)?
让我们假设一个> 25000个节点的完整图表.每个节点基本上是平面上的一个点.它有625M边缘.每条边的长度应存储为浮点数.
我需要一个算法来找到它的MST(在普通的PC上).
如果我采用Kruskal的算法,它需要先对所有边进行排序,但我甚至无法承受在内存中同时存储边缘.
如果我选择Prim算法,那么很难同时评估堆中存储的边数,但可能大多数边将在算法启动后很快就存在.
是否有更多的内存足够的算法可以让我避免排序存储在文件中的边?
还有,是否有任何已知的MST算法利用任何树边缘满足三角不等式的事实?
我找到了以下手册https://code.google.com/p/javamelody/wiki/UserGuideAdvanced#JPA_monitoring
它包含一些有关我应该进行的更改的信息persistence.xml,以便让JavaMelody收集JPA/SQL统计信息.
但是,我不太清楚,是否应该provider用JavaMelody-provider 替换现有的,还是应该将它放到一个单独的持久性单元中?
我尝试了前一个选项,但它打破了应用程序(构建失败,出现错误,例如'无法将某些代理强制转换为EntityManagerFactory').
mongodump util的性能影响是什么?
我找不到任何关于它的行为的官方文档,所以我很好奇某人现实中倾倒大数据库的经验.
java ×7
jpa ×2
oop ×2
performance ×2
algorithm ×1
architecture ×1
encoding ×1
grails ×1
graph ×1
hibernate ×1
java-melody ×1
maven ×1
maven-2 ×1
maven-plugin ×1
mongodb ×1
mongodump ×1
refactoring ×1
scaffolding ×1
threadpool ×1
tomcat ×1
transactions ×1
transient ×1