Posts by JamesCherrill

You create and start a javax.swing.Timer to run every "n" millisecs.
It has a reference to some class with an ActionPerformed method, and it calls that method every "n" miliisecs.
eg:

import javax.swing.Timer;
...
// in main program initialisation...
int milliSecsBetweenRuns = 100;
Timer timer = new Timer(milliSecsBetweenRuns , new ThingToRunRepeatedly());
...
// in rsponse to space key pressed...
timer.start();
...
// in response to space key released...
timer.stop();

... and the thing that gets called is as simple as this...

// gets called buy the timer every 100 mSec as long as space key is down...
class ThingToRunRepeatedly implements ActionListener {
  public void actionPerformed(ActionEvent e) {
     // update x,y coords etc 
     // call repaint for the main window 
  }
}

Where do you load the word into letterArray?

Use a JLabel instead?

Is that line 79? If so, you need to exit the loop after finding a match - otherwize you just go on to test all the other chards - which don't match.

OK - that's also something that is better handled with a Swing Timer. Loops like that execute at very different speeds depending on the hardware, and lock up the CPU thus interfering with GUI response etc. Swing Timer is the way to go.

I want it to animate my bullet across the screen just by pressing the space bar(not by pressing the space bar mulitple times).

On KeyPressed start a Swing Timer that fires every 1/n secs and moves the bullet each time it fires. On KeyReleased, stop the Timer.

ps what on earth is this code supposed to achieve?

for (int q = 0 ; q < 1000000 ; q++)
{
}

== to test for equality of 2 chars. = is assignment

Read the whole of the error message - it tells you the line number where the error is found.
Deprecated means you have used something from an old version of Java that has been replaced by something better. Look at the method(s) you call on the relevant line. The JavaDoc API documentation will tell you how you should update your code

NullPointerException ("NPE") means either you are using a variable that hasn't been initialised, or you are using the result of a method that has returned null.
Search down the error listing until you find a reference to one of your classes, and that's where the error happened, in this case:
at OptionWindow.<init><OptionWindow.java:63>
<init> means during initialisation of a new instance (ie in the constructor), but 63 is the exact line number in file OptionWindow.java

I had a very quick look at the code, and it looks like you have initialised all the JLables. but not the JTextFields, so when you try to add a text field to the window, the variables holding the text fields are still null.

Even at the pseudocode level that's not going to work:
firstStep = console.nextLine(); eg "ooxxx"
secondStep = firstStep.replaceAll(o, x); "xxxxx"
thirdStep = thirdStep.replace(x, o); "ooooo"
System.out.println(thirdStep); "ooooo"

This needs an extra step:
replace all the o with some temp char
replace all the x with o
replace all the temp char with x

Personally I haven't seen any "ordinary" uses for it other than:
1. Data-driven logic - eg storing method names as data then executing them
2. Remote method invocation kinds of interfaces - where a method name is sent across a socket connection for the method to be executed at a server and the results returned.
It's certainly not a thing you use every day.

Here are a few:

You can use it to hack into methods that are declared private. Eg there's a popular hack to give access to the Windows registry by gaining access to the private methods used by the Preferences class to read/write the registry for its own purposes. (NB I'm not advocating or endorsing such dubious practice).

Recent annotation-based advances use Reflection to combine annotations with the Java code they annotate.

Builder tools that work with JavaBeans use reflection to obtain the properties of the beans at runtime.

Yes, BufferedReader / PrintWriter is the "standard" way to copy text files, but I wouldn't rely on them for files with arbitrary binary data. For files in general I'd use DataInputStream and DataOutputStream, reading/writing in decent sized blocks (byte arrays) of maybe 4k bytes.
Even so, it looks to me like NeverSleepin's version should work, once the surrounding logic is right.

ps: I meant the original version - using Logger seems a very round-about way to do things to me; this program can be written with pretty simple & obvious code using just the classes/methods mentioned above

You re-open the output stream each time you go thru the multiple file loop - this erases the previous contents each time. You should open the output stream before entering the multiple file loop, and only close it after the last file has been copied. (You could alternatively open it in append mode on each pass of the loop - but thats inefficient.)

the read method reads one byte from the stream and returns it in the bottom 8 bits of an int variable, so that's why you get numbers. If the file happens to contain ASCII text then these numbers will correspond to the ASCII codes for each character.
write works similarly - takes the low-order byte and writes it to the output stream.
I've never tried doing it that way, because either I would use a BufferedReader to read whole lines of text and write them out to a PrintWriter, or I would read & write whole arrays of bytes if the file was more complex than just lines of text. However, I think what you're doing should work, maybe just a bit slower.
Try reducing the file copy part to its simplest form (copy one very short fixed input file to an output file) and get that working before you try to wrap it in the directory-traversing multiple file case.

