It's certainly acceptable and even desirable if not required in some specific cases.
If and when you run into such cases, you'll know them as there will be no way to get the application compiling and/or running when doing things in other ways.
I'm gonna vote on the side of never having public instance variables (except static final immutables), even if you do believe your class is safe against some bozo arbitrarily changing its values from some arbitrary concurrent thread.
There's for example cases where for performance reasons (and yes, those are rare) the overhead of a method call is simply too much.
Of course you can still make them safe from change by making all data members final, so they can not be changed after setting them in the constructor :)
BTW, most modern IDE's (or at least, Eclipse) will generate all the getters and setters for your private instance variables with a simple menu command.
But if you're tempted to use this you need to ask yourself two questions:
1) Why am I exposing this data, even through a setter? There can be good reasons to do this, but generally you should let an object handle its own data. My favorite example for this is an object in motion. You could manage this from afar by setting its (x,y) position directly, manipulating the variables. You could set them through a setter, and you're really not gaining a lot of objectiness. If I throw a stone, I don't have to calculate its trajectory - it takes care of that. The point of object-oriented design is that the objects take care of themselves.
When you tell the object "turn 90 degrees and accelerate by five frobs", and it knows how to do that, then you're doing OO design. (even if "knowing how to do that" means calling out the back door to some motion engine!)
2) Second question: why am I doing this in an IDE? If you're asking these questions on this board, you shouldn't be using an IDE, you should be interacting directly with the code. Do that, and you'll be answering the questions, not asking them.
Perhaps that's the ANSWER rather than the question.
Question : Why are you making variables public?
Answer : Because IDEs like NetBeans seem to find public variables and they don't find private ones (you know, when you type in the variable name, then hit the dot, all the options come up. If it's private, it doesn't get offered as a hint). Quick, dirty, unpolished, and out the door fast, IDEs speed up the process. A lot of times for my own internal test programs, I just make everything public and use the IDE for that reason. One has to be careful not to let that habit get out of control, of course.