Posts by JamesCherrill

1. You can't assess "efficiency" unless you have a reasonable list of the various ways in which the data needs to be accessed and a rough count of how often each of those will happen. Do you need to find the priority for a given operator? Do you need a list of alloperators with the same priority? How often? etc etc.
   Write down the method signatures for the complete set of accessors that you would need to access your data. That's (a) the requirements statement for the data structure and (b) the starting point for your implementation.

2. Discussions of efficiency in Java are almost always premature. The compiler and runtime are really good nowdays at optimising your code, and if you are using this data structure for processing stuff that you just read in from a file then it's the file i/o that swamps everything else. Unless you have some very good reason otherwize you should encapsulate all your data structures behind public accessor methods, then start with a data structure that is really obvious and clear as to its purpose and implementation. IF sometime later you determine there really is an efficiency problem you can change the data structure without changing the accessor methods and therefore without breaking anything else.

If you post the accessor signatures, and a quick note of which will be used the most, we can make sensible suggestions for an easy and clear way to implement them.

You need public accessor methods such as getName, getID that simply return the values of those private variables. That way you allow other classes to get the values in a controlled way, but not to change or corrupt them.

Similarly you can create public setID etc methods if you want other classes to be able to change some of those values.
In your case, where presumably every Passenger has an ID and a name, which never change, you should consider having a public constructor that requires those values as parameters to create the Passenger object, and not having any set methods.

