Mike Simmons

Master Rancher
+ Follow
since Mar 05, 2008
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
72
In last 30 days
4
Total given
1
Likes
Total received
1046
Received in last 30 days
13
Total given
193
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mike Simmons

Not really.  First, subtype and supertype are well-defined terms in the Java Language Specification, while subset and superset are not.  More importantly though, subset and superset don't really apply here.  You could have two different collections and talk about whether the elements in one collection were a subset or superset of the other.  But that's different from having two different types, and wondering if everything you can do with one type can be done with the other type.
Not really.  They are sort of similar in that they both have algorithms involving counting how many times a method has been called, but their use cases are fairly different.
One minor addition: being reentrant also includes handling the unlocks correctly.  Specifically, if we modify Stephan's example to add something else after the call to doAnotherProtectedThing();

That call to k++ is also protected by the lock, even though the doAnotherProtected() method called unlock on the same lock.  Basically, a reentrant lock counts how many times it has been locked, and how many times it has been unlocked.  And it only really unlocks when the number of unlock calls is equal to the number of lock calls.  So you can have an arbitrary number of nested lock / unlock pairs, and the lock will not be released until the first, outermost pair of lock/unlock calls is finally exited.

This also makes it even more important to make sure that each unlock occurs in a finally blocks, from a try started immediately after the lock() was called.  Because if you ever fail to unlock properly from a bunch of nested calls like that, it can be less than obvious where the problem is.
Perhaps - but from the command line, I get an error like this:

4 days ago
I feel compelled to observe that IntelliJ has been supporting string templates for a while now.  And it correctly errors out if you use preview features without having the appropriate flags set, with a helpful message for how to set them.
4 days ago

Anil Philip wrote:If the first line is a call to another ctor, then how can you set a field on that line also?

you can only transform the data on the first line. After the first line, all of the fields will already be assigned


That call to the other constructor is how the fields are being set.  Running the other constructor sets the fields.

But while the first line must be a call to another constructor, there are nonetheless ways to insert some transformation of the data before the constructor is called.  You show one yourself:

Here the first line of the Crane(int, String) constructor is an invocation of the canonical constructor - and yet, it is changing the data on the way.  It's replacing numberEggs with numberEggs + 1.  And it's putting firstName and lastName together into a single name, separated by " ".  Those are both transformations of data, made by inserting simple expressions into the constructor invocation.  You could also insert an arbitrarily complex expression into that first line - but at some point, it's better to create a new static method, and insert that instead:

So you can squeeze quite a bit of transformation into that one line, if you need to.  Note that you aren't allowed to invoke an instance method there, or a this reference, because the current instance isn't fully constructed yet.  But you can do a lot of other things with the constructor parameters.

Anil Philip wrote:Then you might as well have just one compact constructor!


A compact constructor is a more flexible way to handle this sort of initialization.  But you can only have one compact constructor, and it is a direct companion to the one canonical constructor - that is, you can only reference variables from the canonical constructor arguments, and the canonical constructor is implicitly called at the end of the compact constructor.  The point being, all of this is of no help if you want to be able to create a constructor with a different list of arguments.  For that you need an overloaded constructor, by definition.  And that's when you have to deal with the no-data-alteration-except-on-first-line rule.

Note that they are finding ways to relax these rules in future versions of Java, starting with JDK 22.  But for now, these are the rules we must deal with.
5 days ago

Stephan van Hulst wrote:It appears I was asleep at the wheel. I meant to say "Geographically".


I know; I just had to needle you for it.  My main objective was to give Campbell crap for his geography, but as long as your posts were right next to each other...

Stephan van Hulst wrote:. . . topographically, we should be in the same time zone as Great Britain.


Topographically the Netherlands has a range of elevations from -7 m to 322.4 m, while Great Britain ranges from -2.75 m to 1345 m.  Exclude Scotland. and the remainder would be more comparable to the Netherlands.  But in general, the main topograpic difference between the two is right there in the name Netherlands.  

Campbell Ritchie wrote:Spain is west of Britain and also on CET.



 Parts of Spain are a little to the west and parts are a little to the east.  But overall it's mostly to the south.

I gather the intended point was that geographically it seems like Spain and Britain should be in the time zone, but they aren't.  I agree - it's an example of countries choosing time zone for other reasons.

Stephan van Hulst wrote:

