Posts by JamesCherrill

 public Image getPlayerImage()
{ return mario.getImage(); }

mario already is an Image, so you just need to return it "as-is"

 public Image getPlayerImage()
{ return mario; }

When you initialise mario you have specified both a document base, and a fully-qualified path/file starting at c:
YOu should have one ofr the other of those, not both. For an applet it's the document base you need, the other paramter should just be the file name (and it's dir if that's a sub-dir of the document base directory). As jalpesh suggested, if you are not sure you should print the document base to find out exactly which dir it refers to

Root dir (inthis context) would be a dir referenced in the class path - a dir where javac will start to look for package/class. Current dir is an OS dir that will be a root dir if . is in the classpath.

Yes, it's A.class. Sorry, that was me typing too fast! It looks for .class files in the classpath, not source files.

At this point I have to admit that I haven't compiled a multi-package app at the command line for about 15 years. Nowdays I'm 100% on Eclipse, where all these issues are handled differently. If you want to get any more into it, I'm probably not the best person to get involved.

Yes, I'm sure quite a few of us did. If the OP had followed my suggestion he would have seen the resulting N.P.E. and debugged that for himself. And worked out his own solution.

DaniWeb Member Rules (which you agreed to when you signed up) include:
"Do provide evidence of having done some work yourself if posting questions from school or work assignments"
http://www.daniweb.com/community/rules

Post what you have done so far and someone will help you from there.

Have you added the e.printStackTrace(); yet? I just spotted your mistake, and you will be surprised by what the stack trace reveals.

Parsing "10/10/2012" and "20/10/2012" with a SimpleDateFormat of "dd/MM/yyyy" works perfectly, so your code isn't doing what you think it is...
To find out what's really happening, try putting a lot more print statements into the code, eg print s2 and s3 (with a delimiter immediately before and after so you can see any leading/trailing blanks). Do an e.printStackTrace(); in your catch

OK, just thought that was worth checking.
Your code uses some complex-looking data structures, whose purpose isn't immediately obvious. Maybe it's time to back off a bit and do this is easy stages? Personally I would create small test file with a few blocks of solid RGBCMY colour, then try hard-coding swapping two of the colours before moving on to the full logic and the full file.

That parsing looks right, depending on how sdf has been defined. Can you post the definition of sdf, and an example of the text that's not parsing properly?

You use getData().getDataElements(... which can return all kinds of different formats, depending on the image source. Your apparent assumption that it's 3 bytes/pixel may be wrong? (Most commonly you see one 32-bit int per pixel containing ARGB values that you can unpack with shift/mask operation).
Have a look at the PixelGrabber class for a predictable consistent way to get pixel data from an image.

That's OK. Taywin's code is to check that you are getting the String from the text field correctly. Now we know that's OK we can move on. Taywin has also posted a lot of code that shows how you should approach the parsing. What part of that is causing you a problem? If your code isn't parsing as you expect then you will need to post the code so we can see what's wrong with it.

You're 95% of the way there...
Add some temporary print statements inside your loops etc so you can see what the values of the variables are as the program executes. That will help you find exactly where it's going wrong.

window is a variable. From the context I guess its a top-level Swing component (JFrame, JDialog, JApplet...)
getSize() is a method that's available for all Swing components. Top-level components inherit it from java.awt.Component. Others inherit it from javax.swing.JComponent.

ps *window.setLocationRelativeTo(null); * does the same thing as that code, but in one line, and it handles multi-screen configurations sensibly.

if class A is in package xcom, javac will look for A.java inside a folder (or jar) called xcom, starting from the classpath.
If the classpath includes the xcom directory javac will look in xcom for a folder (or jar) called xcom and, of course, it won't find one there.

DaniWeb Member Rules (which you agreed to when you signed up) include:
"Do provide evidence of having done some work yourself if posting questions from school or work assignments"
http://www.daniweb.com/community/rules

Post what you have done so far and someone will help you from there.

Exactly. your else is placed after that }. There's no such thing as a for-else loop.

When you define an inner class you can extend an existing class, or implement an interface. The syntax is the same for both, which is simple, but can cause the exact confusion that you have raised.

"do" is a Java reserved word - just like if, class, while, return etc etc
You can't use a reserved word as an identifier.
You could change it to "doh" - that would seem appropriate :)

