Matt Pitt

Uhm, yes.
ReentrantReadWriteLock would appear to do exactly what I want.
Thanks. I'll update if it turns out that it doesn't, but it looks like it will.

What if instead of the client passing in a semaphore and acquiring/releasing that, the semaphore itself was internal and and MyOwnPausable provided its own methods for acquiring/releasing the semaphore?
//in class MyOwnPausable private Semaphore semaphore = new Semaphore(1); public void pause() { semaphore.acquire(); } public void resume() { semaphore.release(); }
Then you wouldn't have to pass anything to the constructor, though you would have to retain a reference to the MyOwnPausable instance instead.

Hi,
I have a class that provides some methods for editing variables and accessing data structures and the like, and other methods that do not edit these variables, and only read them to produce output.
Some of these operations can take a while, so I want them to be runnable in parallel - here's where the problem arises.

Hence, here is what I would like to be possible:
- Have multiple 'reading-only' methods running at the same time on different threads
- Not be able to run either type of method if an editing method is running

I've considered things like synchronising on one or two Objects or implementing a ReentrantLock, but I can't see a way to make this work.

An operation-only method would need to get the lock, so that nothing could edit the variables while it was operating.
An editing method would need to get the lock, so that nothing else could edit or access the variables while it was editing.
However, if another operation-only method made an attempt to obtain the lock, it should be allowed to continue even if the lock is held by another OPERATING method, but NOT if it is held by another EDITING method.

Any ideas as to how to proceed? I'm thinking there might be a way to use flags and guarantee thread-safety using Atomics, perhaps, but that throws up even more questions as then I'd have to somehow block the thread until the flag changed at times. I don't know.

Thanks

Line 21 is fine, because you store an Animal, ano1, in pup, which you declared to be an Animal, when you did Animal pup.
If pup was instead declared as Dog pup = new Dog();, this would not work - the compiler will not then compile the line
pup = ano;
as you can't convert an Animal to a Dog, as not every Animal is a Dog, although every Dog is an Animal. This is called Downcasting.
However, the code will compile if you changed that line to this:
pup = (Dog) ano;
When you do this, you're guaranteeing the compiler that you know that at runtime, ano will be a Dog, not just an Animal. In this case, however, ano is not a Dog, it is an Animal.
If you instead declared ano like this:
Animal ano= new Dog();
then
pup = (Dog) ano;
will now run.

Lines 22 and 23 cause ClassCastExceptions for the same reason.
You try to cast Animals to Dogs, but the animals are not dogs.

Hence, downcasting should only be used if you can indeed guarantee that the superclass is indeed one of its subclasses in disguise.

You can check to ensure that a ClassCastException is not thrown, by doing something like the following:
if(ano1 instanceof Dog)
{
pup = (Dog) ano1;
}



Hopefully this helps

Note that I have never used REST, so don't have any specialist knowledge here.
It would appear that .post() returns a Response, explaining why your first block of code runs - post() returns a Response, so you can store the result in Response response. Unless I'm missing something, you therefore don't need to cast at all so the (Response) is unnecessary?

However, your second piece of code throws a ClassCastException at runtime since .body() does NOT return a Response, but a ValidatableResponse - which does NOT extend Response, and hence cannot be cast to Response, so you have an exception.
Perhaps simply changing Response response = ...
to
ValidatableResponse response = ...
will work, or maybe there's another method you need to call for getting it into the right format, or something - but I can't help with that.

Hopefully this at least pushes you in the right direction.

I'm trying to take a look through now, but I must say it's incredibly difficult to follow - identifiers like label1, label2, check1, flag, text1, text2 and the like aren't descriptive at all, especially when combined with a distinct lack of comments. It's especially confusing when you player1 is both a SixNumbersPanel2 and a Player, and in one case player1 is player2 and in another player2 is actually player1, and so forth. Making all that more clear would greatly increase readability.

After slowly stepping through it, I've worked out what most of it does - but I'm slightly confused: player1.Complete() is called in the ActionListener, but the Complete() method performs it's check based on results[], which has never changed since results[] is only modified in play() which is never called, so it should never return true.

Nevermind, just noticed that Complete() always returns true no matter what. Correct me if I'm wrong, but it would appear that the only thing ever used from the Player class is the Check method.

I think I've solved your problem:
I'll use your example to explain.
- Player 1 rolled a 5 on his first turn
- Player 2 takes his turn
- Player 1 rolls a 5
Then,
check = player1.Check(list,key);
is called.
The binary search finds that the number 5 is already in the array, so it returns the index.
This index is greater than 0, so none of the code inside the if(check<0) block is executed, hence control is not passed back to the other player.