Mike Simmons wrote:Just on general principle, I find it silly to make the one with "Summer" in the norm.  "Standard" should be the norm.


It depends on whether summer time or winter time is on average a better fit for your society.


Well, there are various valid (and less valid) reasons to alter the time zone one way or another - and I wasn't objecting to that, in and of itself.  But whatever you call the new time zone, please don't call it "Summer" if it's year-round, because that part sounds like nonsense to me.

Sadly, the world's governments have failed to consult me on this matter, so far.  Oh well.
There are multiple ways to do this, and some of them could use flatMap(), sure.  Though the way the problem is described, using forEach as Paul suggested seems simpler.  

I would probably use Files.newOutputStream() to open a single output stream to the target file at the beginning, and then  use forEachOrdered to call Files.copy(path, outputstream) on each source file.  Note that you will need a try/catch block to fit this in a stream, since it throws a checked IOException.  I would probably just catch the exception and re-throw it wrapped in a RuntimeException.
1 week ago
It looks like there's probably a mismatch in your [ quote ] tags above, making the quote somewhat garbled, unfortunately.  It may be too late to edit it - maybe a moderator will fix it for you.

I'm not really an Android dev, so I'm not sure what are best practices to set this up... but as a guess, I might try having one instance variable in MainActivity:

When the app starts up, in whatever method is appropriate, initialize it something like this:

If you ever need to close everything, that can be done from the controller.  Closing the streams will also close the underlying socket.  You don't need to save the socket in another variable - simply saving the controller gives you access to whatever methods you need.
You don't need to quote the whole previous post in your reply - we often like to see just the part that you're immediately replying to.

David Go wrote:My question is more toward how to use the following in my current code:

What function should I call that as it looks like its taking whatever is in the out_ and in_ variables - right? And what should the ExecutorService be?


Hmmm, I hadn't noticed that.  The ExecutorService looks like an idea Stephan had that he didn't implement here - you should probably just delete it, since it's not being used:

I would probably do something like this instead:

And

The idea here is that when you're done with the controller, you close it.  But you don't want to close it before you're done.  Because that will close the input and output streams, and you may want to keep using those.  To be honest, there's a good chance you never want to close this class - just keep it open for the life of your program.  Unless you ever need to switch to reading and writing with a different socket.

There are probably other changes cascading from here.  You might want to make changes more slowly, rather than using Stephan's class directly, if you're not sure how it's to be used.  

One general design question to think about: do you want to open a socket each time you execute a command?  And then close it (or allow it to close eventually) sometime later?  Or just open the socket once, and use the controller to listen and respond?  Stephen's code is guiding you to the latter.  But your existing code is more like the former.  

David Go wrote:And the error I got was this:

C:\Users\AndroidStudioProjects\OnkyoRC\app\src\main\java\com\example\onkyorc\MainActivity.java:400: error: cannot find symbol
           var bytes = string.getBytes(US_ASCII);
           ^
 symbol:   class var
 location: class MainActivity.EiscpController



That looks like you're using an older version of Java.  What JDK are you using?  It should be version 11 or later.  (Technically, 10, but why would anyone still be using 10 now?)  If you're using an IDE, it may also have some settings for the java language level.  In IntelliJ this is under Project Settings ->Project -> Language Level, which should also be at least 11.

Campbell Ritchie wrote:Is that local class a member of the surrounding class? I am not quite sure.


No.  A "member" of a class must be directly enclosed by that class.  It can't be contained within something else which is a member of the class.  A local class is directly contained by a code block, for a method or constructor or initializer.  It can't be directly contained by a class.
1 week ago
I think we all agree that the underlying physics of the universe are unaffected by this, as are all the animals - it's just the humans and the way we represent our dates and times that are affected.  But whether we call it a "hole" or a "gap", yes, there is something weird going on here.  In Spring we jump directly from 1:59:59 AM to 3:00:00 AM.  And in Fall, we go from 1:59:59 AM to... 1:00:00 AM, and then repeat an hour.  Technically we go from 1:59:59 AM DST to 1:00:00 AM Standard Time, if you need to distinguish between the two.

Someone has probably written a murder mystery where the solution depends on the fact that the same clock time occurs twice during fall DST adjustments.  For a select audience, I imagine.
That was posted before I saw Paul's reply above.  Sounds like we're all on about the same page here.