This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Should you wrap 3rd party libraries that you adopt into your project?
I am using mail.jar, an opensource api to send mails in java.
I am wondering whether I should wrap its call to my own framework like this :
DedicatedFramework.sendMail(subject, body, recipientList);
this dedicatedFramework would then make the necessary calls to mail.jar.
The idea is that if tomorrow I replace mail.jar with a new version which deprecates/changes methods, then I reduce my coupling.
On the other hand, I add boiler code just to "hide" the framework.
What do you people do regarding this ?
Of course, it could be another framework than mail : picture managing, jdbcTemplate, GoogleCollections ...
No.
Do you know you'll have to use a different mail library tomorrow? Is it even likely? I doubt it. Wrappers just for the sake of "maybe one day" are the worst kind of YAGNI.
On the other hand, if your sendMail() method does something that would otherwise be repeated wherever you send a mail, then it's not a wrapper but a useful abstraction.
Wrap it. Making a bridge between what is available and how it's going to be used is going to save you 1) a lot of boilerplate code and 2) a lot of maintaining that code when something minor changes but you have to make the change in 20 places.
It's entirely possible there is more to this question that isn't being shown. What are our memory constraints? Can we support those extra classes being loaded? We have to identify what problems we would face by doing the wrap, just like any other problem.
However, if there isn't anything that says "We can't wrap because __" then I would recommend doing it.
I would wrap it. It's way easier to find and change code when it's all in one place.
In general, APIs are reasonably stable and classes/methods usually don't disappear, they get deprecated. In your particular case mail.jar is very stable so I wouldn't bother wrapping it.
My advice is to not waste your time writing an API on top of an API - it will cost you more time than it saves in the long run. I've used many libraries over the last decade and the only library I've ever had trouble with was one written by an in-house team - they refactored and changed package names and method names. That broke a lot of code. I've never experienced that with open source libraries.
Wrap
If the framework will be used generally all over your codebase
If it will be a part of project where relatively small number of developers know how to use the framework well
Don't Wrap
If it would be used at just a tiny portion of code that would be very unlikely to change
If the framework or api is realy common knowledge for developers
Related
This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
Getting a clue at / debug a huge Java Swing App I’ve inherited
I joined a new project and have to understand the project's product. I am more familiar with daemon/standalone type applications but this time i have to get involved in Java GUI applications using Swing.
I have to familiarise myself with quite a large code base. I have been trying to do this for the last 3 days and find that i am struggling to get the "Big picture". The event driven model means that things can happen and are triggered from anywhere within the application.
At the moment i am still struggling to work out how the screen is built and put together. I can see the code but just struggling to follow because it is not the usual model that i am used to where you can just follow the references, calls etc.
Is there anything i can do to simplify/speed this learning process? I tend to understand things better when i see them in a diagrammatic form (class diagrams, sequence diagrams etc.). I am trying to see if i can try and find a tool that can reverse engineer the code to UML so that i can get a better understanding but because the code base is huge, the UML diagrams that will be generated will probably be unusable because of the number of classes involved.
Any advice would be appreciated.
Guess you are dealing with a legacy application and all the bagage that comes along with it.
So even if you got to generate a UML, I am willing to bet that it will not help you, since you will (most likely) find it to be a giant mess. Things that used to resemble a Design Pattern got messed up, code snippets copied and pasted from a to b to c, etc...
Your best bet (from my experience) is to follow the Programm logic in the debugger when you execute certain actions. At least thats what I found to be most useful when faced with similar senarios.
Get good IDE. I would recommend itellij idea for this task. It's not free, but it beats eclipse on every occasion
I agree with dngfng, a legacy application will come with its 'baggage'. Only 'time' and lot of discussion with existing developers will sort that.
Along with the other suggestions here, I d say just 'use' the product from the user point of view. Perform all the actions that are promised in the features till you get a hang of using the software. After that when you look at the codebase, it may get a little more intuitive.
yesterday i went to English Class and met new friend, he said with me about the worked he did (still now i have studied in school).
In his company, the customers have
many request for their project, if you
use framework but not understand all
component or like that, you would meet
problem with your source code and you
didn't fix it because it built by
another one. And Cusomters paid money
for you to developed their project,
you must completed it by yourself, and
if occur error you would to fix it.
But if you use framework you can fix
or not it's 50/50 percent for you.
I wonder about his said. Can you help me the best way me must choice? Framework or not?
We have many kinds customers and we must work with some technologies such as struts/ hibernate/Spring/ or so on...if not use framework the time we complete project so long but if use it i don't believe all component of it i can understand.
Thank you for your suggest!
• Should I use existing frameworks in my projects?
Yes, in general you should. The creators of the frameworks have put large amounts of work into them to make them good, and many other people use the frameworks, too. That means that the code is well-tested in practice. When you write your own code, it will be tested by just you and your team.
• What happens if there are bugs in the framework, how could I possibly fix them?
Good question, I don't know an answer right now. Most probably you would write some own code to work around the problem, like a small wrapper class.
• Do I have to understand the complete frameworks before I can use them?
No, you don't. Some frameworks are large and cover each and every aspect of software development. In most cases you only have to learn the things you really want to do, and some more. But not every detail.
• When I use a framework, is that cheating, since my customer wants me to develop software?
No, it isn't. Your customer doesn't really want you to do much work, he rather wants his projects to be done and finished. That means if you can do less work and profit from other's work, that's usually fine.
• We must work with third-party products like Structs/Hibernate/Spring, and if we are forced to implement them ourselves, the projects will take very long.
You really don't want to implement everything that Spring, Hibernate and Struts have already solved. So use these frameworks and be glad that someone else did the work. It's many man years that you will save.
There are many factors to consider:
Is the framework commercial? If so, does the framework have a responsive support team with the ability to provide demos, documentation, consulting, "work-abouts" and hot-fixes? Can you purchase the source code to make any tweaks you need? (Is it worth it to may extra to have access to the source and can you redistribute a modified copy?)
Is the framework "open source"? If so, does the framework have a responsive forum or mailing list that can provide answers to problems? Are there paid consultants or contractors? Is the documentation good? Is the framework popular and is it being maintained? Can you apply hot-fixes as needed?
How much "time" is required to learn the framework? Do special conventions need to be used? Does using the framework cause some lock-in that will be incompatible with future requirements?
Etc, etc.
This all leads to: Does using the framework ultimately make work more productive?
I think it depends on the size of the project. If you're working in a small project probably it's a nonsense to use a framework, because you're going to be less productive.
Instead if you're working in a big project the framework can help you a lot.
For example, in the case of Hibernate, if you're working in a project with three or four objects/tables, maybe it's a nonsense use it, because probably it's much easier to work with JDBC, and even the software will run much faster. But if you're in a project with docens of objects/tables working with JDBC can be a big headache, and hibernate helps you a lot.
The time you loose in the configuration of the framework is small compared to the big benefit in the simplification of the development.
According to the possible bugs in the framework, is important to use a framework with a good support and a good community which can help you to solve your problems.
Also if you use an open source framework you can try to solve the bug, add a new feature or modify an existing one to match with your project needs.
I want to migrate my entire C# 4.0(.Net 2010) desktop Application to Java.I don't know any tool available for that?Please suggest me good one.
Also, i would like to know what are the limitations and advantages of Cross Compiler for C# to java?
please guide me to get out of this problem...
Saravanan.P
Crosscompilers will usually produce rather messy code, and sometimes code that doesn't even compile.
Some (maybe most) will force your new code into having bindings with custom libraries from the crosscompiler, and thus be forever linked to that product.
Your new code will be very hard to maintain and expand as a result, and might well offer poor performance as well as compared to the old code when compiled.
In general, you would most likely be better off rewriting the application yourself (or hiring people to do so) if it is going to have to be used and maintained actively for more than a short, transitional period.
That said, for some things a crosscompiler can be helpful. For example start with a crosscompiled version and over time replace that codebase with newly written code, this would get you working more quickly and you'd not have to maintain 2 separate code bases, in 2 different languages, using 2 toolsets, at the same time.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I find the nature of this question to be quite suited for the practical-minded people on Stack Overflow.
I'm setting out on making a rather large-scale project in Java. I'm not going to go into specifics, but it is going to involve data management, parsing of heterogeneous formats, and need to have an appealing interface with editor semantics. I'm a undergraduate student and think it would evolve into a good project to show my skill for employment -- heck, ideally it would even be the grounds for a startup.
I write to ask you what shortcuts I might not be thinking about that will help with a complicated project in Java. Of course, I am planning to go at it in Eclipse, and will probably use SWT for the GUI. However, I know that Java has the unfortunately quality of overcomplicating everything, and I don't want to get stuck.
Before you tell me that I want to do it in Python, or the like, I just want to reiterate why I would choose Java:
Lots more experience with algorithms in Java, and there will be quite a bit of those.
Want a huge library of APIs to expand functionality. ANTLR, databases, libraries for dealing with certain formats
Want to run it anywhere with decent performance
I am open-minded to all technologies (most familiar with Java, perl, sql, a little functional).
EDIT: For the moment, I am giving it to djna (although the low votes). I think all of your answers are definitely helpful in some respect.
I think djna hit better the stuff I need to watch out for as novice programmer, recognizing that I'm not taking shortcuts but rather trying not to mess up. As for the suggestions of large frameworks, esp. J2EE, that is way too much in this situation. I am trying to offer the simplest solution and one in which my API can be extended by someone who is not a J2EE/JDBC expert.
Thanks for bringing up Apache Commons, although I was already aware. Still confused over SWT vs. Swing, but every Swing program I've used has been butt ugly. As I alluded to in the post, I am going to want to focus most on the file interchange and limited DB features that I have to implement myself (but will be cautious -- I am aware of the concurrency and ACID problems).
Still a community wiki to improve.
Learn/use Spring, and create your project so it will run without a Spring config (those things tend to run out of control), while retaining the possibility to configure the parameters of your environment in a later stage. You also get a uniform way to integrate other frameworks like Hibernate, Quartz, ...
And, in my experience, stay away from the GUI builders. It may seem like a good deal, but I like to retain control of my code all the time.
Google-collections:
http://code.google.com/p/google-collections/
Joda Time for all date and time manipulations.
One of Hibernate or iBATIS to manipulate data in a database
Don't forget the IDE: Eclipse, Netbeans or IDEA if you have some cash and like it
Apache Commons has a lot of time saving code that will you most likely need and can reuse.
http://commons.apache.org/
A sensible build and configuration platform will help you along the way, Ant:
http://ant.apache.org/
or Maven (preferably):
http://maven.apache.org/
Especially as the size of the project, and the number of modules in the project increase.
There's getting the "project" completed efficiently and there are "short cuts". I suspect the following may fall into the "avoiding wasted effort" category rather be truly short cuts but if any of them get you to then end more quickly then I perhaps they help.
1). Decomposition and separation of concerns. You've already identified high-level chunks (UI, persistence layer, parser etc.). Define the interfaces for the provider classes as soon as possible and have all dependent classes work against those interfaces. Pay a lot of attention to the usability of those interfaces, make them easy to understand - names matter. Even something as simple as the difference between setShutdownFlag(true) and requestShutdown(), the second has explicit meaning and hence I prefer it.
Benefits: Easier maintenance. Even during initial development "maintenance" happens. You will want to change code you've already written. Make it easy to get that right by strong encapsulation.
2). Expect iterative development, to be refining and redesigning. Don't expect to "finish" any one component in isolation before you use it. In other words don't take a purely bottom up approach to developing your componenets. As you use them you find out more information, as you implement them you find out more about what's possible.
So enable development of higher level components especially the UI by mocking and stubbing low level components. Something such as JMock is a short-cut.
3). Test early, test often. Use JUnit (or equivalent). You've got mocks for your low level components so you can test them.
Subjectively, I feel that I write better code when I've got a "test hat" on.
4). Define your error handling strategy up front. Produce good diagnostics when errors are detected.
Benefits: Much easier to get the bugs out.
5). Following on from error handling - use diagostic debugging statements. Sprinkle them liberally throughout your code. Don't use System.out.println(), instead use the debugging facilities of your logging library - use java.util.logging. Interactive debuggers are useful but not the only way of analysing problems.
Don't discount Swing for the GUI. There are a lot of good 3rd party Swing libraries available (open source and commercial) depending on your needs e.g.
JGoodies Form Layout
SwingX
JFreeChart
Use logging framework (i.e. Log4J) and plan for it. Reliable logging system saves a lot of time during bug fixing.
For me big time-savers are:
use version-control (Subversion/Git)
use automatic builds (Ant/Make/Maven)
use Continuous-integration (Hudson/CruiseControl)
the apache-commons-libraries are very useful
Test Driven Development
Figure out the functionality you want and write tests to demonstrate the functionality. Then write just enough code to pass the tests. This will have some great side effects:
By writing just enough code to satisfy your requirements you will not be tempted to overbuild, which should reduce complexity and make your code cleaner.
Having tests will allow you to "refactor with confidence" and make changes to the code knowing you're not breaking another part of the system.
You're building quality in. Not only will you have assurance that you code "works, but if you really want to use this code as a sort of "resume" for potential employers, this will show them that you place a lot of value on code quality. This alone will set you apart from the majority of the developers out there.
Aside from that, I would agree that other big time savers are Spring, having an automated build (Maven), and using some form of source control.
For data persistency, if you're not certain that you must use SQL, you should take a look at alternate data-storage libraries:
Prevayler: an in memory database systems, using developing ideas like "crash only components", that make it easy to use and very performatic. May be used even for simple applications where you just need to save some state. It has a BSD License.
BerkleyDB Java Edition: a storage system with different layers of abstraction, so one can use it as a basic key-value storage (almost an in-disk hashtable) to a fully transactional ACID system. Take a look at it's licensing information because even some commercial software may use it for free.
Be aware that they have trade-offs when compared with each other or with a standard SQL database! And, of course, there may be other similar options around, but these are the ones I know and like. :)
PS: I was not allowed to post the respective links because I'm a new user. Just google for them; first hits are the right ones.
You can save time between restarts by using JavaRebel (commercial). Briefly, this tool allows you to write your code in Eclipse and have the code changes picked up instantly.
Spring Roo can not only get your project quickly kickstarted (using a sound architecture) but also reduce your ongoing maintenance. If you're thinking of using Spring, servlets, and/or JPA, you should definitely consider it. It's also easy to layer on things like security.
I'm trying to code an application which runs un different java platforms like J2SE, J2ME, Android, etc. I already know that I'll have to rewrite most of the UI for each platform, but want to reuse the core logic.
Keeping this core portable involves three drawbacks that I know of:
Keeping to the old Java 1.4 syntax, not using any of the nice language features of Java 5.0
only using external libraries that are known to work on those platforms (that is: don't use JNI and don't have dependencies to other libs which violate this rules)
only using the classes which are present on all those platforms
I know of ways to overcome (1): code in 5.0 style and automatically convert it to 1.4 (retroweaver - haven't tried it yet, but seems ok).
I think (2) is a problem that I just have to accept.
Now I'd like to know what's the best workarround for (3), especially collection classes, which I miss the most. I can think of those:
Most programmers I know just don't use Set, Map, List, etc. and fallback to Vector and plain Arrays. I think this makes code ugly in the first place. But I also know that the right choice between TreeSet/Hashset or LinkedList/ArrayList is crucial for performance, and always using Vector and Arrays can't be right.
I could code my own implementations of that classes. This seems to be reinventing the wheel, and I think I could not do it as good as others have done.
Since Java is open source, I could grab the sourcecode of the J2SE Collections framework and include into my application when building for J2ME. I don't know if this is a good idea, though. Pherhaps there are good reasons not to do this.
Maybe there already are libraries out there, which rebuild the most important features of the collections framework, but are optimized for low end systems, pherhaps by not implementing functionality that is used infrequently. Do you know any?
Thanks for your answers and opinions!
Edit: I finally found a (complex, but nice) solution, and I thought by providing my own answer and accepting it, the solution would become visible at the top. But to the contrary, my answer is still at the very bottom.
J2ME is brutal, and you're just going to have to resign yourself to doing without some of the niceties of other platforms. Get used to Hashtable and Vector, and writing your own wrappers on top of those. Also, don't make the mistake of assuming that J2ME is standard either, as each manufacturer's JVM can do things in profoundly different ways. I wouldn't worry much about performance initially, as just getting correctness on J2ME is enough of a challenge. It is possible to write an app that runs across J2ME, J2SE and Android, as I've done it, but it takes a lot of work. One suggestion that I'd have is that you write the core of your application logic and keep it strictly to java.lang, java.util and java.io. Anywhere where you're going to be doing something that might interact with the platform, such as the file system or network, you can create an interface that your core application code interacts with, that you have different implementations for the different environments. For example, you can have an interface that wraps up HTTP stuff, and uses javax.microedition.io.HttpConnection with J2ME and java.net.HttpURLConnection on Android. It's a pain, but if you want to maintain an app running on all three of those environments, it can get you there. Good luck.
It's been a while since I asked this question, and I while since I found a nice, working solution for the problem, but I had since forgotton to tell you.
My main focus was the Java Collections Framework, which is part of the java.util package.
I've finally taken the source code of Suns Java 6.0 and copied all the classes that belong to the Collections framework into a project of my own. This was a Java 6.0 project, but I used the jars from J2ME as classpath. Most of those classes that I copied depend on other J2SE classes, so there are broken dependencies. Anyway, it was quite easy to cut those depensencies by leaving out everything that deals with serialization (which is not a priority for me) and some minor adjustments.
I compiled the whole thing with a Java 6 compiler, and retrotranslator was used to port the resulting bytecode back to Java 1.2.
Next problem is the package name, because you can't deliver classes from java.util with a J2ME application and load them - the bootstrap class loader won't look into the applications jar file, the other bootloaders aren't allowed to load something with that package name, and on J2ME you can't define custom classloaders. Retrotranslator not only converts bytecode, it also helps to change name references in existing bytecode. I had to move and rename all classes in my project, e.g. java.util.TreeMap became my.company.backport.java.util.TreeMap_.
I was than able to write actual J2ME application in a second Java 6.0 project which referenced the usual java.util.TreeMap, using the generic syntax to create type-safe collections, compile that app to Java 6.0 byte code, and run it through retrotranslator to create Java 1.2 code that now references my.company.backport.java.util.TreeMap_. Note that TreeMap is just an example, it actually works for the whole collections framework and even for 3rd party J2SE Jars that reference that framework.
The resulting app can be packaged as a jar and jad file, and runs fine on both J2ME emulators and actual devices (tested on a Sony Ericsson W880i).
The whole process seems rather complex, but since I used Ant for build automation, and I needed retranslator anyway, there only was a one-time overhead to setup the collection framework backport.
As stated above, I've done this nearly a year ago, and writing this mostly from the top of my head, so I hope there are no errors in it. If you are interested in more details, leave me a comment. I've got a few pages of German documentation about that process, which I could provide if there is any demand.
We faced exactly this situation in developing zxing. If J2ME is in your list of targets, this is your limiting factor by far. We targeted MIDP 2.0 / CLDC 1.1. If you have a similar requirement, you need to stick to Java 1.2. Java 1.4 language features are definitely not present (like assert) and in general you won't find anything after 1.2 in J2ME.
We did not use external libraries, but, you could package them into your deployed .jar file with little trouble. It would make the resulting .jar bigger, and that could be an issue. (Then you can try optimizers/shrinkers like ProGuard to mitigate that.)
I did end up reimplementing something like Collections.sort() and Comparator since we needed them and they are not in J2ME. So yeah you might consider doing this in cases, though only where necessary.
We used Vector and Hashtable and arrays since there is no other choice, really, in J2ME. I would just use them unless you have a reason not to, and that would be performance I guess. In theory JVM makers are already optimizing their implementation but that doesn't mean you couldn't make a better one... I guess I would be surprised if it is worth it in the vast majority of cases. Just make sure you really need to do this before putting in the effort.
To answer part of your question another collections library would be Javolution which can be built for j2me.