Develop Reference

Issue in addPlugInSingleRowFunction upgrading Esper version from 5.3 to 8.3

In our existing application we are using Esper Version 5.3.
We have added few addPlugInSingleRowFunction() to use it in EPL as below --
final Configuration cepConfiguration = new Configuration();
cepConfiguration.addPlugInSingleRowFunction("toNumber", Double.class.getName(), "parseDouble");
cepConfiguration.addPlugInSingleRowFunction("toBoolean", Boolean.class.getName(), "parseBoolean");
This was working fine in 5.3 version.
Post upgrading to 8.3 above code changed as per Esper documentation --
cepConfiguration.getCompiler().addPlugInSingleRowFunction("toNumber", Double.class.getName(), "parseDouble");
cepConfiguration.getCompiler().addPlugInSingleRowFunction("toBoolean", Boolean.class.getName(), "parseBoolean");
But once the sendEventBean() method is called to send a Event to runtime we are seeing below exception every time.
Surprisingly events are getting matched as per the statements present in runtime even if below exception are coming. Though we are not sure whether some events are not matching or not.
Can someone please help on this?
applog.cls=com.espertech.esper.common.internal.epl.expression.dot.core.ExprDotNodeForgeStaticMethodEval,applog.mthd=staticMethodEvalHandleInvocationException,applog.line=228,applog.msg=Invocation exception when invoking method 'parseDouble' of class 'java.lang.Double' passing parameters [null] for statement 'stmt-0': NullPointerException : null,exc.stack=java.lang.NullPointerException\n\tat sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1838)\n\tat sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110)\n\tat java.lang.Double.parseDouble(Double.java:538)\n\tat generated.StatementAIFactoryProvider_a4bd241445010f45474e4598e34521ca1b2836db_stmt450.m8(StatementAIFactoryProvider_a4bd241445010f45474e4598e34521ca1b2836db_stmt450.java:161)\n\tat generated.StatementAIFactoryProvider_a4bd241445010f45474e4598e34521ca1b2836db_stmt450$2.get(ANONYMOUS.java:148)\n\tat com.espertech.esper.runtime.internal.filtersvcimpl.FilterParamIndexEquals.matchEvent(FilterParamIndexEquals.java:32)\n\tat com.espertech.esper.runtime.internal.filtersvcimpl.FilterHandleSetNode.matchEvent(FilterHandleSetNode.java:100)\n\tat com.espertech.esper.runtime.internal.filtersvcimpl.EventTypeIndex.matchType(EventTypeIndex.java:178)\n\tat com.espertech.esper.runtime.internal.filtersvcimpl.EventTypeIndex.matchEvent(EventTypeIndex.java:124)\n\tat com.espertech.esper.runtime.internal.filtersvcimpl.FilterServiceBase.retryableMatchEvent(FilterServiceBase.java:179)\n\tat com.espertech.esper.runtime.internal.filtersvcimpl.FilterServiceBase.evaluateInternal(FilterServiceBase.java:96)\n\tat com.espertech.esper.runtime.internal.filtersvcimpl.FilterServiceLockCoarse.evaluate(FilterServiceLockCoarse.java:52)\n\tat com.espertech.esper.runtime.internal.kernel.service.EPEventServiceImpl.processMatches(EPEventServiceImpl.java:610)\n\tat com.espertech.esper.runtime.internal.kernel.service.EPEventServiceImpl.processWrappedEvent(EPEventServiceImpl.java:450)\n\tat com.espertech.esper.runtime.internal.kernel.thread.InboundUnitSendEvent.run(InboundUnitSendEvent.java:43)\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat java.lang.Thread.run(Thread.java:748)

You could turn on compiler logging (config.getCompiler().getLogging().setEnableCode(true);) and make sure you have INFO level logging. You can inspect "StatementAIFactoryProvider_a4bd241445010f45474e4598e34521ca1b2836db_stmt450.m8" at line 161 to see what the problem is. Sounds like a null value gets passed to Double.parseDouble. But since I don't have the complete code its hard to say.

Using toUpperCase with Correct Locale

I'm trying to fix errors which are reported by forbiddenapis. I had that line:
paramMap.put(Config.TITLEBOOST.toUpperCase(), titleBoost);
So, its been reported as error as usual. I've tried that:
paramMap.put(Config.TITLEBOOST.toUpperCase(Locale.getDefault()), titleBoost);
and that:
paramMap.put(Config.TITLEBOOST.toUpperCase(Locale.ROOT), titleBoost);
also that:
paramMap.put(Config.TITLEBOOST.toUpperCase(Locale.ENGLISH), titleBoost);
However none of them fixed the error:
[forbiddenapis] Forbidden method invocation:
java.lang.String#toUpperCase() [Uses default locale]
What I miss?

