This week's book giveaway is in the Open Source forum.
We're giving away four copies of Programmers Guide to Apache Thrift and have Randy Abernethy on-line!
See this thread for details.
Win a copy of Programmers Guide to Apache Thrift this week in the Open Source forum!

Rob Spoor

+ Follow
since Oct 27, 2005
Rob likes ...
Chrome Eclipse IDE Java Spring Ubuntu VI Editor Windows
Forum Moderator
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads

Recent posts by Rob Spoor

Jack Tauson wrote:

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.
2 days ago
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.
4 days ago
If you install the new version in the same folder as the old one it probably will be left intact.
1 week ago
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:

It's also possible you only want the file name:

As for the CSVWriter, this takes a Writer, not an OutputStream. You need to wrap it:

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.
1 week ago
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.
1 week ago
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.
1 week ago
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 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.
1 week ago
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.
1 week ago
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.
1 week ago
Heh, Piet gets promoted within days of being promoted
2 weeks ago

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):

In Java 9 and after you can use Map.of:

The latter can go up to 10 entries; after that you need to use the varargs method and Map.entry method:
2 weeks ago
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.
2 weeks ago