Topics

Discussion: Artifact Group Id and Package Names


Will Hopkins
 

EG:

As part of getting ready to publish our artifacts to maven.java.net, I've been looking at the following naming guidelines: https://javaee.github.io/glassfish/wiki-archive/Maven%20Versioning%20Rules.html.

As well, one of Bill's comments on the EDR spec was that he thought there were too many different packages.

As a result, I wonder if we should rethink the current package structure. In particular, I'm concerned about our use of the "javax.security" package, which also implies an artifact groupId of "javax.security".

This package name is the "root" of all Java EE and Java SE security packages, with the exception of a few Java SE packages at and below "java.security".

Previous JSRs, including JACC and JASPIC, have chosen to use packages under javax.security, but not place any classes in javax.security itself. I think that makes sense, as it doesn't "hog" the namespace. It's true that JSR-375 is meant to be the home for all things Java EE security, but as a practical matter we might not want to reserve java.security for our exclusive use for all time. Moving everything under some common sub-package of java.security seems like a good idea -- although I'll grant that no obvious name for that sub-package springs immediately to mind ...

To Bill's comment about the number of packages, how would people feel about consolidating the "annotation" sub-packages with their parents?  I.e., move the annotations into the javax.security.authentication.mechanism.http and java.security.identitystore packages and eliminate the sub-packages?

Lastly, would a shorter-but-still-specific name for javax.security.authentication.mechanism.http make sense? Perhaps java.security.http.authmech? Or a slightly shorter package name for Identity Store: javax.security.idstore? And should we make a javax.security.context package so that SecurityContext and related classes can move out of javax.security?

Appreciate any and all feedback on this.

Will

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Ivar Grimstad
 



On Fri, May 26, 2017 at 1:24 AM Will Hopkins <will.hopkins@...> wrote:
EG:

As part of getting ready to publish our artifacts to maven.java.net, I've been looking at the following naming guidelines: https://javaee.github.io/glassfish/wiki-archive/Maven%20Versioning%20Rules.html.

As well, one of Bill's comments on the EDR spec was that he thought there were too many different packages.

As a result, I wonder if we should rethink the current package structure. In particular, I'm concerned about our use of the "javax.security" package, which also implies an artifact groupId of "javax.security".

This package name is the "root" of all Java EE and Java SE security packages, with the exception of a few Java SE packages at and below "java.security".

Previous JSRs, including JACC and JASPIC, have chosen to use packages under javax.security, but not place any classes in javax.security itself. I think that makes sense, as it doesn't "hog" the namespace. It's true that JSR-375 is meant to be the home for all things Java EE security, but as a practical matter we might not want to reserve java.security for our exclusive use for all time. Moving everything under some common sub-package of java.security seems like a good idea -- although I'll grant that no obvious name for that sub-package springs immediately to mind ...

If we can find a meaningful sub-package name, I guess that would be alright. Otherwise, javax.security seems to be the most obvious place for this JSR.
 

To Bill's comment about the number of packages, how would people feel about consolidating the "annotation" sub-packages with their parents?  I.e., move the annotations into the javax.security.authentication.mechanism.http and java.security.identitystore packages and eliminate the sub-packages?

This is done differently from spec to spec, so I am fine with either. Would be nice to have some common guideline from the umbrella spec on this though.
 

Lastly, would a shorter-but-still-specific name for javax.security.authentication.mechanism.http make sense? Perhaps java.security.http.authmech? Or a slightly shorter package name for Identity Store: javax.security.idstore? And should we make a javax.security.context package so that SecurityContext and related classes can move out of javax.security?

I think we should be careful abbreviating the terms we are defining in the spec. As I remember Auth Mech was one of the alternatives we was one of the alternatives we disregarded when we went for Authentication Mechanism. I am usually wary of abbreviating package names, and in this case I think we should stick to the term we define in the spec.
 

Appreciate any and all feedback on this.

Will

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

--

Java Champion, JCP EC/EG Member, JUG Leader


Guillermo González de Agüero
 

Hi,



On Fri, May 26, 2017 at 1:24 AM, Will Hopkins <will.hopkins@...> wrote:
EG:

As part of getting ready to publish our artifacts to maven.java.net, I've been looking at the following naming guidelines: https://javaee.github.io/glassfish/wiki-archive/Maven%20Versioning%20Rules.html.

As well, one of Bill's comments on the EDR spec was that he thought there were too many different packages.

As a result, I wonder if we should rethink the current package structure. In particular, I'm concerned about our use of the "javax.security" package, which also implies an artifact groupId of "javax.security".

This package name is the "root" of all Java EE and Java SE security packages, with the exception of a few Java SE packages at and below "java.security".

Previous JSRs, including JACC and JASPIC, have chosen to use packages under javax.security, but not place any classes in javax.security itself. I think that makes sense, as it doesn't "hog" the namespace. It's true that JSR-375 is meant to be the home for all things Java EE security, but as a practical matter we might not want to reserve java.security for our exclusive use for all time. Moving everything under some common sub-package of java.security seems like a good idea -- although I'll grant that no obvious name for that sub-package springs immediately to mind ...
What about javax.security.enterprise? The word enterprise is already used in CDI (e.g.: javax.enterprise.context)


To Bill's comment about the number of packages, how would people feel about consolidating the "annotation" sub-packages with their parents?  I.e., move the annotations into the javax.security.authentication.mechanism.http and java.security.identitystore packages and eliminate the sub-packages?