OK, that's the kind of thing I was referring to. Although htis may seems a bit complicated to start with, in the end it will be easier to use a proper model/view structure, a simple form of MVC, in which the logic is implemented in a non-GUI model, and a separate GUI just displays whatever the current state of the model may be. This breaks one big problem into two smaller ones.
Create a 2D array of Square objects. Each Square will have a color attribute (and other attributes depending on your application). Perform all your updating on that array (eg "directly touching" == array index differs by 1).
Create the GUI with each of your JPanels linked to one element of the array of Squares (you can use the JPanels' putClientProperty method to store a direct reference to its corresponding Square in the JPanel). Then updating the GUI is simply a process of looping thru all the JPanels querying their associated Squares to get the current color.

They could ask you about sorting arrays - various algorithms and their advantages/disadvatages

It's really hard to understand your requirement, but is this what you mean (pseudocode)?...

  valuesToSkip = new ArrayList<Integer>

  for (r ...
     if (valuesToSkip.contains(r)) continue;
     ...
     valuesToSkip.add(anotherValueThatYouWantToSkipNextTime)

Instead of the println method, use printf
printf allows you to specify formats for how each variable is printed.
Have a look at http://www.homeandlearn.co.uk/java/java_formatted_strings.html

You didn't say where the exception was being thrown, but maybe its like this:

for(ship currentShip : shipList){
   ...
   shipList.remove(currentShip)

You can't add or delete members from a list when you're in the middle of iterating thru it with an ordinary Interator or an enhanced for loop.

The easiest fix (provided the list isn't gargantuan big) is to create a temp copy of the original list to iterate thru, then you can delete from the original with no problems

ArrayList<ship> temp = new ArrayList<ship>(shipList);
for(ship currentShip : temp){
   ...
   shipList.remove(currentShip)

Or, if you want to be a real ninja java master, use a ListIterator

ps: "Ship" not "ship" for a class name

Scanner is a pre-packaged reading/parsing class that gives novices a one-stop solution to processing simple text stream input. Apart from the nextInt/nextLine issue that you (and pretty much everybody else) ran into, it does a decent job within its design scope.
You use BufferedReader if you want to take control over all the parsing yourself, eg to parse input that's too complex for Scanner, eg dates or oddly-delimited multiple fields. Sooner or later you will get to that place, after which you will have climbed the learning curve, and will have no further need of Scanner. In the meantime there's no harm in doing it the easy way and using Scanners.

Since OP is going with the brute force approach, I guess there's no harm in posting this code....

<snip>

It will multiply any two Java ints with a max of 31 recursions, vs 2 billion for the brute force solution.

<On second thoughts, maybe it's not a good idea to post the complete code here. Let's just say it's very small and fast, and you will get a real kick of satisfaction when you do it yourself. JC>

Because it will also accept objects from Integer's superclass(es), and they cannot be assigned to an Integer variable

Be careful, that code doesn't do what you think it does.
Line 2 declares a static variable "has" that can refer to an array of ints. It's initial value is null.
Line 7 does not initialise that variable. It creates a new local variable, also called "has" and initialises it to an array with those values in it. If line 7 appears inside a method then the scope of the new "has" variable is just that method. As soon as the method terminates that array is garbage collected and all you are left with is the original "has" variable, which is still null. (Don't be embarrassed; this is a very common mistake.)

OK, sorry.

Ah ha! That looks like a standard floating point arithmetic rounding problem, nothing to do with your dot.
Decimals like 0.1 don't have an exact equivalent in a binary floating point number, so when you use them in arithmetic you often get an error in the very last digit of the floating point value. You can reduce these problems by using a higher-accuracy floating point type, ie double, but the problem still won't entirely go away.

This link explains the problem in more detail, and shows you how to use the BigDecimal class for exactly correct calculations on numbers with decimals.

Case 1 every element is an Integer or a subclass of Integer. All subclasses of Integer are Integers (can be cast to Integer), so the implicit cast to Integer is OK
Case 2 every element is an Integer or a superclass of Integer. Not all superclasses of Integer are Integers (eg Object is not a kind of Integer), so the implicit cast is not valid.

getCaretPosition() ?

Strings in Java are immutable - ie their content never changes. The replace method therefore does not change the original String. It returns a new String that has the replacements made...

      String somestring="203/9834/345";
      String replaced = somestring.replace("/","");
      System.out.println(replaced);

You probably should be looking at something like Flash for this, rather than a full programming language like Java.
Fix the links, then try asking this in the web design forum

Yes, there's a "Mark Question Solved" at the bottom of the page.

Seriously - you need more prints. Eg print the shipCell array after you have initialised it.
Some line of your code is not doing what you think it is - so trying to think your way out of this is unlikely to work. Use prints to check every stage in detail until you find the error. By definition the problem will be in one of the things you haven't checked yet, no matter how obviously right it may seem to you.
It may sound tedious but that's how real programmers find real bugs in real life - they may use a debugger to see the variables rather than using prints, but the process is the same.

(I did have a quick look at the logic, but nothing jumped out at me. I was confused by the naming vs the implementation - the naming suggests that there is one ship of length 8, but the logic seems more like 8 disconnected one-cell ships)

Thta's just one error, with a complete list of where it came from. In theis case the first two lines tell you everything - on line 48 you try to access an array element [-1]
Almost certainly because paint is being called before you select something in "colors", ie selected index == -1

String and StringBuffer have no "extends" relationship, so you can't assign or cast either to the other.
Case 1 works because StringBuffer has a constructor that takes a String as parameter.

Just this one time...
I just replaced the stupid int with a boolean, and gave it a meaningful name. If this code still isn't clear then add some print statements to show how the values of the main variables change, and execute it yourself.

class PrimeNo{
    public static void main(String args[]){
        int num = Integer.parseInt(args[0]);
        boolean numberHasADivisor = false;
        for(int i=2;i<num;i++){
            if(num%i==0)
            {
                System.out.println(num+" is not a Prime Number");
                numberHasADivisor =  true;
                break;
            }
        }
        if(! numberHasADivisor)
            System.out.println(num+" is a Prime Number");
    }
}

You'll need to be a lot more specific about your question. What scores? Why an array? What method? etc.

ps1: variable names user1, user2, user3 etc make it very hard to understand your code, compared to (eg) q1answer, q1confirm, q1secondTry etc
ps2: You do a lot of comparisons to cope with various combinations of upper and lower case. You could simplify your code by using the String equalsIgnoreCase method that's just like equals, except that it tests for two strings being equal ignoring any differences in case.

System.exit(0) is one of a very small list of things that stop the JVM, thus preventing the finally from executing. Otherwize, a finally clause will always be executed. That's how the language is defined.

A finally clause ensures that the finally block is executed after the try block
and any catch block that might be executed, no matter how control leaves the try
block or catch block.

Java Language Specification Section 14.20 (my emphasis)

Yes, you are on the right track.
The "API" (application Programming Interface) is all the classes that come with Java, as documented here. Searching and understanding the API documentation is an absolutely essential skill for every Java programmer.

You don't need to make another class. You can just add a method to the Player class, eg

public Rectangle getBounds() {
   return  new Rectangle(x, y, 32,32);
}

... and do the same for the enemy class, then you can code

if (player.getBounds().intersects(wall.getBounds())) { etc

... which is much simpler and clearer for anyone reading your program.

Why not make use of the proven code in the Java API to do the work for you?
The Rectangle class has an intersects(Rectangle other) method.
It's trivial to update your main/enemy classes witha method to return the onbjects' bounding rectangle - new Rectangle(x,y,width,height) - then you can use the intersects method to see if those rectangles overlap anywhere.

Seriously dude, please re-read the previous posts. There's one that gives you a hint, followed by one that has pseudo-code, followed by one that has the actual Java code you need. All you have to do is adapt it into your code.
I'm detecting a hint of panic in your posts, so the first thing is to slow down, take a deep breath, maybe do something else for a few minutes, then settle down and re-read all thoses posts very slowly and carefully. The answers you seek are aready there.

Sorry, but that code makes no sense at all, it just looks like a random collection of assignments. Line 8 will screw up the loop variable, and where did 12 ever come into this problem? I guess you just tried things at random until the output was nearly right for that one test case?
You should re-read the good advice you have been given, and follow it.

Use JFrame for a normal application window - not a web site - resizable, minimise/maximise/close buttons etc.

Check boxes are independent - you can select as many or as few of them as you want. It makes no sense to group them. Radio buttons come in groups, and only one can be selected in any group. AWT got the terminology mixed up, which was very confusing, but Swing does it right.
So:
If you want independently selectable options, use JCheckBoxes, no grouping.
If you want a group in which only one can be selected at a time, use JRadioButton buttons in a ButtonGroup.

Swing was built on top of AWT, so there are a few AWT classes that you still use with swing because there was no need to replace them. Container is one that you still use; your code is OK.

use JRadioButton buttons in a ButtonGroup

Lines 115-117:

catch(Exception e)
{
}

How many times have we said this in the Java forum...
Never NEVER NEVER do this when writing new code.

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.

You also have nested loops spanning 170 lines of incorrectly indented code. Nobody is going to waste any time trying to read or understand that.

So: make sure you print the stack trace for every exception, sort out the indentation of your code, make those loops shorter by refactoring some or all of their contents into separate methods, run the program again, and report back here where somneone will help.

The Swing equivalent to the old CheckBoxGroup (only one can be selected at any time) is to use JRadioButton buttons in a ButtonGroup

The align specs apply to a whole paragraph, so you can't mix them on one line. You could try ALIGN_JUSTIFIED.

The answer to your first two questions is "no problem, that's perfectly OK"
The output you get is what you asked for on lines 82/83. When you print the order object o1 Java has no information on how to print that, so you get a default printout which shows the the object's class (stellarstationary.order) and its hash (8dc8569). If you want to print someting more useful you define a toString method in your order class. This overrides the default one you inherit from Object, and allows you to specify how to print an order, eg

@Override
public String toString() {
   return "This is an order, its number is " + OrderNum;
}

ps Java naming conventions are that classes should begin with an upper case letter, variables should begin with a lower-case letter. It's easier for others to understand your code if you stick to the conventions.

You can download the source code, which also has no doc, but there's a simple main method that looks like a kind of demo of how to use it.
Personally I wouldn't touch undocumented code with a 10 meter pole.

Looks like the answer is in the difference between the raw type GenericDemo and the parametised type GenericDemo<E extends GenericDemo>
E extends GenericDemo but that does not automatically mean it extends GenericDemo<whatever>
That's about as much effort as I'm prepared to put into this until someone gives me an example of how you would encounter it in the real world :)

To compare two Objects you can either:
1. Implement the Comparable interface (which consists of a compareTo method) in the objects being compared, or
2. Write a Comparator that compares two arbitrary Objects
Both these interfaces are documented in the usual Java API documentation.

In this case it would be normal to define the SortedSet class to require objects that are Comparable, ie
class SortedSet<E extends Comparable>
then you can always use their compareTo methods to compare them

OK, that makes more sense.
This article is an excellent and authoratative read on the differences between AWT and Swing painting.
In brief, here are some of the things it has to say...

For the most part, the Swing painting mechanism resembles and relies on the AWT's. But it also introduces some differences in the mechanism, as well as new APIs that make it easier for applications to customize how painting works.
...
Swing starts with AWT's basic painting model and extends it further in order to maximize performance and improve extensibility
...
One of the most notable features of Swing is that it builds support for double-buffering right into the toolkit.
...
Swing introduces a couple of additional properties on JComponent in order to improve the efficiency of the internal paint algorithms
...
The purpose of Swing's RepaintManager class is to maximize the efficiency of repaint processing on a Swing containment hierarchy... It implements the repaint mechanism by intercepting all repaint requests on Swing components (so they are no longer processed by the AWT) and maintaining its own state on what needs to be updated

When Swing was introduced (over a decade ago!) you may have been right about native methods vs Java "lightweight" methods, but subsequent preferential development of Swing over AWT means that Swing will be the better, and faster, choice for all normal GUI applications.

If you really want to build the fastest …

the problem with using javax.swing is that compared the the awt its slower...

Not true.
AWT was the first attempt at a GUI layer for Java, it's design was bad, so they tried again and fixed most of the problems with Swing which was fully released in 1998. Since then all the development and tuning has been done on Swing, and AWT has only been enhanced to the extent that parts of it underpin Swing. No normal application should ever use AWT rather than Swing.

... because your referring to java specific locations

This makes no sense at all

Somewhere you should have a method that executes at regular intervals (eg 30 per second) to update the position according to the velocity. (A javax.swing.Timer is the best way to do that.) That's where you need to have your

 velocity_Y -= gravity;
y += velocity_Y; //set y

No, you can't stop it! Swing will call that whenever it thinks the panel needs painting, including the very first time it's made visible. You can either test some boolean flag you set to see if you want to paint, or you can keep the panel invisible until you are ready.

You have 4 connections throiugh one ServerSocket, but only one per Socket - the difference is important.
It's always a bit messy clsing a Socket connection when you have input/output streams going in both directions. Whichever end closes first will trigger a SocketException at the other end. ALl you can do AFAIK is to send 999 and close the socket. At the other end set a flag when you get the 999, then catch the exception and then ignore it if the flag is set.

There are lots of people here who will freely give their time to help you become the best Java programmer you can be.

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.

@piyush
Please don't just spoon feed raw code to people. All that teaches them is how easy it is to cheat with a quick copy/paste. You didn't even attempt to explain why you made the changes you did. Give people assistance that helps them learn how to fix problems for themselves.

Details depend on what you are removing from (ArrayList, HashSet etc?), but re-starting the find from the beginning each time is what gives you the O(N^2).
Use an algorithm that just searches once through the data, removing as it goes. (You may need to start at the end of the data and iterate backwards towards the beginning, depending on what happens when you delete an item.)

Schol-R-LEA gave you the answer. GregorianCalendar. Look it up in the API doc.

Google Factory Design pattern
The very first link takes you to the Wikipedia entry that answers your question.

In future please try to do at least a little research before asking someone to spend their valuable time helping you.

The message is perfectly clear - you defined a Player class and it doesn't have a getDocumentBase method. That method is defined in the Applet class. Main extends Applet, so you can call the method there and maybe pass the result to PLayer's constructor, or maybe proving a tiny get method in Main that the otehr class(es) can call to get the doc. base.

ps: Applet was effctively superceeded by JApplet abouta decade ago.