Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
It seems to me that there are many instances where implementation of a specific class is the same for different projects.
In Java this is true for classes like ArrayList. So there is obviously reason to reusing generic classes across different projects.
Another generic class that would be usefull would then be ArrayMatrix, but since there is no default implementation in Java I made one myself. It's generic, safe and documented.
Is it common practice to create your own implementation in a situation like this?
If not, what's the preffered way?
If it is, what's the best practice way to share the class/code between projects and organize your "library"?
This is the entire point of having libraries. The best way to share them is to put them in an artifact repository; if possible, Central and JCenter, or some company-internal repository if the libraries can't be open-sourced for some reason. Here's the intro to publishing to Central; it's a minor hassle, but I've done it myself, and it's not too difficult.
I would encourage you to make sure that an equivalent to your class isn't already available in something like Guava or Apache Commons.
Related
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 8 years ago.
Improve this question
I've done a lot with IO in Java and after looking for code to convert primitives to byte arrays and back I found source for java.io.Bits on one of the Java source code hosting websites. After a quick glance I realized it's exactly what I need, except it's package-private. So I made a copy which I made public, stored in my project's package and used (only in personal projects, I assure you). I find it very useful.
My question is, why is this package-private? I can see it being really useful for people who work with IO and I see no disadvantage from changing it's visibility to public (in rt.jar). Or is there perhaps an equivalent (and please don't mention other libraries)?
Here's a link to a randomly chosen website that has Java source for java.io.Bits: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/io/Bits.java
You'd have to ask one of the Java devs for sure, but by making it package private, the API can be treated as "internal" - i.e. it might change or disappear at any time. This means the API can be developed relatively quickly, and doesn't need to go through the same relatively thorough testing process that public APIs need to go through (since once they're released, they're stuck there for good.)
In short, making an API public has long term implications, and it requires much, much more work than just hitting a switch.
I would hazard a guess it started life as a "hacked together" group of functions useful for a few other classes in the IO package, and has just stayed there ever since.
It's package-private, sure, but there are public APIs that expose the same behavior, e.g. ByteBuffer.wrap(array).getInt(index) and the other methods on ByteBuffer. You're almost certainly better off using that properly designed, well-documented public API than trying to wrap or copy internal implementation details from Java.
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 8 years ago.
Improve this question
A Java developer (with lots of experience in sophisticated, high-performance environments) very recently commented that "composition is not used much anymore." I was surprised by this comment. Is this true?
On the one hand, other answers on this forum indicate that difference between composition and aggregation can be ambiguous (can the whole exist without the part; does the part exist throughout the life of the containing object?). But perhaps in all of these cases the question stands--how to add behavior to an existing class or class hierarchy.
The context of his comment was a discussion of possible alternatives to inheritance. If this developer is correct, what has replaced composition in working practice? Mix-ins through added interfaces?
Any perspectives are welcome!
If anything, it's probably used now more than ever thanks to dependency injection frameworks like Spring. The model that all of the Java developers I know use is to build classes that relate to one another in functionality more by interface and purpose and to use Spring to inject them according to a particular configuration (ex the ability to replace entire security frameworks just by changing a spring configuration file and adding a few new JAR files).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
We’re working like hadoop big project. We’ve a problem.
We want to work on Java based CMS (Content management system). But this CMS must include Spring, hibernate, MySQL and must have Responsive interface (our library is twitter bootsrapt).
Our project usually quite big so, what can i do ?
What's your usage to hadoop? Is it just map and reduce? If so, I seriously recommend to write map-reduce part yourself. It's simple to code up as long as you have already object serialization and communication layer; and since you mention your project is big you probably have them already. Then the value of hadoop is just an interface and I am sure you can write it in more compact and adaptive way to suit your usage.
To me this is a typical case where a 3rd party lib gives you 20% of functionality you need while introducing 80% of its own rubbish. So I'd say just write your own.
BTW, if your use case is simple, you might also want to take a look at ForkJoinPool
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 9 years ago.
Improve this question
My question is fairly simple, I haven't found a direct answer to it.
Is redundant code between two or more packages to achieve package independence considered as a good or bad practice, for instance I have two packages one does a download-and-cache , the other is for readfromserver-and-cache. while cached data and mechanism are completely different but have some common classes/methods.
Shall I create a third package which holds commons, and break package in-dependency?
Or shall I continue with two packages and will result in redundant code?
Lastly, to go deep in design and dependency, I'd appreciate it if you suggest me good material to read.
*Please note : I write in java , common code is not that much
I think that you go for creating an interface for the Cache. If the cache is not the same for both packages then common code can be in a abstract class and the individual packages can implement the rest.
Of course if the code is identical, then strip it out to its own jar.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
How do you decide what a package name should be and what class should go into what package ?
I'm working on a project where I am constantly adding/removing classes and not really sure if I need a new package, or should add it to an existing one that im not currently aware of.
Do you follow a set of rules when creating a new package ?
How do you know if you are not duplicating package functionality ? Is this just down to familiarity with the project.
Any pointers appreciated.
I strongly discourage from organizing packages from an implementational point of view, like controllers, data, etc. I prefer grouping them by functionality, that is, feature1, feature2, etc. If a feature is reasonably complex and requires a large number of classes, then (and only then) I create subpackages like above, that is, feature1.controllers, feature1.data, etc.
Classes should do one thing (Single Responsibility Principle).
Classes that do related things should go in the same package. If you find you can more closely relate some of the classes in a package, make them a subpackage!
For example, if I had a project with these classes:
GreetingInputWindow
GreetingDatabaseObject
GreetingDatabaseConnector
I might just put them all in the greeting package. If I wanted to, I might put GreetingInputWindow in the greeting.ui package, and the other 2 into the greeting.db package.
I don't believe there are any hard and fast rules on packaging convention (though I could be wrong). Normally I break it up into
com.mycompanyname and then:
api
controllers
data (for models)
jobs (for cron jobs)
reporting
servlet
utils
If I find I have a class which does not fit into any of those, then I create a new package.