Lastly, would a shorter-but-still-specific name for javax.security.authentication.mechanism.http make sense? Perhaps java.security.http.authmech? Or a slightly shorter package name for Identity Store: javax.security.idstore? And should we make a javax.security.context package so that SecurityContext and related classes can move out of javax.security?
I strongly prefer longer but self-explanatory package names. I see they easier to find, and once they are imported, I only have to deal with the class name anyway, so a long package name is not a problem at all.
 

Appreciate any and all feedback on this.

Will

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

Regards,

Guillermo González de Agüero


Arjan Tijms
 

Hi,

I remember there was quite some discussion about the package names in the EG and the current ones are the results of a broad consensus including a vote.

Indeed, the longer non-abbrivated names are probably better. They give the API IMO a more fresh and modern feel. Abbreviating to (very) short names reminds me quite a bit of old AS/400 code. "AuthMech" in particular sounds a bit like a Japanese robot suit :P 

Kind regards,
Arjan Tijms




On Fri, May 26, 2017 at 7:56 AM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,



On Fri, May 26, 2017 at 1:24 AM, Will Hopkins <will.hopkins@...> wrote:
EG:

As part of getting ready to publish our artifacts to maven.java.net, I've been looking at the following naming guidelines: https://javaee.github.io/glassfish/wiki-archive/Maven%20Versioning%20Rules.html.

As well, one of Bill's comments on the EDR spec was that he thought there were too many different packages.

As a result, I wonder if we should rethink the current package structure. In particular, I'm concerned about our use of the "javax.security" package, which also implies an artifact groupId of "javax.security".

This package name is the "root" of all Java EE and Java SE security packages, with the exception of a few Java SE packages at and below "java.security".

Previous JSRs, including JACC and JASPIC, have chosen to use packages under javax.security, but not place any classes in javax.security itself. I think that makes sense, as it doesn't "hog" the namespace. It's true that JSR-375 is meant to be the home for all things Java EE security, but as a practical matter we might not want to reserve java.security for our exclusive use for all time. Moving everything under some common sub-package of java.security seems like a good idea -- although I'll grant that no obvious name for that sub-package springs immediately to mind ...
What about javax.security.enterprise? The word enterprise is already used in CDI (e.g.: javax.enterprise.context)


To Bill's comment about the number of packages, how would people feel about consolidating the "annotation" sub-packages with their parents?  I.e., move the annotations into the javax.security.authentication.mechanism.http and java.security.identitystore packages and eliminate the sub-packages?

Lastly, would a shorter-but-still-specific name for javax.security.authentication.mechanism.http make sense? Perhaps java.security.http.authmech? Or a slightly shorter package name for Identity Store: javax.security.idstore? And should we make a javax.security.context package so that SecurityContext and related classes can move out of javax.security?
I strongly prefer longer but self-explanatory package names. I see they easier to find, and once they are imported, I only have to deal with the class name anyway, so a long package name is not a problem at all.
 

Appreciate any and all feedback on this.

Will

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

Regards,

Guillermo González de Agüero



Rudy De Busscher
 

Hi,

A sub package of javax.security  is maybe a better idea. We don't do the *complete* security.

I agree that we need to avoid abbreviations as they are not as clear as the full name.

Best regards
Rudy


On 26 May 2017 at 08:38, Arjan Tijms <arjan.tijms@...> wrote:
Hi,

I remember there was quite some discussion about the package names in the EG and the current ones are the results of a broad consensus including a vote.

Indeed, the longer non-abbrivated names are probably better. They give the API IMO a more fresh and modern feel. Abbreviating to (very) short names reminds me quite a bit of old AS/400 code. "AuthMech" in particular sounds a bit like a Japanese robot suit :P 

Kind regards,
Arjan Tijms




On Fri, May 26, 2017 at 7:56 AM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,



On Fri, May 26, 2017 at 1:24 AM, Will Hopkins <will.hopkins@...> wrote:
EG:

As part of getting ready to publish our artifacts to maven.java.net, I've been looking at the following naming guidelines: https://javaee.github.io/glassfish/wiki-archive/Maven%20Versioning%20Rules.html.

As well, one of Bill's comments on the EDR spec was that he thought there were too many different packages.

As a result, I wonder if we should rethink the current package structure. In particular, I'm concerned about our use of the "javax.security" package, which also implies an artifact groupId of "javax.security".

This package name is the "root" of all Java EE and Java SE security packages, with the exception of a few Java SE packages at and below "java.security".

Previous JSRs, including JACC and JASPIC, have chosen to use packages under javax.security, but not place any classes in javax.security itself. I think that makes sense, as it doesn't "hog" the namespace. It's true that JSR-375 is meant to be the home for all things Java EE security, but as a practical matter we might not want to reserve java.security for our exclusive use for all time. Moving everything under some common sub-package of java.security seems like a good idea -- although I'll grant that no obvious name for that sub-package springs immediately to mind ...
What about javax.security.enterprise? The word enterprise is already used in CDI (e.g.: javax.enterprise.context)


To Bill's comment about the number of packages, how would people feel about consolidating the "annotation" sub-packages with their parents?  I.e., move the annotations into the javax.security.authentication.mechanism.http and java.security.identitystore packages and eliminate the sub-packages?

Lastly, would a shorter-but-still-specific name for javax.security.authentication.mechanism.http make sense? Perhaps java.security.http.authmech? Or a slightly shorter package name for Identity Store: javax.security.idstore? And should we make a javax.security.context package so that SecurityContext and related classes can move out of javax.security?
I strongly prefer longer but self-explanatory package names. I see they easier to find, and once they are imported, I only have to deal with the class name anyway, so a long package name is not a problem at all.
 

