Rob Spoor

The documentation of File.length() implies that 0L is returned whenever the length could not be determined. Try using Files.readAttributes(child.toPath(), BasicFileAttributes.class) and you'll probably see an exception instead.

Mike Simmons wrote:1240528 is not a random example - it's today's date, 2024-05-28, formatted according to the format given in the original post, 1yyMMdd.  It contains no time info, only date.  This can be reversed to parse a given string as a LocalDate, e.g.
   DateTimeFormatter format = DateTimeFormatter.ofPattern("1yyMMdd");    var dateStr = "1240528";    var date = LocalDate.from(format.parse(dateStr));    System.out.println(date);

That LocalDate.from(format.parse(dateStr)) can be simplified as LocalDate.parse(dateStr, format), which is shorthand for format.parse(dateStr, LocalDate::from). All three create an intermediate object that is converted to a LocalDate, but the second form is shorter and (at least for me) easiest to read.

Ron McLeod wrote:

Kiran Er wrote:Can anyone help me with a java code which can convert below json into list of hashmaps

This may not be the best, but you could use Gson

Jackson also supports this, using TypeReference:
Map<String, List<Map<String, String>>> parsed = objectMapper.readValue(payload, new TypeReference<Map<String, List<Map<String, String>>>>() {});
Like Gson's TypeToken you need to create an anonymous inner class like this, because that allows reflection to read the generic types.

ChatGPT is lying. Temporary files are not removed automatically. You need to use shutdown hooks or (with File) call deleteOnExit). That's explicitly documented at Files.createTempFile.

Jack Tauson wrote:I found this.

https://blogs.oracle.com/javamagazine/post/transition-from-java-ee-to-jakarta-ee

Do you think this is still an up to date reference to figure out what things were involved as far as javax to Java EE conversion is concerned?

It still looks valid, although you should go to Java EE 9 instead of 8.

When in doubt you can use the search bar at https://docs.oracle.com/en/java/javase/22/docs/api/. Type in the package name - if it shows up you can keep it, otherwise it very likely needs to be changed to jakarta.

Not everything that starts with javax is part of Java EE. Quite a lot are part of Java SE, for instance javax.net.ssl, javax.sql and javax.swing. javax.print and javax.crypto are also some of those. In other words - no need to change them.

There's one that you need to take a good look at - javax.xml. Part of it is Java SE, but javax.xml.bind is for JAXB which is part of Java EE, so that needs to be replaced. Likewise for javax.xml.ws.

Paul Clapham wrote:Interestingly, it let me use Structured Concurrency classes without checking the "Enable Preview Features" box in the project's properties. Not even a warning. Although it might have been different if I'd tried running the compiled code outside Eclipse, I suppose.

Perhaps because that's not a language feature but an API feature?

Note that functional programming allows us to store the constructor as a field and provide it during construction of instances:
class A<T> {    private final Supplier<T> aFactory;    T a;    public A(Supplier<? extends T> aFactory) {        this.aFactory = Objects.requireNotNull(aFactory);    }        void f() {        a = aFactory.get();    } } A<String> a = new A<>(String::new); // A<String> a = new A<>(() -> new String());

What if I did the following?
A<LocalDate> a = new A<>();What would a.f() do, considering that LocalDate doesn't have a no-arg constructor?

But even if you could find a way to declare that a constructor exists (and I actually have devised syntax for this), it's not possible because of type erasure. Generics in Java only exist at compile time. In the compiled byte code it's replaced by the best matching type:

With <T> the best matching type is Object

With <T extends X> the best matching type is X (for example, <T extends Serializable> leads to Serializable)

With <T extends X & Y> the best matching type is X as well. This is why Collections.max uses <T extends Object & Comparable<? super T>> and not <T extends Comparable<? super T>>; the former results in Object which was needed for binary compatibility, the latter results in Comparable

With <T super X> and <T super X & Y> the best matching type is Object

So your example would compile to this:
class A {  Object a;      void f() {    a = new Object();  } } A a = new A();
If I would try to access a.a, the compiler turns that into (String) a.a. Because it wouldn't be a String you'd get a ClassCastException.

Stephan is right.

A better version would be int mthd(Class<? extends Enum<?>> enum), unless the first version should be <T extends Enum<T>> int mthd(T enum).

Which one to use depends on what you prefer to read, and whether or not you need that T inside your method.

Stephan van Hulst wrote:That would be a really bad idea.

In essence, that means that I can no longer control whether and how a caller makes an instance of my class, and it also means that I can create instances of classes without providing the bare minimum of information they need for initialization.

