Stephan van Hulst

Have you gone through the Java tutorials, and do you know what an object is?

I don't see why a 2D game would give even an older system any trouble when you use sensible programming techniques.

Let me put it this way: if your game runs fine on an integrated GPU, you obviously don't have to worry about getting it to run on a graphics card. If it only runs well using a graphics card, what about players that don't have one?

Yes. The only way to make a LinkedList outperform an ArrayList is by modifying it through the iterator.

HashSet stores its elements in such a way that the ordering appears random. That's to make it faster and use less memory.

If you want the set to maintain insertion order, use LinkedHashSet. If you want the elements to be sorted some way, use TreeSet.

Carey Brown wrote:Are you planning on doing a lot of insertions or deletions in the middle of the list?

This is not enough. For LinkedList to be effective, a modification must be spatially proximal to the previous, so that it doesn't take a lot of time to move the iterator from the previous position to the next. Simply inserting at an index multiple times is just as disastrous for performance as performing multiple searches.

You're saying it as if those are the only ways to store a polynomial. Personally I'd probably use a LinkedHashMap.

Why are you wondering about this? ArrayList should be your default choice, unless you have a very particular reason for using a LinkedList. What reason do you have?

Welcome to CodeRanch!

You're not giving us much to work with. What kind of application is it? What rendering library are you using?

D.J. Quavern wrote:Yes, but this is what I address in the "else" case.

Well, it's just not very clear, or object oriented. Any time you have to write a piece of comment inside a method body to explain what a statement or expression is doing, then you should take it as a hint to make a method out of it instead. Preferably, the method should be an instance method on an appropriate type, and if you don't have an appropriate type that you can add the method to, it's probably time to think about creating a new class.

But since it is such a small piece of code I did not think I needed so many clarifications.

A single clarification is one clarification too much. Code should be self documenting, meaning that small bits of code should be inside a method with a name that very clearly says what that piece of code is supposed to do, and variable names should clearly and correctly state what they represent. Abbreviations are almost never good variable names. Take another look at the boolean expression that Junilu replaced with a method call to firstPosition.isDifferentColor(secondPosition). It's immediately clear what the method is supposed to do, without having to decrypt the actual expression that you used. That's because he took the time to write out the variable and method names completely and correctly.

besides, my tests give me right results. Can you think about a test that could fail?

Show us the latest version of your code, hopefully refactored somewhat to include some of our suggestions.

Unless the thing you want to solve can be solved in two lines of code, take the time to design a proper object oriented model of the problem.

After thinking about it a bit more, you probably don't need a Diagonal class. Instead, add a method isOnSameDiagonal(Position other) to your Position class. Your problem then reduces to finding a position that's on the same diagonal as the original position of the bishop and is also on the same diagonal as the target position.

Good to have you back!

D.J. Quavern wrote:I wrote all in Java and tried to do all in a Javanic way  

I'm afraid that apart from the syntax and the classes from the standard API, there's not much 'Javanic' about your code. Why is everything in the main method? Why have you not split up your application in separate classes that are responsible for different things? Why are you using poor variable names like fB and sB?

First, I suggest you rewrite the application so that you have a Position class that encapsulates the coordinates on a chessboard, a Diagonal class that can tell you the positions of the squares that are on the diagonal it represents, and a Bishop class that encapsulates a position and can determine in how many moves it can reach another specified position. Then, in your main class add a method that reads a position from the standard input. Call it twice and construct a bishop of one of them. Let the bishop determine how many moves it needs to reach the other position.

Now that you have different classes and methods, you can write proper unit tests that will tell you in what part of the code the problem lies.

Before you implement any methods, write some skeleton classes and show it to us so we can tell you you are on the right track. For instance, you can add a method getColor() to the Position class, but don't implement it yet.

I even closed the scanner.

You managed to do it at the one time you shouldn't have: don't close System.in or resources based on System.in. Also, when you do want to close a resource, do it by using the try-with-resources syntax.

Right. When the return type is void, the body of the lambda expression must be a statement expression. Statement expressions are expressions that you can use as a statement, because they DO something. The following are statement expressions:

Variable assignment

Variable increment/decrement

Method call

Object creation

An expression like a+2 or just i is not a statement and therefore can't be used as the body of a function that returns void.

Welcome to CodeRanch!

If you just want a stage without decorations, call initStyle() with either StageStyle.TRANSPARENT or StageStyle.UNDECORATED before you make the stage visible.

If you want to make the stage fullscreen, just call setFullscreen().

I assumed that you thought that the application wouldn't compile because you pass forEach() a function that returns a Future, while forEach() expects a function that returns void.

To that I answered that it doesn't matter, forEach() just ignores the return type of your lambda expression.

When a function that returns void is expected, you can pass it a function that returns anything. The return value is simply ignored.

It seems to me that the correct answers should be F and H: you can't determine what the output will be because the tasks may be performed in any order and the program will keep running because the executor is never shutdown.

Well, to the user, what's the difference between running an executable jar or a batch file? You can also just make a link file.