Mon, 17 Oct 2016 12:09:30 +0200 Patch package class and regenerate build files to hopefully fix the clean build. cvs_MAIN
mawalch [Mon, 17 Oct 2016 12:09:30 +0200] rev 3633
Patch package class and regenerate build files to hopefully fix the clean build.
Mon, 17 Oct 2016 12:09:29 +0200 Patch package class and regenerate build files to hopefully fix the clean build. cvs_MAIN
mawalch [Mon, 17 Oct 2016 12:09:29 +0200] rev 3632
Patch package class and regenerate build files to hopefully fix the clean build.
Mon, 17 Oct 2016 12:08:44 +0200 #BUGFIX by mawalch cvs_MAIN
mawalch [Mon, 17 Oct 2016 12:08:44 +0200] rev 3631
#BUGFIX by mawalch Patch package class and regenerate build files to hopefully fix the clean build.
Fri, 14 Oct 2016 13:46:22 +0200 #REFACTORING by stefan cvs_MAIN
Stefan Vogel <sv@exept.de> [Fri, 14 Oct 2016 13:46:22 +0200] rev 3630
#REFACTORING by stefan class: JavaLookup changed: #lookupMethodForSelector:directedTo: (send #overwrites: instead of #overrides:) be compatible with Method
Fri, 14 Oct 2016 13:46:05 +0200 #REFACTORING by stefan cvs_MAIN
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
Wed, 12 Oct 2016 23:02:07 +0200 #BUGFIX by mawalch cvs_MAIN
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.
Tue, 20 Sep 2016 22:56:52 +0100 Issue #93 [3/3]: Avoid (expensive) registry scan to find all erroneous classes
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
Wed, 21 Sep 2016 09:18:20 +0100 Issue #93 [2/3]: Avoid (expensive) test for compilation error at (re)compilation time
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
Tue, 20 Sep 2016 10:11:05 +0100 Issue #93 [1/3]: Added 2 simple benchmarks to measure performance of class loading
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
Mon, 19 Sep 2016 23:20:38 +0100 Update system classloader's classpath when a package is loaded
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.
(0) -3000 -1000 -300 -100 -10 +10 +100 +300 tip