Bug

If you are experiencing high memory comsumption with Lucene 2.9.0/3.0.1 it could be due… ... to a recently reported and fixed bug in StandardTokenizer where JFlex generated code was expanding a buffer (zzBuffer) and never trimming it down Uploaded with plasq's Skitch! ... to another recently reported and fixed bug where IndexWriter held references to Readers used in your Fields, (and if you have apache tika's reader, those can take up a lot of space) Uploaded with plasq's Skitch!

Java 6 includes STaX , when I tried to parse a Evernote backup file with it, I got a OOME error. java.lang.OutOfMemoryError: Java heap space at com.sun.org.apache.xerces.internal.util.XMLStringBuffer.append(XMLStringBuffer.java:205) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.refresh(XMLDocumentScannerImpl.java:1520) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.invokeListeners(XMLEntityScanner.java:2070) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.peekChar(XMLEntityScanner.java:486) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2679) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:548) at Googling a bit I found a bug report 6536111. It says that this should be fixed in 1.6.0_14. But I tried Sun 1.6.0_16 and no luck. I got the exact same thing. ...

I filed a bug report http://www.netbeans.org/issues/show_bug.cgi?id=153354 It seems that it cannot find the inner class ResolvableHelper inside the TopComponent. (throws a NoClassDefFoundException, see the messages.log for details ). It’s funny though, because it works perfectly in Windows XP and Vista, I thought this stuff was platform independent.

It seems that is imposible to type the ˜ symbol (named also tilde,squiggle,twiddle,not,approx,wiggle,swung,dash,enyay,sqiggle) in Netbeans with a Swedish keyboard at least. It seems that it’s a long known java bug (bug 6353098, bug 6253172). At least I can use the Alt+126 code to type it.

After long long time since the bug #149890 was reported on 2006-07-06 has been finally resolved on 2008-02-03. I wonder if my comment on javalobby a couple of days ago has something to do with this. Now it seems that is possible to have a dynamic MenuManager as a submenu of the parent MenuManager.

I’ve submitted a patch (Attachment #77777 and a couple of screenshots ( Attachment #77774 y Attachment #77776) to Bug #201116. It’s only a preliminary work but it enables the user to select with contentMergeViewer to use with each FileType/ContentType. Now it’s only useful if you use my java formatting compare plugin. Currently the org.eclipse.compare subsystem will allow only one contentMergeViewer per fileType or contentType and you cannot tell which one it will be as Szymon Brandys comments. With this patch the user can select/switch which one he wants to use among all viewer registered for a given file extension/content type. ...

I filled Bug 201116 – Compare will silently discard additional contentMergeViewers associated with the same file extension a couple of days ago. As Szymon Brandys says eclipse should allow the user to switch between the differente merge viewer available for a given extension. He proposes two solutions: Having a mechanishm inside the compare view to do the switch or having a preference page to do the same I feel more inclined towards the second solution, as I’m used to change the defautl editor for .xml, etc though the preference page General -> Editors -> File Associations. Having a similar preference page would fit me. I’m trying to figure out how to integrate a preference page to org.eclipse.compare and send it back to eclipse.org to include it in the next release.

I run onto the following exception a couple of days ago: Caused by: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces. at com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.checkDOMNSErr (CoreDocumentImpl.java:2421) the following log trace was also present in the log file SEVERE: SAAJ0511: Unable to create envelope from given source Apparently I run onto a known java bug present in jdk1.5.0_08 up to jdk1.5.0_11. Funny, I downgraded to jdk1.5.0_07.

The JDBC Sampler always commits (it doesn’t honor the auto-commit = false parameter) http://issues.apache.org/bugzilla/show_bug.cgi?id=42018. I’ve provided a patch that solved it at Bugzilla