http://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html

Logic error: your syntax in the while is OK, but the way you have coded it will give you exactly the opposite of the result you wanted.

DaniWeb Member Rules include:
"Do provide evidence of having done some work yourself if posting questions from school or work assignments"
http://www.daniweb.com/community/rules

Post what you have done so far and someone will help you from there.

... insisting that the rating supplied by the user be valid.
rating should be 1 to 5;

The first verion does not even try to do this, so it cannot be right.
The second version does, but it has a logic error in the if test, which you can fix easily
And you might want to set a variable that will survive after the end of your method

You could just close the input stream associated with that socket, but anyway closing the stream or socket should not result in the close throwing an exception, it's the read that will throw it. It's up to you whether you exit or not in the appropriate catch.

Maybe it's always waiting on in.read? You could try closing that input stream, which should cause the read to throw an exception

Here's what the Java API documentation has to say:

stop()
Deprecated.
This method is inherently unsafe. (...) Many uses of stop should be replaced by code that simply modifies some variable to indicate that the target thread should stop running. The target thread should check this variable regularly, and return from its run method in an orderly fashion if the variable indicates that it is to stop running. If the target thread waits for long periods (on a condition variable, for example), the interrupt method should be used to interrupt the wait.

There are quite a few syntax errors there - missing () etc. Compile your program to get a list of syntax errors and fix them (start at the top and re-compile after each one, as an error early in the code can disrupt parsing of the code that follows).
Then a couple of hints:
To compare Strings you can't use == (even less =, which is assignment). YOU need the equals method (documented in the standard API doc for String)
You can use a Scanner with System.in to read input from the user. Google for more detail.

The improvements in 1.7 are no big deal over 1.6, and many corporates take forever to update, so I wouldn't worry about that. If you're happy with the core concepts I would recommend writing as much code as possible and getting feedback (eg from here) rather than just reading about it.

It's the way generics were implemented as a compile-time thing. In the .class files there are no generic types - it's called "type erasure". Your generic info has been "erased" by the time the code is executed, so there's no info that would cause a class cast ex. At run time your List<? extends Dog> is just a List.
Some people (me included) think it's a great shame they used type erasure. As I understand it they took the aproach they did because there were technical cases where a better implementation would fail. Personally I think i would have been better to let those fail (runtime exception maybe) and give us proper run-time generics for the 99% of cases where it would be good. But then I don't work for Sun/Oracle, so what I think is irrelevant.
More to the point this explains what and why.

1. When compiling main the compiler knows that l1 is a non-genericised list, so you can add anything to it.
2. When compiling the met method the compiler knows that any parameter passed will be a List of Animal or a superclass of Animal. Maybe when met is called the parameter will actually be a List<Object>, or even just a List, but maybe it will be a List<Animal>. In this case you happen to know that the value passed as parameter will be a List, but tomorrow I may write a method that calls met and passes a List<Animal>. "hello" and 12 are not Animals, so the compiler cannot guarantee that the add is OK.
   You can add a Dog because a Dog is an Animal - all Dogs are Animals.

Line 56 - has an incorrect ; - just delete it

 public static void main(String[] args) {
    // method body
 }

When you have something like void met(List<? super Animal> l2) you are saying that the parameter will be a List of type "x"where "x" is Animal or a superclass of Animal. Note that at compile time you don't know what "x" will be exactly - it could be Animal, it could be Object etc. That depends on who calls the method and what they pass, which in general cannot be known until run time.
Ex 1 - it doesn't matter what superclass of Animal "x" will be, a Dog wil always be a subclass of "x".
Ex2 - exactly the same.
Ex 3 - "x" could be Dog or any superclass of Dog. So its OK to pass a List<Dog> for that parameter. In which case adding an Animal would be invalid, so the code will not compile.

The learning point here is that the exact type of the value that's passed to met is irrelevant at compile time, as long as it fits the generic spec in met's definition. The compiler can only compile met based on its method signature.

As a new employee you are unlikely to be asked to do a new project. New hires are usually assigned maintenance tasks, mostly because that teaches them about the existing systems, and partly because they are bottom of the pecking order and nobody likes maintenance.
So a typical task may be to take an existing appication - many thousands of lines of code - and add a new data item to gui and database, or change the logic for processing a particular transaction.

