I'd like to create a project in Java that as a shell or box or controller for other parts of itself (there might be an adequate naming for it). I want it to be possible to load additional program parts after the installation of the program, like plugins or addons or how you might call them.
As an example one could think of a program called Calculator having a MenuBar on top giving the possibility to load several JFrames (or JInternalFrame) that provide different calculation ways, for instance ListSums, InvoiceSums, BreakEvenCalculator, ... (and so on).
Now what I want to create is a kind of mask giving me the possibility to import for instance a new JInternalFrame with weather calculations. Literally adding a couple of menu entries and a set of new masks. Well, and this kind of plugin or addon shall be downloaded from a link I provide.
I already tried myself in googling for some ways how to do that, but I'm not quite sure what to search for.
Is there any site providing information about how to create plugins or addons like this?
Cheers in advance for every helpful soul!
Since your question is not very specific I am not sure if I understood correctly but I will try to answer anyways.
I am guessing, that you want to load java code dynamically at runtime (without restart / recompile of your program).
So there are some different approaches to achieve that:
1. Own "Framework"
You create a generic GUI which is able to generate GUI Elements dynamically on the fly. Then you define in your modules via you own DSL or XML your Module. The GUI is then generated based on your definitions which you can load dynamically. I used that once to automatically generate a GUI where a user can build his own dynamic reports and once for come generic installer tool which could create a new workspace with checkout of projects in one case and build & deploy & run a webapp in tomcat.
Pros:
Easy to start with
You know the code (because you have written it)
Cons:
Is very specific
time-consuming since it supports only the things you programmed into the framework
you can easily develop bad code if you do not know exaclty what you do / the requirements change / ...
2. Use some execution engine (e.g. Rhino or Nashorn (Java 8) )
You can develop your modules in JS and either generate the GUI from some modules (like described in 1.) - which I would do in case of a Swing GUI or even create the output from JS (which I would do in case of a WebApp since its just printing html)
Pros:
You can do everything which is supported in the engine / the module language
You are much more flexible than with 1.
Much less time needed
Cons:
Need to understand how the engine works
Starting is not as easy as 1. since you have more external dependencies
you are limited by the limits of the engine (in case of js e.g. the sandboxing like no writing to files, no swing integration / interaction by default,...)
3. OSGi / Spring dm Server
You can as well create your modules in java with own packaging and deploying on the fly into your application with OSGi.
If you want this for an WebApplication I would look into Spring dm Server: http://static.springsource.com/projects/dm-server/1.0.x/programmer-guide/html/ch03s02.html
Otherwise, OSGi should be the better fit.
Since there is much documentation out there on these two topics I wont go more into deep here.
Pros:
You can do everything because your modules will be just java
You use java well established standard mechanisms
Cons:
Need to understand how the framework works
Starting is not as easy as 1. or 2. since you will have to understand the techniques used
more external dependencies
If my answer helped you, I would be happy if you accept it, if not please provide more detailled information on what you want to achieve and what are your requirements.
Regards, Manuel
Related
I am trying to build an application that runs under JavaSE and Android. Most of the code is the same between the two, but there are some specific functions that need to be separated. I use Eclipse. So I decided to put the shared code in a separate project, and then build one more project for Android and one for Java, which reference the shared project. I put all Java and Android specific functions in one class residing in the Java and Android specific projects. These classes are called UtilsJ (for Java) and UtilsA (for Android). The code in the shared project uses a factory to determine at runtime which version it needs to pick, and then calls the class loader to load the right class. Essentially: if property java.vm.name equals Dalvik, load UtilsA, else load UtilsJ (and of course cast to the Utils interface before returning).
My question is simply if this is a good idea or is something going to eventually break? I've never used class loader before. Any other suggestions how to implement this sharing would also be appreciated.
Generating an interface implementation dynamically is certainly a valid technique. For instance, having a data access interface that has multiple implementations; one each for flat files, MySQL and WebDAV. The program can pick an implementation at run time based on system/platform properties.
But this feels different. If I saw that I had a Java app and an Android app that had a lot of common code, my goal would be to create an Eclipse project that generates a jar file that I could just drop into the libraries of both projects. In that case, the jar file wouldn't contain any code that was incompatible with one platform or the other. So there wouldn't be any reason to have a platform-specific implementation.
Let's take your example some code reading an initialization file. If it's common code, you have an input parameter which is a file. On Android, maybe it's "/data/data/com.whatever.blahblahblah" and on Java you're getting the "user.dir" system parameter for the top level directories. But one way or another, it's a File, and you hand it to your common setup method. That's okay. But if your initialization file read code e.g. needs a Context to get a Resource to read the file for Android, then it's not common code. And it doesn't belong in a library jar for a JVM-hosted app.
So I think that in your case the platform-specific implementation classes are overkill. If it's common code, it's the same code — period.
Let's talk about another example in your comment. If you are using desktop Java, then you are probably using Swing or AWT, so you still have the same issue of running some network task off the UI thread, notifying when it completes, maybe even updating some progress indicator UI while it's processing. Same function, same operation, but the code is so different that I can't see how having it in the same library next to an AsyncTask version could be of any benefit.
And testing might get tricky. Obviously JUnit will work for everything, but some tests would need to run on a device or emulator.
I stated that it was a valid technique, and of course you may have other compelling reasons to choose the multi-platform option. You asked the question; is anything going to break? My answer is: Probably not, but why risk dealing with some heartburn down the road? Speaking for myself, I wouldn't do it. If I had to support multiple MVC apps, my common library would have nothing but M.
I'm currently working on an application in Java that contains a core set of functionality, this has to be extended for several different purposes (~10 different purposes) and as such, the best solution that came to mind was the option to add plugins to expand the functionality when needed as opposed to having a different code base for each.
Is the best way of doing this simply creating an interface and extending that in the relevant plugins?
public coreCode()
{
// Core
doThis();
doThat();
// Call plugin code
plugin.doStuff();
}
// Plugin
public interface PluginInterface()
{
doStuff();
...
}
I've looked into JSF etc but due to work limitations (not spcifically authorized etc), they are sadly not a viable option.
--EDIT--
It should roughly work like this:
purpose A, B and C require a certain set of functionality and so plugin1 is developed for them, bundled with them and then deployed. purpose D and E require a different set so plugin2 is developed for them, bundled and deployed. etc.
For plugins you could create a certain directory where class files implementing a certain interface or extending a certain abstract class are located. Then you can create new instances of these classes and see if they are an instance of the abstract class/interface you want them to be, then make a certain list of them and give users the ability to enable/disable them. If they are enabled you can then cast and execute them.
I would suggest you to look into OSGi - a dynamic component model where applications are developed and deployed as a set of bundles/plug-ins that can be added, started, stopped and removed remotely without even requiring a reboot of the core/host application.
You can model your application on the Eclipse RCP platform (one the best implementations of OSGi) and create a head-less (without any UI) core RCP application. All other application functionalities would then be developed as plug-ins that can come bundled or added later on to your core RCP application in any combination you like (or your clients may request) even after the application has gone live.
If you're application would have a UI and you like the Eclipse IDE's look and functionalities like "New Project" Wizards, use of Perspectives to change the layout of Views, Workspaces, context-sensitive Help functionality and over-the-network updates through plug-in repositories etc. then it's definitely worth considering. Have a look at this RCP FAQ page to see if this fits your needs.
The only thing that put developers off is that it has a bit of a steep learning curve. The dependencies are always declared declaratively with XMLs and within the code all the components are so de-coupled that you always find yourself interacting with the framework more.
The use of JFace for building UI components puts a lot of stress on the separation between the Model and the View. So, while all of this translates to good application design it doesn't allow rapid application development if one is new to the framework. Most of its other complexities come from the fact that RCP just has so much to offer.
First off, I'm coming (back) to Java from C#, so apologies if my terminology or philosophy doesn't quite line up.
Here's the background: we've got a growing collection of internal support tools written for the web. They use HTML5/AJAX/other buzzwords for the frontend and Java for the backend. These tools utilize a lightweight in-house framework so they can share an administrative interface for security and other configuration. Each tool has been written by a separate author and I expect that trend to continue, so I'd like to make it easy for future authors to stay "standardized" on the third-party libraries that we've already decided to use for things like DI, unit testing, ORM, etc.
Our package naming currently looks like this:
com.ourcompany.tools.framework
com.ourcompany.tools.apps.app1name
com.ourcompany.tools.apps.app2name
...and so on.
So here's my question: should each of these apps (and the framework) be treated as a separate project for purposes of Maven setup, Eclipse, etc?
We could have lots of apps appear here over time, so it seems like separation would keep dependencies cleaner and let someone jump in on a single tool more easily. On the other hand, (1) maybe "splitting" deeper portions of a package structure over multiple projects is a code smell and (2) keeping them combined would make tool writers more inclined to use third-party libraries already in place for the other tools.
FWIW, my initial instinct is to separate them.
What say you, Java gurus?
I would absolutely separate them. For the purposes of Maven, make sure each app/project has the appropriate dependencies to the framework/apps so you don't have to build everything when you just want to build a single app.
I keep my projects separated out, but use a parent pom for including all of the dependencies and other common properties. Individual tools / projects have a name and a reference to the parent project, and any project-specific dependencies, if any. This works for helping to keep to common libraries and dependencies, since the common ones are already all configured, but allows me to focus on the specific portion of the codebase that I need to work with.
I'd definitely separate these kind of things out into separate projects.
You should use Maven to handle the dependencies / build process automatically (both for your own internal shared libraries and third party dependencies). There won't be any issue having multiple applications reference the same shared libraries - you can even keep multiple versions around if you need to.
Couple of bonuses from this approach:
This forces you to think carefully about your API design for the shared projects which will be a good thing in the long run.
It will probably also give you about the right granularity for source code control - i.e. your developers can check out and work on specific applications or backend modules individually
If there is a section of a project that is likely to be used on more than one project it makes sense to pull that out. It will make it a little cleaner as well if you need to update the code in one of the commonly used projects.
If you keep them together you will have fewer obstacles developing, building and deploying your tools.
We had the opposite situation, having many separate projects. After merging them into one project tree we are much more productive and this is more important to us than whatever conventions happen to be trending.
When writing code in an Eclipse project, I'm usually quite messy and undisciplined in how I create and organize my classes, at least in the early hacky and experimental stages. In particular, I create more than one class with a main method for testing different ideas that share most of the same classes.
If I come up with something like a useful app, I can export it to a runnable jar so I can share it with friends. But this simply packs up the whole project, which can become several megabytes big if I'm relying on large library such as httpclient.
Also, if I decide to refactor my lump of code into several projects once I work out what works, and I can't remember which source files are used in a particular run configuration, all I can do it copy the main class to a new project and then keep copying missing types till the new project compiles.
Is there a way in Eclipse to determine which classes are actually used in a particular run configuration?
EDIT: Here's an example. Say I'm experimenting with web scraping, and so far I've tried to scrape the search-result pages of both youtube.com and wrzuta.pl. I have a bunch of classes that implement scraping in general, a few that are specific to each of youtube and wrzuta. On top of this I have a basic gui common to both scrapers, but a few wrzuta- and youtube-specific buttons and options.
The WrzutaGuiMain and YoutubeGuiMain classes each contain a main method to configure and show the gui for each respective website. Can Eclipse look at each of these to determine which types are referenced?
Take a look at ProGuard, it is a "java shrinker, optimizer, obfuscator, and preverifier". I think you'll mainly be interested in the first capability for this problem.
Yes it's not technically part of Eclipse, as you requested, but it can be run from an Ant script, which can be pretty easily run in Eclipse.
I create more than one class with a main method for testing different ideas that share most of the same classes.
It's better to be pedantic than lazy, it saves you time when coding :-)
You can have one class with a main method that accepts a command-line argument and calls a certain branch of functionality based on its value.
I am looking for a Java GUI building tool that generates the Java Swing code for me. I'm planning on using it to get all of the Frame/Panel code created quickly and then customize everything by hand after that.
It would be nice to be able to choose between different layout managers, but it's not necessarily required.
The most important part, the tool can't require any .jar files to be placed in my project (this isn't allowed for the project I'm working on.)
NetBeans will build pure Swing apps for you, as will a number of other tools.
In fact, as far as I know, that's the rule rather than the exception. Just ask for a Swing app and you'll have pure Java (in most cases).
I agree with Carl, Netbeans.
By default, when Netbeans creates a Java Desktop Application (swing), it wants to include some other jars. (At least it does for me)
appframework-x.x.x.jar
swing-worker-x.x.jar
Just start from a generic Java Application, then add the GUI classes manually. This will result in a project with no dependencies.
Way back when I used JVider to lay out my screens. It's not nearly as complete or complex as NetBeans, but it does allow you to quickly and comfortably lay out screens using GridBagLayout.
What I like about it is that it generates source code and has no runtime requirements. There is a runtime option that will allow you to load your UI from XML files it generates, rather than generating classes, but you don't have to use it.
My process back then was to have JVider generate source classes. Then I would create a subclass and add all the event logic, data binding, etc. to that subclass. This would allow me to tweak the UI files and regenerate without losing any of my logic.
Nowadays I'd typically use NetBeans, but if I had a "no external jars/classes allowed" requirement JVider might be my first choice again.
Good luck!