Posts by JamesCherrill

You can convert an int to String with the String.valueOf(int i) method, but you will often see people using string concatenation because Java will find a way to convert any non-string values to string in order to perform the concatenation. That's the method Seldar hid carefully in his undocumented code (line 15) - concatenating the int with a string value of "" to force conversion of the int to string.

More seriously, when you change the title of a JFrame 5000 times in some tiny fraction of a second, what exactly do you expect to see on the screen when Swing finally gets its slice of CPU time?
...and before someone with limited Java knowledge suggests wait(1000) or sleep(1000), have a look at javax.swing.Timer.

Sorry, I'm out now until tomorrow. Do try to run your code - the sooner you run it the sooner yo will find the bugs. Just hard-code values for anything that you need but haven't sorted yet. Trust me, real programmers test early and test often.
See you tomorrow.
J

Surely by now you know how to call a method using a variable to specify which object you are calling it on. It's one the very first things you learn in Java (rememberSystem.out.println(...) ?)

It really is that simple, eg let's suppose the2D array is called weights, then if the user asks if row B, position 4 is occupied, your test is

if (weights[1][3] > 0)

(remember Java arrays start at element 0, not element 1)

You have a 2d array (rows / positions). All its entries will initially be zero. When you place a musician you put their weight into the corresponding entry. So it's really easy to see if a position is empty (the entry is still zero) or occupied (the entry is a non-zero weight). And to remove a musician just set the entry back to zero.

So when you say this.push(something); you are trying to call the push method of "this" - the current object (the current ListStack). You want to invoke the push method of your Stack (the one you created in the constructor)

The main advantage of Semaphore is that you can limit access to n threads, not just one thread, at a time. Personally I would use synchronised to limit to one thread at atime, mainly because its simpler and more obvious code.

Getting closer...
now what is the object (list) onto which "something" is being pushed?

OK, so you need to look at the API doc for Stack to find the correct syntax for pushing an item onto the stack. (hint: the item to be pushed should be in there somnewhere)

If there is supposed to be a push() method tghen write it. If that's wrong then fix line 14.
I'm not sure what your problem is with this... what is line 14 intended to do?

In the method above (plus(T something)) I get an error on push. Eclipse tells me to create a new method called push.

That's clear enough. What's your question?

I want a new stack to be created whenever someone creates a stack list object

Isn't that what line 9 in your constructor does?

I think that compiled stub stuff related to an earlier version of RMI (pre Java 1.5), but the current version works at run time via reflection and so doesn't need the old skeleton/stub files. That's one danger of using a book rather than current online sources.

codebase is an HTML spec that's used for loading applets' needed classes and aother such stuff

Its an example of Java Generics - introduced with Java 5 (AKA 1.5).
I could try to explain then more, but Oracle have already done that in their excellent tutorials
http://docs.oracle.com/javase/tutorial/java/generics/index.html

This particular example means the parameter classToAddToServerCodebase must be an instance of Class, but that Class must be a class that extends (implements) the Remote interface.
I could just say

    public static void rmiStarter(Class classToAddToServerCodebase)

but then it would allow any old Class to be passed and the code would fail at runtime. Through the generic spec the compiler will know to check that any Class passed to my method will implement Remote and thus work properly.

You can't just remove data from the middle of a sequential file.
Your two "easiest" options are
1. Copy the file record by record, omitting the record(s) you want to delete
or
2. Open the file as a random access file and overwrite the record with some values that your program will recognise as meaning "deleted record" when it reads the file.

Although, if your application involves updating and deleting records then maybe you should bite the bullet and use a proper database - all current versions of the JDK come with a complete JavaDB SQL database that will do all you need.

That's it. You close the scanner at the end of the first pass of the while loop, so the second pass fails. Better to close the scanner after you have finished with it!

Yes. Whenever you see code repeated like that, with one value changing from line to line, you just know it should be a loop. Eg::

for(int i=0;i<str1.length;i++) {
   graphics.drawString(str1[i].toUpperCase(), 360, 50 + i*10);
}

In general a jar will run on any higher jre version. It's possible you may run foul of tighter security settings, as there have been a number of changes there since 1.5.
How exectly does it "fail"? - absolutely nothing happens - runs but wrong results etc?
Did you try running the jar with java.exe (as opposed to the normal javaw.exe) so you can see the console output?

You are drawing them all at the same position 250,200
You need to increment that position's x or y value after each print so the next string goes to a different position

I don't see you calling that method, that might explain a lot.

No, the code is correct (except for the error identified in my previous post). You call PrinterJob's setPrintable passing an instance of a Printable. The Printable interface specifies the print(etc) method, and so it's the PrinterJobb that calls his print method. An @Override annotation on his print method would have made this clearer...

OK, here's what you did wrong...

In your class you created a printer job...

PrinterJob job = PrinterJob.getPrinterJob();

Then in the actionPerformed you created another one ...

PrinterJob pj = PrinterJob.getPrinterJob();

Then you proceed to mix the two up ...

