2009/3/30 <[email protected]> > Generic information does not disappear when the code is compiled, and if > you disassemble the compiled code you see that the method signature (not > the method descriptor) contains <foo.bar.MyClass>. So <foo.bar.MyClass> is > present in the bytecode, and I would like to know if it is possible not to > ignore this information. >
there is some generic information left in the bytecode (mainly signatures) but most is erased - this is because you don't actually need it at runtime and this is why bnd currently ignores this information - adding such an import is not required for runtime use and would just pollute the import space (it would be an artificial dependency just to satisfy one IDE) adding these imports could also stop your bundle from working when no bundle exports the packages, which is not correct - your bundle would work without them there is a workaround: add the package explicitly to your Import-Package instruction another possibility is adding a switch to bnd to scan generic signatures (or using the bnd plugin api to extend its scanning algorithm - actually this is something I'd like to work on when I have time, to allow people to add scanners for hibernate mappings, etc.) you'd have to convince Peter of the merits of adding such a switch compared to the current workaround (which doesn't bloat the code) and providing a suggested patch would probably be a good start [ yet another option is to bug the Eclipse/PDE people to find out why they require an import when it's not required at runtime - I believe this is another case of the underlying JDT bug which forces you to declare dependencies to make these things visible at both compile and runtime ] -- clovis > > ______________________________________ > Diese E-Mail kann vertrauliche und geschuetzte Informationen enthalten. > Wenn diese E-Mail nicht für Sie bestimmt ist, bitten wir Sie, uns > unverzueglich zu informieren und sie zu loeschen. > > This e-mail message may contain information, which is confidential and > protected. If you are not the intended recipient of this message, we ask you > to inform us immediately and delete the message afterwards. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers, Stuart