Appreciate any and all feedback on this.

Will

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

Regards,

Guillermo González de Agüero




Arjan Tijms
 

Hi,

We indeed don't do the complete security yet, although I think the plan was that we eventually would.

The package we were given was javax.security. We could perhaps move everything to javax.security.api.*? As the current other packages (jaspic and jacc) are an spi. Jaspic even has it in its name: Java Authentication *SPI* for Containers.

We can't change it now anymore, but javax.security.api.* and javax.security.spi.* with the latter containing jaspic and jacc would have been awesome.

Curious what Werner has to say though, I remember him being most vocal about the current package arrangement.

Kind regards,
Arjan Tijms


 



On Fri, May 26, 2017 at 9:51 AM, Rudy De Busscher <rdebusscher@...> wrote:
Hi,

A sub package of javax.security  is maybe a better idea. We don't do the *complete* security.

I agree that we need to avoid abbreviations as they are not as clear as the full name.

Best regards
Rudy


On 26 May 2017 at 08:38, Arjan Tijms <arjan.tijms@...> wrote:
Hi,

I remember there was quite some discussion about the package names in the EG and the current ones are the results of a broad consensus including a vote.

Indeed, the longer non-abbrivated names are probably better. They give the API IMO a more fresh and modern feel. Abbreviating to (very) short names reminds me quite a bit of old AS/400 code. "AuthMech" in particular sounds a bit like a Japanese robot suit :P 

Kind regards,
Arjan Tijms




On Fri, May 26, 2017 at 7:56 AM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,



On Fri, May 26, 2017 at 1:24 AM, Will Hopkins <will.hopkins@...> wrote:
EG:

As part of getting ready to publish our artifacts to maven.java.net, I've been looking at the following naming guidelines: https://javaee.github.io/glassfish/wiki-archive/Maven%20Versioning%20Rules.html.

As well, one of Bill's comments on the EDR spec was that he thought there were too many different packages.

As a result, I wonder if we should rethink the current package structure. In particular, I'm concerned about our use of the "javax.security" package, which also implies an artifact groupId of "javax.security".

This package name is the "root" of all Java EE and Java SE security packages, with the exception of a few Java SE packages at and below "java.security".

Previous JSRs, including JACC and JASPIC, have chosen to use packages under javax.security, but not place any classes in javax.security itself. I think that makes sense, as it doesn't "hog" the namespace. It's true that JSR-375 is meant to be the home for all things Java EE security, but as a practical matter we might not want to reserve java.security for our exclusive use for all time. Moving everything under some common sub-package of java.security seems like a good idea -- although I'll grant that no obvious name for that sub-package springs immediately to mind ...
What about javax.security.enterprise? The word enterprise is already used in CDI (e.g.: javax.enterprise.context)


To Bill's comment about the number of packages, how would people feel about consolidating the "annotation" sub-packages with their parents?  I.e., move the annotations into the javax.security.authentication.mechanism.http and java.security.identitystore packages and eliminate the sub-packages?

Lastly, would a shorter-but-still-specific name for javax.security.authentication.mechanism.http make sense? Perhaps java.security.http.authmech? Or a slightly shorter package name for Identity Store: javax.security.idstore? And should we make a javax.security.context package so that SecurityContext and related classes can move out of javax.security?
I strongly prefer longer but self-explanatory package names. I see they easier to find, and once they are imported, I only have to deal with the class name anyway, so a long package name is not a problem at all.
 

Appreciate any and all feedback on this.

Will

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

Regards,

Guillermo González de Agüero





Rudy De Busscher
 

Arjan,

With my remark, We don't do the *complete* security. I was referring to the fact that we only do it for Java EE, not SE for example.

So we don't do the *complete* security for the JVM was a better comment. So subpackage is then more clear.


best regards
Rudy

On 26 May 2017 at 12:49, Arjan Tijms <arjan.tijms@...> wrote:
Hi,

We indeed don't do the complete security yet, although I think the plan was that we eventually would.

The package we were given was javax.security. We could perhaps move everything to javax.security.api.*? As the current other packages (jaspic and jacc) are an spi. Jaspic even has it in its name: Java Authentication *SPI* for Containers.

We can't change it now anymore, but javax.security.api.* and javax.security.spi.* with the latter containing jaspic and jacc would have been awesome.

Curious what Werner has to say though, I remember him being most vocal about the current package arrangement.

Kind regards,
Arjan Tijms


 



On Fri, May 26, 2017 at 9:51 AM, Rudy De Busscher <rdebusscher@...> wrote:
Hi,

A sub package of javax.security  is maybe a better idea. We don't do the *complete* security.

I agree that we need to avoid abbreviations as they are not as clear as the full name.

Best regards
Rudy


On 26 May 2017 at 08:38, Arjan Tijms <arjan.tijms@...> wrote:
Hi,

I remember there was quite some discussion about the package names in the EG and the current ones are the results of a broad consensus including a vote.

Indeed, the longer non-abbrivated names are probably better. They give the API IMO a more fresh and modern feel. Abbreviating to (very) short names reminds me quite a bit of old AS/400 code. "AuthMech" in particular sounds a bit like a Japanese robot suit :P 

Kind regards,
Arjan Tijms




On Fri, May 26, 2017 at 7:56 AM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,



On Fri, May 26, 2017 at 1:24 AM, Will Hopkins <will.hopkins@...> wrote:
EG:

As part of getting ready to publish our artifacts to maven.java.net, I've been looking at the following naming guidelines: https://javaee.github.io/glassfish/wiki-archive/Maven%20Versioning%20Rules.html.