Can I also recommend that instead of implementing ActionListener and using getSource to add different behaviour for different buttons, to use lambda expressions like the following:
[code=java]
button.addActionListener((ActionEvent event) -> {
//Whatever you want to happen when the button is pressed
});
[/java]
You'd do this at the same time as you construct the button and set it's name and the like.
You can still separate your logic from your UI initialisation by calling a method inside that lambda expression.

Hopefully this helps, I don't mean to be too harsh, but make your code more readable!!! It'll help people help you fix real problems way more easily in the future.

I'm using a Socket to send and receive data to and from a remote server.
Currently, I declare my socket like this:
socket = new Socket(SERVER_IP, PORT); socket.setSoTimeout(timeout); reader = new BufferedReader(new InputStreamReader(socket.getInputStream())); writer = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));
I then read and write using reader.readLine() and writer.write().
In case of serverside error or a problem with the connection, I want to control the timeout on reader.readLine().
According to the javadoc on setSoTimeout in Socket:

With this option set
to a non-zero timeout, a read() call on the InputStream associated with
this Socket will block for only this amount of time.  If the timeout
expires, a java.net.SocketTimeoutException is raised, though the
Socket is still valid.

Herein lies my problem. I am, firstly, unsure as to where read() is even called once I wrap the stream in a BufferedReader, but, most importantly, when I do the following:
try{ reader.readLine(); }catch(SocketTimeoutException e) { //handle }
I am told that SocketTimeoutException is never thrown by reader.readLine(), implying that the setSoTimeout() has no effect here, contradicting the javadoc.

Am I doing something wrong or would it just be better for me to ignore setSoTimeout() entirely and implement my own timer system?
Thanks.

Forgot to mention, I'm storing a static reference to the Controller in the launcher class.

Knute Snortum wrote:I'm interested in your solution.  Post back here what you did and how it worked when you're done.

I've implemented roughly what I said, though with some changes. So far, it's working fine, though I've only implemented one scene under this new system so far - so I'll update if I discover anything glaringly wrong or bad about this design in the future. Do tell me if you notice anything that's going to come back and bite me later!
These very likely aren't finished, and I'll add more functionality to them as I need to.

The JavaFX entry point looks like this:
@Override public void start(Stage primaryStage) { primaryStage.setFullScreen(true); primaryStage.setResizable(false); primaryStage.setFullScreen(true); primaryStage.setFullScreenExitKeyCombination(KeyCombination.NO_MATCH); //Prevent user from exiting full screen controller = new Controller(primaryStage); //Instantiate controller TopView tv = new TopView(); TopController tc = new TopController(tv); controller.prepare("top", tc); //Prepare the first View for display controller.setView("top"); //Set the view controller.show(); //Show the stage }

And the three classes that I've designed to hopefully be reusable:

Controller:

package menus; import java.util.HashMap; import exceptions.ViewAlreadyBuiltException; import javafx.stage.Stage; public class Controller { private Stage stage; public HashMap<String, ViewController> views = new HashMap<>(); public Controller(Stage stage) { this.stage = stage; } public void setView(String scene) { stage.setScene(views.get(scene).initialize()); } public void prepare(String scene, ViewController vc) { if(views.containsValue(vc) || views.containsKey(scene)) { throw new ViewAlreadyBuiltException(); } vc.view.name = scene; views.put(scene, vc); vc.build(); } public void updateView(String scene) { views.get(scene).update(); } public void show() { stage.show(); } public Stage getStage() { return stage; } }

View:

package menus; import javafx.scene.Scene; public abstract class View { /** * Set when the ViewController is prepared in Controller */ protected String name; /** * Builds the scene for the first time. This is called when ViewController.build is first called. */ public abstract void build(); /** * Updates the scene display. * This is called when ViewController.build is first called. * This should also be called whenever the scene is set, or when Controller.updateView("viewcontrollername") is called, via the related ViewController (implemenation defined) * @return The scene that was updated */ public abstract Scene update(); }

and finally, ViewController:

package menus; import javafx.scene.Scene; public abstract class ViewController { private boolean built = false; protected View view; /** * Called whenever updateView("viewcontrollername") is called in Controller */ public void update() { view.update(); } /** * Called whenever this View is set * @return the Scene being set, obtained from this ViewController's View instance */ public Scene initialize() { return view.update(); } public ViewController(View v) { view = v; } public void build() { view.build(); view.update(); built = true; } public boolean isBuilt() { return built; } }

That's rather helpful, thanks. It's a bit different since I'm not using FXML, but I think I get the idea.
I think I'll do the following:
- Have a main controller class that is the equivalent of Play in that framework, to hold my Stage and a HashMap containing my ViewControllers (thereby preventing accidental creation of multiple of the same scenes)

Then my only issue is that, since I'm not using FXML, a Controller class can't work in the same way - in an FXML program, the FXML defines the view and the Controller modifies it once it has been created, but here the View and Controller kind of go together.
So, I either:
- Create an abstract ViewController class and an abstract View class
- When a ViewController is instantiated, its partner View is too. A reference to the ViewController is stored in the play equivalent, and a reference to the View in the ViewController.
Or,
- I have an abstract View class
- Each View class handles everything to do with that view
- Each View could have an inner class to help keep logic separate

I think I'll go with the first solution above, though, to keep classes smaller. It's also possible that I prevent anything except a ViewController from instantiating a View? Since one isn't supposed to exist without another.

Knute Snortum wrote:You shouldn't have to re-open a view every time you switch to it.  Create a stage field and at least a setter in the view's controller, then when the view builds the stage, also set it in the controller.  Now the controller can have hideStage and showStage methods, if need be.

I don't want separate stages for each View, though, I just want to change the scene within the same stage - right now, I'm using stage.setScene (where stage is a static reference to the primaryStage) - so, each View would construct its Scene when first created and then to go to it I'd do stage.setScene(ViewObject/ViewClass.scene);
The reason why I wanted to make these classes singletons was because you're right, I don't need to re-build a view when I switch to it (although I may need to update it) - and I wanted to enforce that.

You shouldn't use static unless you have a really go reason to.  Static methods encourage procedural, rather that object oriented or event driven programming. I'm not sure of the reasons not to use static on views, but it may have to do with multi-user systems.  I've never seen another use static views, so there probably is a good reason not to.  What does having the views be static help with?  

I'm not entirely sure - but using this model, would I not want to limit the existence of each View to one? I don't want to build a new instance of a View class every time I switch to it, I want one instance of each View, constructed when first required, and then to use the same instance forever.

Actually, I think I'm kind of stuck in a rut right here. Whatever I look at doing, I can't see why it's better than doing things statically, I just keep reading articles and posts saying static = bad, singleton = evil, this/that should never be done, etc.
I'm sure there must be grounding somewhere, but I'm struggling to see it right now - unless it IS suited for my circumstances?
Even if I used MVC, I'm struggling to understand why, for each View class, have one statically available instance of it - since would want only one of each View to exist at a time...

That looks like a distinct possibility, though I'm not sure I follow the implementation in your project - it looks like you do almost everything in View, put your validation methods in Controller and called your logic Model, but I'm probably missing something.

The problem for me with splitting the building of the scene with the handlers that control it as you suggest is that the handlers are defined when the scene is being built - I could call a method from a Model class in the handler, but other than for organisations' sake, it feels a bit pointless.

I think MVC could still suit me, but I'm struggling to see a way to effectively implement it - especially since I don't have one scene, one view, that I need to update - I have many very different scenes.

Perhaps I could make each view class (which has its own scene, and extends some abstract view class), and then simply switch between them / initialize them when required through some Controller, and then have all of my other logic methods contained within some Model class? I fear I'd end up with some with some very large classes, though. I'm not sure it wouldn't be better to combine Model and View into one in my case, and have the logic for each Scene contained within the same class (unless, of course, said logic wasn't specific to that scene and is actually reusable).

I've also looked at a couple of examples online using MVC that use Observable and Observers to update the view automatically when the Model changes, but again I don't think that fits my use case, since I'm rarely updating the same scene with new information before going to a different scene and coming back, although sometimes I do, I don't think it would be a good idea to base the whole program around that premise.

Hi, I'm currently creating a JavaFX application and have encountered a dilemma.
My program will contain a system of menus and different scenes used for different things.
I have started by creating a class for each Scene, where the code for the construction of the scene and interaction with the scene is located. Each class has its own private static Scene, a static method for the construction of the scene the first time it's loaded (since it's not guaranteed that every scene will be required each time the program is run), a static method for setting the scene and doing anything that needs doing whenever the scene is set, and other private methods handling whatever goes on inside the scene itself.
However, this means that I have to implement these methods in each class that has a Scene that I create manually, and that I can't (at least without Reflection) use generic methods taking any class with a Scene as an argument or do similar things since all of these classes are purely static. I feel like my design is flawed.
My first thought was that a static abstract class would suit me perfectly, but those don't exist. I'm considering making each class a singleton extending an abstract superclass, allowing me to take advantage of polymorphism and the like, whilst also enforcing the existence of certain methods in each class and ensuring that only one scene for each menu can exist. However, upon further research, I have found many people denouncing the use of the singleton pattern, so now I am in doubt as to whether or not this is a good idea. I also thought about making each menu an instance of one class, defining the behaviour with Runnables, but again that sounds like a bad idea to me.
I would like advice or ideas as to whether I should keep doing what I'm doing, use singletons, or if there is another pattern I should be using that I don't know about.
Note that I'm programming this in Java (and some css) - so I'm not using FXML or scene builders, and I have no idea how that works.

Thanks