It's a warning due to the use of 'raw' types - such as a List without a type parameter - which is occasionally necessary in Greenfoot due to the fact that Greenfoot's API uses raw types. Greenfoot actually filters the warnings, but sometimes it doesn't manage to catch them all - the next release of Greenfoot will have improved filtering. You can ignore the warnings - they're harmless.

The use of raw types really bothers me, speaking as someone who stopped using raw types over a decade ago. I was just helping my son work on some Java code in Greenfoot and found myself stuck teaching him bad practice. I understand that the nuances of generics may be difficult to teach to kids, but couldn't you at least return List<?> or (for instance) List<? extends Actor>. You refer to Greenfoot as "standard Java" but generics are an industry standard. Is there any chance of updating your API some day?

(I think it would be better to open a new discussion topic rather than revive one from several years back, but anyway): We (in the development team) have actually talked about this issue a great deal. The original reasoning was that (for example) "List<? extends Actor>" is somewhat scarier / more difficult to comprehend for a complete beginner. We could perhaps have used "List<?>" but it still introduces syntax beyond what we were wanting the students to have to cope with. The main advantage of using the raw List type is that it allows for assignment to the correct generic type without too much hassle, that is, you can do things like: This won't be properly type checked, but it will compile (without warning, since Greenfoot will hide the usual Java warning), and it gives you a generic list. If getObjects() returned List<?> or List<? extends Actor>, the above line would not compile; you'd need a cast. When we say "standard Java" we refer to the Java language and environment standard, not any industry standard. However: yes, the API will be updated. The current development version of Greenfoot has the following signature for the World getObjects() method: As you can see we've gone to the other extreme, so that a call to 'getObjects(Fruit.class)' will automatically return a 'List<Fruit>'.

Thanks for the reply, and sorry for reopening an old thread. This was just the only reference to raw types I could find on your site, and I was puzzled by your decision. I also don't mean to sound overly critical. I was puzzled, and I understand your explanation. A local summer camp program uses Greenfoot and it looks like a good intermediate step between Scratch programming and Java with an IDE like Eclipse. But my son (who is 11) also uses Eclipse and I want to minimize the amount of unlearning he has to do. Note that he is having fun writing games in Greenfoot and is less frustrated than when using Eclipse. I admit I never thought about putting raw List into List<Fruit> like that. I will keep that in mind next time I help my son. At least I can avoid explicit casting. I like the new signature for getObjects. As long as kids aren't expected to write methods with signatures like that, I don't think there is any harm to having them in the API.