Rob Spoor

You're welcome.

Jack Tauson wrote:FileOutputStream fos = new FileOutputStream("your_files.zip")

That creates the actual zip file, and it puts it in "the current working directory". Why don't you use the dir variable here? Files has method newOutputStream that you can use just like the newBufferedWriter method.

A little off-topic, but you usually shouldn't use Void in any of the out-of-the-box functional interfaces. For most situations, there's an alternative that makes the Void superfluous. For instance, a Function<Void, X> can be replaced by a Supplier<X>, and a Function<String[], Void> by a Consumer<String[]>. The latter has as advantage that it doesn't need to return anything. Even with Void, you need to return something. Since you can't instantiate Void, that means you need to return null. By switching to a Consumer<String[]> you no longer have to, the functional interface's method already has void as return type.

If you install the new version in the same folder as the old one it probably will be left intact.

ZipEntry takes a String (or another ZipEntry, but let's ignore that), not a Path. You need to convert your Path to a String. For instance, to include the full path:
ZipEntry entry = new ZipEntry(file.toString());
It's also possible you only want the file name:
ZipEntry entry = new ZipEntry(file.getFileName().toString());

As for the CSVWriter, this takes a Writer, not an OutputStream. You need to wrap it:
try (CSVWriter writer = new CSVWriter(new OutputStreamWriter(zos, StandardCharsets.UTF8))) {
However, I will repeat my previous warning:

Rob Spoor wrote:Check out ZipOutputStream. In short:
   * Write content to the ZipOutputStream. Don't close it!

Closing the CSVWriter will close its nested OutputStreamWriter which will close its nested ZipOutputStream. As a result you can't write your second or third file anymore.

Can you please pick someone else in my place? The one message I posted during the book promo was meant as a joke, and I feel someone else deserves the book more.

No idea. They may be removed by the uninstaller, but I think it's more likely they will remain in place. If they do remain, then the installer will most likely leave them in place, and you end up with a newer Java version with the same libraries in <jre>/lib/ext.

Even worse is using the JRE extension mechanism, which allows JARs to be available by putting them in <jre>/lib/ext. That's just asking for problems, because JARs in this folder have precedence over JARs on your class path. We recently had a class loading issue with Bouncy Castle which we discovered was caused by an older version in <jre>/lib/ext.

Reminds me of this comic:



As long as people don't agree on what the best approach / framework / standard / ... is, there will never be a single winner.

If you're using Java 10 or before, you actually don't have to add any dependency, because it was part of the core Java libraries. For Java 9 and 10 you needed to add module java.xml.ws.annotation but that was enough. They removed this module (and all other JEE modules) in Java 11, so you do need that dependency if you're using Java 11 or higher.

Check out ZipOutputStream. In short:
* Create a ZipOutputStream wrapped around a FileOutputStream.
* For each file:
   * Create a ZipEntry.
   * Call putNextEntry.
   * Write content to the ZipOutputStream. Don't close it!
   * Call closeEntry.
* Close the ZipOutputStream.

That "Don't close it!" can be troublesome, because it means you can't use try-with-resources, or perform any other finalization that a wrapping OutputStream may need. A simple workaround is to create a wrapper that does nothing for its close method. You can extend FilterOutputStream and override close to do nothing, or you can use commons-io's CloseShieldOutputStream.

Welcome to the Ranch!

It appears you have a multipart/form-data request. You shouldn't read those directly from the input stream, you should use request.getParts() or request.getPart("aa") instead.

If you get a ServletException that indicates you do not have a valid multipart/form-data request, you should check the sender of the request - it's then not sending properly formatted requests.

Heh, Piet gets promoted within days of being promoted

Atul More wrote:If the ConcurrentHashMap is static then how the locking will work is the only thing is in my mind.

ConcurrentHashMap is built for optimized access, both read and write. It doesn't lock the entire map but only segments. That doesn't prevent threads waiting on each other, but it does try to minimize it.

Even though the map is used for read the data not even for update or add.

If the map is really read-only, then you can consider not using any concurrent structure at all - an unmodifiable map may be a better fit, especially if you can create it at class initialization time. A simple HashMap is thread-safe as long as you're only doing reads. Wrap that using Collections.unmodifiableMap and you prevent writes completely.

In Java 8 and before, you can use a static initializer block (this is also what you can use if your contents are more dynamic, because you can use Java code to calculate keys and values):
private static final Map<String, Integer> MY_MAP; static {    Map<String, Integer> myMap = new HashMap<>();    myMap.put("foo", 1);    myMap.put("bar", 2);    for (int i = 10; i < 15; i++) {        myMap.put(Integer.toString(i), i);    }    MY_MAP = Collections.unmodifiableMap(myMap); }
In Java 9 and after you can use Map.of:
private static final Map<String, Integer> MY_MAP = Map.of("foo", 1, "bar", 2);
The latter can go up to 10 entries; after that you need to use the varargs method and Map.entry method:
private static final Map<String, Integer> MY_MAP = Map.of(        Map.entry("foo", 1),        Map.entry("bar", 2),        ... );

Is there any other way to do it properly? Almost all inter-component communication I work with is either REST or SOAP (the latter mostly with legacy systems). A few exceptions use something else like ActiveMQ, but those are really exceptions.