Assuming I have a decompiled source of lwpd.xsp.core library, is there any way to run it through Domino Designer Java debug session? I want to fully understand what happens behind the scenes, but IBM actually lacks any good documentation except apidoc that doesn't help too much. I think running the full request/response cycle from debugger would be the fastest and most effective way to clear things up, than browsing the code through IDE. On the other hand, I can put sout pritln-s where I need or insert some custom logging statements, but debugger is still preferred.
I guess maybe I have to remove lwpd.xsp.core.jar from Plug-in Dependencies of my XPages application and attach it as an external library instead, but I don't have a clue how to do it. If it is possible at all, I'll make a research on the topic.
You can decompile the code during runtime with the JD GUI Eclipse Plugin. Just download the update site and import it into DDE.
No Source code needed.
And please donate for the project (I am not the author of JD GUI or have any benefits from a donation).
By the way: the most interesting parts of the XPages engine are stored in the files
lwpd.xsp.core.jar
lwpd.xsp.extsn.jar
lwpd.xsp.domino.jar
lwpd.xsp.designer
I am a C++ dev, working in java technology for about a year. Forgive my ignorance, but I have tried to search for following two questions.
What is the best way to debug in console for a java application (ala gdb in good ol' C++).
It seems jdb is below par.
Eclipse is the way to go for its IDE. But Eclipse is a GUI and I do develop in console on unix servers.
What is the best way to tame huge jave open-source frameworks. eg, camel, hibernate, spring, logback, blah, blah
I do most of my debugging in the console.
I have found that for the majority of bugs, Java stack traces are sufficient to identify the bug and develop a fix. This of course means that it's critical to allow stack traces to be seen on the console. For most applications, I've found that it's best to allow unchecked exceptions to propagate until they terminate the thread, with a stack trace showing up in the console; unchecked exceptions should normally indicate programming errors or uncontrollable conditions where the thread should be terminated anyway.
In cases where the stack trace is not sufficient, I've found that using System.out.println() during the debugging process is actually more effective than using an interactive debugger. Having a full log of a run is for me more useful than running a debugger where I may easily step past an issue that later turns out to be important.
Wat is the problem in setting up the project in eclipse IDE, you can always get the source code and set up your workspace??
Using sysout is great for small java programs but as the code grows or for big application (according to my understanding you plan to debug something big :P) it would really be a headache placing all those sysout and then removing them once you are done with the debugging.
I would suggest you to set up your own workspace by choosing 'import existing project in workspace' option of IDE, though it would be tiring first but will help you in long run.
I would say that there is no need for such a tool, because Java supports remote debugging.
You need to start your (server) JVM with remote debugging enabled - this will work for newer JDKs:
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
After that you connect to it from the IDE, and set breakpoints or conditional breakpoints wherever you like.
See this question for more details
Also, this is a personal preference, but I would say that IntelliJ IDEA is the way to go as far as Java IDEs go.
I'm currently using Eclipse for a Java application I am creating. I find it very irritating when I'm trying to create the GUI and I have to keep launching the application to check every element is in the correct place. Is there any sort of live management system that would allow me to see the editing happening live as I change positions of components, etcetera? It sounds highly unlikely as I have never come across such a thing, but it sure does sound helpful.
Yes, I used it many years ago and dont remember the exactly name.
You should install a plugin called "Matisse for Eclipse" (but the code it generates to a simple GUI is awful)
Theres others too you should look for Visual Interface Builders.
I want to use emacs for java coding, but I'm confused on what mode to use for java coding. There's jdee, which seems ide-like; malabar, who is said to be more well versed in java 1.5 constructs than jdee; and emacs-eclim, which is an eclipse backend for emacs. There are also a wealth of completion extensions for emacs, and I'm also confused on which one to use. In fact, I'm so confused that I deferred using any of them until I get recommendations.
What is the current best option for java-mode + completion in emacs? And, if ever I decide to use a combination of what I mentioned above, will conflicts happen?
For those used to the power of Emacs text manipulation then Eclipse can seem like pedaling a bicycle with one foot. The Emacs+ plugin from http://www.mulgasoft.com/ is excellent for getting Emacs key bindings into Eclipse.
I use both Eclipse and Emacs a lot, but if I only did Java development I might use only Eclipse with Emacs+. It takes some work to get many Eclipse features enabled on Emacs.
My advice is to use Emacs >= 23. If you are on a Mac, look at AquaMacs. I use JDEE as the Java plugin. This has the serious drawback of not playing well with generics. It's not that it stops working, it's just that a lot of stuff isn't recognized. Do not use the old 2.3.5 JDEE plugin (that comes with most Linux distributions), but get the 2.4 version from the sourceforge site. Also get the Emacs Code Browser (ECB); this is a plugin that will give you stuff like Eclipse's Project Explorer and Outline views (other developers will look at this and not believe you when tell them that it's Emacs). I've used this setup for commercial projects on Windows, Mac, and Linux in the past year.
In fact, Eclipse plays pretty well with Emacs and I often switch between the two. Eclipse has some nice refactoring tools that I used to use sed for, and it has a good debugger interface. You can use them simultaneously. I find that I use Eclipse when working with other people's code and Emacs when I am writing my own code---Emacs is that much faster. Note that for me, a lot of the value of Emacs is the non-Java functionality, like editing Tomcat configuration files on remote servers from my local Emacs, writing professional documents with LaTeX, developing in Python or Bash or MATLAB or XML, and the odd text manipulation task (e.g., converting CVS files into String[] arrays).
I haven't used the other two projects you mention. It is possible to use the Eclipse compiler with Emacs already, so I'm not sure I see the point of the emacs-eclim project, which seems to be moribund anyway. The Malabar project might be interesting, but seems to be the product of one somewhat cranky developer (e.g., the warning "if you're not using Maven (why?) you should not consider malabar-mode"---I'll tell my clients that?).
Java on Emacs is in a sad state. I wish for JDEE to be revitalized, but it's not clear when or if that will happen. The web site and mailing list offer few clues.
I use emacs-eclim with auto-complete-mode support and java-mode highlighting exclusively for Java programming. 90% of my work is done in emacs, but I switch to eclipse when I need to debug, run unit tests or do major refactorings. All in all, this setup works very well for me.
I haven't tried JDEE for years, but I remember it was a b*tch to set up. I didn't care for the UI very much, as it put up lots of prearranged windows that were locked in place. I like to be able to switch back and forth between editing buffers, often showing just one window, but splitting and rearranging on the fly when it becomes necessary.
Note: I am an emacs-eclim maintainer, and this has probably coloured my judgement.
If you're using Maven, then I'd recommend malabar-mode. It will set everything up for you automagically, no need for editing project files like you'd have to do with JDEE. The downside I've found with malabar, is that it can consume a lot of memory if you've got a lot of multi level module projects open.
Both Malabar and JDEE will give you "true" completion, i.e. only completions that are possible. However, there are two amazing "intelligent guessing completion frameworks" in Emacs. hippie-expand and auto-complete.
The former is great (can complete whole code blocks for you, making it possible to e.g. cycle through all if-tests in your projects), but auto-complete mode is even better. It'll give you a nice intelli sense style menu, will "learn" as you use it, and allows you to define a file with the completions you'd like to be available in the various languages.
I'm the sole developer for an academic consortium headquartered at a university in the northeast. All of my development work involves internal tools, mostly in Java, so nothing that is released to the public. Right now, I feel like my development workflow is very "hobbyist" and is nothing like you would see at an experienced software development firm. I would be inclined to say that it doesn't really matter since I'm the only developer anyway, but it can't hurt to make some changes, if for no other reason than to make my job a little easier and get a few more technologies on my resume. Right now my workflow is something like this:
I do most of my development work in Eclipse on my laptop. Everything is saved locally on my laptop, and I don't use a VCS, nor do I really backup my code (except for occasionally emailing it to myself so I can see it on a different computer - yeah, I told you my development environment needs work).
When I'm done with a project and want to deploy it or if I just want to test it, I use the built-in Jar tool in Eclipse to make an executable .jar of my project. If I use external .jar libraries, I use the Fat-Jar plugin to include those .jars in my executable .jar.
After I create the .jar, I manually upload it to the server via SFTP and test it with something like java -jar MyProject.jar.
Oh yeah, did I mention that I don't unit test?
The most glaringly obvious problem that I'd like to fix first is my lack of source control. I like git because of it's distributed nature, but it doesn't seem to integrate with Eclipse well and I've heard that it doesn't work very well on Windows, which is my primary development OS. So, I'm leaning toward SVN, which I do have some experience with. I do have my own personal server, and I think I'll use that for my source control, because I'd rather be my own admin than have to deal with university bureaucracy. I had some trouble setting up SVN once before, but I'll give it another shot. Maybe I'll also install something like Trac or Redmine for bug-tracking, todo list, etc?
What about building and deployment? There has to be a better way than using Fat-Jar and manually uploading my jar to the server. I've heard about tools like Ant and Maven - do these apply to what I want to do? How can I get started using those?
I suppose I'd eventually like to integrate unit testing with JUnit too. Even though it probably should be, that is not my primary concern right now, because so far my applications aren't terribly complex. I'd really like to work on simplifying and streamlining my workflow right now, and then I'll ease into unit testing.
Sorry for the long question. I guess my question boils down to, for a sole developer, what tools and methodologies can/should I be using to not only make my job easier, but also just to expose myself to some technologies that would be expected requisite knowledge at a dedicated development house?
edit: Thanks for the great answers so far. I didn't mean to suggest that I wanted to make my workflow "enterprisey" just for the sake of doing it, but to make my job simpler and to get a few technologies under my belt that are typically used in enterprise development environments. That's all I meant by that.
It seems to me like you actually have a pretty good idea of what you need to do.
Using Subversion (or other VCS) is a must. Although it might be wise to setup a separate SVN repository for your work-related code rather than using a personal one.
You can integrate Subversion with Eclipse using a plugin like Subclipse, which I've found works pretty well.
I'd definitely use Ant or Maven - my preference is Ant because it's more flexible, and I think it would suit your development style more than Maven as well. But you might also want to look into Apache Ivy, which handles dependency-management.
Basically you set up an ant task which runs your compile, build and deployment steps - so that when you create a final JAR package you can be sure that it's been unit tested as that is part of your ant script. The best way to get started with ant is to look at some examples, and read through the manual.
As for unit testing - you can gradually build up with unit testing. I would recommend using JUnit in conjunction with a code coverage tool such as Cobertura (which is easy to set up) - it will help you to understand how much code your tests are covering and is an indicator about how effective your tests are.
It may also be worth your while setting up something like Trac - it's important to be able to keep track of bugs, and a wiki is surprisingly useful for documentation.
In other words, all of this sounds like you're on the right lines, you just need to get started using some of these tools!
If you're really set on distributed source control, I'd recommend you look at Bazaar. Its GIT-like distributed source control that's designed around performing very high quality merges. Out of the box it works on all platforms including Windows and they have a TortoiseBZR client.
Really though, any source control is better than none. If you're the sole developer then there's no need for anything more complex than SVN. Large companies and projects use SVN all the time with little issue.
As far as unit testing goes, you should make yourself familiar with JUnit. The fact that you're aware of unit testing and know you should be doing it is still several steps ahead of most ad-hoc developers.
Use version control. Period. SVN has great intergration with Eclipse and Windows. Get the TourtisSVN client for windows and use the subclipse plugin with Eclipse.
I would recomend getting an external HD or use one of your companies' servers for putting your repository on and do backups often. Subversion works great with deployment and upgrading as well. Just learn how to do it and you will never look back :)
As far as Unit Testing, some people would say that is the way to go but I have not found enough evidence to start the practice myself. If sombody on this question can convince me otherwise then please do!
Also, don't look to "enterprise" your workflow - look to make it better. Practices that work well with huge teams and corperations may not work well for you. I am pretty much an only developer myself and know the situation you are in. Just try everything and only keep what feels natural after a while.
But make sure to just try SVN! If your company has a LINUX server with apache see if you can set up your server there using DAV-SVN.
:)
I think you answered most of your own questions.
Source control: pick SVN - easy installation, great integration with Eclipse (subclipse).
Use Ant to build your project and deploy it (SCP/SFTP task)
Keep all your settings (Eclipse project settings, build xmls, etc.) in SVN.
Use Bugzilla to keep track of your bugs/issues/requests/ideas.
It would be VERY beneficial to start working with version control. Start now, don't delay! Git is moving REALLY fast, and there's already a TortoiseGit being developed. SVN is still a great standard to work with. And I have not worked with Mercurial, but that's another VCS that's worth looking into.
Other than that, I don't see why your workflow has to be enterprisey. It just has to be efficient and comfortable. That said, I think you should try working with a simple text editor and compiling from the command line. Most of the world's best programmers still use that instead of an IDE, and it will help you understand the processes underneath your favorite IDE.
Check out the Pragmatic Programmers' Pragmatic Starter Kit.
It schools you on the important basics of software development that universities/etc. seem to pass up, like version control, unit testing, and project automation (in that order), and does it in a very approachable manner.
It will give you a solid base to keep going from there.
Take a look # Matt Raible's Appfuse.
It incorporates Maven and Unit Testing.
http://raibledesigns.com/rd/tags/appfuse
Although you put it as the last thing, I think you should start using jUnit without delay.
The reason is, it's probably the easiest of the ambitions you've identified, and the tools are almost certainly already built into your Eclipse build.
Make a new folder in your project called 'jUnit'.
Let's say you have an Employee class, with setAnnualSalary() and getMonthlySalary() methods.
Right click on the jUunit folder, new -> "jUnit test case". This will make a new class. Call it TestEmployee. Eclipse generates the boilerplate stuff for you, as usual.
Add a void method with a name beginning with 'test':
public void testSalaryCalc() {
Employee emp = new Employee("John Doe");
emp.setAnnualSalary(12000);
assertEquals(1000,emp.getMonthlySalary());
}
Right click, "run as" -> "jUnit test". (the first time Eclipse may prompt you to do some setup for the project. Just do what it says.)
If Employee works properly, you'll see a green bar.
Sabotage the Employee class, run the test again, and you'll see a red bar, as well as output telling you what the failure was.
Congratulations: you are unit testing!
Right-clicking on the parent directory and choosing "Run as jUnit test" will run every Testcase class in the directory. Later you can incorporate jUnit into your build process, but don't worry about that for now.
Autocomplete will show you all the variations on assert() you can use. You can read up on it, and aim towards practices where you write the test cases before the implementation that passes them. But just doing the simple stuff above gets you big benefits.
Once you have a set up version control and a few unit-tests, I would consider a continous integration server (you wanted to be enterprisey, right?).
Even if you are and stay the sole developer, this might help you to uncover a few errors. Things you forgot to check in or the likes. A CI-server regularly checks out all your sources, does a clean build an runs all your tests. It also contacts you in the case of errors.
This gives you the guarantee that you (or any other person) is able to check out your code and build/run your projects.
I would recommend to take a look at Hudson
Like others have said, you already clearly know what you need to do. A VCS is a must, CI or bug-tracking may be overkill (for a single developer a spreadsheet might suffice for bug-tracking).
One thing that might benefit you greatly is keeping an organized product backlog. In solo development, I find keeping focused on the high-priority features and avoiding feature creep to be one of my biggest challenges. Keeping a backlog helps immensely. It doesn't have to be much more than a prioritized list of features with some notes about the scope of each. At my workplace, we keep this info in Trac, but here again, a spreadsheet may be all you need.
And I want to put in a plug for unit testing, particularly Test Driven Development (TDD). Kent Beck's book is a good place to start. I find that TDD helps keep me honest and focused on what I really need to do, particularly on a single-developer project without QA. Sometimes it seems like the code writes itself.
You got some really solid answers so short post adding a link to an article about Test Driven Development which is an agile practice that will look good on your CV.
TDD
If you are running a Windows Server where you want to put your SVN server, use Visual SVN as the server. It is super easy to setup and use, it supports both basic authentication and windows authentication. It is also free to use.
Eclipse has quite a few modules to integrate with a SVN server, so use one of those, or the already suggested Tortoise SVN.
All the previous comments covered almost everything you might ever need :-)
I want to add another approach on how to develop (the development workflow).
I suggest that you read the following article and although it's a git workflow you can use the same idea for any other tool you might be using.
http://nvie.com/posts/a-successful-git-branching-model/