I have been facing the above mentioned problem in my java application that I recently created. Even though I clearly set the field as JPasswordField and have tried to mask the password with astericks, I continue to face this issue. I issue does not occur when we edit the password field it occurs only when you select the row. For example I have 2 columns in a row and if I select the entire row and try to copy paste the row in notepad the pasword appears. I’m new in the world of java programming, if someone can help will be of great help.
Share
What you want is rather logical. When copy-pasting the data from your table the rendering should be respected.
The standard copy action will use the data available in your model, where the password is available as plain text. We could start a discussion whether you want to have your model contain a password as plain text, without any hashing applied to it … but that does not answer your question.
For your question you should modify the behavior of the cut/copy actions of the
JTable. Take a look at the Drag and drop Swing tutorial, and more specifically to the Adding Cut, Copy and Paste section. Unfortunately I do not immediately find an example to refer to.Edit
Find below an example of a
JXTablewhich uses the rendered values for the copy-action (I did not copy-pasted the imports). A little side-note about the code:TableModeland its elements are rather stupid. To avoid too much work I needed something similar to our real product to be able to copy some of the codeSpeedStringValueandAltitudeStringValueclasses violate theStringValueinterface as they returnnull. I was too lazy to define a new interface, and theStringValueinstance I set on the SwingXDefaultTableRendererbehaves according to the documentation. I think however that having separateStringValueinstances which each have knowledge for converting a specific class toStringis a real-world use-case which is lacking inSwingXTransferHandlerreuses theStringValuelogic to create aTablecontaining onlyStringinstances, and then falls back on the defaultJTablebehavior. This allows to reuse the logic implemented in the renderer, and allows to copy the visual values instead of the model values. I am not sure whether this is the nicest solution, but it works. It would be nice however if similar behavior was standard inSwingX, as they already have the infrastructureThe code lacks comments as it was already long enough. If something is unclear, leave a comment and I will try to clarify