Problem with 1.0.11, specifically commit a95546

#1

Have been away from the Axoloti for a while, but now getting back. I've updated my git tree to 1.0.11, and building from source via platform_linux/build.sh on Debian Jessie, and I'm having a weird problem which seems to be related to commit a955462936ace48f37cc5fe5302ecfbd180fccc2 .

When I start the Axoloti UI, I get the following java exception:

java.lang.NullPointerException
at axoloti.MainFrame$2.run(MainFrame.java:276)

(and a whole bunch of traceback printouts).

The line in question contains the following statement:

String cb = ulib.getCurrentBranch();

and ulib being an AxolotiLibrary, getCurrentBranch() in AxolotiLibrary.java looks like this:

public String getCurrentBranch() {
    return getBranch();
}

Now, I'm not at all fluent in Java, but it looks like getCurrentBranch() and getBranch() would return the same thing, but in MainFrame.java, the two are compared for equality and then acted on - perhaps this is intended as a future feature, as currently both methods seem to return the same value.

However, the weird thing is that getCurrentBranch() never seems to run at all when called. The resulting String is assigned to null, and adding a printout to getCurrentBranch() shows that the method is never run. I can't understand how this can be, perhaps it's a Java feature somehow? I could imagine some form of overloading, but the only overloading I can find is in the AxoGitLibrary class, but it's not that type of object.

I can't see anyone else having reported this, so I'm thinking it's something in my setup, but I can't really fathom what at this point.

Does Java cache any internal references away between compilations, other than in build/classes?

UPDATE: I checked out a fresh tree, built it and it runs fine, so it must be something that's left over from the previous build. I wish I knew what though, it is impractical not just to be able to do a git pull to update an existing tree.

#2

you should do an 'ant clean' ... its possible for some reason that ant/java has not detected a class that needs to be recompiled. (basically the same as a make clean for C)

#3

Thanks @thetechnobear! I didn't know about that. However, I tried it now, and the problem persists. (I've also tried 'rm -r build dist' to clear out what I believed were all the generated files from the Java compilation, with no improvement. As with 'ant clear' it does say 'Compiling 403 source files' during the subsequent build, which indicates it's actually rebuilding everything).

The weird thing is that if I add a method called getMyBranch() which does the same thing as getCurrentBranch(), and use that method instead, it works fine. Of course, getMyBranch() is not overridden in AxoGitLibrary, but that should no be an issue as the object in question is not of that type anyway.

UPDATE: Actually, I'm probably wrong about the type. Adding a printout to AxoGitLibrary:getCurrentBranch() shows that it is in fact the library in fact is of this class, so I need to take another hard look at the code. I'm wondering if something has gone wrong when updating axoloti-factory and axoloti-contrib.

#4

Are there no errors in the console?

User library would be in an instance of AxoGitLibrary...
looking at that code, the only thing that looks possible is the git call is returning null, but that should not be the case , as far as i have seen....

also, how did you get the 1.0.11 code, did you do ?

 git checkout 1.0.11

my suspicion is this is not a code problem, more a setup problem, linked to not finding the user library branch... either to do with tag and so app versioning, or the tag on the user library

can you try doing...

 git fetch --tags

also, if you are planning on using this as a 'user' then you either need to set the revision for the user library or you need my lastest fix, to ensure you use the 1.0.11 branch of the user library,
i.e. you need to checkout master (for now)

this all stems from this post
basically, we its about getting the 'build tree' into a state where users can use without thinking about which revisions they need to use for the factory and user library.
sorry for the confusion, if this is the issue.

#5

I think there were a number of issues here, all to do with my local tree. First of all, my axoloti-contrib was apparently empty after doing a git pull, but that is because there apparently is no master branch in this repository, which there was at the time of 1.0.9, so that was what my local axoloti-contrib clone was set to. Manually checking out 1.0.11 brought the library back, but I was thrown off guard by the popup 'User Library version mismatch, do you want to upgrade' when the UI starts. When I click 'Yes' I get a Java traceback in the console starting with:

org.eclipse.jgit.api.errors.RefNotFoundException: Ref origin/master can not be resolved

but clicking 'No' allows it to continue without errors.

