小编sie*_*egi的帖子

我注意到我的依赖注入,观察者模式繁重的代码(使用Guava的EventBus)通常比我过去编写的没有这些功能的代码更难调试.特别是在尝试确定调用观察者代码的时间和原因时.

马丁·奥德斯基和朋友们写了一篇冗长的论文,题目是"弃用观察者模式",我还没有花时间阅读它.

我想知道观察者模式的错误是什么,以及更好地引导这些聪明人写这篇论文的(建议的或其他的)替代方案.

首先,我确实在这里找到了一篇(有趣的)论文批评.

我看到LinkedList内部的JDK实现包含Node内部类,其中包含next和previous的地址.

所以我怀疑LinkedListjava不是双重链表.如果没有,为什么？

以及如何实现我们自己的双向链表？

简短版本:为什么File.createNewFile()不应该用于文件锁定？或者更具体地说:如果用于锁定应用程序数据目录,是否存在问题？

细节:

我想使用锁定文件保护我的应用程序数据目录:如果该文件lock存在,则该目录被锁定,并且应用程序退出并显示错误消息.如果它不存在,将创建它并继续应用程序.退出时,文件将被删除.

锁定将不会经常创建(即性能不是问题),并且在出现某些错误时手动删除锁定文件没有问题(即无法删除文件不是问题).

代码看起来像这样:

File lockFile = new File("lock");
boolean lockCreated = lockFile.createNewFile();
if (lockCreated)
{
    // do stuff
    lockFile.delete();
}
else
{
    System.err.println("Lockfile exists => please retry later");
    // alternative: Wait and retry e.g. 5 times
}

现在我对JavadoccreateNewFile()有点困惑:

当且仅当具有此名称的文件尚不存在时,以原子方式创建由此抽象路径名命名的新空文件.检查文件是否存在以及文件的创建(如果不存在)是针对可能影响文件的所有其他文件系统活动的原子操作.

注意:此方法不应用于文件锁定,因为无法使生成的协议可靠地工作.的的FileLock设施应改为使用.

考虑到存在检查和文件创建是原子的,注释中提到的潜在问题是什么？

2007年12月的这篇论坛帖子表明,根据File.delete()的Javadoc,存在"显着的平台差异" (尽管至少从Java SE 1.4.2开始我找不到这样的声明).但即使存在这样的差异:它们真的会导致锁定失败(即两个进程认为数据目录同时可用)？

注意:我不想要以下任何内容:

• 锁定文件,以便其他进程无法访问和/或修改它(我发现的大多数信息似乎都在讨论这个问题).
• 确保没有其他进程可以删除锁定.
• 同步同一JVM的多个线程(虽然我认为我的解决方案也应该能够处理它).

我试图在shell脚本中传递命令,但收到错误:

a.sh: command substitution: line 1: syntax error near unexpected token `('
a.sh: command substitution: line 1: `comm -12 <( sort /home/xyz/a.csv1 | uniq) <( sort /home/abc/tempfile | uniq) | wc -l'

代码片段 -

temp=`comm -12 <( sort /home/xyz/a.csv1 | uniq) <( sort /home/abc/tempfile | uniq) | wc -l`
echo $temp

注意:我发现了多个问题,指出了javacEclipse编译器之间的差异,但据我所知,所有这些问题都讨论了其他问题.

假设我们有这个方法:

public static <T, U> void foo(Supplier<T> a, Function<T, U> b, Consumer<U> c)
{
    c.accept(b.apply(a.get()));
}

javac在编译对此方法的调用时,我发现Eclipse Java编译器与Eclipse Java编译器之间存在不同的行为,我不确定哪两个是正确的.

这种方法的简单用法可能是:

// variant 1
foo(
    () -> Optional.of("foo"),
    value -> value.get(),
    value -> System.out.println(value));

编译器应该能够结合T到Optional<String>使用所述第一参数,并U以String使用所述第二.所以这个电话应该是有效的(在我看来).

这可以很好javac地编译,但无法使用Eclipse进行编译:

类型不匹配:无法从void转换为<unknown>

在第一个参数(() -> Optional.<String> of("foo"))中添加一个类型参数也使它在Eclipse中编译.

问题:从规范的角度来看,Eclipse是否正确拒绝此调用(以及为什么(不))？

现在假设我们想抛出一个自定义(运行时)异常,如果它Optional是空的:

// variant 2
foo(
    () -> Optional.of("foo"),
    value -> value.orElseThrow(() -> new RuntimeException()),
    value -> System.out.println(value));

这javac和Eclipse编译器都拒绝了,但是有不同的错误消息:

• javac …

如果出现错误或异常，Java AWS Lambda 最多会尝试重新调用该函数 3 次。有没有办法跟踪当前的调用计数，即知道它是第一次、第二次还是第三次调用？谢谢

在Eclipse的安装过程中（使用Eclipse Installer），我被问到“您信任这些证书吗？”，其中列出了Bouncy Castle的两个证书（一个由Sun签名，一个由Oracle签名）和一个Eclipse的证书（由Sun签名）。如何验证这些证书？

我了解这是JCE（Java密码学扩展）的代码签名证书，即Oracle签署的用于加密，密钥生成和密钥协议以及消息身份验证代码（MAC）算法的证书。我也知道Bouncy Castle通常用于提供与加密有关的算法。

两个问题：

1. 所有证书都由相同的两个CA签名，但是我找不到“官方” CA证书指纹的（公共）列表。我如何验证这些？
   • 由Sun Microsystems Inc颁发给JCE的JCE代码签名CA，有效期至2020-04-25，指纹57：37：D1：E1：16：2F：F6：FE：26：B9：87：88：D2：86： DA：66：7F：98：54：3C
   • 由Oracle Corporation颁发给Oracle Corporation的JCE代码签名CA，有效期至2030-12-31，指纹F4：B9：C6：4A：52：AD：22：3C：E4：BF：BA：52：52：87：9C ：9F：71：1D：4B：33
2. 为什么默认情况下不信任那些CA，即这些CA包含在JDK / JRE随附的某些信任存储中？CA由Oracle操作（至少CA证书这样说），我使用的JRE由Oracle提供（openjdk 11.0.2），我认为没有理由不信任CA（因为它们确实合法） 。