Etichettato: java

Interfaces in Java could be useful, but they suck instead

I usually dislike interfaces in favor of abstract classes, because I often have common code to share between many classes. The abstraction level of interfaces is kind of “I don’t REALLY know what will fit in here”, and this is almost never the case in what I do.

Obviously interfaces ARE useful sometimes and DO have their uses, I know, but I often try to use them (for instance, for java generics) and then backoff using something else because they don’t do what I would expect.

As an example, today I thought of interfaces as a way to limit the access to a particolar method to classes that have no common ancestor (no multiple inheritance in Java) and are in different packages (no default access). How hard could it be? You just define an interface with a protected method

interface AccessControlInterface {
    protected void protectedMethod();

and then implement the interface and the method in any class you want, making it possible to call A.protectedMetod() from class B only if B implements AccessControlInterface. Dead simple, right?

Wrong. As it turns out, in Java the only valid modificators for methods in interfaces are public and abstract. Yeah, abstract, the most useful keyword to use in something that can’t be anything else than abstract.

Is it just me, or there should be a giant WHY in the sky right now?


Java 8 will have nicer-looking closures. Due late 2013. Probably

Java Tutorials: ‘At First Sight’ With Closures in Java.

Hope you didn’t hold your breath for the release of Java 8. They’re surely doing e hell of a good job, taking inspiration from other languages that already run in the jvm which are several steps ahead, but the wait will kill all of us.

For closures in current Java editions, this is a nice pointer:

Useful Eclipse plugins for java developers

JD-Eclipse | Java Decompiler –
Very simple to use. CTRL+Click on or debug a class you don’t have the source of, and you can see it. Depending on how it has been compiled you can see it seamlessly as it was the real source (this is the case for JDK classes), or in debug you could have some issue tracking down the exact line it’s executing (the debugger chooses a line but you have to look for comments indicating original lines). The stand-alone Java Decompiler JD-GUI is very good too.
UCDetector: Unnecessary Code Detector –
Imagine you have a big project with thousands of classes and methods, and you suspect that the majority of those is not really necessary: this plugin is for you. It can check for hard-coded references in your .java sources and the presence of full-path or simple name matching of classes in text files (you can specify regular expressions for files to check, but I’ve managed to only use file extensions, I’m not really sure of what kind of regular expressions it’s using), for example servlet mappings in web.xml. You can decide to be notified of a zero or a low number of references to whole classes or single methods. If you delete unnecessary classes and method you can then re-check to see if something new pops out. The process can be a bit slow, but that’s because it’s thorough.
Classpath Checker –
This is an old plugin that I used some time ago (I don’t know if it’s still working). It warns you of unresolved dependencies in the classpath, which is useful if the unresolved dependencies are in some jar in your project. You can get a ton of false positives, as many jars can have unresolved dependencies for parts you don’t use (and so you haven’t provided the dependencies of), but if you know where to look it may be of great help.
MercurialEclipse –
A plugin for using Mercurial as (D)VCS. It’s in active development, and it has much increased it’s usability in the last year. It’s almost perfect for everyday use (commit, pull, push, merge, switch to, add branch, show history, compare), even though for particular uses or external mercurial plugins you could often need the good old command line or TortoiseHG. Switching between very different branches or revisions can be very slow (TortoiseHG is probably much faster).

Eclipse and his quite zombie/nazi JavaScript Validator

Since when I’ve begun to code in Java (in 2005) I’ve tried many IDEs, but the best is still probably Eclipse. Sadly enough, it’s the best but not that good in every aspect. Sometimes you spend whole days trying to just make something work: while you’re doing everything right, he’s trolling you not really doing something at some point; so the hard part is finding out what it is and then doing it manually.

The issues and solutions I’m going to list apply to Indigo SR1, but probably to many other versions (from the beginning until the end of times, as we are used to with Eclipse). Solutions are mainly from other people, go see the linked threads and posts for credits. I just wanted to have them all in the same place.

Issues with Eclipse, chapter 1: JavaScript Validator

1) Sometimes a NullPointerException pops up (constantly, at every build) saying “Errors running builder ‘JavaScript Validator’ on project ‘${project}’. java.lang.NullPointerException”.

The solution, as you can read here and in many other places, is to open project properties (this is a project-only option) and disable (or remove altogether if it’s not enough) Builders -> JavaScript Validator.

2) Errors on JavaScript files sometimes are reported (as the usual little red icon) on the project tree, even though you have solved them in the source files and even after a full rebuild or a manual “Validate”; sometimes Eclipse continues to report them at the very same line of the opened file, even though the error is not there anymore.

The causes can be many (one of them is “have you messed with it too much?”), and getting rid of this may be done the taliban or the diplomatic way. The diplomatic way to clear the report of a non-existent JavaScript error is to find it in the “Problems” tab and deleting it. If it works, good for you. The taliban way is to blow up the folder


as suggested here. In this way you’re clearing a cache for project metadata (has it errors? are all changes committed to the repository? and so on), and in order to regenerate it you have to close and reopen the project.

3) Sometimes you just want to ignore JavaScript errors because you don’t care.

You can try to disable them for a single project (but don’t assume it will work): Properties -> Validation, check Enable project specific settings, disable Client-side JavaScript Validator, for Manual (when you right-click on the file and choose “Validate”, should be harmless if you don’t use it) and/or Build (validation on *every* build).

Or you can disable them for the entire workspace: Preferences -> Validation, disable Allow projects to override these preference settings (hope it works), disable Client-side JavaScript Validator in the same way as above.

Be aware that even if you disabled the validator you can still have caching issues as described in 2).

Is the Validator still running? You may have to open your .project file and remove the <buildCommand> XML block containing <name>org.eclipse.wst.jsdt.core.javascriptValidator</name>, and <nature>org.eclipse.wst.jsdt.core.jsNature</nature>, as described here (yes, it’s an old issue). Close and reopen your project.

Still issues? Maybe the solution proposed in this comment (same thread on stackoverflow) will work for you: Preferences -> JavaScript -> Editor, disable “Report problems as you type”.

4) In a Dynamic Web Project with many files (hundreds, both .java and .js), the time required to open for the first time (since Eclipse startup) the project tree is about 1 minute.

Having disabled JavaScript Validation (in some or all of the many horrible ways listed above), it takes about 1 second, so I guess it’s related.