job.setPrintable(this);
if (pj.printDialog() == true)
...  pj.print();

That's why your print doesn't work. I'm sure you can see how trivial the fix is, knowing that.

I'm comparing your code with a small demo I wrote a while ago - I thought the demo was pretty minimal, but your code is a lot smaller, so maybe you're missing something essential. Just in case you may find it useful, here's that demo...

The interface is just one method that takes an int, adds one to it, and returns the result...

package misc;

import java.rmi.Remote;
import java.rmi.RemoteException;

public interface RMIInterface extends Remote {

   public int plusOne(int i) throws RemoteException;
}

The client just locates the server, calls the remote method and prints the result...

package misc;

import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

public class RMIClient {

   public static void main(String args[]) {

      try {
         RMIServer.rmiStarter(RMIInterface.class);
         Registry registry = LocateRegistry.getRegistry();
         String serviceName = "PlusOne";
         RMIInterface server = (RMIInterface) registry.lookup(serviceName);
         int i = server.plusOne(2);
         System.out.println("RMIClient result: " + i);
      } catch (Exception e) {
         e.printStackTrace();
      }
   }

}

The server is more interesting because it includes some bullt-proofing code to avoid some common configuration problems... (1) start the naming server if one isn't already running and available, (2) set the java.rmi.server.codebase System property, and (3) creates a security policy file that allows everything and uses that.

package misc;

import java.io.BufferedWriter;
import java.io.File;
import java.io.FileWriter;
import java.io.IOException;
import java.rmi.Remote;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
import java.rmi.server.UnicastRemoteObject;

public class RMIServer implements RMIInterface {

   @Override
   public int plusOne(int i) throws RemoteException {
      return ++i;
   }

   public static void main(String[] args) {

      try {
         rmiStarter(RMIInterface.class);
         Registry registry = startRegistry();
         String …

You CAN compile it. You don't need a main method to compile one or more java files, you just need one to execute a program.

Looks like you may not have your RMIInterface.class file in the classpath of the client (and/or server?).

The name being bound is normally just an ordinary string, maybe starting with a package name just to keep it unique. The doc says it's not parsed, but it looks like the // at the front is causing someone to try to parse & interpret it. This is just a guess, but try something simpler eg "sample.test.RMIserver"

There are no compiler messages.

Look again...
Your class definition ends on line 6 - how did you compile what follows?
Line 33 is invalid syntax - how did you compile that?
(etc)

And your main method makes things a LOT worse...
How many times have we said this in the Java forum...
Never NEVER NEVER do this when writing new code:

} catch (Exception e) {
}

If/when there is an error you just told Java that you didn't want to know anything about it, and please discard the detailed error message that Java just created for you.
ALWAYS put an e.printStackTrace(); in your catch blocks until/unless you have a good reason to do something else.

It doesn't print because it doesn't run because it doesn't compile!

Read all the compiler error messages, fix all the compile errors, and maybe you will get a bit further.

I think your original if test was correct. The problem is the semicolon at the end of line 8, which terminates the while block right there, so the message dialog is not part of the while, and always gets executed. Just get rid of that ;

Its a hierarchy. At the bottom are simple components like keypad, screen, cash dispenser, mainframe access. Each knows how to do it's own limited set of functions. None of them needs to know about the others, or even know about the ATM.
Above these is the "master" ATM object, that owns one screen, one keypad etc and orchestrates the whole thing to produce a useful result. It doesn't need to know how any of those components work, it just knows what functions they can provide (their public methods). eg Here's part of the code for ATM's doCashWithdrawal() method

int amountRequired = keypad.getAmount();
boolean isOk = mainframeAccess.validateBalanceAvailable(amountRequired);
if (isOK) {
   cashDispenser.dispense(requestedAmount);
   screen.display("Take your money");
} else
   screen.display("Request refused");
}

The goal of all this is to divide the code into pieces that are. as far as possible, independent of each other, and thus easier to write, read, and maintain. Here'a a good article on the subject:
http://msdn.microsoft.com/en-us/magazine/cc947917.aspx

Most people just place the Images directory alongside the package directories for the application's class files. Eg if you have MyMainClass in a package myApp then the Images directory would be placed next to the myApp directory (in which the MyMainClass.class file is found).

Because you want your ATM to be able to do things like

