Rob Spoor

Sheriff
+ Follow
since Oct 27, 2005
Rob likes ...
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
Forum Moderator
Rob Spoor currently moderates these forums:
Cows and Likes
Cows
Total received
113
In last 30 days
5
Total given
50
Likes
Total received
1625
Received in last 30 days
5
Total given
2389
Given in last 30 days
3
Forums and Threads

Recent posts by Rob Spoor

With the resolve method, it will resolve the file relative to the path. Windows supports both \ and / for directory separators, Linux only /. As long as you don't have any \ in the path to resolve, the method should do the same on both Windows and Linux.
2 days ago
It could be caused by the properties parsing that uses \ as an escape character.

It the only issue is that the directory is missing a trailing \, then the solution is actually quite simple. Don't use string concatenation, use Path.resolve:

6 days ago

Norm Radder wrote:If there is an appletviewer.exe file in your JDK's bin folder, you can use that to run an applet.


AdoptOpenJDK 8 still contains it.
1 week ago

Stephan van Hulst wrote:But still, why don't you just put your Config class in the student-management-system package?


Because package names cannot contain dashes
1 week ago
Use MatrixToImageWriter to write a BitMatrix to a file or an output stream, or convert it into a BufferedImage. How that can be embedded in a PDF file depends on the PDF library you use.
2 weeks ago

tangara goh wrote:


How did that content type get created? Because the format is wrong; instead of multipart/form-data, boundary = ----------a bunch of digits' not supported it should be multipart/form-data; boundary = ----------a bunch of digits' not supported. In other words, between multipart/form-data and the boundary there should be a semi-colon, not a comma.

I'd also suggest not to use a boundary that start with any dashes, because multipart/form-data bodies use two dashes to indicate the start of new parts, and the end of the overall body. And I don't know if the spaces around the = are actually supported; I never add them.
2 weeks ago
I'm with Campbell. Since I moved to AdoptOpenJDK I don't use installers anymore, just the ZIP files (since I'm on Windows).
2 weeks ago

Deyan Perov wrote:

Cascades bubble "down".


Sorry, I don't get this.

In your example, any of the listed operations performed on Town will also be performed on all of the Students stored in the list.


Does this mean because I wrote this - @OneToMany(mappedBy = "townEntity"...) or because it this annotation is in TownEntity class?


By bubble down I meant, that any cascade that you define on a relationship will be applied to any entity on the other side of that relationship. If that has cascades on its relationships, it will go through those as well, etc.

Did you persist the Student before persisting the Town? Because otherwise the Student shouldn't have been persisted.


This is how I persist the Student.


That's not the persisting code, that's just the source of the Student and Town. But since neither has an id, the Town should only be persisted if either you persist it manually, or if the Student cascades PERSIST to the Town.

Be aware with REMOVE. Only use it if your entities are really tied together. If a Student can live without a Town, removing the Town should usually leave the Student intact. If you use REMOVE (or ALL) on every relationship, you can end up removing many records by just removing one. You'd need to first break the relationship (by removing the link between the two) before removing to prevent this.


Thank you for suggestion.

In my case I should left these:

But what about the other side, above attribute TownEntity? I don't see any affect do I left CascadeType.ALL or put only any other cascade. I know if I don't have any cascade it will be CascadeType.ALL by default.


By default there will be no cascading.

Campbell Ritchie wrote:

Rob Spoor wrote:. . . new toArray method: . . .

Is it this method, Rob?


It is.
4 weeks ago
Cascades bubble "down". In your example, any of the listed operations performed on Town will also be performed on all of the Students stored in the list.

Deyan Perov wrote:When I remove PERSIST it still creates the Town or Student, only where I saw affect is when I put CascadeType.REMOVE. If I remove a Student it will remove his Town too. Then I created two students and one town and when I remove the student id = 1 it removed both students and town.


Did you persist the Student before persisting the Town? Because otherwise the Student shouldn't have been persisted.

Be aware with REMOVE. Only use it if your entities are really tied together. If a Student can live without a Town, removing the Town should usually leave the Student intact. If you use REMOVE (or ALL) on every relationship, you can end up removing many records by just removing one. You'd need to first break the relationship (by removing the link between the two) before removing to prevent this.
Why don't you pull the trigger print out the value and find out?
4 weeks ago

Dave Tolls wrote:

Jesse Silverman wrote:
I memorized today that the preferred way to get a cloned array out of a list is:



Not sure that's necessarily the preferred way.
toArray() uses the supplied array if it's long enough to fit the contents of the list, otherwise it creates a new one of the correct size.
So with the above it will essentially create an additional object to then fill whereas:

will use the supplied array.

I mean, there's not exactly much in it, but one creates an object that's not used for anything other than figuring what type to return, and the other just uses the given object.


I also prefer to pass pre-sized arrays, but I've read somewhere that it's actually better to pass empty arrays. A quick search found another source: https://github.com/pinpoint-apm/pinpoint/issues/4138.

Of course, in Java 11 and later the solution is obviously to not use this method at all, but instead use the new toArray method:

4 weeks ago
Although that code tries to read from both the output stream and the error stream, it's still prone to deadlock. If the process outputs a lot to its error stream, and the error stream buffers become full, your code is still trying to read from the output stream. However, there's nothing coming to that because the process is blocked on its error stream, which you're not consuming yet. It also won't end because the process doesn't end.

There are two solutions:
1) Do the reads in two threads, one for the output and one for the input. This is what When Runtime.exec() won't teaches us. Be careful about interleaving the two though.
2) Use ProcessBuilder and call redirectErrorStream(true). You'll then only need to read from the process' output stream.

I prefer the latter, because it lets the JVM and/or OS deal with merging the two streams.
4 weeks ago
It's a great way to handle multiple optional arguments. Suppose you have a method like this:

You need to pass the first two required arguments, but if you want to additionally only use a non-default value for the third optional, you call it like this:

4 weeks ago