Show us the relevant code

Good morning. Things have obviously stalled here.
Line 20 you open the input stream using the file "here" - but that's the File you used to hold the directory, and you can't read a directory with an input stream!

line 10 is good:
for(File content : here.listFiles()) {

so line 20 needs to be
FileInputStream fis = new FileInputStream(content);

Get that working and we'll then move on to the next pproblem (it's to do with the output file...)

Debugging Exceptions summary: printStackTrace tells you what error and where (line number). Look at that line. If it's not obvious use System.out.println(...) to print the variables and expressions used on that line so you can see what exactly has gone wrong.

OK guys - its 23:00 here and I'm going to bed now. Here's a final clue:

Line 29 if trying to read stream fis which is created on line 20. It's supposed to be a file in the directory, but look closely at line 20 - what File is that???

Good night
J

ps: bibiki - your contribution IS valuable and welcome. Please keep contributing. Maybe you can finish this one off while I get some sleep!

Hi bibiki
Line 29 is the normal way to read a char and test for EOF - it's OK as written.
I think the {} on 12/13 are just an artefact of the various things the OP has tried.
I'm currently trying to help him to learn how to debug this kind of thing - so he can get to the obvious error (I'll PM you what it is if you like) and gain some useful skills at the same time. If you've spotted the error, please help OP to find it for himself, don't just tell him what it is

That seems unlikely - you shouldn't get a FileNotFoundException before you try to do any kind of file access. In your catch blocks rather than printing the short exception message, get the full stack trace
e.printStackTrace();
This will tell you exact line of your program where the error was first detected (in general you should always have a full printStackTrace() for any exception when you first write a program - the info it gives is essential for debugging)

A few debugging print statements would help.

eg print something (including the file name) immediately before & after trying to open/read/write each file. That way you can see which file it was trying to open/read/write when the error occurs

Would be useful to know which file caused the refused access - especially if it was the output file. A few debugging print statements would help.

OK. Time to mark this thread as solved?

No way.
BigInteger stores the number in normal binary form, using an array of ints big enough to hold all the bits for the number. At approx 10 decimal digits for each int, your 600 digit number only needs array approx int[60]. I don't think 240 bytes is going to run you out of memory - your problem lies elsewhere. Anyway, you get an explicit runtime Exception when you run out of memory.
Can you share your code?

AFAIK BigInteger will handle as many digits as you have memory for, certainly 600 is OK.

Each time you call your method test you create a new ArrayList. Just declare and initialise it outside that method.

Have a look at the PixelGrabber class for getting pixels from images in general

With the commented line in you read the whole file into the buffer. Then in the while you start by reading again - but the file has now been read so you get an immediate end-of-file and the var is et to -1.
read(byte[]) works just fine.

Don't have time to cehck this now, but don't you need a default constructor for a Serialisable class to be restored?

That's probably OK for a college project, but just remember that it's poor practice for real life - Java is designed for use with multiple languages, so the text in your GUI could end up in a user-defined choice of English, Arabic, or Japanese; you can't use it reliably to identify things in your code.
Anyway. mark this one as "solved" and start a new thread if you get a new roblem.

Forget about relational stuff. This is Object Oriented. You don't create a relationship using IDs, you have variables that contain direct to the objects themselves. Don't worry if this doesn't quite compute yet - it's a concept that sometimes takes a little time to grok, especially if you've just come from doing relational databases.
You get an instance of Client somehow, you get an instance of DVD somehow. You create an instance of Rental that has the Client and the DVD as its instance variables. The ID's play no part in that.

No, it will return the actual JRadioButton object. So, for example, you could say
if (getSelectedButton(group) == one) ...

ps: I just typed that code but I didn't test it, it's just a starter for you. You may need to debug it a bit. maybe.

That looks like a mistake - the Rentals (Java classes conventionally begin with an upper case letter) class should have an instance of Client, not just a clientID (ie like the 3 DVD members).

Here's some code you can use as a starting point. Please share your final solution with everyone here - it's a common problem.

public  JRadioButton getSelectedButton(ButtonGroup group) {
      Enumeration<AbstractButton> e = group.getElements();
      while (e.hasMoreElements()) {
         AbstractButton b =  e.nextElement();
        if (b.isSelected()) return (JRadioButton) b;
      }
      return null;
    }