    int pin = keypad.getPin();
    or
    screen.displayBalance();

in the ATM class, you need references to its Keypad ans Screen objects. Otherwize the ATM won't have any link to its screen/keypad and it won't be able to use them.
It really is as simple as that.

It's just like the Quit button you already have, but in the ActionListener instead of the run() method just being system.exit(); itshould have the necessary code to set the text of the field you want to update.

Lines 52-54 you have a synch block in which you wait on the lock object. But no other thread can get the lock to execute their notify, so the app hangs.

Just synching on the same lock object will prevent simultaneous access from different threads. YOu only need to get into wait/notify if you want to force some kind of management of which thread runs when, eg to make them alternate strictly.

Finding files froma Java program is always a difficult area, especially when moving from an IDE to a runtime environment. There's always confusion and doubt about where the files should be.
The getResource is a good approach. If you change your path to "/Images/dragons.jpg" and place the Images directory in the classpath then all should be OK. Most people just place the Images directory alongside the package directories for the application's class files. That way if Java can find the classes then it can find the images as well. In prticular this allows you to place everything in the same jar, and the code runs just like it did in the IDE

It's not clear what it is you don't understand... I suspect you already know the answer but are looking for a problem that isn't really there?
Maybe this will help?...

When you set up a new ATM it will need a Screen abd a Keypad, eg

public ATM() { // constructor
   screen = new Screen();
   keypad = new KeyPad();
   ...

then later in the code you will be able to do stuff like (just made this up)

   int pin = keypad.getPin();
   ...
   screen.displayBalance();

Does that help? If not maybe you can clarify exectly what's worrying you.

Like I said before, use Day for the outer index, and hard-code the inner indexes, eg

   System.out.printf(leftAlignFormat,"Day "+ Day, myArray[Day][0], myArray{Day][1] etc

ps: Java convention is that variables have names that start with lower-case letters (class names start with a capital)

1. Yes, that declaration is OK

2. Looping goes like:

      for (int i = 0; i < myArray.length; i++) {
         for (int j = 0; j < myArray[i].length; j++) {
             do stiff with   myArray[i][j]
         }
      }
   

Declare a 30x5 array (an array of 30 elements, each of which is a 5 element array of ints).
use your Day variable (line 14) to index the outer array, and hard-code the inner array refs, eg myDataArray[Day][0] instaed of the first "i" on line 16

That code seems to do what your topic title asked, so what exactly is your question now?

Why is it not feasible?

Unwrap your loop, ie

SELECT * FROM myTable WHERE columnId < 45...

result of current row goes to row1.txt;
rs.next();
result of current row goes to row2.txt;
rs.next();
result of current row goes to row3.txt;
rs.next();
result of current row goes to row4.txt;

(or maybe it would be better to have an array of rows for the reuslts?)

I do not know how to make it so that, when you guess a correct letter, it reveals that letter in the hidden word while still keeping the other parts of the word hidden.

You can use a StringBuilder - it's like a String but you can update individual characters in it. So start with a StringBuilder that just contains the right nunmber of '.' characters. As the user guesses correctly you can replace the corresponding '.' with the correct character. You can print a StringBuilder just like printing a String, so no problems there! À Bientôt J

http://docs.oracle.com/javase/7/docs/api/java/lang/StringBuilder.html

Yes, absolutely, a very good thing to do. The advantage of also running format is that you spot errors immediately, without having to run and interpret test cases. It's a fundamental part of the philosophy of Java that you should try to prevent errors at compile time rather than wait until you run things - hence strict typing, uninitialised variable checks etc.
Way way back in my IBM days we had a rule of thumb that given 7 stages of OS development
spec / design / code / unit test / system test / user test / deployment
the cost of finding and fixing an error increases by a factor of 10x at each stage. Now maybe that should be 4x ? but either way the moral is to fix things at the earliest possible stage.

Nice catch!
Personally I click the "format" menu item in Eclipse and NetBeans after typing each block, and after any line deletions/insertions. It's surprising how often the "official" indentation doesn't match my intentions. (Mind you, I may be the world's worst typpist.)

You have a good scattering of print statements there, so can you tell us which code is actually being called when? Eg does the document listener interface correctly call getIn() each time you type in the text field?

I tried implementing the switch, ... I was using str in the switch,

The first word of each line is in the first element of the array where you split the line, so that's the string you can switch on
switch (array[0]) { ...

BufferedReader is the best way to read whole lines.

That looks like you're piping the file to the std input stream. I don't know if that's possible when executing within Eclipse.

Far better to create your Scanner using the file directly, not via System.in.

You can pass the file name into your java program as a parameter when you invoke it - that's what the String[] args parameters on the main method are for.

Onl line 4 you create an ArrayList, and a reference variable that refers to it.
On line 11 you call addB passing the reference (the variable called list) to your ArrayList.
In that method you get a copy of that reference and you call that list1.

Now list and list1 contain the same value, ie a reference to your ArrayList. It doesn't matter whether you use list or list1, they both refer too exactly the same ArrayList

Scanner was intended as an easy tool for beginners, but in reality it's a poor implementation, and causes more problems than it solves. Forget it.

I would just read each line of the file, then split it onto an array of words using String's split() method.
You can then use a switch on the first word (Java 7 and later) and handle the remaining words as appropriate in the different cases.

(ps " I don't need any help with the actual drawing of the shapes" - suggest you check back into that thread. A couple of posts explain why your implementation is badly broken)

Good. Now please mark ALL your threads for reverse list problems as "solved"

Dining Philosophers is a lot of fun, and trickier than it looks. It's a classic where the solution is hard to wrap your brain around, but really not so hard once you've got it.
Strongly recommended for building your threading qi