As well, one of Bill's comments on the EDR spec was that he thought there were too many different packages.

As a result, I wonder if we should rethink the current package structure. In particular, I'm concerned about our use of the "javax.security" package, which also implies an artifact groupId of "javax.security".

This package name is the "root" of all Java EE and Java SE security packages, with the exception of a few Java SE packages at and below "java.security".

Previous JSRs, including JACC and JASPIC, have chosen to use packages under javax.security, but not place any classes in javax.security itself. I think that makes sense, as it doesn't "hog" the namespace. It's true that JSR-375 is meant to be the home for all things Java EE security, but as a practical matter we might not want to reserve java.security for our exclusive use for all time. Moving everything under some common sub-package of java.security seems like a good idea -- although I'll grant that no obvious name for that sub-package springs immediately to mind ...
What about javax.security.enterprise? The word enterprise is already used in CDI (e.g.: javax.enterprise.context)


To Bill's comment about the number of packages, how would people feel about consolidating the "annotation" sub-packages with their parents?  I.e., move the annotations into the javax.security.authentication.mechanism.http and java.security.identitystore packages and eliminate the sub-packages?

Lastly, would a shorter-but-still-specific name for javax.security.authentication.mechanism.http make sense? Perhaps java.security.http.authmech? Or a slightly shorter package name for Identity Store: javax.security.idstore? And should we make a javax.security.context package so that SecurityContext and related classes can move out of javax.security?
I strongly prefer longer but self-explanatory package names. I see they easier to find, and once they are imported, I only have to deal with the class name anyway, so a long package name is not a problem at all.
 

Appreciate any and all feedback on this.

Will

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

Regards,

Guillermo González de Agüero






Will Hopkins
 

Thanks for the replies.

Arjan -- what do you mean by javax.security is "the package we were given"? In what sense was it given?

With respect to the base package name:
  • The javax.security.enterprise suggestion seems viable (although not all users of the API will be enterprise developers).
  • Arjan's suggestion of javax.security.api is also viable, but it does run into the problem that we're reserving an entire namespace -- all APIs for javax.security -- for ourselves, for all time. My main concern here is not to paint ourselves into a corner that constrains future JSRs.
  • What do people think about javax.security.jsapi, or javax.security.jesapi, to represent Java EE Security API? This is similar to what JACC did with javax.security.jacc.
With respect to long names, if this has already been discussed and voted on, I'm fine with keeping things as they are. That said, while I also like to see words spelled out (I like Japanese robots suits, but not the name "authmech" ;) ), I think packages with a lot of long words do get unwieldy, and some words are abbreviated often enough that I don't mind them (authn and authz, for example). One place where I think long names do intrude is when viewing javadoc with frames on -- the package list at the left isn't very usable with very long names.

With respect to the package structure, one person replied that they were OK with moving the annotations in with their parent packages, but nobody else commented on that directly. Does that mean people are OK with it, or does the comment "we like long names" imply keeping the annotations separate?

Two other comments/questions while I'm at it:
  • It seems like the javax.security.identitystore.credentials package could really come up a level, to javax.security.credentials. If the credentials classes are really general purpose, they can and should be used by lots of code, not just by IdentityStore and consumers of IdentityStore.
  • Similarly, I'm not a fan of having classes in the "root" package -- I'd like to see SecurityContext and related classes moved to javax.security.context. The CallerPrincipal class might warrant a "principals" package, or maybe it could live in "credentials".
Thoughts? I apologize if I'm revisiting issues that were discussed and decided before, but as I'm looking at this stuff I feel like I need to at least ask the question(s).

Regards,

Will


On 05/26/2017 07:05 AM, Rudy De Busscher wrote:
Arjan,

With my remark, We don't do the *complete* security. I was referring to the fact that we only do it for Java EE, not SE for example.

So we don't do the *complete* security for the JVM was a better comment. So subpackage is then more clear.


best regards
Rudy

On 26 May 2017 at 12:49, Arjan Tijms <arjan.tijms@...> wrote:
Hi,

We indeed don't do the complete security yet, although I think the plan was that we eventually would.

The package we were given was javax.security. We could perhaps move everything to javax.security.api.*? As the current other packages (jaspic and jacc) are an spi. Jaspic even has it in its name: Java Authentication *SPI* for Containers.

We can't change it now anymore, but javax.security.api.* and javax.security.spi.* with the latter containing jaspic and jacc would have been awesome.

Curious what Werner has to say though, I remember him being most vocal about the current package arrangement.

Kind regards,
Arjan Tijms


 



On Fri, May 26, 2017 at 9:51 AM, Rudy De Busscher <rdebusscher@...> wrote:
Hi,

A sub package of javax.security  is maybe a better idea. We don't do the *complete* security.

I agree that we need to avoid abbreviations as they are not as clear as the full name.

Best regards
Rudy


On 26 May 2017 at 08:38, Arjan Tijms <arjan.tijms@...> wrote:
Hi,

I remember there was quite some discussion about the package names in the EG and the current ones are the results of a broad consensus including a vote.

Indeed, the longer non-abbrivated names are probably better. They give the API IMO a more fresh and modern feel. Abbreviating to (very) short names reminds me quite a bit of old AS/400 code. "AuthMech" in particular sounds a bit like a Japanese robot suit :P 

Kind regards,
Arjan Tijms




On Fri, May 26, 2017 at 7:56 AM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,



On Fri, May 26, 2017 at 1:24 AM, Will Hopkins <will.hopkins@...> wrote:
EG:

