Roman, I’ve been mentioning two possibilities:
- Moving from Bags to ArrayLists now that (it appears) HotSpot has special-cased the errors in ArrayList.
- Adding some limited support for generics where appropriate in MASON.
These are both really big jobs. We were hoping to move MASON in that direction with the support of an NSF grant, but applying for that grant will have to wait for a year. :-( So I think these two moves aren’t going to happen for a while.
If you’re specifically thinking about Bags, here’s what would need to be done:
1. All internal references to scanning over bags using the numObjs variable would have to move to using get() and set(). This would include all applications.
2. Any calls to Bag.remove() would have to instead go to a utility method we’d make up which would do the same but be outside the class. Also, all applications.
3. We might need to deal with a few special constructors, though it wouldn’t be often.
4. Then we’d just need to refactor Bag to ArrayList namewise.
5. And finish up with changes to the documentation (manual, tutorials).
Not a small task.
On Jan 21, 2014, at 6:19 PM, Roman Seidl <[log in to unmask]> wrote:
> Dear Mason-Users!
> As I remember there has been some discussion to abolish the Bags in favor of Java collections as the performance advantage might be gone with more recent JDKs.
> Is this still a current debate?
> I prefer to avoid casting wherever possible. Else one could maybe think about typing Bags. Would that be possible?
> best regards,