io.netty.util.internal

[carrot-garden]

consider elimination of io.netty.util.internal

1. split zip lib into netty-jzlib module
2. move the rest into io.netty.util
   see osgi: convert all modules into bundles, ensure no package split #870

[trustin]

I'm not sure if the current package structure has a problem. Why should we make such changes? The internal package contains the classes that we really don't want to expose to the users besides jzlib.

[carrot-garden]

the way it is done now is sort of misleading:
"internal" or "impl" normally means packages which are "really" not visible

• non-osgi : via "default" package access modifier
• osgi mode : via exclusion from Export-Package

cleaner way would be to expose public interfaces and public factories
and use "default" package access modifier to really hide stuff.

[trustin]

The problem is that there's no way to hide common utility classes that are not intended for use by users. Java and OSGi provide a solution, so I guess we have to rely on less secure options.

[normanmaurer]

@trustin @carrot-garden I spoke with David Bosschaert and it seems like there is a solution for our problem. He will come back to me today or tomorrow.. Stay tuned.

[normanmaurer]

Response of David:

Hi Norman,

This is explained in the OSGi Core Specification (look for a section called 'Mandatory Attributes') but it's not really explained that well in the spec. So here's an example.

Let's say you want to export the 'org.mypkg' package only for internal usage. To do this you add a custom attribute to the export (e.g. netty_scope=internal) and then you declare the netty_scope as a mandatory attribute. This is done via the mandatory directive. Like this:
Export-Package: org.mypkg;version="1.0.0";netty_scope=internal;mandatory:=netty_scope
(note that directives are asssigned with := and attributes with =)

Then the importer must also declare a matching netty_scope attribute, e.g:
Import-Package: org.mypkg;version="[1.0.0,2.0.0)";netty_scope=internal

Importers that don't have the netty_scope attribute set to 'internal' or don't have it at all will not see the package.

So it's not 100% watertight in that any bundle can put the netty_scope attribute in their import, but you've clearly marked your package as a netty internal one so people should be warned and should avoid doing this from outside bundles...

Hope this helps,

David

[normanmaurer]

@carrot-garden can you do this ?

[carrot-garden]

@normanmaurer re "netty_scope"
yes, I can do this. but it seems needles complication, and only addresses osgi.

@trustin re "no way to hide common utility classes that are not intended for use by users"
why not change mind about them and treat as "intended for use by users"

in the past I found myself quite often cloning your "internal" classes in my app code.

[normanmaurer]

I would prefer to not declare it as 'public', as I would like to be sble to not care about API changed in this package.

Sent from my iPhone. Excuse any typos....

Am 04.02.2013 um 15:54 schrieb Andrei Pozolotin notifications@github.com:

@normanmaurer re "netty_scope"
yes, I can do this. but it seems needles complication, and only addresses osgi.

@trustin re "no way to hide common utility classes that are not intended for use by users"
why not change mind about them and treat as "intended for use by users"

in the past I found myself quite often cloning your "internal" classes in my app code.

—
Reply to this email directly or view it on GitHub.

[normanmaurer]

So what about just add the scope stuff ? It can't harm I guess...

[carrot-garden]

re "scope" last time I tried it, it was inconsistent between equinox vs felix vs knopflerfish.
need volunteer to write more tests in netty-verify-osgi-exam :-)

[normanmaurer]

I think it is ok how it is now..