As part of getting ready to publish our artifacts to maven.java.net, I've been looking at the following naming guidelines: https://javaee.github.io/glassfish/wiki-archive/Maven%20Versioning%20Rules.html.

As well, one of Bill's comments on the EDR spec was that he thought there were too many different packages.

As a result, I wonder if we should rethink the current package structure. In particular, I'm concerned about our use of the "javax.security" package, which also implies an artifact groupId of "javax.security".

This package name is the "root" of all Java EE and Java SE security packages, with the exception of a few Java SE packages at and below "java.security".

Previous JSRs, including JACC and JASPIC, have chosen to use packages under javax.security, but not place any classes in javax.security itself. I think that makes sense, as it doesn't "hog" the namespace. It's true that JSR-375 is meant to be the home for all things Java EE security, but as a practical matter we might not want to reserve java.security for our exclusive use for all time. Moving everything under some common sub-package of java.security seems like a good idea -- although I'll grant that no obvious name for that sub-package springs immediately to mind ...
What about javax.security.enterprise? The word enterprise is already used in CDI (e.g.: javax.enterprise.context)


To Bill's comment about the number of packages, how would people feel about consolidating the "annotation" sub-packages with their parents?  I.e., move the annotations into the javax.security.authentication.mechanism.http and java.security.identitystore packages and eliminate the sub-packages?

Lastly, would a shorter-but-still-specific name for javax.security.authentication.mechanism.http make sense? Perhaps java.security.http.authmech? Or a slightly shorter package name for Identity Store: javax.security.idstore? And should we make a javax.security.context package so that SecurityContext and related classes can move out of javax.security?
I strongly prefer longer but self-explanatory package names. I see they easier to find, and once they are imported, I only have to deal with the class name anyway, so a long package name is not a problem at all.
 

Appreciate any and all feedback on this.

Will

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803
Regards,

Guillermo González de Agüero





-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Arjan Tijms
 

Hi,

On Fri, May 26, 2017 at 6:01 PM, Will Hopkins <will.hopkins@...> wrote:
Thanks for the replies.

Arjan -- what do you mean by javax.security is "the package we were given"? In what sense was it given?

By the original JSR submission. It listed the packages we could use. So the JSR was filed with that and the EC signed off on it.

 

With respect to the base package name:
  • The javax.security.enterprise suggestion seems viable (although not all users of the API will be enterprise developers).
  • Arjan's suggestion of javax.security.api is also viable, but it does run into the problem that we're reserving an entire namespace -- all APIs for javax.security -- for ourselves, for all time. My main concern here is not to paint ourselves into a corner that constrains future JSRs.

The problem is perhaps that "javax" is basically seen as Java EE package, but Java SE in fact uses it too. IMHO Java EE should have been given its own exclusively package a long time ago, but it's no use arguing about that now as this ship has sailed.

The name of the JSR is "Java EE Security API", so it says "all APIs for Java EE security". But the question is whether we're taking "javax" to mean "java ee" or not.

If we're not, and in fact it is not, then perhaps javax.security.ee would be another option after javax.security.enterprise. That not all users may be enterprise users is perhaps not that important, it just reflects on the name of the JSR which is "Java EE Security API".

 
  • What do people think about javax.security.jsapi, or javax.security.jesapi, to represent Java EE Security API? This is similar to what JACC did with javax.security.jacc.
Not really a big fan of "jesapi" I have to say, as it sounds a little cryptic, but if other people like it I won't be against it either.

 
  • It seems like the javax.security.identitystore.credentials package could really come up a level, to javax.security.credentials. If the credentials classes are really general purpose, they can and should be used by lots of code, not just by IdentityStore and consumers of IdentityStore.

I'm a bit impartial about that too and could live with both options ;) If I remember correctly javax.security.identitystore.credentials was originally proposed by Alex.

 
  • Similarly, I'm not a fan of having classes in the "root" package -- I'd like to see SecurityContext and related classes moved to javax.security.context. The CallerPrincipal class might warrant a "principals" package, or maybe it could live in "credentials".
There are examples in EE both for and against that. FacesContext lives in a .context package, but ServletContext lives in the root.

My preference would be for the root though, as for a user facing API the SecurityContext would be the entry point. Then again, I would not be strongly against moving it out of the root.
 
Thoughts? I apologize if I'm revisiting issues that were discussed and decided before, but as I'm looking at this stuff I feel like I need to at least ask the question(s).

I'm fairly sure the classes in the JSR root were discussed earlier as well,  but fair enough ;)

Kind regards,
Arjan Tijms

 

Regards,

Will



On 05/26/2017 07:05 AM, Rudy De Busscher wrote:
Arjan,

With my remark, We don't do the *complete* security. I was referring to the fact that we only do it for Java EE, not SE for example.

So we don't do the *complete* security for the JVM was a better comment. So subpackage is then more clear.


best regards
Rudy

On 26 May 2017 at 12:49, Arjan Tijms <arjan.tijms@...> wrote:
Hi,

We indeed don't do the complete security yet, although I think the plan was that we eventually would.

The package we were given was javax.security. We could perhaps move everything to javax.security.api.*? As the current other packages (jaspic and jacc) are an spi. Jaspic even has it in its name: Java Authentication *SPI* for Containers.

We can't change it now anymore, but javax.security.api.* and javax.security.spi.* with the latter containing jaspic and jacc would have been awesome.

Curious what Werner has to say though, I remember him being most vocal about the current package arrangement.

Kind regards,
Arjan Tijms


 



On Fri, May 26, 2017 at 9:51 AM, Rudy De Busscher <rdebusscher@...> wrote:
Hi,