So it appears my original error was caused by the fact that the axoloti-contrib clone was set to master, when there is in fact no master branch any more, which in turn causes cb to become null around line 275 in MainFrame.java, which in turn causes a null pointer exception when cb.equalsIgnoreCase(ulib.getBranch()) is invoked on the line after. So I suppose there should at least be a test for cb == null somewhere, potentially throwing up a popup that the contrib repository is missing, or at least acting as if the user doesn't have or want one. Throwing an exception because a repository is missing seems a bit too severe; even though the program itself doesn't crash, it does cause the factory library not to be loaded either as that code is after the user library load.

BTW, another thing I've noticed is that the axoloti-contrib and axoloti-factory repositories no longer seem to be set up as submodules, at least that's what the top-level .git/config says.

UPDATE: And that is the other part of the problem, when going into for instance axoloti-contrib and doing 'git branch', the current branch name is returned, however the Git class used in the UI seems to return null in this case (there seems to be code to handle this in AxoGitLibrary:getGit(), but it is dependent on usingSubmodule() which is always false currently). Since the axoloti-contrib and axoloti-factory repositories in my tree are submodules, they don't have their own .git directory, and instead refer to the parent directory. I solved this by simply erasing the directories and cloning the upstream repositories, which finally got my 1.0.11 UI to run smoothly when starting up.

So the net result is that when upgrading an Axoloti repository from one where axoloti-contrib and axoloti-factory were submodules, these directories need to be properly cloned from the upstream repositories.

I'm sorry to admit I haven't followed the latest developments on how the libraries are maintained, which might have caused me to look in that area sooner. Hopefully this thread will help someone else who is in the same predicament and can't figure out what's gone wrong...

#6

ah, if you had told me about the console error, I would have known immediately what the issue was :wink:
(it would be very useful , if users always posted full console dumps, regardless if they think its important)

I do make posts in the dev section which I have to assume people who are building axoloti are reading... there is no other way to communicate such information.
Its important that people read these... (its why I go to the effort of writing them)

I do think we need to review this 'developer mode', as clearly there are many builders (mainly linux users) that are not using this for development purposes, but merely to have a running system (as a 'user'), and in this case we want axoloti running like the 'released build'.
(this was partly the reason for the recent library changes)

I'll review the code to see if there are some changes I can make to make it handle these situations gracefully.

#7

Well, I did actually post the initial error I got:

java.lang.NullPointerException
at axoloti.MainFrame$2.run(MainFrame.java:276)

but of course you're absolutely right regarding reading the available forums and documentation. And also, point taken about posting full dumps. (It's just that Java is very verbose with a full stack trace for each exception, so it tends to result in a lot of text, most of which is not terribly interesting which is why I'm hesitant to post it all).

In the end, I will actually be using the checked-out tree for development, but since I've been away from it for a while, I wanted to start getting the vanilla upstream version working properly, before applying my own patches.

Also, given that it is, at least from my perspective, very easy to build the complete Axoloti system from scratch, there will as you say be a lot of people who just want to build it in order to get the latest version.

#8

its not the stack trace I'm after, its the console showing things leading up to the event.
most bugs (like this one) are due to 'unusual/unexpected/un-handled' things happening before it goes bang, the 'bang' at the end is often a consequence not the cause.
(its way too easy for java developers to fix these 'null pointers' with a check, whilst not solving the underlying cause... this has driven me crazy on some of my dev teams, as it can introduce really subtle bugs! )

yeah, this is not necessarily/always a good thing...
its ok where they are developers so understand that dev branches are. rather someone who might tthink its a way to 'the latest and greatest', dev branches are not early access programs :wink:

there are often good reasons for things not having been releases yet... e.g. migration/upgrade paths have not been developed, so you may trash your setup/patches/objects.
... also as I pointed out on other threads, its easy for users to release objects/patches into a library, that are not compatible with the released version - and that will cause confusion, and likely require my manual intervention in the relevant libraries.(i.e. extra support load)

on the flip side, I think we need to organise ourselves a bit better, so that those wanting to use the repo, can have clear idea of what to use. (e.g. using release tags, and feature branches)

anyway, its not been a big problem (= high support load) as of now, only really affecting linux users, so hopefully the improvements we've been making will resolve the issues before they become a problem

in line with my comments above, at the moment use master (due to my 'fix' after the 1.0.11 release) but generally for this purpose you should be using the released version/tag for this purpose... not the dev/master branch.