Categoria: english

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:

http://stackoverflow.com/questions/5443510/closure-in-java-7

“Full Frame Equivalence” and Why It Doesn’t Matter @ Admiring Light

Full Frame Equivalence *is* a useful tool to speak about and use different lens formats at the same time (thus reducing all of them to a common denominator), but you can’t make assumptions without understanding its meaning.

A relatively short and great article, seen on 4/3 Rumors, explains FFE very well:

“Full Frame Equivalence” and Why It Doesn’t Matter @ Admiring Light.

How Mat Honan’s digital life got hacked (badly)

From his thorough and shocking report:

Since he already had the e-mail, all he needed was my billing address and the last four digits of my credit card number to have Apple’s tech support issue him the keys to my account.

So how did he get this vital information? He began with the easy one. He got the billing address by doing a whois search on my personal web domain. If someone doesn’t have a domain, you can also look up his or her information on Spokeo, WhitePages, and PeopleSmart.

Getting a credit card number is tricker, but it also relies on taking advantage of a company’s back-end systems. Phobia says that a partner performed this part of the hack, but described the technique to us, which we were able to verify via our own tech support phone calls. It’s remarkably easy — so easy that Wired was able to duplicate the exploit twice in minutes.

First you call Amazon and tell them you are the account holder, and want to add a credit card number to the account. All you need is the name on the account, an associated e-mail address, and the billing address. Amazon then allows you to input a new credit card. (Wired used a bogus credit card number from a website that generates fake card numbers that conform with the industry’s published self-check algorithm.) Then you hang up.

Next you call back, and tell Amazon that you’ve lost access to your account. Upon providing a name, billing address, and the new credit card number you gave the company on the prior call, Amazon will allow you to add a new e-mail address to the account. From here, you go to the Amazon website, and send a password reset to the new e-mail account. This allows you to see all the credit cards on file for the account — not the complete numbers, just the last four digits. But, as we know, Apple only needs those last four digits. We asked Amazon to comment on its security policy, but didn’t have anything to share by press time.

And it’s also worth noting that one wouldn’t have to call Amazon to pull this off. Your pizza guy could do the same thing, for example. If you have an AppleID, every time you call Pizza Hut, you’ve giving the 16-year-old on the other end of the line all he needs to take over your entire digital life.

Useful Eclipse plugins for java developers

JD-Eclipse | Java Decompiler – http://java.decompiler.free.fr/?q=jdeclipse
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 – http://www.ucdetector.org/
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 – http://classpathchecker.free.fr/
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 – http://javaforge.com/project/HGE
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

${workspace}/.metadata/.plugins/org.eclipse.core.resources/.projects/${project}

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.