A sub package of javax.security  is maybe a better idea. We don't do the *complete* security.

I agree that we need to avoid abbreviations as they are not as clear as the full name.

Best regards
Rudy


On 26 May 2017 at 08:38, Arjan Tijms <arjan.tijms@...> wrote:
Hi,

I remember there was quite some discussion about the package names in the EG and the current ones are the results of a broad consensus including a vote.

Indeed, the longer non-abbrivated names are probably better. They give the API IMO a more fresh and modern feel. Abbreviating to (very) short names reminds me quite a bit of old AS/400 code. "AuthMech" in particular sounds a bit like a Japanese robot suit :P 

Kind regards,
Arjan Tijms




On Fri, May 26, 2017 at 7:56 AM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,



On Fri, May 26, 2017 at 1:24 AM, Will Hopkins <will.hopkins@...> wrote:
EG:

As part of getting ready to publish our artifacts to maven.java.net, I've been looking at the following naming guidelines: https://javaee.github.io/glassfish/wiki-archive/Maven%20Versioning%20Rules.html.

As well, one of Bill's comments on the EDR spec was that he thought there were too many different packages.

As a result, I wonder if we should rethink the current package structure. In particular, I'm concerned about our use of the "javax.security" package, which also implies an artifact groupId of "javax.security".

This package name is the "root" of all Java EE and Java SE security packages, with the exception of a few Java SE packages at and below "java.security".

Previous JSRs, including JACC and JASPIC, have chosen to use packages under javax.security, but not place any classes in javax.security itself. I think that makes sense, as it doesn't "hog" the namespace. It's true that JSR-375 is meant to be the home for all things Java EE security, but as a practical matter we might not want to reserve java.security for our exclusive use for all time. Moving everything under some common sub-package of java.security seems like a good idea -- although I'll grant that no obvious name for that sub-package springs immediately to mind ...
What about javax.security.enterprise? The word enterprise is already used in CDI (e.g.: javax.enterprise.context)


To Bill's comment about the number of packages, how would people feel about consolidating the "annotation" sub-packages with their parents?  I.e., move the annotations into the javax.security.authentication.mechanism.http and java.security.identitystore packages and eliminate the sub-packages?

Lastly, would a shorter-but-still-specific name for javax.security.authentication.mechanism.http make sense? Perhaps java.security.http.authmech? Or a slightly shorter package name for Identity Store: javax.security.idstore? And should we make a javax.security.context package so that SecurityContext and related classes can move out of javax.security?
I strongly prefer longer but self-explanatory package names. I see they easier to find, and once they are imported, I only have to deal with the class name anyway, so a long package name is not a problem at all.
 

Appreciate any and all feedback on this.

Will

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803
Regards,

Guillermo González de Agüero





-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Guillermo González de Agüero
 

Hi,

On Fri, May 26, 2017 at 6:01 PM, Will Hopkins <will.hopkins@...> wrote:
Thanks for the replies.

Arjan -- what do you mean by javax.security is "the package we were given"? In what sense was it given?

With respect to the base package name:
  • The javax.security.enterprise suggestion seems viable (although not all users of the API will be enterprise developers).
  • Arjan's suggestion of javax.security.api is also viable, but it does run into the problem that we're reserving an entire namespace -- all APIs for javax.security -- for ourselves, for all time. My main concern here is not to paint ourselves into a corner that constrains future JSRs.
  • What do people think about javax.security.jsapi, or javax.security.jesapi, to represent Java EE Security API? This is similar to what JACC did with javax.security.jacc.
I personally don't like abbreviations in general. I proposed "javax.security.enterprise" as this is a Java EE spec. "javax.security.ee" could also be used but that is even more coupled to the "enterprise" concept you try to avoid.
With respect to long names, if this has already been discussed and voted on, I'm fine with keeping things as they are. That said, while I also like to see words spelled out (I like Japanese robots suits, but not the name "authmech" ;) ), I think packages with a lot of long words do get unwieldy, and some words are abbreviated often enough that I don't mind them (authn and authz, for example). One place where I think long names do intrude is when viewing javadoc with frames on -- the package list at the left isn't very usable with very long names.

With respect to the package structure, one person replied that they were OK with moving the annotations in with their parent packages, but nobody else commented on that directly. Does that mean people are OK with it, or does the comment "we like long names" imply keeping the annotations separate?
Sorry I missed that part of your mail. I'm +1 for moving annotations to the parent level as the "annotation" element on the package name doesn't really express too much.


Two other comments/questions while I'm at it:
  • It seems like the javax.security.identitystore.credentials package could really come up a level, to javax.security.credentials. If the credentials classes are really general purpose, they can and should be used by lots of code, not just by IdentityStore and consumers of IdentityStore.
+1
  • Similarly, I'm not a fan of having classes in the "root" package -- I'd like to see SecurityContext and related classes moved to javax.security.context. The CallerPrincipal class might warrant a "principals" package, or maybe it could live in "credentials".
I'd leave this as it is. In the same way that putting annotations in a specific "annotation" package doesn't add any value for me, I don't see the benefit of moving a context class to a specific "contexts" package just for one class that will not have more implementations. I'm not sure about the CallerPrincipal case. Do you expect more principals to be provided by the API in the future?
Thoughts? I apologize if I'm revisiting issues that were discussed and decided before, but as I'm looking at this stuff I feel like I need to at least ask the question(s).

Regards,

Will



On 05/26/2017 07:05 AM, Rudy De Busscher wrote:
Arjan,