the parameter in dostuff() is type safe to Number so it checks and should give error

Yes, that would be a nice idea, but Java doesn't do that. It does not go through the Set testing each element to see if it a kind of Number every time a Set is passed as a parameter. Presumably that's because it could be a very large overhead. Maybe not a "limitation", but a "design compromise"?

To confirm what is happening, change line 13 to

while(i.hasNext()) System.out.println((Number) i.next() + " ");

then you will get a ClassCastException when it trys to cast the "1" to Number at run time.

0 (an int) is auto-boxed into an Integer. "1" is a String and NOT cast to a Number - that's not a valid cast. It just stays as a String.
Note that when you execute (you did execute that code, didn't you?)

System.out.println(s.contains(1));

it is "false", "1" has not been converted to any numeric type.

Did you try casting a String to an Integer? I thought not! No, you can't cast String to Integer.
You may also notice that the final print (line 18) prints "false".

The real reason for no error is that there's no place where that error will be checked for. The original add of a String is OK because that Set is just, by default <Object>. There's no code that checks that a set passed as a parameter contains only the right kind of data, and nothing you do with the data inside doStuff will fail witha non-Number.

I think this question is drawing your attention to one of (many) "limitations" in the implementation of Generocs.

Just an abstract class Soprt, and non-abstract sub-classes Basketball etc. for the data, and a MySports class as the driver? Yes, makes complete sense to me.

1. Get the Java Date from the chooser.
2. get the time (mSecs) from the Java Date
3. create a new SQL Date using the time (mSecs)

Every parameter of every public method of every Java API class is documented in the API documentation, and learning to use it is an absolutely essential skill for Java prgrammers
http://docs.oracle.com/javase/7/docs/api/

for drawLine it says

> public abstract void drawLine(int x1,
>             int y1,
>             int x2,
>             int y2)
> 
> Draws a line, using the current color, between the points (x1, y1) and (x2, y2) in this graphics context's coordinate system.
> 
> Parameters:
>     x1 - the first point's x coordinate.
>     y1 - the first point's y coordinate.
>     x2 - the second point's x coordinate.
>     y2 - the second point's y coordinate.

Here's a really really simple runnable demo that has the basic parts: the Sprite class is the simulation of different things (squares, circles) moving about. This demos the use of a timer to run the simulation in real time, and the display technique I described above to show the sprites moving. It's totally simple, but it shows the key components and how they fit together. It's deliberately short on comments so you'll have to study it to understand it before you apply it's ideas to your own problem.

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import java.util.ArrayList;

public class Animation2 extends JPanel implements ActionListener {
   // Animation demo showing use of an abstract Sprite class to
   // model basic behaviour for multiple moving objects.
   // Sprites have two mandatory methods - update and draw

   Animation2(int width, int height) {
      setPreferredSize(new Dimension(width, height));
      new Timer(50, this).start();
   }

   @Override
   public void actionPerformed(ActionEvent arg0) {
      // called by Timer every 50 milliseconds
      for (SimpleSprite s : SimpleSprite.sprites)
         s.update(); // update positions of all sprites
      repaint();
   }

   @Override
   public void paintComponent(Graphics g) {
      super.paintComponent(g); // ensure background etc is painted
      Graphics2D g2d = (Graphics2D) g;
      for (SimpleSprite s : SimpleSprite.sprites)
         s.draw(g2d);// draw all sprites at latest positions
   }

   public static void main(String[] args) {
      // create and display the animation in a JFrame
       final JFrame frame = new JFrame("Animation 2 (close window to exit)");
     Animation2 animationPanel = new Animation2(600, 500);
      frame.add(animationPanel);
      frame.pack();
      frame.setLocationRelativeTo(null);
      frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
      frame.setVisible(true);
      // add some sprites...
      new Square(0, 0, 3, 2, …

At some stage you will need to tell the ATM which customer/account it is dealing with. You could just add that as a parameter to the deposit & withdraw methods.
OR if one customer is likely to do a load of transactions you could have a logon method in ATM so the customer enters his PIN or whatever, then the ATM knows which customer to use in the following deposit/withdraw etc.

p6/b2/b3/s1/s2 are not objects, they are reference variables, and their type is fixed when they are declared. They haven't been initialised, so they don't have a object to refer to. Think about his example:

 Pan p4 = new Sour();
 Blue b2 = (Blue)b4;

(Blue)p4 cannot be known as definitely OK or not OK at compile time. p4's type is Pan, so the object it refers to may, or may not, be a Blue. So that has to be checked at run time.
At run time the actual object referred to by b4 is used, it's found to be a Sour. Sour is a subclass of Blue, so the cast is valid, and b2 can be set to refer to the same Sour object.

Yes, it's not easy to read, but it is the only definitive answer!

Here's a crude summary of the key points for casting reference types, but I do mean crude, so see the JLS for the exactly correct version:

• Compile-time checks are based on the declared types of the variables. Runtime checks are based on the actual type of the actual object.
• casting or assigning a subclass to superclass is always OK, it's checked OK at compile time, no runtime checks needed.
• assigning a superclass to a subclass (without a cast) is always wrong, and is rejected at compile time
• casting a superclass to subclass may or may not be OK, it must be checked at runtime to see what the actual class of the object is. Then it may be OK or it may throw an exception
• if the classes are not related by inheritance the cast is always invalid and errors at compile time

In case 5 the cast to a subclass may or may not be OK, so it will be checked at runtime. Because the object is a Sour it's also a valid Blue and the cast will be found to be OK. But the assignment of a Blue to a Sour is not valid without an explicit cast and is rejected at compile time.

Sorry of that's a bit garbled - it's late here - but with that overview maybe you can now revisit the JLS?

This is a good example of why variable and method names are important. With a method called "compareValues" it's totally unknown what returning true or false will mean. Change the name to allValuesAreDifferent and the fact that the logic has true and false the wrong way round jumps straight out at you...

boolean allValuesAreDifferent(...
    ...
    if (numArray[i] == numArray[j]) return true;  // obviously wrong

This is fully described in the Java Language Specification section 15.16 "Cast Expressions".

No, I didn't mean call the revised sender code exactly as it is! The revised version starts a new thread and runs the new Sender() (etc) in that thread. You need to do the same thing in your actionPeformed. The revised code is a good template or example for how to do that.

Lines 184,185 these need to be run in a new thread - just like the revised version of the sender code that you posted. That way the actionPerformed will start the thread and immediately return, after which the GUI will be able to respond/update as usual

Please check the Daniweb member rules before posting
http://www.daniweb.com/community/rules

DaniWeb Member Rules include:
"Do provide evidence of having done some work yourself if posting questions from school or work assignments"

When you call anything from an actionPeformed the whole of Swing (including GUI updates) will wait until your actionPerformed returns. This is because it's all done on one thread (Swing is not thread-safe). You need your actionPerformed to start a new thread for this code so it can return immediately.

A lot depends on where you may want to go afterwards. If you see a career in enterprise Java then go with EE-specific technogies like servlets and jsp. On the other hand if you just want to improve yur general Java and programming skills then build something using Java SE and get your hands dirty with sockets, threads and JDBC.
For the SE approach I would suggest a Java server that manages the oracle database-related stuff, and clients that use Sockets to talk Java-Java with the server. (But there are many alternative architectures; other people may have different opinions.)

You can use a ComponentListener, something like:

    myThing.addComponentListener(new ComponentListener() {

         @Override
         public void componentShown(ComponentEvent arg0) {
            System.out.println(arg0);
         }

         @Override
         public void componentHidden(ComponentEvent arg0) {
            System.out.println(arg0);          
         }

         @Override
         public void componentMoved(ComponentEvent arg0) {
            // not interested
         }

         @Override
         public void componentResized(ComponentEvent arg0) {
            // not interested
         }

      });

Certainly the obvious advice is to update your program to use a GUI. This is 2012, and console-based end-user applications just aren't written any more (except in the early stages of learning Java).
You could distribute it with a tiny batch file that just has the single line
java -jar Apollonius_Theorem.jar
then they could double-click the batch file

@godzab:
In the example you gave, do you want to remove the 2 from java. lava, or both? What if there are duplicate entries in either one of those two lists?

ps: Guys - what's all this fortran-style for looping and hand-coded searches? This is Java, we have enhanced for loops, and ArrayList has a remove method that does exactly what's needed. Removing every object from list2 that is present in list1 is a single line of code - a "do" a "while" and a single method call.