Posts by JamesCherrill

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.

@subramanya.vl

babi.meloo is obviously a beginner. Do you seriously think that they will understand how "\\s+" works? All they could do is copy/paste it like some Harry Potter spell and hope it works. Teach, explain.

"memory problems" in Java are pretty much limited to Java throwing an out of memory exception. If you don't have such an exception it's 99% certain you have a problem with your code.

It assumes yo have a JFrame or whatever called window. Then when you run the code it moves your window to the centre of the screen. That's all. If your window is called something else, use that name instead of window. You just put the code somewhere in one of your methods, whenever you want the screen to be centered.

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.

Your Generic class definition says that the type T of the array must extend/implement Comparable. int isn't an Object, and doesn't implement anything, so your class cannot work with an int array.
In fact all generic types must be Objects, never primitives, so there's nothing you can do to make your generic class work with ints.
If you change to an array of Integers that would work, Integer implements Comparable.

You're just sorting numnbers, so a Comparator isn't needed. You need any sort algorithm that you code yourself because you need to keep the index array in synch.

It's a bit messy, but what you have to do is create a second array containing all the indexes (originally 0, 1, 2, etc).
Then in your bubble sort, every time you swap two values, you also swap the corresponding entries in the array of indexes. So you keep the indexes array in step with the values.

Yes, of course you're right. There are also many websites where you can download pornography or pirated versions of software. or discuss hacking techniques. Here on DaniWeb we don't do any of those things, nor do we support, help, or condone anyone else doing them. It's not YouTube that you have to convince here, it's Dani.

We will be very happy to help you with your programming projects, but only if they are 100% legal.

@latecomer:
Your help, advice, and assistance are very welcome here. But please don't just post solutions to people's homework for them to copy & paste. All they learn from that is how to cheat. Give them guidance that allows them to learn how to do it for themselves.

YouTube Terms of Service, section 5B says:

You shall not download any Content unless you see a “download” or similar link displayed by YouTube on the Service for that Content. You shall not copy, reproduce, distribute, transmit, broadcast, display, sell, license, or otherwise exploit any Content for any other purposes without the prior written consent of YouTube or the respective licensors of the Content

Unless you can provide some kind of convincing assurance that you will only use yur Java program in full compliance with YouTube's Terms of Service, and with the full written consent of the Copyright owner(s), this thread cannot go any further.

This is your first post, so you get some extra tolerance, but the code you posted did not produce the output you said it did. If you want our help you must start by being honest with us.

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

You really should get a programmer's editor and clean that code up - proper consistent indentation would make this kind of problem obvious.
Anyway, I count four "if ... {"s, but there are five "}" before the else, so that's the error.

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

You execute two count++ per iteration of the loop, that's one too many.

That's some variant of C,it's not Java

There are lots of people here who will freely give their time to help you become the best Java programmer you can be. There's nobody here who is interested in helping you cheat or doing your homework for you.

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.

Line 32 - need to cast to IntData to access that classes' fields

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.

... 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

The official Java documentation is always the definitive place to look. Here's what the Java Language Specification says about how an instance is created and initialised

That code looks ok - presumably th eproblem is in the print?

ps you don't need all those arrays and indexing to loop thru an enum. Just an enhanced for loop will do, and is much cleaner simpler code, eg

  for (Suit s : Suit.values()) {
     for (Rank r : Rank.values()) {
        deck.add(new Card(s, r));
     }
  }

deck1 is a single object, it is NOT an array of cards. It happens to contain an array of cards, but that's not relevent except to how it's printed out. So deckArray is an array list of 1 element, an instance of Deck. When you remove that 1 element the arraylist is empty.
If you want an arraylist of cards you will need an accessor method in Deck that returns the array of Cards. Maybe it would be better to have Deck contain an ArrayList<Card> rather than a Card[], especially if you want to remove Cards from the Deck etc.

You'll have to explain exactly how the output differs from what you wanted.

You declare totalPur inside the loop, so you get a brand new totalPur each time thru the loop and the previous one(s) are forgotten. Declare and initialise it before you enter the loop so the same variable is used throughout.

Maybe put them into the array starting at the end and filling backwards? ie keep
deck[x] = new Card(rankValues[j], suitValues[i]);
but start x at 51 and decrement it in each pass of the inner loop instead of incrementing it.

ps When you have an answer to a problem please mark the thread "solved" for our knowledge base.
Thanks
J

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.

pwd is defined as a Long, and a long will be auto boxed when assigned to a Long...

You want to assign a color to a player. In Object Oriented terms that immediately implies that Player is a class and color is one of its attribues (member variables). Maybe you should look at your design again and see what other info is associated with a player and how that could fit into an OO solution?

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.

All met knows is that you will pass it a List as a parameter, so there's no compile-time checking it can do on what you add.
Remember the method is compiled based on how you declare it. The compiler cannot know everything about the actual objects that you (or I) may pass it at runtime.

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.

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.

for (int i = 0; i < comix.length; i++)
    {
    Scanner console = new Scanner(System.in);
    String temp = console.nextLine();

Your problems start here.
Your loop starts with i = 0. It gets the search word from the user, and tests the first element of comix.
It then goes to the second element, and forgets the original search word, and gets a new one from the user, which it compares with the second element of comix.
Ie because you get the user input inside the loop, each search word is only compared with one element of comix, not with them all.

Is there a Player class? Does it have get/setColor methods? Is the color initially null?
Why not just have a test in the potting logic that says if ball is yellow or red AND player1.getColor()==null, call setColor as appropriate?

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.

You could try calling requestFocus for window B to bring it to the front. Details are in the API doc as always.

If that answers your question please mark this thread "solved" for our knowledge base. Thanks.

Latest version has completely lost all the stuff about remembering that the previous game as a war.
(I'm finishing now for this evening, someone else will probably step in...)

NPE at which line? The message tells you that. Then look at that line to see which variable(s) could be null. Print it/them to confirm, then work backwards to find out why.
(I'm finishing now for this evening, someone else will probably step in...)

Look at yor logic... unless both if tests are false you never execute that return. Keep it simple and just set your variables in the if/else tests and have a single return as the last line of the method.
ps I don't see why you are returning warCards anyway - why not just treat that variable like playerScore or compScore?

OK, well, have fun. You'll find lots of friendly people here to help you learn Java (and use Eclipse!).
Now your immediate problem is answered, please mark this thread "solved" for our knowledge base. Start a new thread for any new question. Thanks.