How to perform batch methods renaming in Java project - java

I have a set of Java projects that use the same library. The problem is that the previous version of the library included classes which methods names started from upper-case characters like MyClass.DoSomething(). The next version of the library became more "Java-friendly" and method names were changed to lowerCamelCase like MyClass.doSomething().
Now I need to rename all these methods in all of my projects, but doing it manually is a long and boring task.
I wonder is there exists some IDE plugin or tool that may perform this task automatically.

Most (Any?) modern IDEs have method rename refactoring feature. In Intellij Idea it is Shift-F6 when your cursor is at the method name. So one of the options is to rename each of the methods.
You could also write a hacky script which I think should work for most of the cases and all other cases could be done manually. It would search for entries like .DoSomething( and replace them with .doSomething(.

What IDE? Netbeans allows you to do project-wide search and replace, so you just need to do that once for each function.
Alternatively you can open up the old version of the library project (if it is open source) and change your library dependency to be a project one. Now go through and refactor the library project to the new names and it will rename all the old references in your code at the same time. Once you are done ditch your copy of the project and switch back to the library but the changes from refactoring will remain.

Related

How to use different version of a library at Runtime?

I have a java project where I use an external jar (not controlled by me).
Until now whenever that a new version of that library is out, I update
my project to use the more recent one, but now is required that the
project uses different versions of that library.
My problem is I don't have any clue how to do that.
How do I tell in java to make the imports according a version of a jar,
What I need to do:
int versionFlag = getVersion2use();
if(verssionFlag = 0){
use imports from last version
}else if(verssionFlag = 1){
use imports from last version 1
} else if(verssionFlag = 2){
use imports from last version 2
}
This is to be used at runtime!
This is usually something that a project will do at build time rather than dynamically at runtime.
That said, here's a good answer on how to add a jar to the system classloader dynamically at runtime, which is something you could work into your general logic above:
How should I load Jars dynamically at runtime?
With respect to imports, there's no way around the fact that you can't dynamically pick your imports. So if you're lucky the two versions have the same basic API. If that holds, add the jar to classloader as early as possible in your app and then develop like normal.
If the two versions have different a different API, however, then you're going to have to write some very convoluted code that tries building objects and almost ubiquitously catches all the many different class load / class incompatibility exceptions (such as ClassNotFoundException). Worse, you'll probably have to do this behind some sort of facade or factory architecture so that you can actually keep running software insulated from all these class loading shenanigans. In short, if the two have different APIs you may actually be better off writing two separate products.
At Runtime
Classes with the same name in the same package follow a first available rule. The first one that is on the classpath is the one that is used.
You can not easily do what you want at runtime without a wrapper program to move the libraries into and out of the system classpath before the Java application is started.
A launcher script/program that dynamically builds the classpath and only includes the version you need of each library and passes it to java -cp is the only way to do what you want at runtime.
At build time
If it is at build time, then just use something like the shade plugin in Maven to build an uberjar with all the required libraries embedded in a single .jar for each of the versions. So 3 versions would be 3 separate uberjar assemblies.
If you can do it at build time, you can use a dependency manager, like Maven.
It provides you with a means to be able to select which versions of which library you use at build-time.
If you need to do this at runtime, you might need to package all libraries in your project. You can use shading (see here) to make sure you don't get import issues, because when importing different versions of libs you end up with similar imports.
Shading can help you make for example:
com.foo.Class in jarv1
com.foo.Class in jarv2
To become
com.foo.v1.Class in jarv1
com.foo.v2.Class in jarv2
This will make sure your code can still use all libs you want.

Change IntelliJ code construct symbols

Is there a way to change the icons for symbols suchs the C for classes and the M methods. They're a little hard to distinguish on my laptop. Ideally I'd like to change it throughout the IDE but fine if it's just for the project pane or auto complete.
The icons can't be changed via the UI as far as I know. It is however possible to change them manually. All icons used by IntelliJ are located in $IDEA_HOME/lib/icons.jar, where $IDEA_HOME represents the IntelliJ installation directory.
It might be possible to modify content of this JAR (by unzipping it, changing the icons and creating JAR from it again) and replace the original icons.jar with it. But change such as this will probably be overwritten during IntelliJ upgrade.
One solution would be to package the icons into a plugin. There is a Idea 11 Icon Pack plugin which does exactly the same thing you want. It is a JAR with the same structure as the icons.jar. Except two things:
It has plugin descriptor (META-INF/plugin.xml) in order for the JAR to be registered as plugin
It has implementation class com/bulenkov/idea/Idea11IconPack in order to register the icons I guess
I would use this as an inspiration. You can modify the descriptor so that there are no clashes in plugins, and change all of the old icons for your modified ones. One thing I'm not sure about is the implementation class. You could keep it and it might work. Or you could decompile it to see what it does and create your own version.
You can then install the JAR with the plugin descriptor by clicking Install plugin from disk button in the plugin settings.
Here is also a documentation for plugin development which might be useful.

Tool for creating Dynamically Generated Code in Java (In Eclipse)

In Visual Studio land, I used to be able to define a structure in an XSD file and add a special attribute to it which would cause it to be dynamically compiled and available to use with intellisense in the other C# files in the application. I am not sure exactly what the term for this is, perhaps "dynamic code generation."
I am trying to accomplish the same in Java using Eclipse IDE. Basically what I am looking for is a tool that will allow me to specify some template and generate Java code from it in a "hot folder" that will allow me code complete in the other static Java files.
Does anyone know of a solution for this? I know it is possible in Visual Studio, but I can't seem to find anything for Eclipse.
Ok, here is exactly what I want to do.
Step 1. I create a folder called templates
Step 2. I create a file called HelloWord.ibes
Step 3. Code it automatically generated in my src folder HelloWorld.java
I want to be able to do this in eclipse easily.
You may create an ant build file that does the source generation for you. Then you are free to use any code generator you like. Ant support is part of the eclipse IDE. If you prefer maven, there's a nice eclipse pluging available (that's what I actually use for source code generation based on jaxb, javacc and xdoclet...).
Technically spoken, you just add another eclipse builder which is invoked anytime eclipse detects a change in your code base.
If you already have a code generator in mind, just 'ask' the internet if there's a plugin available.
Edit
On how to install a builder: This is done automatically. For maven, you just install the maven plugin (m2eclipse) and enable maven dependencies for a project. Then if you look at the projects properties pages (Builder section), you find a second entry in the list of builders.
It's similiar with ant, even easier, because ant is already integrated. "enable" ant for a project and the builder is added to the list of builders for the project. You can deselect it at any time if it kills performance or switch of automatic building (I don't know by heart how to enable ant builds for a project, but I remember that the eclipse help had sufficiant informations).
All about ant can be found here: Apache Ant
Creating a new builder is difficult, as it has to be coded in java and added to eclipse as a plugin. I bet you don't want to follow that track ;)
I'm not sure whether you have seen the code template option?
Preferences.Java, Code Style then Code Templates
How
to add code templates
Useful
code templates

