Stefan Vogel <sv@exept.de> [Fri, 14 Oct 2016 13:46:05 +0200] rev 3629
#REFACTORING by stefan
class: JavaMethod
added: #overwrites:
removed: #overrides:
be compatible with Method
mawalch [Wed, 12 Oct 2016 23:02:07 +0200] rev 3628
#BUGFIX by mawalch
class: JavaSettingsApplication
changed: #javaHomeList
Care for the case that the Java installation could not be located.
Jan Vrany <jan.vrany@fit.cvut.cz> [Tue, 20 Sep 2016 22:56:52 +0100] rev 3627
Issue #93 [3/3]: Avoid (expensive) registry scan to find all erroneous classes
Instead remember such classes in a separate set when the class is
registered. The set is NOT weak and does not need to. Registry holds
classes strongly anyway. There's no point to recompile an obsolete class
(I believe, we'll see).
This yields in another ~25% speedup for Groovy classloading benchmark.
https://swing.fit.cvut.cz/projects/stx-libjava/ticket/93
Jan Vrany <jan.vrany@fit.cvut.cz> [Wed, 21 Sep 2016 09:18:20 +0100] rev 3626
Issue #93 [2/3]: Avoid (expensive) test for compilation error at (re)compilation time
Instead, detect compilation errors when .class file is read by `JavaClassReader`.
If error are detected, mark class a erroneous using ACX_HASERRORS flag.
At (re)compilation time, just test for this flag, which is a lot quicker than
scanning a constant pool.
https://swing.fit.cvut.cz/projects/stx-libjava/ticket/93
Jan Vrany <jan.vrany@fit.cvut.cz> [Tue, 20 Sep 2016 10:11:05 +0100] rev 3625
Issue #93 [1/3]: Added 2 simple benchmarks to measure performance of class loading
https://swing.fit.cvut.cz/projects/stx-libjava/ticket/93
Jan Vrany <jan.vrany@fit.cvut.cz> [Mon, 19 Sep 2016 23:20:38 +0100] rev 3624
Update system classloader's classpath when a package is loaded
...at runtime and defines its own java libraries. While this should
not be a common case for standalone applications, in development mode
once often load packages on demand. Then this comes handy as one does
not need to reboot the JVM.
Jan Vrany <jan.vrany@fit.cvut.cz> [Mon, 19 Sep 2016 17:01:59 +0100] rev 3623
Fixed #isObsolete for Java classes being replaceb by newer version(s).
* Fixed JavaClass>>isObsolete to test for bit ACX_OBSOLETE.
* Fixed JavaMetaclass>>isObsolete to ask it's class.
* Changed `JavaClassRegistry` to mark old class as obsolete when
it's replaced.
This is necessary for tools (namely browser) as it refetches class
the onecurrently being displayed is changed. This depends on correct
return value of #isObsolete.
Jan Vrany <jan.vrany@fit.cvut.cz> [Mon, 19 Sep 2016 15:26:35 +0100] rev 3622
Renamed ACC_OBSOLETE to ACX_OBSOLETE as JVM spec does not define ACC_OBSOLETE
Define ACX_HASERRORS (not used currently)
Jan Vrany <jan.vrany@fit.cvut.cz> [Sun, 18 Sep 2016 12:11:12 +0100] rev 3621
Issue #49: Fixed a little bug when setting `thisContext` for debugger evaluation
...caused by refactoring. Test was missing so not spotted before. Sigh.
mawalch [Tue, 27 Sep 2016 15:18:24 +0200] rev 3620
#DOCUMENTATION by mawalch
class: JavaMethod
comment/format in: #resolve