Consider the following example:
var i = new Integer();
First of all, you're not supposed to instantiate an Integer directly. You're supposed to use a literal or one of the valueOf() factory methods. Secondly, if you DID instantiate an Integer directly, then what would it even mean to instantiate one without a value?

Remember, according to your proposal, Integer should inherit the parameterless constructor from the Number class.

This could be circumvented by only automatically creating constructors if no explicit constructors exists. If you create just one constructor manually, no more automatically created constructors. That's already done right now with the no-argument constructor, but this would actually change what the compiler does - a single no-argument constructor might not be added anymore, but several others.

I don't think Oracle will implement this, and I won't miss it. Within seconds my IDE can create these constructors just as easily (and those seconds are me find the right context menu item).

Tim Holloway wrote:Java supports a "universal" file path notation which is essentially that of Unix. There are conversion rules that can map DOS paths to this notation and they necessarily include the drive ID. So "C:\Program Files\java" maps as "/C:/Program Files/java". Resolving in the other direction is ambgious, so expect that "/" will map to the root directory of the currently-logged drive.

I don't think this is correct. In Windows, it's not allowed to have "/" in file names. Java uses that to translate every "/" into "\", both in the old File class and in NIO/2.
The file path "/C:/Program Files/java" cannot be used in Windows applications. I've seen it though, but I think that's mostly in URIs. You can use it with File but not with Path.of. You can use "C:/Program Files/java" with both though; that gets translated to "C:\Program Files\java".

Windows does have a "\" though (which means you can use "/" in Java). It's the root of the current drive, e.g. "C:\" or "D:\".

Assuming you're not doing something stupid like uploading/creating/altering files within the WAR directory structure. Which will fail horribly on an unexploded WAR.

Not to mention that with exploded WARs, you'll lose those changes after each deployment.

One final note. Java is a very bad language to use a "current directory" in. There's only one current directory for a given JVM instance, and since many processes may be running under that JVM, you can not be 100% sure that one of them might change the current directory programmatically at any given time. So as a rule, absolute paths are preferable, the Universal path notation is likewise preferable and ideally that path should include the currently-logged disk when running Windows.

As far as I know, it's not possible to change the current directory at run time. You can set it when the JVM is started using system property "user.dir", but once the JVM has started, new File(".") and Path.of(".") will always refer to the same file. Unless maybe, very maybe, it's possible with some nasty native code or reflection to change it.

The problem is you're mixing Windows and Linux (through wsl).

In Windows, /Try is equivalent to C:\Try. (It can be on a different drive, that all depends from where Java was started, but you've already shown that the current drive is C:.)
In Linux, / is just that: /. The matching directory for Windows' C:\ is not / but /mnt/c; you can see that in the console snippets you've shown:

Anil Philip wrote:

PS C:\> wsl
ANIL-PHILIP-LAPTOP:/mnt/c$ sudo mkdir /Try/tea/
ANIL-PHILIP-LAPTOP:/mnt/c$ sudo mkdir /Try/tea/earlgrey
ANIL-PHILIP-LAPTOP:/mnt/c$ sudo mkdir /Try/tea/hot.txt

I can see it did create the files

ANIL-PHILIP-LAPTOP:/mnt/c$ cd /Try/tea/earlgrey/.././hot.txt
ANIL-PHILIP-LAPTOP:/Try/tea/hot.txt$ cd ..
ANIL-PHILIP-LAPTOP:/Try/tea$ ls
earlgrey  hot.txt

You see from the prompt that you start in folder /mnt/c, but you create /Try/tea. The second console snippet shows that if you cd into /Try/tea/earlgrey/.././hot.txt the current folder is /Try/tea/hot.txt. That does not match Windows' C:\Try\tea\hot.txt because in wsl that's /mnt/c/Try/tea/hot.txt.

That would probably be caused by JEP 396: Strongly Encapsulate JDK Internals by Default and JEP 403: Strongly Encapsulate JDK Internals. Before Java 16, there would be a warning. The first of these JEPS changed the default from warn to fail, but it was still possible to switch back to fail with a JVM flag. The second JEP caused this flag to be ignored; it will be completely removed in some later release.

I've become a bit of a fan of @snippet. Before I used a combination of pre and code HTML tags. While that worked, it allowed any code to be included in documentation - even code that didn't even compile. With @snippet I've been able to link to (parts of) actual classes, that I've added to the test source path using Maven. The end result are code snippets that actually compile.