Double-check that the bytecode you are analyzing is actually your most recent build output, and that you're looking at the same line forbiddenapis is :) . This looks to me like your source/bytecode/analysis are falling out of sync — the relevant rule shouldn't flag an error on String.toUpperCase(Locale).
Disclaimer: I haven't used forbiddenapis myself --- I wrote this answer based on the repo and on a blog post I found.

Run an ABCL code that uses cl-cppre

With reference to my previous question,
Executing a lisp function from Java
I was able to call lisp code from Java using ABCL.
But the problem is, the already existing lisp code uses CL-PPCRE package.
I can not compile the code as it says 'CL-PPCRE not found'.
I have tried different approaches to add that package,
including
1) how does one compile a clisp program which uses cl-ppcre?
2)https://groups.google.com/forum/#!topic/cl-ppcre/juSfOhEDa1k
Doesnot work!
Other thing is, that executing (compile-file aima.asd) works perfectly fine although it does also require cl-pprce
(defpackage #:aima-asd
(:use :cl :asdf))
(in-package :aima-asd)
(defsystem aima
:name "aima"
:version "0.1"
:components ((:file "defpackage")
(:file "main" :depends-on ("defpackage")))
:depends-on (:cl-ppcre))
The final java code is
interpreter.eval("(load \"aima/asdf.lisp\")");
interpreter.eval("(compile-file \"aima/aima.asd\")");
interpreter.eval("(compile-file \"aima/defpackage.lisp\")");
interpreter.eval("(in-package :aima)");
interpreter.eval("(load \"aima/aima.lisp\")");
interpreter.eval("(aima-load 'all)");
The error message is
Error loading C:/Users/Administrator.NUIG-1Z7HN12/workspace/aima/probability/domains/edit-nets.lisp at line 376 (offset 16389)
#<THREAD "main" {3A188AF2}>: Debugger invoked on condition of type READER-ERROR
The package "CL-PPCRE" can't be found.
[1] AIMA(1):
Can anyone help me?

You need to load cl-ppcre before you can use it. You can do that by using (asdf:load-system :aima), provided that you put both aima and cl-ppcre into locations that your ASDF searches.

I used QuickLisp to add cl-ppcre (because nothing else worked for me).
Here is what I did
(load \"~/QuickLisp.lisp\")")
(quicklisp-quickstart:install)
(load "~/quicklisp/setup.lisp")
(ql:quickload :cl-ppcre)
First 2 lines are only a one time things. Once quickLisp is installed you can start from line 3.

YUICompressor crashes - stackoverflow error

I frequently get what appears to be a stackoverflow error ;-) from YUICompressor. The following is the first part of thousands of error lines that come from attempting to compress a 24074 byte css stylesheet (not the "Caused by java.lang.StackOverflowError about 8 lines down):
iMac1:src jas$ min ../style2.min.css style2.css
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.yahoo.platform.yui.compressor.Bootstrap.main(Bootstrap.java:21)
Caused by: java.lang.StackOverflowError
at java.lang.Character.codePointAt(Character.java:2335)
at java.util.regex.Pattern$CharProperty.match(Pattern.java:3344)
at java.util.regex.Pattern$Branch.match(Pattern.java:4114)
... (plus 1021 more error lines)
The errors happen usually after adding a couple of lines to the file getting compressed. The css is fine, and works perfectly in the uncompressed format. I don't see a particular pattern to the types of selectors added to the file that cause the errors. In this case, adding the following selector to a previously compressible file resulted in the errors:
#thisisatest
{
margin-left:87px;
}
I am wondering if there is perhaps a flag to java to enlarge the stack that might help. Or if that is not the problem, what is?
EDIT:
As I was posting this question, it dawned on me that I should check the java command to see if there was a parameter to enlarge the stack. Turns out that it is -Xssn, where "n" is a parameter to indicate the stack size. Its default value is 512k. So I tried 1024k but that still led to the stackoverflow. Trying 2048k works however, and I think this could be the solution.
EDIT 2:
While I no longer use this method for minification any longer, to be more specific here is the full command (which I have set up as a shell alias), showing how the -Xss2048k parameter is used:
java -Xss2048k -jar ~/Documents/RepHunter/Website\ Materials/Code/Third\ Party\ Libraries/YUI\ Compressor/yuicompressor-2.4.8.jar --type css -o

As posted in my edit, the solution was to add the parameters to the java command. The clue was the error line at the 5-th "at" line, as follows:
at com.yahoo.platform.yui.compressor.Bootstrap.main(Bootstrap.java:21)
Caused by: java.lang.StackOverflowError
Seeing that the issue was a "StackOverlowError" ;-) gave the suggestion to try to increase the stack size. The default is 512k. My first try of 1024k did not work. However increasing it to 2048k did work, and I have had no further issues.

