static troubles..
Ok I have a program that asks for a password to be used in Password Based Encryption (PBE), I revently changed all my objects to static, because I heard it was safer or something like that..
Now whenever I send my password ( passField.getPassword() ) it says:
java.security.spec.InvalidKeySpecException: Password is not ASCII
I didnt change anything in my code with the exception of changing all objects to static. (I didnt get this error before, it worked fine)
Please help!
> Ok I have a program that asks for a password to be
> used in Password Based Encryption (PBE), I revently
> changed all my objects to static,
What? Objects aren't static. They're kind of mutually exclusive, actually.
> because I heard it
> was safer or something like that..
That's a very poor rationalization for making a major code change. You should KNOW what's safer.
> I didnt change anything in my code with the exception
> of changing all objects to static. (I didnt get this
> error before, it worked fine)
So change stuff back!
Could you explain the difference between static and not? or give me a link that describes it very well, because I cant find anything in the tutorials
It turns out that NOBODY can find things in the tutorials anymore! Thanks Sun!
Basically, "static" means "there is no associated object". So a static field or a static method operates on or is associated with the class in question, because there are no instances associated with it.
Similarly, a nested static class doesn't have an associated enclosing object, although there can be instances of the nested class.
So it doesn't really make sense to have a static object. Maybe you made all your code static, so there are no objects. Or maybe you made all the fields and methods static, but kept objects, which means that you wrote a bug factory, because the code probably assumes that each object has access to its own data.
Does that help?
Compare to the normal, non-static case. There's a separate version of each field for each object. So if you have a class Bob, which is declared with a field "fred", then each instance of Bob can have its own value of "fred". But if "fred" is declared static, then "fred" is separate from any single instance, and applies to the Bob class as a whole. So if you have five Bob objects, and one changes "fred", then "fred" changes for ALL Bob objects.
Generally speaking, you don't want to use "static". There are cases when you should use it, of course, but it's kind of missing the point of object-oriented programming to use it. You're missing out on a lot of functionality if you start declaring too much stuff static, and since Java is an OO language, you're going to end up with clumsy broken code if you program in non-OO ways.
Okay, so now how do I access methods from other classes in my package now that they arent static?
By creating one or more instances of your class.
Back in the good old days (up until yesterday or so), I'd have posted a link to the excellent online tutorials that Sun used to provide. However, Sun has decided that the people who cause Java to thrive by learning and using it would rather pay for a hardcover book than have a free online tutorial. Those tutorials are gone now.
So there is no other way to do it without creating more instances...?
Hi,
You should not be worried about creating instances. The JRE has a garbage collector which is taking care of deallocation of memory used by instances created by you once they are gone out of scope.
If you want all instances of your class to have same value for a property then make it static.
HTH
VJ
> So there is no other way to do it without creating
> more instances...?
Well, you have to create at least one instance. How many depends on the semantics of that class and what you're trying to do.
What's your objection to creating instances? Java is an object-oriented language. That means that much of your work will be with objects.
You define classes that represent the various kinds of objects and concepts that you're trying to model, then you create instances of those classes to represent the actual objects and concepts that you're working with, and you ask those instances to do things for you.
If you have an Employee class, you'll have one instance to represent Joe the Janitor and another one to represent Pete the President. Each one will have different state--name, home address, start date, pay rate, title, etc.--and each will exhibit slighly different behavior as a result of the different state.
