1

my java dekstop send error like this what can i do?

getText() in JPasswordField has been deprecated

i have tried to replace getText() and change to getPassword():

pst.setString(2,txtPass.getPassword());
Paul Lemarchand
  • 2,068
  • 1
  • 15
  • 27
abdul kadir almasyhur
  • 43
  • 1
  • 9

1 Answers1

2

Convert the char[] to String. For that matter, you can simply use the String constructor String(char[] value):

pst.setString(2, new String(txtPass.getPassword()));

Alternatively, you can simply use @SuppressWarnings("deprecation"), as the main point of the deprecation, avoiding to create an immutable String, is entirely defeated by constructing a String out of the char[] array afterwards.

However, this is not a good idea, getText() is deprecated for a reason:

Once you've created the String, if another process can dump memory, there's no way (aside from reflection) you can get rid of the data before garbage collection kicks in.

With an array, you can explicitly wipe the data after you're done with it. You can overwrite the array with anything you like, and the password won't be present anywhere in the system, even before garbage collection.

Source

Community
  • 1
  • 1
Paul Lemarchand
  • 2,068
  • 1
  • 15
  • 27
  • 2
    Alternatively, you can simply use `@SuppressWarnings("deprecation")`, as the main point of the deprecation, the tenacious myth that using `char[]` instead of `String` improved security, is entirely defeated by constructing a `String` out of the `char[]` array afterwards. – Holger May 14 '19 at 08:38
  • @Holger That's a good point. Edited my answer to include your thoughts. – Paul Lemarchand May 14 '19 at 09:04
  • 2
    Well, then, it might be worth noting that the idea behind not using a `String` is the possibility to overwrite a `char[]` array after use. To make this an effective reduction of the attack window for software being able to read the heap, the software would have to fix the other issues, e.g. not write passwords into a database as plaintext. When using the `char[]` array to calculate the encrypted password, clearing the array after the calculation, even before accessing the database, is possible. But the password still exist within the `JPasswordField`, until explicitly cleared. – Holger May 14 '19 at 09:08
  • 2
    Recommended reading [Why is `char[]` preferred over String for passwords?](https://stackoverflow.com/q/8881291/2711488) – Holger May 14 '19 at 09:10
  • 1
    It’s your decision, how deep you will go into the matter, however, I’m uncomfortable with the impression, the cite of my first comment will cause by the reader. There’s a rationale behind the deprecation, which a developer should understand, before deciding whether to dismiss it or not. The main point of my first comment was that `new String(txtPass.getPassword())` is in no way better than `txtPass.getText()` and it’s worth understanding *why*. – Holger May 14 '19 at 09:31
  • You're both making good points. I hope the answer is more convenient now @Holger – Paul Lemarchand May 14 '19 at 09:32
  • @AndrewThompson Please see the changes and tell me if you think it is convenient as of now. – Paul Lemarchand May 14 '19 at 09:33
  • @Holger Done. I cited you literally because I'm always afraid my English skills come short when making complexe sentences. I guess I should have more faith in myself though. – Paul Lemarchand May 14 '19 at 09:42