With my remark, We don't do the *complete* security. I was referring to the fact that we only do it for Java EE, not SE for example.

So we don't do the *complete* security for the JVM was a better comment. So subpackage is then more clear.


best regards
Rudy

On 26 May 2017 at 12:49, Arjan Tijms <arjan.tijms@...> wrote:
Hi,

We indeed don't do the complete security yet, although I think the plan was that we eventually would.

The package we were given was javax.security. We could perhaps move everything to javax.security.api.*? As the current other packages (jaspic and jacc) are an spi. Jaspic even has it in its name: Java Authentication *SPI* for Containers.

We can't change it now anymore, but javax.security.api.* and javax.security.spi.* with the latter containing jaspic and jacc would have been awesome.

Curious what Werner has to say though, I remember him being most vocal about the current package arrangement.

Kind regards,
Arjan Tijms


 



On Fri, May 26, 2017 at 9:51 AM, Rudy De Busscher <rdebusscher@...> wrote:
Hi,

A sub package of javax.security  is maybe a better idea. We don't do the *complete* security.

I agree that we need to avoid abbreviations as they are not as clear as the full name.

Best regards
Rudy


On 26 May 2017 at 08:38, Arjan Tijms <arjan.tijms@...> wrote:
Hi,

I remember there was quite some discussion about the package names in the EG and the current ones are the results of a broad consensus including a vote.

Indeed, the longer non-abbrivated names are probably better. They give the API IMO a more fresh and modern feel. Abbreviating to (very) short names reminds me quite a bit of old AS/400 code. "AuthMech" in particular sounds a bit like a Japanese robot suit :P 

Kind regards,
Arjan Tijms




On Fri, May 26, 2017 at 7:56 AM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,



On Fri, May 26, 2017 at 1:24 AM, Will Hopkins <will.hopkins@...> wrote:
EG:

As part of getting ready to publish our artifacts to maven.java.net, I've been looking at the following naming guidelines: https://javaee.github.io/glassfish/wiki-archive/Maven%20Versioning%20Rules.html.

As well, one of Bill's comments on the EDR spec was that he thought there were too many different packages.

As a result, I wonder if we should rethink the current package structure. In particular, I'm concerned about our use of the "javax.security" package, which also implies an artifact groupId of "javax.security".

This package name is the "root" of all Java EE and Java SE security packages, with the exception of a few Java SE packages at and below "java.security".

Previous JSRs, including JACC and JASPIC, have chosen to use packages under javax.security, but not place any classes in javax.security itself. I think that makes sense, as it doesn't "hog" the namespace. It's true that JSR-375 is meant to be the home for all things Java EE security, but as a practical matter we might not want to reserve java.security for our exclusive use for all time. Moving everything under some common sub-package of java.security seems like a good idea -- although I'll grant that no obvious name for that sub-package springs immediately to mind ...
What about javax.security.enterprise? The word enterprise is already used in CDI (e.g.: javax.enterprise.context)


To Bill's comment about the number of packages, how would people feel about consolidating the "annotation" sub-packages with their parents?  I.e., move the annotations into the javax.security.authentication.mechanism.http and java.security.identitystore packages and eliminate the sub-packages?

Lastly, would a shorter-but-still-specific name for javax.security.authentication.mechanism.http make sense? Perhaps java.security.http.authmech? Or a slightly shorter package name for Identity Store: javax.security.idstore? And should we make a javax.security.context package so that SecurityContext and related classes can move out of javax.security?
I strongly prefer longer but self-explanatory package names. I see they easier to find, and once they are imported, I only have to deal with the class name anyway, so a long package name is not a problem at all.
 

Appreciate any and all feedback on this.

Will

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803
Regards,

Guillermo González de Agüero





-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Regards,

Guillermo González de Agüero


Will Hopkins
 

The root package name discussion has now forked to a different thread, but I want to follow up on the other issues.

On 05/26/2017 01:40 PM, Guillermo González de Agüero wrote:
On Fri, May 26, 2017 at 6:01 PM, Will Hopkins <will.hopkins@...> wrote:

With respect to the package structure, one person replied that they were OK with moving the annotations in with their parent packages, but nobody else commented on that directly. Does that mean people are OK with it, or does the comment "we like long names" imply keeping the annotations separate?
Sorry I missed that part of your mail. I'm +1 for moving annotations to the parent level as the "annotation" element on the package name doesn't really express too much.

OK, two votes for moving "annotation" packages into their parents.


Two other comments/questions while I'm at it:
  • It seems like the javax.security.identitystore.credentials package could really come up a level, to javax.security.credentials. If the credentials classes are really general purpose, they can and should be used by lots of code, not just by IdentityStore and consumers of IdentityStore.
+1

And one for moving "credentials" up.

  • Similarly, I'm not a fan of having classes in the "root" package -- I'd like to see SecurityContext and related classes moved to javax.security.context. The CallerPrincipal class might warrant a "principals" package, or maybe it could live in "credentials".
I'd leave this as it is. In the same way that putting annotations in a specific "annotation" package doesn't add any value for me, I don't see the benefit of moving a context class to a specific "contexts" package just for one class that will not have more implementations. I'm not sure about the CallerPrincipal case. Do you expect more principals to be provided by the API in the future?

Potentially. Separately, we're having a discussion about how to handle caller principals. I would note that there are actually two classes now for SecurityContext, if you include the AuthenticationStatus class. Also it's possible we may end up with more (I plan to start a separate email thread related to SecurityContext).

Where the principal class goes is an interesting question. If we had more than one, it might warrant its own package, or it could go in the credentials package, or stay with context.

