Details
-
Bug
-
Status: Closed
-
Blocker
-
Resolution: Fixed
-
None
-
None
-
None
Description
as GROOVY-1848 states Groovy should try to not to load classes by ClassLoader#loadClass but to open them using a stream based class reader. As this will avoid the issue with the static initializer it will also avoid allow to read the class creation date in a class without loading it and it will allow to extract generics (or annotation) information from the class without using the java5 API (GROOVY-1314).
As a fall back we still require a module accessing the class using reflection. In same cases we can not avoid this action. therefor I thought that adding an optional module to the build that uses java5 methods would solve that in a way we can live with. For this the default build would have to migrate to java5, but could still be run on java4. in case of java4 the build would not compile the optional module, thus allowing us to operate on a replacement doing the job as good as a running on a JVM prior to java5 can do. This dummy would also be used if groovy runs on a pre java5 VM.
With that we can still build Groovy on java4, but without generics and annotations, even when run on java5. When build on java5 we can still run Groovy on java4, if run on java5 the optional module will be used and allow additional information for java5 classes. The stream based reader will not need to be part of that module.
Attachments
Issue Links
- is depended upon by
-
GROOVY-1902 add check for usage of generics only with generics enabled classes and with the correct number of parameters
-
- Closed
-
-
-
- Closed
-
-
GROOVY-1314 support covariant return types (& generics)
-
- Closed
-