Can Java annotation do this?

I'm looking into a solution that displays the subversion revision number and last modification date in my application (written in GWT, therefore reflection is not available). Encode the revision in subversion keyword doesn't work as it applies only to the current file. Is there a better solution using annotation? (e.g., a separate class that's executed during the compile time, grab the latest revision # on the whole project and inject the revision and last modification date to the source code)
I kn
#SvnRevision("$Id$")
public class Foo {
}
Then your classes are all annotated with their version. You need to make sure the annotation is defined as having runtime retention so it can be queried at runtime.
EDIT
OK, since SVN doesn't have that feature, I'd write a Maven plugin to emulate it. Maven has access to the SCM information for every file so during the build phase you could have it do the same keyword expansion.
Annotations are not really designed for this. It's easiest to do it as part of the build.
Using Ant you can generate a file that contains the version information, include it in your application's JAR, load it as a resource on the server, and serve it out to the browser-side code by RPC. Ant can also do string replacement in files as it copies them, which you can use to include the version number in your application's HTML files (no need for RPC then).
No idea about Maven, but I would be very surprised if it could not do the same kind of thing.
Subversion still has the $Id$ feature, but it needs to be enabled explicitly using the svn:keywords property on the files (set it to 'Id').
See also: http://svnbook.red-bean.com/en/1.5/svn.advanced.props.special.keywords.html
So the idea of Jherico above with #SvnRevision would work.

how to repackage eclipse for my team

I'd like to set up eclipse with a bunch of plugins and DB connection configurations, etc and re-zip it up so my team-mates and new starters can all be working on the same platform easily.
It seems that installing plugins is fine, but when I add in custom jars (e.g. ivy2, ojdbc, etc) they all save with full, absolute paths which probably dont exist on others machines (particularly if they unzip in a different location to me).
Anyway, I'm hoping that this idea is not silly and am working if this sort of process is documented somewhere or if anyone has any tips in general.
Thanks,
I would recommend against requiring all developers to place eclipse in the same location. There are times when some developers may want to try an alternate version of eclipse to explore a technology that requires a different set of plugins or a different eclipse base version.
Let developers install eclipse where they would like.
However, for jars that you need to run plugins (external dependencies that you need to configure for proper plugin usage):
Hardwire a directory for those jars (as opposed to the entire eclipse dir), like c:\eclipse-helpers or something.
To deal with third-party library dependencies (in the code you're developing), you have a few good choices:
Create project(s) to hold the third-party libs and check them into your source version control system (which you are using, right?). You can then add the libs to the build path(s) of the project(s) - make sure you mark them for export in the "order and export" tab of the build path page. You can then simply add these third-party projects as project dependencies.
Reference the third-party jars as CLASSPATH variables when adding them to the build path of your projects. This allows other developers to store the dependencies in different locations. Perhaps define a CLASSPATH variable (in eclipse's Window->Preferences->Java->Build Path->Classpath Variables) called THIRD_PARTY_JARS; each developer can map it to a different path where they want to hold their deps.
Reference the third-party jars as a "user library" (Window->Preferences->Java->Build Path->User library). This is similar to classpath variables, but acts as an explicit set of jars.
Include the third-party jars directly in your projects. Use this option only if you need the deps in a single location.
Although not exactly in line with the direction of the question, you could use Yoxos OnDemand. It allows you to "roll-your-own" Eclipse distro and download it as a zip. They add in their own perspective where you can add more plugins (direct from their repo), or update the plugins that you have.
Although I've never used the feature, you can make make your own stacks and name them, allowing anyone to go to the site later and download it (with the most up-to-date versions of the plugins). Also, dependencies for plugins are resolved automatically if need be.
In eclipse - in many places it's possible to use workspace relative paths or system environment infos to reference external files, too.
Another option could be to place your jars into a workspace project so that every team member can check it out from cvs/subversion/whatever and start working. Working like this ensures a reproducible environment for server builds or for desktops even after years.
Talking about Yoxos...
it provides "Workspace Provisioning" as well. This means you can attach Eclipse Preferences, checkstyle configurations and Mylyn setups additionally to your list of needed tools/plugins for your IDE to your yoxos profile.
This means your team could share a profile and would be able to start working with the same setup regardless of their OS or whatever. (Its possible to use multiple profiles at once, too.)
We did a similar thing with our development environment (it needed both Eclipse and our own plug-in which, in the early stages, had to run in a known location).
We just put it in c:\eclipse_<projName> and made that a requirement for the team. That's probably the easiest solution for you.
It's your team, you can dictate this as a requirement. Unless your team members are absolute idiots, they'll work with you.
I found Yoxos really good and it does very good work in determining dependencies.
Its really a good tool and worth giving a look.
I just started using git to manage my eclipse install. I did a write-up. The approach might work for you, and it's probably worth looking at.
If developers all don't have the same paths on their machine, instead of adding independent JAR files you could create what Eclipse calls a "library" and include a bunch of jars in that. Then another developer just has to change the location of the library and it'll pick up all the jars in there.

Categories

Resources