On Mon, 8 Aug 2022 02:14:45 GMT, Ioi Lam wrote:
> the above reason can be used against any sort of refactoring of the source
> code
Indeed - they are always the "cons" of such a refactoring, and it is up to the
"pros" to outweigh them.
-
PR: https://git.openjdk.org/jdk/pull/9788
On Mon, 8 Aug 2022 01:26:11 GMT, David Holmes wrote:
> My issue with these kinds of changes in general is that they:
>
> * undermine institutional memory
> * make it harder to do backports due to the shuffling
> * make it harder to track changes due to the shuffling
>
> So the benefit to me has
On Sat, 6 Aug 2022 00:11:08 GMT, Ioi Lam wrote:
> To improve modularity and build time, move the declaration of the following
> accessor from classfile/javaClasses.hpp to runtime/threadJavaClasses.hpp:
>
> + java_lang_Thread_FieldHolder
> + java_lang_Thread_Constants
> + java_lang_ThreadGroup
>
On Sat, 6 Aug 2022 13:09:01 GMT, Thomas Stuefe wrote:
>> To improve modularity and build time, move the declaration of the following
>> accessor from classfile/javaClasses.hpp to runtime/threadJavaClasses.hpp:
>>
>> + java_lang_Thread_FieldHolder
>> + java_lang_Thread_Constants
>> + java_lang_T
On Sat, 6 Aug 2022 00:11:08 GMT, Ioi Lam wrote:
> To improve modularity and build time, move the declaration of the following
> accessor from classfile/javaClasses.hpp to runtime/threadJavaClasses.hpp:
>
> + java_lang_Thread_FieldHolder
> + java_lang_Thread_Constants
> + java_lang_ThreadGroup
>
On Sat, 6 Aug 2022 00:11:08 GMT, Ioi Lam wrote:
> To improve modularity and build time, move the declaration of the following
> accessor from classfile/javaClasses.hpp to runtime/threadJavaClasses.hpp:
>
> + java_lang_Thread_FieldHolder
> + java_lang_Thread_Constants
> + java_lang_ThreadGroup
>
