VM state:not at safepoint (normal execution) =>0x00395800 JavaThread "main" Ġx0aa7fc00 VMThread Ġx0aab9c00 WatcherThread P R O C E S S -Ġx0ad98c00 JavaThread "Thread-0" Ġx0aaa6800 JavaThread "Low Memory Detector" daemon Ġx0aa98800 JavaThread "CompilerThread0" daemon Ġx0aa97400 JavaThread "Attach Listener" daemon Ġx0aa96800 JavaThread "Signal Dispatcher" daemon Ġx0aa88c00 JavaThread "Finalizer" daemon Ġx0aa84800 JavaThread "Reference Handler" daemon Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) T H R E A D -Ĭurrent thread (0x00395800): JavaThread "main" # If you would like to submit a bug report, please visit: # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode windows-x86) # An unexpected error has been detected by Java Runtime Environment: Therefore it is expected that some things won't work as they should, I guess.The error occurs with Jabref 2.3, 2.4b, and 2.4: I did not report these issues so far, as the groups of version 4 are, as far as I understand, in active development. Having said all of this, I have to say, however, that, indeed, the new group panel does look much nicer, than the old one and that - once those issues are solved - I'm looking forward to the (potential) new capabilities of the new groups panel (e.g. brackets are added to the first character following the underscoreĮ) does not offer the same options that were available with the old group panel, when rightclicking onto one of the groups "Alpha_taxonomy" as "Alpha_(t)axonomy", i. It could also have to with the current implementation of the groups in version 4, which is:ī) does not allow to hide the number of entries (which might cause some performance issues on large databases)Ĭ) cannot be opened with all subgroups expanded as defaultĭ) displays group titles with underscore, e.g. Now, I can't say, whether this is related to the new fix or whether this was introduced earlier on in the development of version 4. In the meantime it behaves as if JabRef had crashed. Indeed, the usage of the CPU suddenly spikes to nearly 100% and it takes several seconds for JabRef to save the database. it was saved nearly instantaneously), especially when the entry preview is open. Something I noticed, however, is that saving the (huge) database takes now much longer than before (with 3.8.2. I've tried the new build and, as far as I can tell, it does indeed fix the reported issue. JabRef 4.0.0-dev-snapshot-braces-checking-followup-488825af5
0 Comments
Leave a Reply. |