Surrender your ego
Microsoft has a term "knowledge base article" which solves a particular problem or at least describes it better.
It comes out, there's a term http://en.wikipedia.org/wiki/Knowledge_base
Today was the second time I use the blog as a knowledge base. I know I have stumbled upon a problem, I think I wrote about it, I search the blog - there it is, and it solves my problem again.
Great, another usage of the seemingly useless blog.
There's an Apache Tomcat I'm managing that's in the wild (internet).
Saturday evening it was under attack.
I use Tomcat's manager console to drop applications from time to time and I had it's password pretty simple. Within this console a new java web application may be installed.
What's even worse is that that Tomcat instance was running with pretty high privileges.
It was a test machine, only a few guys knew the address.
So using this console a trojan was inserted. The admin password was changed. This trojan might have succeeded if it weren't for the antivirus that got the trojan on time (yes, it was a windows machine).
The trojan is called TROJ_DELF.BDG and it was deployed in webapps/fexshell/init.exe
Now the tomcat is running with pretty low privileges, the port is not so obvious, and the manager password is changed.
Did you know that classes in the 'default package' (classes that don't have a package) cannot be imported from classes that do have a package?
I did not know that.
Try it:
This is what javac says:
>javac package2\Clazz2.java -cp .
package2\Clazz2.java:3: '.' expected
import Class1;
^
package2\Clazz2.java:3: ';' expected
import Class1;
^
2 errors
How stupid is this?
Is this why omitting package is deprecated?
The last couple of posts look terribly in Internet Explorer 6. There are some background rectangles that should not be there:
IE7 displays them correctly.
Update: Maybe it's because I used Word 2007 to write the html for the colored code from Eclipse.
I had an issue compiling some java classes. Javac failed, Eclipse's compiler worked. The issue is described here.
I was blaming Eclipse, I was blaming java6's endorsing. I was thinking it was due to JAXB.
It comes out they all were innocent.
Here's my code:
package f;
import static f.ProblematicClass.E1.E2.VALUE;
import javax.annotation.Resource;
public class ProblematicClass {
@Resource
public static enum E1 {
F(VALUE);
private E1( E2
requiredBankAccounts ) {
}
public static enum E2 {
VALUE;
}
}
}
The result with javac is:
f\ProblematicClass.java:9: cannot find symbol
symbol : class Resource
location: class f.CorrectClass1
@Resource
^
1 error
After some research I think I simplified the problem:
(If I continue to simplify it would still fail to compile but at some
point it would start to compile which yesterday drove me crazy.
This is the most simplistic case that consistently fails to compile)
package f;
import static f.ProblematicClass.E1.VALUE;
import
javax.annotation.Resource;
public class ProblematicClass {
@Resource
public static enum E1 {
VALUE;
}
}
All of these changes fix the compilation error (from javac):
// Reverse the order of imports
import
javax.annotation.Resource;
import static f.ProblematicClass.E1.VALUE;
...
or
@javax.annotation.Resource
public static enum E1 {
VALUE;
}
...
This all makes me think that the static import fails the next one only if the next one is an annotation (I've tried with a java.util.Collection - it compiled).
I have tried this with jdk6u3 and jdk6u10.
I don't have jdk 1.5. Can someone test it on jdk 1.5?
Update: GRRRRRRRRRRRRRR, Somebody found it before me:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6391197
It was reported on 27th of June, 2006 :'(
Here's what they say:
Workarounds:
1) switching the order of the import statements works (although they often get changed back by our development tools).
2) Commenting out the static import statements, then compiling, then putting the import statements back and
compiling again with the old classes still there also works. This means that the compiler errors happen at the strangest
of times, and in large programs it can be very difficult to work out how to workaround the problems.
I have some code.
I have two classes. They both have inner enums.
The two inner enums have an annotation.
But one of them does not compile. The other one compiles just fine.
In eclipse there's no error, but when I build the code from ant I get a compilation error - the annotation class is not found:
I spent some time looking for it - I thought that the classpath is wrong, I endorsed an updated version of the API (java 6). The issue persisted.
Then I decided to use javac directly:
Strangely enough I got the same error?! Then I did the same for the class that did compile successfully using ant - it worked.
So there was a difference between the two classes and I had to find it.
And I found it, can you find it?
-->
-->
//Does not compile
public class ProblematicClass
{
@XmlType( name = "fff1" )
public static enum InnerType {}
}
// Compiles
public class CompilableClass
{
@XmlType( name = "fff2" )
public enum InnerType {}
}
Yes, you're correct. The second enum is not static.
This only happens with inner static enums. The anomaly does not occur if it's an inner static class. I don't know why.
So I'm thinking that in the ProblematicClass the annotation is not visible because the import of XmlType is not visible.
I was correct - this one works:
-->
-->
-->
//Does not compile
public class ProblematicClass
{
@javax.xml.bind.annotation.XmlType( name = "fff1" )
public static enum InnerType {}
}
I just supplied the FQN of @XmlType.
So eclipse is working, javac is not. Now is the time to say that Eclipse is not using javac. I thought it was using jikes (made by IBM), but that's not correct. Eclipse is using its own incremental compiler part of JDT Core. JDT stands for Eclipse Java Development Tools.
http://www.eclipse.org/jdt/core/:
JDT Core is the Java infrastructure of the Java
IDE. It includes:
builder, it is based on technology evolved from VisualAge for Java compiler.
In particular, it allows to run and debug code which still contains unresolved
errors.
So either javac or Eclipse's compiler is wrong. I would bet that javac is following the spec more strictly.
This is the second time I'm catching Eclipse's compiler of misconduct. The first time was something related to a very complex case with generics - one of the compilers said it was a warning, the other - error.
Update: I was wrong. I was trying to report the problem. I was making a pretty simple case. I used a different annotation: @javax.annotation.Resource. It worked both on Eclipse and on javac.
So the problem is somehow linked with JAXB.
JAXB is an API bundled with Java 6 (an 'endorsed standard' a 'standalone technology'). The version bundled was JAXB 2.0. If one wants to use a newer version, say JAXB 2.1, an 'Endorsed Standards Override Mechanism' had to be used.
Info on JAXB here.
Info on endorsed mechanism here.
I'm currently with JDK 6 update 10. Somewhere I saw that 'endorsed standard override mechanism' was no longer necessary.
It looks like the problem is more on javac side than on Eclipse's compiler.
I will investigate further.
Update2: It comes out that 'Endorsed Standards Override Mechanism' was existing prior to java 6. Only the standalone technologies were added in Java 6.
Update3: It comes out that 'Endorsed Standards Override Mechanism' is still used.
Update4: It comes out that this bug is very hard to reproduce. My simple examples at some point just started compiling 🙁
Update5: I just created some code that consistently reproduces the bug. I'll write it in a new entry to be cleaner.
Update6: I fixed coloring and finished the new article on the bug.
I'm using JAX-WS.
When I'm generating stuff for a web service I generate the jaxws package in a 'gen' source folder.
I don't need the compiled stuff so I generate it to a temp folder that I don't care about.
It comes out that I do have to care about that folder because yesterday I got an obscure error:
This error has only 1 (one) hit on Google. Don't trust me?
Try this one out:
http://www.google.com/search?q=%22com.sun.xml.ws.model.RuntimeModelerException%3A+The+serviceName+cannot+be+retrieved+from+an+interface.%22
The use case in the forum has nothing to do with my environment so I cleaned up and everything worked like a charm.
I've always been unhappy with how production unready wsgen is (here).
WinMerge has great shortcuts for next/previous change, copy left/right.
It has textual comparison feature which works pretty well.
Recently I had to move 200GB from one hard-drive to another.
It was imperative to make sure everything was copied successfully.
Using a binary comparison tool would take a really long time. So I only check the total file size of all files copied and the number of files.
I tried copying these 200GB files several times and never succeeded. I was too lazy or busy to investigate until today when I got really pissed off.
It comes out that the difference comes from thumbs.db files.
Thumbs.db is a thumbnail cache used by Windows XP and Windows 2k3 Server.
How to stop the creation of these files:
Ctrl + Num = switch through tabs. Useful.
No comment!
No comment!
Those who would sacrifice liberty for security deserve neither.
Benjamin Franklin
In Bulgarian:
Този, който е готов да пожертва свободата заради сигурността, не заслужава нито едно от двете.
Бенджамин Франклин
I accentally went to http://www.gaijin.at/.
The weird part is that when one presses "English" (since it's in German) it goes to:
http://translate.google.com/translate?hl=de&langpair=de|en&u=http://www.gaijin.at/index.php
I didn't know that Google can translate whole web sites.
The translation seems to be pretty good.
The site look&feel is exactly the same.
Very good thing.