Contrafactual Java Package Name

I know of at least two limitations to package names. One, I've stumbled upon a few times until I learned to avoid it 'by heart': Java keywords.

Just found out about another one: can't start with a (decimal :) numeral. Which is a bummer. For instance, stuff having to do with 3-dimensional maths and graphics would be most easily recognized under the name '3d'.

Workarounds.... for '3d', let's see: Ugly "_3d"? Cryptic "ddd"? Associative "xyz"? Silly "three_d"?

With the keywords, you can at least have a name that starts with the word you'd rather have, helping with matching and alphabetical ordering and such things.

---

I wonder why he/they didn't go for a separate package syntax. I mean, the '.' can never be used as the other form of qualification operator anyway. Maybe there was plans for namespaces-as-objects or something.

(Interesting digression...it could actually be implemented (except being able to use regular dot syntax, of course); take (ClassLoader, InitialPackage) --> PackageNamespaceObject or something.)

Slash syntax would've worked. Contrafactual Java:

package com/mylib/somepackage;

import com/mylib/somepackage/misc/*;

import com/mylib/someotherpackage/thispackage/ThisClass;

import com/mylib/someotherpackage/3d-math/SomeModule;

public class Contrafactual3dDemo { //...

}

(And why not lose those package and import semicolons...)

Eclipse Is Back

That's a new one, served fresh in a modal popup close to my face: 

An internal error occurred during: "Launching TestTemplate".
java.lang.NullPointerException

Restart, clean, refresh, nothing helped so far. Is it something in the code itself? Weird. Only other symptoms: 'misplaced' breakpoint (due to quick edit somehow) can't be removed, and no new breakpoints can be added anywhere.

Getting new issues from Eclipse is getting old.

---

(Expletive deleted), this is annoying. Deleted various project files. Open/Closed project, committed all uncommitted, tried the trick "Disable-Enable Dependencies" described in earlier posts, et-f5g-cetera. No go.

---

Found a clue: after deleting the contents of target/, the classes/ and test-classes/ folders are recreated, but they don't get populated. Is it my deletion of the .settings project files, or is it the original problem?

...no, the .settings/ files are actually back (org.eclipse.jdt.core.prefs, org.maven.ide.eclipse.prefs).

---

Two more clues: the process roster has a large number of zombie-like processes in it. When they are terminated, they take a long time, then both die, and a dialog "Termination Failed" is shown.

And shifting to 'Run' instead of 'Debug As..' I get this:

Exception in thread "main" java.lang.NoClassDefFoundError: org/pub/TemplateTest
Caused by: java.lang.ClassNotFoundException: org.pub.TemplateTest
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

Yeah, if the build isn't working, that's not totally weird.

It's interesting that this causes the debugger to not be able to connect to the child process! Is it that it fails so fast, that there's no time? Or does it depend on a working classpath? Would be interesting to know...

---

Solution: rename the project. Don't ask me why it works. My guess is that some cache or setting is associated with the project name.

Repugnant shit...

Java Misfeatures Collection

The Misfeature Collection blogging pattern again, applied to Java, the language.  Things big and small.

1) There should be a 'Integer' super-type for all the integer types (Byte, Short, Integer, Long). The name's taken, unfortunately. That's another misfeature, but understandable, 'int' was inherited from C/C++, I suppose. They could've named Integer as Int; and had Integer as the super-type name.

1a) Same thing for floating-points, of course. 'float' is traditional. But float could've been 'Single', IIRC there are languages that use 'single' as the name of single-precision FP numbers.

2) Annotations should fit in better with interfaces. Lots of good reasons for this; and only the 'tools' excuse on the other side, right?

// THIS TOO, SHALL AMASS //

Yesterday Eclipse, Today Eclipse; Extra Character

Just had a weird error, where it looked like Eclipse thought that a Java file was at the source root level, aka default package, and Quick Fix wanted to remove the package declaration. "Oh god, not another one" would be a nice description of the sentiment.

Thought it was another Svn problem, so I opened the Properties dialog, to find out what could be found out. Today is a much better day than yesterday, so it had nothing to do with Svn. The end of the path looked like this:

api/pub/annot%C2%A8/ApiPath.java

So then I looked in the GUI, and sure enough, there is some trema-looking extra character there that I didn't see, that I must've added inadvertently.

But I don't know why it made Eclipse think wrong about the packages.

This might mean that package names aren't allowed to be any unicode? If so, that's an unfortunate irregularity: other Java identifiers can be in unicode. But it's probably just that diacriticals are not allowed as characters in their own, which is very sensible. The Character.isJavaIdentifierPart method tells which characters are allowed, which is what I learned from this incident.

--

Today's UTF-8 character is: http://en.wikipedia.org/wiki/Diaeresis_(diacritic).

And as you can see at  http://www.fileformat.info/info/unicode/char/a8/index.htm, this character cannot be part of a Java identifier; the Character.isJavaIdentifierPart is false.

Juno II, The Brightening Up

Back in Eclipse Juno, incidentally, had to use a new Eclipse due to a mysterious error with a cryptography module not getting found. Stopped using it a couple months ago because it seemed to have small bugs. Possibly one of them was that Subclipse seemed badly integrated. The small file status symbols didn't show; or sometimes all files appeared with the question mark symbol making me think it didn't work.

But today it is looking fine, after both things happening at first; no symbols, then question marks. Then after a restart and a "Could not write metadata for '/RemoteSystemsTempFiles' modal dialog, and a while, and now they are showing. It might be the synchronization command I invoked was needed to finally get them showing.

So if you're seeing the same thing, just be a bit patient, do a 'Synchronize', and your day may brighten up some.


---

Oh, no, not bright. Installed the 'm2e' Maven Plugin (I think). Going from not finding "javax.persistence", to:

 The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files

And 'java.lang.Object' would probably be the most resolvable class in Java. 

---

Had to explicitly convert the project to a maven project. Odd, because: 

1) the .project had a couple of maven-related settings; maven2Nature and whatnot. 

2) ISTR that .pom files are auto-detected? I probably remember wrong. 

Better. 

...except: 

maven-dependency-plugin (goals "copy-dependencies", "unpack") is not supported by m2e
Plugin execution not covered by lifecycle configuration: org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (execution: default, phase: initialize)
Plugin execution not covered by lifecycle configuration: org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (execution: create_db_and_user, phase: initialize)
Plugin execution not covered by lifecycle configuration:
 org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (execution:
 create_test_db_and_user, phase: initialize)

Great. Well,  I believe we had at least the copy-dependencies those to support an old ant project setup, copying maven lib dependencies into some folder for ant to deal with, so that might be ok.

...maybe I should have installed m2eclipse instead? I thought they were practically the same thing. But 

here is an article that begs to differ: http://java.dzone.com/articles/migrating-m2eclipse-m2e. 

(Original: http://blog.frankel.ch/migrating-from-m2eclipse-to-m2e.)

Ok, so how do I uninstall m2e and change to m2eclipse? The menus give no clue. 

...ah got it: select "Install Software..." menu item; the install dialog contains a "already installed" link. It has "Uninstall..." buttons. Of course, why didn't I think of that first? 

Selected the two items that seemed to have to do with m2e. (Restart, problems saving state modal dialog...)

---

Ok, Eclipse Marketplace, what have you got for me? m2eclipse-wtp seems to be the closest match for m2eclipse. ...ouch, "unsigned content". 

Let's try the other one, "Install New Software...". m2eclipse-wtp -- what the, it contains only m2e? Maybe I can't get an older m2eclipse with Juno? 

-- 

The blog I found above has a nice article here: 

http://blog.frankel.ch/better-maven-integration-leads-to-unforeseen-consequences-bugs

which seems kind of relevant; for instance this passage: 

However, the problem is much more widespread than m2eclipse. It’s very similar to issues adressed in Andrew Spencer’s post, only more so since if we don’t upgrade, we may have to keep an Eclipse instance for each project, that has to be shared between all team members. Right now, I don’t have any solutions for this problem, apart from changing the code to keep in synch with the tool.

---

Tried the "Discover new m2e connectors" link in quick tip. I don't know what those are, because nothing showed up. 

Proposing a Improvement to the Override Annotation

The Java "@Override" annotation should have a "Class[] value() default {};" allowing you to be more specific about where the overridden method is inherited. The "default {}" is to be backwards compatible; and also to not force you to do it; and for non-branching inheritance paths, where it is not needed. (Or could it be useful even then? Discuss.) Note that multiple 'sub/super-type paths' could be involved, even where there may be only one 'original' method type declaration. 

Small thing, but nice-to-have. In Eclipse, you can already navigate to it using Cmd-T (or corresponding). But it just might be nice for readability, and refactorings could probably use it in some cases. 

Anyway, it would be more expressive. And aesthetics matter.

This will of course happen really soon, just because I suggested it, but never soon enough; so how about using this simple annotation while we hold our respective breaths:

@interface Overriding {

   Class[] value() default {};

}

Maybe @Overrides is better. It's one letter shorter. 

We could also implement some library code to walk the classpath and perform actual checking using reflection. It's not trivial, so I'll leave it as an exercise for the reader.