I think the main reason I'm not a fan of having classes in the root package is that it doesn't seem like a clean way to encapsulate functionality. A reference to a package name often implies a reference to everything underneath it in the package hierarchy, even if the language doesn't actually treat packages that way. Classes at the root often seem like they're there just because there wasn't anyplace better to put them -- why not a package like, "core", or "common", or "general", or "util", if that's what it really is? And if the classes at the root are just miscellaneous, not really related, then putting them all at the root becomes problematic if we ever want to break things out into multiple jars, since the package might end up split across multiple jars. Granted, that seems like a remote possibility, but not impossible. A package with just one or two classes in it, if that package is clearly defined in terms of a unit of functionality, doesn't bother me.

As far as past practice, JACC made do with a single package. JASPIC has javax.security.auth as its root, but has no classes in that package -- all classes are in sub-packages underneath java.security.auth. That approach just seems cleaner, somehow.

Anyway, that's my thinking. I can live with classes at the root if that's the consensus, but wanted to see what others thought.

Will

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Bill Shannon
 

Will Hopkins wrote on 05/26/17 02:49 PM:

Anyway, that's my thinking. I can live with classes at the root if that's the
consensus, but wanted to see what others thought.
Assuming you own the root package (e.g., javax.security.enterprise),
classes at the root are fine, maybe even good. That's where I would expect to
find most of your classes, except for maybe spi classes and classes specialized
for some use case.


Will Hopkins
 

I agree w.r.t. classes that are truly common, and that strategy works well for something like JACC, which doesn't have a lot of classes, and which is focused on a single, narrow area (authorization).

Having classes at the root here may also be fine, but there are a several discrete functional areas covered by JSR-375, with more likely in follow-on JSRs.

Will

On 05/26/2017 06:22 PM, Bill Shannon wrote:
Will Hopkins wrote on 05/26/17 02:49 PM:
Anyway, that's my thinking. I can live with classes at the root if that's the
consensus, but wanted to see what others thought.
Assuming you own the root package (e.g., javax.security.enterprise),
classes at the root are fine, maybe even good.  That's where I would expect to
find most of your classes, except for maybe spi classes and classes specialized
for some use case.





-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Arjan Tijms
 

Hi,

Well let's at least start with moving everything to javax.security.enterprise, as there seems to be consensus about that.

Kind regards,
Arjan Tijms
 





On Tue, May 30, 2017 at 7:54 PM, Will Hopkins <will.hopkins@...> wrote:
I agree w.r.t. classes that are truly common, and that strategy works well for something like JACC, which doesn't have a lot of classes, and which is focused on a single, narrow area (authorization).

Having classes at the root here may also be fine, but there are a several discrete functional areas covered by JSR-375, with more likely in follow-on JSRs.

Will

On 05/26/2017 06:22 PM, Bill Shannon wrote:
Will Hopkins wrote on 05/26/17 02:49 PM:
Anyway, that's my thinking. I can live with classes at the root if that's the
consensus, but wanted to see what others thought.
Assuming you own the root package (e.g., javax.security.enterprise),
classes at the root are fine, maybe even good.  That's where I would expect to
find most of your classes, except for maybe spi classes and classes specialized
for some use case.





-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Will Hopkins
 

Agreed.

On 05/30/2017 01:57 PM, Arjan Tijms wrote:
Hi,

Well let's at least start with moving everything to javax.security.enterprise, as there seems to be consensus about that.

Kind regards,
Arjan Tijms
 





On Tue, May 30, 2017 at 7:54 PM, Will Hopkins <will.hopkins@...> wrote:
I agree w.r.t. classes that are truly common, and that strategy works well for something like JACC, which doesn't have a lot of classes, and which is focused on a single, narrow area (authorization).

Having classes at the root here may also be fine, but there are a several discrete functional areas covered by JSR-375, with more likely in follow-on JSRs.

Will

On 05/26/2017 06:22 PM, Bill Shannon wrote:
Will Hopkins wrote on 05/26/17 02:49 PM:
Anyway, that's my thinking. I can live with classes at the root if that's the
consensus, but wanted to see what others thought.
Assuming you own the root package (e.g., javax.security.enterprise),
classes at the root are fine, maybe even good.  That's where I would expect to
find most of your classes, except for maybe spi classes and classes specialized
for some use case.





-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Will Hopkins
 

I think we have consensus on moving the "annotations" to the parent packages as well?

On 05/30/2017 03:00 PM, Will Hopkins wrote:
Agreed.

On 05/30/2017 01:57 PM, Arjan Tijms wrote:
Hi,

Well let's at least start with moving everything to javax.security.enterprise, as there seems to be consensus about that.

Kind regards,
Arjan Tijms
 





On Tue, May 30, 2017 at 7:54 PM, Will Hopkins <will.hopkins@...> wrote:
I agree w.r.t. classes that are truly common, and that strategy works well for something like JACC, which doesn't have a lot of classes, and which is focused on a single, narrow area (authorization).

Having classes at the root here may also be fine, but there are a several discrete functional areas covered by JSR-375, with more likely in follow-on JSRs.

Will

On 05/26/2017 06:22 PM, Bill Shannon wrote:
Will Hopkins wrote on 05/26/17 02:49 PM:
Anyway, that's my thinking. I can live with classes at the root if that's the
consensus, but wanted to see what others thought.
Assuming you own the root package (e.g., javax.security.enterprise),
classes at the root are fine, maybe even good.  That's where I would expect to
find most of your classes, except for maybe spi classes and classes specialized
for some use case.





-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803