Jan Van den bosch

+ Follow
since Apr 17, 2008
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jan Van den bosch

Birla Murugesan wrote:
well,Is it applicable to declare the static member inside the static or Nonstatic method?

No it's not possible java throws illegal start of expression at line of static member declaretion,
because static or Nonstatic method is one of the property of class and thier static or Nonstatic methods can be invoked by thier class instances.

Likewise , i think Inner class instance also instantiated by thier outer class instances.

so Inner class also one of the property of outer class

so it throws compile error

Could you rephrase that please?
11 years ago

Birla Murugesan wrote:
since Inner class is associated with outer instance,so if you call static member inside the Inner class,how can they associate that static field with instance of outer.

They shouldn't.

It's static, so the member is shared between all instances of the inner class, even if they are associated with different outer instances.
11 years ago

Campbell Ritchie wrote:Does this Java™ Tutorials section help?

Not really, no. It says: "Also, because an inner class is associated with an instance, it cannot define any static members itself." Why should having a reference to your outer class keep you from defining static members?

Rob Prime wrote:Maybe Sun thought that if it's shared among all inner class instances, it is also shared among all outer class instances. Because that's where you should add these members - in the outer class.

What about the single responsibility principle then? Now I've got to add members to my outer class that logically belong to my inner class.

Rob Prime wrote:I wondered about it myself as well some time ago, but I decided it wasn't worth the trouble.

Yeah, probably. I just assumed there was a logical explanation for this behaviour.
11 years ago

This code won't compile. I fail to see why the Inner class can't have a static member field that's shared among all instances.
11 years ago
You're right. I'm not familiar with the book but the Runnable object definitely needs to implement the run() method:

Okay, it's called a Fibonacci series or a Fibonacci sequence; that should give you some clue about what to return from the method. You can't return the series as a single Integer value since it consists of multiple values, and you can't return multiple values from a method since that's simply not possible in Java. If you decide to return a List<Integer> from your call() method, your implements clause should reflect that; after all, that's the whole point of the type parameter: it buys you type safety.
The problem is not the Callable. You're not decrementing count so the algorithm goes on forever -- or at least until you run out of memory. Why are you using two Lists, instance variables at that?

Below is an example in Bruce Eckel's book Thinking in Java. Don't let the number of lines scare you away, it's actually pretty straightforward. For improved readability, you can just paste it in your IDE if you want to, it's a single file with no dependencies. I've added a few comments here and there for my (and your) convenience.

What the program does is simulate a line of customers queueing in front of a number of teller machines. Each customer is served by a teller for a certain amount of time. Additional customers get in line while the programming is running, and the number of active tellers adjusts itself to the total number of customers (in the TellerManager class).

The compareTo() method in Teller is used by the PriorityQueue in TellerManager and is used for sorting the Tellers in said queue, for example upon calling workingTellers.add(teller). These add methods are called in TellerManager.adjustTellerNumber(), which effectively runs in a dedicated TellerManager thread. You can see that in TellerManager's run() method.

Now, Bruce Eckel has synchronized the Teller.compareTo() method. Since Teller.customersServed is shared between the Teller's thread (look at its run() method) and the TellerManager's thread (which calls workingTellers.add(teller), which calls Teller.compareTo(Teller)), I can see why synchronization is necessary.

The part I'm having a problem with is the implementation of compareTo() on line 106. It makes use of other.customersServed. When TellerManager takes the lock on this, it makes sure that this.customersServed cannot be changed while the lock is held, but in the meanwhile, other.customersServed can still be changed by an other thread, since this thread isn't locking on other. What do you think, am I right?

I'd solve the problem with a private synchronized getCustomersServed() method in Teller, and call this method instead of accessing the field directly.

11 years ago
They might as well get rid of the default package altogether then. Seems like a, pardon my language, half-arsed feature to me.
11 years ago
I've got an enum MyEnum in the default package, and I'm trying to import its instances in another file:
The result is a compiler error: The import MyEnum cannot be resolved. When I put MyEnum in a package, it works flawlessly.

I've googled a little on the subject and apparently, this is expected behaviour. Static import of something in the default package was possible in previous versions of Java, but for some reason Sun decided to disallow it. My question: why?

Yes, I normally put all of my classes in packages, I just want to understand the reasoning behind this decision.
11 years ago

The following exception comes up when I run my application in an Orion application server:

Wanneer ik crimson.jar verwijder uit de Orion-directory, werkt alles naar behoren.

Zal deze oplossing nare gevolgen hebben? Is er een betere manier?,

Ik word geplaagd door de volgende exception wanneer ik mijn applicatie uitvoer in een Orion application server:

When I remove crimson.jar from Orion's subdirectory, it works fine.

Will this solution have consequences in the future? Is there a better way to solve this?
12 years ago

I've got a stateless session bean with CMT. One of its methods does two things:

1) it looks up an entity bean to update a row in the DB.

2) it sends a message to a queue to be picked up by a message-drive bean, which will perform a query on the DB, do some calculations and update lots (possibly hundreds of thousands) of rows in the DB.

The calculations and the DB update are to be performed asynchrously since they may take a lot of time, hence the message-driven bean.

The query in the MDB in step 2 relies on the row that was updated by the entity bean in step 1. The problem is, this row isn't updated until the transaction is committed after the session bean's method returns. By then, the MDB could have already stepped in and performed its query and recalculations with the old value, and it does.

I believe stateful session beans can use the SessionSynchronization interface to cope with this kind of problem. How can I handle this with a stateless session bean?

Simple question here: is wrapping a checked exception in a RuntimeException, like:

considered good practice? The exception originates in your DAO (lowest level), can't be recovered from along the way, and only results in an error message for the user (highest level).

I don't want to put "throws DaoException" in every one of my method declarations, but the exception still has to propagate to the user.

Any ideas?

12 years ago
That's... pretty lame.

Thanks though!
12 years ago