This is (IMHO) a horrible design omission in Swing - AFAIK there's no simple method to get the selected JRadioButton in a ButtonGroup. Most people just loop thru the buttons using their inherited isSelected() method to find the one (if any) that's selected OR they have a Listener for the buttons that keeps track of the current selection.

So put some System.out.println statements into the relevant parts of the code to see which code is being executed and whether the variables have the values you expect.
(It's called "debugging").

Account newAcc is defined inside buttonCreateActionPerformed so it can't be accessed from outside that method.
You haven't explained the overall logic of your app, so I can't suggest the best way to fix this. But deposit is an instance method of Account, so you should just be able to call deposit(5000.0); in buttonDepositActionPerformed (which is an instance method, so the instance of Account is already part of its context and doesn't need to specified again).

A blank final var must be initialised in all constructors - ie it must have a value by the time the containing instance has been initialised.

Yes, if the brief is to count the letters then the isLetter method is the "correct" way to go.
The 97's and 'a'-1 stuff is a dead end. It only works for the 26 non-accented English letters and even if that's enough for this exercise, it's definitely not enough for anything real. As an algorithm it doesn't scale up either. As long as you know that chars are numbers, and each letter is represented by a different number defined by the UNICODE system, that's enough.

if (charInt>=97 && charInt<=122) { charInt -= 32; } // convert lower to upper
if (intLetter>=1 && intLetter<=26)

When will people ever learn? Of all the world's many languages, English is just about the only one that uses a 26 letter alphabet. Even Spanish and French have accented characters with upper and lower case variants, and German has a commonly used additional letter that is not in the 26.
This kind of code, that assumes US ASCII 7 bit coding, has no place in Java, which is UNICODE.

Please use the methods that the Java developers have provided to ensure some kind of international correctness.

Finally. nobody has actually mentioned the key point for the OP - char is an integer data type. You can simply assign a char to an int without needing to convert anything.

Is the content length being returned as zero?
Does the if on line 61 evaluate to false?
Is stream.available on line 70 zero?

Just a gut feel - but the whole loop starting line 74 seems insanely complex - why not just create buf of the right length and read the whole stream into it directly?

You can't send a ref between different JVMs, but why have 2 JVMs?
If they really are different JVMs the your choices include a file or a socket connection. 500KB is a very small amount of data so either way it's all going to be in in-memory buffers.

"move data with large size from one object to another"? Move or just get access to? How large? Objects in the same JVM? Different JVMs on the same machine? Two machines in the same network?

In general trying to optimise code before its working ("premature optimisation") is a waste of time.

Once a thread is started it executes "until the app exits" OR until the run method terminates normally. Unless the run method contains an infinite loop sooner or later it will either execute a "return" statement, or it will drop out of its last statement (or throw an Exception).
The "true" in quuba's code just ensures the loop keeps on running until something else stops it.
The idea of the sleep is to control the speed at which the repaints happen - ie if we flatten the loop it goes
repaint
sleep 100 mSec
repaint
sleep 100 mSec
etc
Without the sleep the JVM will execute repaints as fast as the CPU can go, and this will make it animate far too fast, and it will be difficult or impossible for any other threads to execute.
You don't need to override Thread's start() - just call it.

Having answered all those questions, I now have to tell you that, depending on what else is going to be in your app, this is probably the wrong way to do this (sorry). You can stay with this a bit longer, and you should be able to get a basic animation running, and you will learn good stuff about how Java threads work.
If/when you run into serious problems you can switch your code to use the recommended approach (Swing Timer) to run your animation. This uses and integrates properly with the …

IF your class extends Thread the it inherits the start() method, and you can start it. Otherwize you need a new Thread(yourRunnableInstance) and start that.

That's really interesting. I too can assign a String too what should be an Integer and it works.
The real answer is to declare nn1 fully, as in
R2<Integer> nn1 = new R2<Integer>();
ij which case the compiler correctly rejects (1)

Without a server you may have a problem getting the IP addresses of the two machines that need to communicate. JmDNS http://sourceforge.net/projects/jmdns/ can be useful in that case.

Split is usually the easiest way to split a sentence into an array of words - try it and see what you think!

Yes, the keyboard generates events when a key is pressed and when it's released. If you hold down a key while y ou press another you get
key1 pressed
key2 pressed
key2 released
key1 released
(etc)

Without your code I have no idea why things change speed. Are you using a javax.swing.Timer to control your repaints?

AFAIK it's no problem if you handle KEY_PRESSED and KEY_RELEASED KeyEvents.