-
Here's an example violation. These code snippets are executed in order:
(Some code in Servlet before response is committed)
response.setLocale(Locale.DE);
(Joda in JSP)
response.setLocale(Locale.EN);
(Some other JSP taglib or code called by the JSP)
Locale locale = response.getLocale();
// Locale is now English
As you can see, the locale going back to the client is going to be...
2008-08-20 15:00:54 UTC in Joda - Time
-
In the JSP taglibs, the format tags are making calls to the Util class to manage the Locale's and conform to the JSTL specification. However, they are also setting the response Locale using the setLocale method on the ServletResponse interface.
This violates the servlet specification because by the time these tags are being execute the output stream and writer have already been used and...
2008-07-10 20:10:53 UTC in Joda - Time
-
I figured this out. It looks like the SimpleCompletor has two bugs in it. I fixed these locally and it works great. The first issue is that if multiple matches exist, but the prefix of all of them up to the delimiter is the same, the candidates still contains multiple values, each of them are identical. This causes the CompletionHandler to print out candidates, even though there really is only...
2007-10-01 21:03:33 UTC in JLine - Java console input library
-
It looks like this only happens when there is a single class within a JAR file. Still not sure if it is the ClassNameCompletor or the ConsoleReader. My initial guess is the ClassNameCompletor.
2007-10-01 17:01:52 UTC in JLine - Java console input library
-
I'm using Ubuntu linux and JLine 0.9.91 with the Class name tab completer and when trying to tab complete a class within the JDK everything works fine. However, when attempting to tab complete a class within the JAR file that my test class is running from, each time I hit the tab key I get an extra space after the package name.
it looks like this:
Enter bean: com.texturemedia.
I...
2007-10-01 16:55:09 UTC in JLine - Java console input library
-
Logged In: YES
user_id=1541332
Tried -client and still has the same problem. It might be
worse actually. One of the most horrific issues is that when
JEdit gets focus it completely pins the CPU for an instant,
locking up even Linux momentarily. Real pain.
2006-09-22 19:42:40 UTC in jEdit
-
Logged In: YES
user_id=1541332
No, I'm using this command line:
/opt/programs/jdk1.6.0/jre/bin/java -server -mx128m
-classpath /opt/programs/jedit/4.3pre6/jedit.jar
org.gjt.sp.jedit.jEdit
which is what JEdit ships with. Perhaps the server VM flag
is making JDK 1.6 mad. I'll try a few other tweaks and see
if I can get some more responsiveness. Oh and I'm using Linux.
2006-09-22 16:37:44 UTC in jEdit
-
Logged In: YES
user_id=1541332
Looks like that is working. I haven't seen the issue again.
If it comes back I'll update this bug.
2006-09-22 16:14:32 UTC in jEdit
-
Another things I've noticed is that JEdit 4.3pre6
running under JDK 1.6 beta2 is very slow. I'm not sure
what is causing the slow down, but all other
applications I've run on JDK 1.6 beta2 have shown a
very good performace increase, except JEdit.
2006-09-13 15:34:39 UTC in jEdit
-
Logged In: YES
user_id=1541332
Oops. Forgot, I'm running JDK 1.6 beta 2 so that I have GTK+
integration (JEdit always looks a bit rough in the GUI
unless you use the platform native PLAF).
2006-09-13 15:33:27 UTC in jEdit
