Istvan Kovacs

Ynl0ZS5jbGFzcywgQnl0ZS5jbGFzcw==

Mike Simmons wrote:

Istvan Kovacs wrote:I've used the fully specified name of Arrays so you don't get funny ideas

I note you didn't do the same for Class... not sure if that's intentional. There's a solution that exploits that omission.

It was unintentional. The solution does not need any tricks. You can solve it in 22 characters, even if nicely formatted. :-)

No, that's essentially the same as a raw cast.
Hint (quoting the Javadoc of getDeclaredMethods()): SWYgdGhpcyBDbGFzcyBvYmplY3QgcmVwcmVzZW50cyBhbiBhcnJheSB0eXBlLCBhIHByaW1pdGl2ZSB0eXBlLCBvciB2b2lkLCB0aGVuIHRoZSByZXR1cm5lZCBhcnJheSBoYXMgbGVuZ3RoIDAuIA==

Hunter McMillen wrote:You have to be careful with the kind of terminology you use. "static" is a keyword in Java that has a particular meaning. By saying "static" array I think you mean "fixed-size" array. A "static" array in Java is an array that belongs to a particular instance of a class.
Hunter

You mean an array that belongs to no particular instance of the type, but to the type itself.

OK, sorry about the edit.
Would you like a hint, or the solution?

OK. Maybe I did not explain properly what the challenge is about.
<T> void check(Class<T> type1, Class<T> type2) enforces that type1 and type2 are both Class<Foo> (if T=Foo).
If this were not enforced, it'd be trivial to just send two unrelated classes to check, and their methods would be different.
By using the raw cast (from Class<String> to raw Class), we pretty much 'disable the generics' on the invocation of check), since, based on the 2nd argument, the compiler will deduce that T = Object, and the raw type Class can be assigned to any parameterised Class<T> reference, so we'll have an assignment of Class (pointing at String.class) to Class<Object> as the 1st argument to check.

Now, your job is to find arguments for check such that the cast is not needed. In other words, replace ABC and XYZ with something that

does not involve a cast

results in compilable code

and prints 'You won'

check(ABC, XYZ); // line 3 of original code

Nope, lockedAccounts.wait() releases the lock on the Set's monitor. Also, this would not cause a DB-level deadlock.

I'm not a JPA/Hibernate expert, but that's not how I'd use the EntityManager. Why unwrap the session, why call saveOrUpdate etc.?
Get the objects via the EntityManager, update their state, and you should be done (as long as the entity is managed by the EntityManager, it will know when you modify it, and will save it without any extra calls when the transaction completes).
Also, I have never had to do this magic with ordering entity loading, and mixing in synchronisation via wait-notify. You can use optimistic locking (by adding a version number to the entity and to the DB table). It will sometimes fail, but that's a fact of life: someone has committed a transaction that changed the state of your object, so you're working on stale data. How you handle that optimistic lock failure depends on the business logic: most probably you'd have to propagate the exception and make the top-level call fail, e.g. reporting it to the user or returning an error code on your REST API.

I'm not sure why the Javadocs of Arrays#equals would be helpful, or why something related to this puzzle would get one fired.
Instead, I'd recommend checking out Class.getDeclaredMethods.

You're right in having to return false, not true, I've updated the post. Thanks!

OK, some more Java fun. The following will print 'You won'.
What arguments (you may modify both!) to check would make the code compile without casting to Class, and still result in "You won" being  printed?
(I've used the fully specified name of Arrays so you don't get funny ideas and create a class with that name, adding a static equals method that simply returns false all the time.)
Please post your base64-encoded answer as a comment, so you don't spoil the fun for others. Long-time readers of Peter Verhas's blog, javax0.wordpress.com, will be at a definite advantage (true in general, BTW).
public class ClassFun {    public static void main(String[] args) {        check((Class) String.class, Object.class);    }    private static <T> void check(Class<T> type1, Class<T> type2) {        if (!java.util.Arrays.equals(type1.getDeclaredMethods(), type2.getDeclaredMethods())) {            System.out.println("You won");        }    } }

You are asking the wrong question. The question you should be asking is "Why does Thread run the supplied Runnable?". (Tip: read its source code.) Once you figure that out, you'll know the answer to your question.

Java Concurrency In Practice devotes a complete chapter to shutting down. I highly recommend the book.
Basically, as the others have suggested, you could use interrupt() and handle InterruptedException or check the flag (but be sure to check the difference between interrupted() and isInterrupted()).
You could also use a volatile boolean field (say, keepRunning) that you check in a loop.
Or, if you read jobs from a queue, you could insert a 'poison pill', a special job instance that you do not execute, but use its occurrance as a signal to stop.
If your thread is stuck reading from a socket, closing the socket is the only way to wake it up (it will not react to interruption). For NIO, use InterruptibleChannel. With java.nio.channels.Selector, use wakeup(). If the thread is waiting to enter a synchronized block, you can do nothing; converting code to use explicit Locks allows for interruption (but you have to be careful with exception handling).

Henry,

Your clarification is perfect, thank you for the addition. It says what my 'unless you publish your variable (assign it to an instance or class attribute, or pass it to other objects that do so)' was meant to say, in a lot more understandable way, and also covers the case when the publishing is done before the local reference is created.

Cheers,
Kofa / István

I don't like the last solution. The only thing we reuse from BusinessTaxStrategy is its 'BusinessTaxStrategy-ness'. Using that approach, it'd probably be better to refactor the code, making BusinessTaxStrategy an interface, and implementing it.
ps. "implements TaxStrategy" is redundant if we leave the code as it is, since we already have class BusinessTaxStrategy implements TaxStrategy.

Now, let's steer away from trying to solve this without generics (not because it's wrong, but because it's not the thing at the heart of my question). What I'm interested in is if it's possible to create an unparameterised UniversalBusinessStrategy type and have no warnings (without @SuppressWarnings, of course).