There is a corner case in String optimizations that is missing. It's a questionable programming practice, since the code sequence should just be replaced by "new String(s)", or even "s" assuming the new identity is not required. However, it might be trivial to support in OptimizeStringConcat? @State(Scope.Benchmark) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Warmup(ite
FULL PRODUCT VERSION : java version "1.6.0_23" Java(TM) SE Runtime Environment (build 1.6.0_23-b05) Java HotSpot(TM) Client VM (build 19.0-b09, mixed mode) ADDITIONAL OS VERSION INFORMATION : Windows Server 2008 R2 Standard with SP 1 Microsoft Windows [Version 6.1.7601] EXTRA RELEVANT SYSTEM CONFIGURATION : Windows Server time zone is 'America/New_York' Client time zone is 'Europe/Helsinki' A DESC
The "stand-alone" month names ("LLLL" format) in English are expected to be identical to the "context sensitive" ("MMMM" format) month names, but instead we see only numbers. This program: import java.text.*; import java.util.*; public class September { public static void main(String[] args) throws Throwable { Date date = new SimpleDateFormat("yyyy-MM-dd").parse("2010-09-15"); String[] formats = {
FULL PRODUCT VERSION : java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) ADDITIONAL OS VERSION INFORMATION : Windows 7 Professional Service Pack 1 A DESCRIPTION OF THE PROBLEM : The java.text.DateFormat.format() method returns inconsistent values for months if the Date object comes from a Calendar with germa
FULL PRODUCT VERSION : java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) ADDITIONAL OS VERSION INFORMATION : OSX Yosemite 10.10.2 A DESCRIPTION OF THE PROBLEM : The output of DateFormat is incorrect in the long form for Finnish, in that it adds an extra 'ta' to the end of the month name. java8 output: 6. maa
This is phase 1 of getting sun.nio.cs (java.base) and sun.nio.cs.ext (jdk.charsets) to work with module system. The current module system implementation requires the charset that might be used during vm startup to be in java.base module. The charset build mechanism needs to be able to configure a set of charsets that currently in extended charsets pakcage (sun.nio.cs.ext) to be re-located into sun
Looking at UNIXProcess.java.linux, there are a number of possible improvements: The "process reaper" thread should run in a thread pool to save on thread creation in case of repeated process creation. Its stack size should be small. If the process reaper thread throws a non-IOException (e.g. OOME) the thread creating the subprocess will hang, waiting for a signal from the reaper thread. The JDK kn
If this code is compiled: import java.io.IOException; public class FunWithMultiCatch { public static void main(String[] args) { Runnable r = () -> { try { Object o = null; o.getClass(); throw new IOException(); } catch(IOException | IllegalArgumentException e) { System.out.println("KO !"); } catch(RuntimeException e) { System.out.println("OK !"); } }; r.run(); } } javac generates this code: privat
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く