Release 1.3

[kevinbrandon]

Task list

• limit to one start
• update the documentation for JDB
• create a issue closing commit

The approach

Okay I deviated a bit from our discussion. Hopefully you're cool with the approach. If not I can change it...

So here goes. I went with the single startup. However, I converted the first argument to be a optional in the args dictionary. Here are my reasons:

• Dictionary approach is powerful in that it lends flexibility. Why not do that for the first argument? I understand for other debuggers like gdb you have supply the binary to get at debug symbols. In java you don't have too. Does it really have to have consistency across all start calls? I really like to avoid passing blank string or something falsey as the first argument.
• If the entryClass is defined in the dictionary, I have that take precedence.
• Having the only argument be the dictionary, requires erroring out or reasonable defaults. For JDB I feel that the reasonable defaults would be having con set to 9009 (the standard jvm debug port). It would be cool to maybe default the entryClass if your current buffer contains main.
• This affords a simple startup with the command VBGstartJDB
• VBGstartJDB was made to work with or without arguments.

If changset is adopted, what issues I'd create

1. It would be cool to have some feedback that you are attached or not. Going bufferless when attached makes sense, but you then lack any signal that you are attached or not.
2. Seems like the file being edited in the buffers and the package definition could be used to create the srcpath.
3. Create test scripts via http://linux.die.net/man/1/expect scripts

Let me know what you think!

[idanarye]

1. Removing the first argument is indeed a good idea, but it's a breaking change so if we do it it has to go in 2.0.0. No need for a new PR though - I'll just merge release-1.3 into develop and then delete release-1.3(to avoid confusing people). Following protocol is good, but no reason to be pedantic about it. After that, I'll also make the other debugger starters accept a single dictionary argument.

2. The command

   call l:debugger.writeLine('monitor where')

   should really be outside of the if condition, because we do need it in this mode. Without monitor where JDB won't print the location when it pauses and vebugger won't jump to it.

3. About VBGstartJDB:

   1. string(<q-args>) is never false, because even if <q-args> is an empty string, string(<q-args>) is not empty because it contains a string of the blank string literal "''", which is a non-empty string.
   2. Since only the first argument matters, it should be -nargs=+ and pass eval(<q-args>) instead of eval([<f-args][0]). That way, it can be used with spaces.
   3. (which renders the previous points meaningless) Don't make it a command if it can't be used like a command. If we ever implement your suggestion of deducing srcpath(and srcpath) from the currently open file(or maybe even search for other .java files in the project tree) we'll want this command to be usable like the other commands - VBGstartJDB EntryPointClass arg1 arg2 arg3 - and not with a dictionary. If the user is going to use dictionary args they might as well use the function version...

   I think a command for starting JDB should be put off until we can do this deduction. Once we can do it, we should have a separate VBGstartJDB for starting a new JVM for debugging, and VBGconnectJDB for connecting to an existing JVM(I don't want to call it VBGattachJDB vecause the GDB version, VBGattachGDB, does something different - it connects to a debugger-less process via PID. I should probably also add VBGconnectGDB to connect to a gdbserver, since we have that feature in the dictionary args, but that's a whole different story...)

4. Why is 9009 the default port? When I run it it seems to be 6000:

   $ java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=6000 Main
   Listening for transport dt_socket at address: 6000
   

5. Your decision process of whether to start a new JVM or attach to an existing one is confusing. In the GDB version, having pid or con is the trigger for attaching/connection, and I think it should be the same here. We can, though, check for mutual exclusion - but we'll do that later(I'll probably want to write some helpers for that, cause we'll probably need them in other debuggers as well).

[idanarye]

About your suggestions:

1. "It would be cool to have some feedback that you are attached or not. Going bufferless when attached makes sense, but you then lack any signal that you are attached or not."

   We can probably detect debugger errors and display them to the user, but we should be very careful with that, because the debugger starters don't really wait for the debugger to start before they return control to the user, and do to Vim's single-threaded nature throwing too many errors while the debugger is running can be really annoying...

   Many features I want to do in the future(watchers are a prime example) require a side-panel, so we might be able to display the errors there.

2. "Seems like the file being edited in the buffers and the package definition could be used to create the srcpath."

   That's a pretty good idea, though I'd rather have the debugger-starting independent of the currently edited file. Still - we might be able to find .class and .java files in the source tree and deduce stuff from there...

3. "Create test scripts via http://linux.die.net/man/1/expect scripts"

   Can expect be used to test Vimscript? If we want to add tests, there are test frameworks dedicated to Vimscript, like:

   • https://github.com/junegunn/vader.vim
   • https://github.com/LucHermitte/vim-UT
   • https://github.com/tomtom/spec_vim

[kevinbrandon]

Take Aways

• fix 'monitor where'
• remove VMGstartJDB
• remove default port.
• Migrate changes to a branch off of develop.
• Create pull request for that branch

1. Why is 9009 the default port? When I run it it seems to be 6000

I normally always define my port when I spin up a jvm. I did a lookup for the default and thought I was reading port 9009 as the default. Thats true for glassfish. Eclipse its 1044. Seems like it should not try to default and echo out an error that "Either the con or entryClass needs to be defined'. With that there probably should be some overall strategy for bailing out with error. I saw the kill commands... maybe those should fire if the debugger fails to start. Haven't looked to deeply into what's hooked in yet. I just read your other response about future error handling ideas. Sounds good.

2. Your decision process of whether to start a new JVM or attach to an existing one is confusing. In the GDB version, having pid or con is the trigger for attaching/connection, and I think it should be the same here.

   .(!has_key(a:args,'entryClass') ? ' -attach '.fnameescape(a:args.con) : ''

The thought here was that if we have an entry class defined then use that and spin up a JVM. Otherwise use the --attach convention with the con info. Two use cases are someone wants to start up a JVM and they have to tell the debugger what class to use that has the intended main to run. The other case is that you've already started off and you just have to attach.

3. Can expect be used to test Vimscript?

Expect definitely could be used, but I would favor the ones that you have suggested. Which one do you prefer? Like I said I am a complete noob to vimscript. Used vim for a long long time but first time venturing into writing vim script. I tossed out the idea to just start the convo about possibilities there.

[idanarye]

I never tried any of these testing frameworks - I just stumbled upon them on a quick search. I'll have to try them out before deciding...

[kevinbrandon]

Cool I could look too if you want. This is your baby so whatever you want I'll go with. I have several things on different burners right now but I'm committing myself to helping on this because I can't stand eclipse any more and I would love to use vim in this manner. Especially like it because my roots are in C and I really appreciate this works with gdb as well. GDB was decent though and I liked DDD. But staying native to vim is fantastic.

[idanarye]

This is hardly my baby - just another tool I maintain so I can use it(though I can't really use it for the main project at my current workplace, so I don't have too much motivation to work on it right now...). I always appreciate more people contributing to make a project like this better because the also want to use it - that's the open source way!

[wsdjeg]

@idanarye what is the status of jdb support? I want to use this in java project.