Yes, var and the diamond operator can be combined together. The compiler will infer the most specific generic type: var list = new ArrayList<>(); // Infers ArrayList<Object> var list = new ArrayList<>(List.of(1, 2, 3)); // Infers ArrayList<Integer> And you can even combine them with an anonymous class: var list = new ArrayList<>() {};
There is no val in Java 10, as stated in JEP 286: Local-Variable Type Inference: Syntax Choices There was a diversity of opinions on syntax. The two main degrees of freedom here are what keywords to use (var, auto, etc), and whether to have a separate new form for immutable locals (val, let). We considered … Read more
One thing I notice is that your application (assuming that it’s packaged in tech.flexpoint.dashman) does not seem to be opened up to Spring in any way, which will surely result in failed class loading/illegal access. I would expect to see something like this in module-info.java (depending on your Spring dependencies): opens tech.flexpoint.dashman to spring.core, spring.beans, … Read more
I don’t say it’s a nice solution, but it seems to be a way through. Map<Long, String> dayOfWeekTexts = Map.of(1L, “Mo”, 2L, “Di”, 3L, “Mi”, 4L, “Do”, 5L, “Fr”, 6L, “Sa”, 7L, “So”); Map<Long, String> monthTexts = Map.ofEntries(Map.entry(1L, “Jan”), Map.entry(2L, “Feb”), Map.entry(3L, “Mär”), Map.entry(4L, “Apr”), Map.entry(5L, “Mai”), Map.entry(6L, “Jun”), Map.entry(7L, “Jul”), Map.entry(8L, “Aug”), Map.entry(9L, “Sep”), … Read more
jaxb-ri runtime uses ClassLoader#defineClass / Unsafe#defineClass to do some bytecode modification in runtime to optimize performance. ClassLoader#defineClass is tried first which causes the warning. This legacy optimization is removed completely in jaxb-ri master (after 2.3.0, not released yet). To disable this optimization for 2.3.0, set system property com.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize. After next jaxb-ri release updating to newest … Read more
I believe this was a bug which seems to have been fixed. Throwing a NullPointerException seems to be the correct behavior, according to the JLS. I think that what is going on here is that for some reason in version 8, the compiler considered the bounds of the type variable mentioned by the method’s return … Read more
Same problem fixed for me by setting JAVA_HOME environment variable to point to the JDK with right version. My source and destination java version in maven-compiler-plugin were 11, java -version was also on version 11, but my JAVA_HOME was pointing to JDK-1.8. Check JAVA_HOME again by using a terminal instead of IDE: Linux: echo $JAVA_HOME … Read more
[*] Update: JDK 11 Now Available sudo apt-get install openjdk-11-jdk For JDK 10 Option 1: Easy Installation (PPA) sudo add-apt-repository ppa:linuxuprising/java sudo apt-get update sudo apt-get install oracle-java10-installer Then set as default with: sudo apt-get install oracle-java10-set-default And finally verify Installation with: $ java -version java version “10.0.1” 2018-04-17 Java(TM) SE Runtime Environment 18.3 (build … Read more
This has nothing to do with var. It has to do with whether a lambda has a standalone type. The way var works is that it computes the standalone type of the initializer on the RHS, and infers that. Since their introduction in Java 8, lambda expressions and method references have no standalone type — … Read more
I assume that the project being migrated from Java 1.8 still has no module-info.java. This implies you are compiling code in the “unnamed module”. Code in the unnamed module “reads” all observable named and unnamed modules, in particular it reads module “java.xml” from the JRE System Library. This module exports package like java.xml.xpath. Additionally, you … Read more