(Unknown Source) in Exception stack trace

Background
This question is related to Why does String.valueOf(null) throw a NullPointerException?
Consider the following snippet:
public class StringValueOfNull {
public static void main(String[] args) {
String.valueOf(null);
// programmer intention is to invoke valueOf(Object), but instead
// code invokes valueOf(char[]) and throws NullPointerException
}
}
As explained in the answer to the linked question, Java's method overloading resolves the above invokation to String.valueOf(char[]), which rightfully results in a NullPointerException at run-time.
Compiled in Eclipse and javac 1.6.0_17, this is the stack trace:
Exception in thread "main" java.lang.NullPointerException
at java.lang.String.<init>(Unknown Source)
at java.lang.String.valueOf(Unknown Source)
at StringValueOfNull.main(StringValueOfNull.java:3)
Note that the stack trace above is missing the KEY information: it does NOT have the full signature of the valueOf method! It just says String.valueOf(Unknown Source)!
In most situations I've encountered, exception stack traces always have the complete signature of the methods that are actually in the stack trace, which of course is very helpful in identifying the problem immediately and a major reason why the stack trace (which needless to say is rather expensive to construct) is provided in the first place.
And yet, in this case, the stack trace does not help at all. It has failed miserably in helping the programmer identify the problem.
As is, I can see 3 ways that a programmer can identify the problem with the above snippet:
Programmer realizes on his/her own that the method is overloaded, and by resolution rule, the "wrong" overload gets invoked in this case
Programmer uses a good IDE that allows him/her to quickly see which method is selected
In Eclipse, for example, mouse-hovering on the above expression quickly tells programmer that the String valueOf(char[] data) is indeed the one selected
Programmer examines the bytecode (ugh!)
The last option is probably the least accessible, but of course is the Ultimate Answer (a programmer may misunderstood the overloading rule, IDE may be buggy, but bytecodes always(?) tell the truth on what's being done).
The questions
Why is the stack trace so uninformative in this case with regards to the signatures of the methods that are actually in the stack trace?
Is this due to the compiler? The runtime? Something else?
In what other (rare?) scenarios can the stack trace fail to capture essential information like these?

Note that if you are using Ant build and if the debug attribute set to false in javac command this could happen.
ex : if you need proper location in trace set debug = true in Ant build,
<javac verbose="false" srcdir="${src}" destdir="${classdir}" debug="true" includes="**/*.java">
<classpath refid="compile.classpath" />
</javac>

This is normally related to missing debug information. You are probably using JRE (not JDK), which does not include debug information for rt.jar classes. Try using full JDK, you'll get proper locations in the stack trace:
Exception in thread "main" java.lang.NullPointerException
at java.lang.String.<init>(String.java:177)
at java.lang.String.valueOf(String.java:2840)
at StringValueOfNull.main(StringValueOfNull.java:3)

I had the same problem, I'm using spring and apache ant for continuous integration.
The error I had was in the build.xml file.
The gender change log with more precise content was:
build.xml with the error:
<javac srcdir="${src.home}" destdir="${work.home}/WEB-INF/classes">
<classpath refid="compile.classpath" />
</javac>
build.xml without error:
<javac srcdir="${src.home}" destdir="${work.home}/WEB-INF/classes" debug="true">
<classpath refid="compile.classpath" />
</javac>
Within the structure I lacked the courage debug = "true"

I ran the code in Eclipse and I got the following output,
public class Aloof {
public static void main(String[] args) {
String.valueOf(null);
}
}
Exception in thread "main" java.lang.NullPointerException
at java.lang.String.<init>(String.java:177)
at java.lang.String.valueOf(String.java:2840)
at mysql.Aloof.main(Aloof.java:19)
If you include the full source (from JDK), you can actually debug to the line 177 in String.java

This happens when there is no debug (line) information in the source or the VM is told to throw that information away at class loading time. Since you have some line numbers, it's not the VM setting but the class String is missing debug information.

In Eclipse: Preferences > Java > Installed JREs. The checked entry should have a path inside the JDK, e.g. C:\Program Files (x86)\Java\jdk1.7.0_55\jre.