2

I'm working on a app where I have 2 types called Asset, from different packages. I know I can prepend the type with the path of the package, but they're both really long and they both need to be passed as parameters to methods, which looks horrible. the 2 classes I have are: 

really.long.path.to.this.one.package.Asset

and

Ridiculusly.long.path.to.this.otherPackage.Asset

Since both types are used in parameters and as returntypes, I end up in this situation:

import really.long.path.to.this.one.package.Asset;

private List<Ridiculusly.long.path.to.this.otherPackage.Asset> getSimilarAssets(Ridiculusly.long.path.to.this.otherPackage.Asset asset,String otherParam){...}

and some methods look even worse, when the non-imoported Asset-type is in the parameter list.

Both types are out of my control, and there is no way for me to exchange one for anything else.

I know I cant import both classes the normal way(this has been answered elsewhere), but can I somehow import a parenting package so that I can get away with writing only part of the path? It seems to me that if I could import some package that is a parent of one of the Asset's, I could cut the path in method-definitions down quite a bit. the above method could then look like:

private List<otherPackage.Asset>getSimilarAssets(otherPackage.Asset asset, String otherParam){...}

I assume this would work since the parent package of the 2 classes are different, but I cant seem to get a working reference to the package into my class.any way to do this?

Anders Martini
  • 828
  • 1
  • 14
  • 31

2 Answers2

1

Ideally you need something rather like the typedef or using keywords of C++. Sadly Java does not support that.

The best you can do - but this does intrusively alter your program source code - is to consider defining two of your own Asset classes, each in separate (but shorter) paths, or, alternatively with different names:

class Asset extends Ridiculusly.long.path.to.this.otherPackage.Asset
{
    /*constructors calling super*/
}

and instantiate these versions of Asset rather than the one with the long name. In implementing this, you will not encounter any ambiguity in the importing. But you will suffer the overhead of having to write out the constructor stubs so this might not be feasible.

But, would I do this? The answer is no. The reason being is that I believe it's best to work with rather than against the language you have chosen to use for your implementation. Consider, in particular, this article before adopting this approach. http://www.ibm.com/developerworks/library/j-jtp02216/

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
  • huh, never thought of that. seems like a bit of a hack, but it might be worth it! If I change the name of my own class it should also be enough to do this with only one of the `Assets`. My biggest concern is that this is likely to confuse anyone dealing with my code down the road. not sure which is worse.. I also have to consider whether or not I can return this hack of a class to other components calling my code...the extra dependency might be a dealbreaker, but many thanks for the imput, this is the best answer so far for sure! – Anders Martini Sep 08 '16 at 13:52
  • 1
    First, keep in mind that non-`static` inner classes contain references to their outer instance that may prevent garbage collection. Second, this works only in the class which creates these instances, not in any class that only has to work with existing instances. – Holger Sep 08 '16 at 15:41
  • 2
    This is a hack, that often comes with consequences. See http://www.ibm.com/developerworks/library/j-jtp02216/. – Brian Goetz Sep 08 '16 at 21:18
  • @BrianGoetz: Upvoted: it's flattering to think that the approach I came up with over a cup of tea has a name! If you don't mind, I've added the link to my answer, with additional disclaimers. (Do note, by the way, that the typedef mechanisms differ substantially in C and C++). – Bathsheba Sep 09 '16 at 07:07
0

The best you can get is import one class (the one that's used more) and use the FQN for the other. If you're using other classes from their packages, you'll need to import them separately too.

There's no way to create "partial imports" like you're hoping. Be glad it's just an eyesore and not a complex design issue that's preventing you to continue developing.

Kayaman
  • 72,141
  • 5
  • 83
  • 121