I have written a common class which I want to use in separate Blackberry applications. This class is not in a separate project but just at a common location and I have linked the path of the common class in Java Build Path. I have added same common path to both of my BB applications and they builds and installs without any problem. When I run one application, it start running but when I run the other application, it gives error message "class xxx multiply defined" error and exits.
Any idea what is going wrong here. Thanks in advance
Regards,
Braj
BlackBerry doesn't work as other Java platforms. In BB Java, you can't have two classes with the same full qualified name, even if they live in different projects.
You'll have to rename one of them (either change the class name or the package name) for it to work.
In fact, the only platform where I have seen this restriction is BB. It is a real pain in the ass since you can't reuse a jar library in different projects without renaming it.
UPDATE:
This is the official article on the topic:
http://supportforums.blackberry.com/t5/Java-Development/Application-throws-quot-multiply-defined-quot-error-at-start-up/ta-p/501498
All applications in RIM OS run under one instance of Java Virtual Machine. And therefore it is allowed only one class with particular full qualified name. Adding another class with the same name will lead to failure upon running both of these classes.
There is a library thing, supported in RIM OS, but I do not recommend to use libraries in your project, unless it is very necessary.
It is because if you have several apps with the same library, but with different versions of libraries you may get the same error you reported in your question. And it is hard to manage libraries when you have many applications which use these libraries.
I recommend to copy source code of your library to the project you are working on. Copy via refactoring, to change all full qualified names of classes included in that library.
Thanks guys for replying. I have created a common library and put common code in that. Now I can use this library in different applications without any problem.
However, when I install my applications using BB desktop Manager, the library appears as part of first application but not in second application. I assume it is because, second application realizes that the library is already been included so doesn't need to include it again.
Related
When distributing a Java application to others, it can be deployed as a JAR file for easy execution.
But is there a way to change a Java class / part of the code after deployment without having to rebundle the whole application again?
If you have an app with say 10 classes where 9 are finalized but one needs to be adjusted according to the individual case. What would be the easiest way to change just one class in an app?
Probably you want to use java web start. If your user starts application via java web start it is automatically being updated if updates are available.
EDIT
It does not provide class-based granularity, but I believe this is not the real issue. It however provides the jar-based granularity, i.e. the newer version of jar is being downloaded only if it was changed.
No, there's not.
You should repackage OR design the one that should be adjusted to be configurable at runtime. If you can modify it using a configuration database and factory that would be the only way to do it without repackaging.
In theory you could create another jar for the customized classes and put it into the classpath before the old jar, and the JVM will load the customized classes. But this is simply looking for trouble...
Better to build two jars, one with the non changing classes and another with the customized classes and rebuild the later when you need it.
I am supposed to deliver a SDK in Java for the company I work for.
I have a few years of Java EE experience but not so much when it comes to develop API and SDK.
The problem here, is that the SDK is already available in .NET C# and working just fine. I made it myself.
Switching to Java is a nightmare. I tried several solutions. All failed, some were inconclusive due to the fact I could not progress.
As the title says, I a need to develop a Java Library that has modules. Internal modules. Modules the world out there is NOT supposed to see / use / modify.
In C#, it's easy as pie : create your modules respective namespace, make their classes and methods privates, expose one or more wrappers (bridges) to the entire assembly (project) with internal so that the "main module", through it's own public wrapper accessible by the world, can use the tools provided within these internals modules.
The keyword, here, is INTERNAL. I think it's pretty easy to understand. So let's take an example.
Let's say the SDK is consisting of 4 modules.
The 1st module, is the main module, the one that is public and
exposed to the whole world. In other words, the unique entry point
of the SDK. It's like a master of its own universe. It can use the
internal modules at will, but will never show them to the world.
Never.
The 2nd module is network-related. As in, it deals with network to manage connexions to remote services, read and write data from and to a stream. It offers its own little wrapper so that the main module does not need to use the 2nd module internal tools. Like a universe inside a universe.
The 3rd module is a data processing module. It receives packets (hand-made by the 2nd module) so that it can be processed and relevant information dealt with.
So here we are. How can I do that in Java using NetBeans ?
I tried Maven with POM Project, and Netbeans modules. A nightmare.
I tried creating multiple libraries (one per module), tweaked the Main Module library to include its (modules) dependancies but it does not work.
In a standard Java EE console application, as soon as I attempt to instanciate my SDK Manager (ergo the main wrapper from the main module), it fails because Class Not Found exception : could not find classes related to the internal sub-modules.
If I add all modules respective Jar into this Java Console app, it can access all wrappers. Where is the fun in that ?
Thanks for the help !
Project Jigsaw will eventually give you what you want when java 9 comes out.
See this article about how jigsaw works, in particular,
An exports clause in a module declaration makes the public types in
the package it names available to other modules, so we can with Jigsaw
defines boundaries, and not all public types could be used from other
modules, we must explicitly specify which types are visible.
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 recently started using Eclipse IDE and have read at a number of places that one shouldn't use the default(src) package and create new packages.
I just wanted to know the reason behind this.
Using the default package may create namespace collisions. Imagine you're creating a library which contains a MyClass class. Someone uses your library in his project and also has a MyClass class in his default package. What should the compiler do? Package in Java is actually a namespace which fully identifies your project. So it's important to not use the default package in the real world projects.
Originally, it was intended as a means to ensure there were no clashes between different pieces of Java code.
Because Java was meant to be run anywhere, and over the net (meaning it might pick up bits from Sun, IBM or even Joe Bloggs and the Dodgy Software Company Pty Ltd), the fact that I owned paxdiablo.com (I don't actually but let's pretend I do for the sake of this answer) meant that it would be safe to call all my code com.paxdiablo.blah.blah.blah and that wouldn't interfere with anyone else, unless they were mentally deficient in some way and used my namespace :-)
From chapter 7, "Packages", of the Java Language Spec:
Programs are organized as sets of packages. Each package has its own set of names for types, which helps to prevent name conflicts.
I actually usually start by using the default package and only move it into a real package (something fairly easy to do with the Eclipse IDE) if it survives long enough to be released to the wild.
Java uses the package as a way to differentiate between classes. By using packages, you can have an org.example.Something class and an org.example.extended.Something class and be able to differentiate between them even though they are both named Something. Since their packages are different, you can use them both in the same project.
By declaring a package you define your own namespace (for classes). This way if you have two identical classes using a different package name (namespace) will differentiate between which one you want to use.
The main reasons I can think of are:
It keeps things organised, which will help you (and others!) know where to look for classes/functionality.
You can define classes with the same name if they are in different packages.
Classes/etc in the default package cannot be imported into named packages. This means that in order to use your classes, other people will have to put all their classes in the default package too. This exacerbates the problems which reasons 1 & 2 solve.
From a java point of view, there are two general dev/deploy lifecycles you can folllow, either using ant to build and deploy, or the maven lifecycle. Both of these lifecycles look for source code and resources in local directories, and in the case of maven, in defined repositories, either locally or on the net.
The point is, when you set up a project, for development and eventually deployment, you want to build a project structure that is portable, and not dependent on the IDE, ie. your project can be built and deployed using either of your build environments. If you use a heavy dependence on the Eclipse framework for providing class variables, compile paths, etc.. you may run into the problem that your project will only build and deploy using that configurationj, and it may not be portable to another developers environment, so to speak.
I'm developing a Java plugin for an existing Java program. The existing program uses a specific version of eclipse.uml2.* and my plugin does too. Unfortunately I need a newer version for my plugin.
In order to run the plugin, I need to export it into a Jar file (with all jars packed). Then the program executes it. But somehow the new eclipse.uml2.* seem to interfere with the program -> it crashes.
Is there a way to "separate" both versions of the jar files?
An approach will be to use a custom class loader in your application. This can very easily introduce bugs that are difficult to trace, so take care.
http://www.devx.com/Java/Article/31614/1954
This is the exact problem OSGi tries to solve. Would it be feasible to rework the Java app to another plugin platform?
This will be difficult. You conceivably try to use class loader tricks to allow both versions of the eclipse.uml.* classes to be loaded in the same JVM. But as far as the JVM would be concerned they would be different sets of classes, and your plugin and the base java app wouldn't be able to exchange instances.
It is probably simpler (and less risky ... in terms of likelihood of success) to rebuild (and if necessary modify) either the base program or your plugin so that they both work with the same version of the eclipse.uml2.* classes.