> On Mar 14, 2016, at 12:27 AM, David M. Lloyd wrote:
>
> On 3/12/16 9:57 AM, Alan Bateman wrote:
>>
>> On 11/03/2016 15:30, David M. Lloyd wrote:
>>>
>>> What are the limiting factors? In my analysis the only problem that
>>> seemed close to insurmountable was the special natives that are us
On 14/03/2016 07:27, David M. Lloyd wrote:
So really there are multiple parts to be able to move modules out of
the bootstrap class loader:
1. Relax the spec so that other class loaders (preferably only
trusted/blessed class loaders) can define java.* classes
This is part of the getPlatfor
On 3/12/16 9:57 AM, Alan Bateman wrote:
On 11/03/2016 15:30, David M. Lloyd wrote:
What are the limiting factors? In my analysis the only problem that
seemed close to insurmountable was the special natives that are used
in the JDK but these only seem to be used from java.base. Does it all
bo
On 11/03/2016 21:31, Alex Buckley wrote:
A type in the java.sql module (javax.sql.XAConnection) returns a
javax.transaction.xa.* type. Therefore, the java.sql module would have
to depend on the tiny new module containing the javax.transaction.xa
package. The java.sql module is mapped to the
On 11/03/2016 15:30, David M. Lloyd wrote:
What are the limiting factors? In my analysis the only problem that
seemed close to insurmountable was the special natives that are used
in the JDK but these only seem to be used from java.base. Does it all
boil down to getClassLoader()==null secu
> On 11 Mar 2016, at 21:56, Alex Buckley wrote:
>
> On 3/11/2016 2:04 AM, Neil Bartlett wrote:
>>> On 11 Mar 2016, at 08:50, Alan Bateman
>>> wrote:
>>> The transaction API is one of a small number of APIs shared between
>>> Java SE and EE. The complete set is non-aggregator modules that
>>> ja
On 3/10/2016 6:33 PM, Stephen Felts wrote:
I'm aware of classes in our application server (not javax) that are
unused when running with our own JVM and used when running with
another JVM. In that case, the packages are duplicate of classes in
the JDK. I would not want that usage to generate a fa
On 3/11/2016 2:04 AM, Neil Bartlett wrote:
On 11 Mar 2016, at 08:50, Alan Bateman
wrote:
The transaction API is one of a small number of APIs shared between
Java SE and EE. The complete set is non-aggregator modules that
java.se.ee requires. In the case of the transaction API then Java
SE define
On 3/11/2016 7:31 AM, David M. Lloyd wrote:
On 03/11/2016 09:23 AM, Alan Bateman wrote:
On 11/03/2016 14:52, David M. Lloyd wrote:
What about javax.transaction.xa? Ideally we won't just throw that
into some unnamed module right?
With it being a part of java.sql though, it's going to be pret
On 03/11/2016 09:23 AM, Alan Bateman wrote:
On 11/03/2016 14:52, David M. Lloyd wrote:
What about javax.transaction.xa? Ideally we won't just throw that
into some unnamed module right?
With it being a part of java.sql though, it's going to be pretty tough
to separate out. Can it not at leas
On 03/11/2016 09:23 AM, Alan Bateman wrote:
On 11/03/2016 14:52, David M. Lloyd wrote:
What about javax.transaction.xa? Ideally we won't just throw that
into some unnamed module right?
With it being a part of java.sql though, it's going to be pretty tough
to separate out. Can it not at leas
On 11/03/2016 14:52, David M. Lloyd wrote:
What about javax.transaction.xa? Ideally we won't just throw that
into some unnamed module right?
With it being a part of java.sql though, it's going to be pretty tough
to separate out. Can it not at least be its own module which can be
upgraded
On 03/11/2016 04:42 AM, Alan Bateman wrote:
On 11/03/2016 10:04, Neil Bartlett wrote:
:
Whatever the motivation, I referred to this package as “broken”
because it has caused a great many problems for OSGi users.
Applications that import the javax.transaction package may encounter
NoClassDefFou
-JDK8 and/or I know they won’t be re-released for a couple of years.
From: Paul Benedict [mailto:pbened...@apache.org]
Sent: Thursday, March 10, 2016 11:43 PM
To: Stephen Felts
Cc: Alex Buckley; ML OpenJDK Jigsaw Developers
Subject: Re: Unnamed module and duplicate package
On Thu, Mar 10
On 11/03/2016 10:04, Neil Bartlett wrote:
:
Whatever the motivation, I referred to this package as “broken” because it has
caused a great many problems for OSGi users. Applications that import the
javax.transaction package may encounter NoClassDefFoundError due to the missing
types if they w
Hello Alan,
> On 11 Mar 2016, at 08:50, Alan Bateman wrote:
>
>
>
> On 10/03/2016 23:58, Neil Bartlett wrote:
>> Paul,
>>
>> This sounds like you are suggesting a backwards-incompatible change to the
>> behaviour of the application classpath.
>>
>> For example, many apps include on their cl
On 11/03/2016 04:02, Stephen Felts wrote:
:
The Java EE folks are aware of the problems with both the transaction and
annotation jars. One of the outstanding issues I have is to get official
copies of these module jar files. Also, the current approach requires two
associated jar file
On 10/03/2016 23:58, Neil Bartlett wrote:
Paul,
This sounds like you are suggesting a backwards-incompatible change to the
behaviour of the application classpath.
For example, many apps include on their classpath a library containing
javax.transaction.xa, since the version of this package p
ses put you in a split package
situation?
Cheers,
Paul
>
>
> *From:* Paul Benedict [mailto:pbened...@apache.org]
> *Sent:* Thursday, March 10, 2016 10:16 PM
> *To:* Stephen Felts
> *Cc:* Alex Buckley; ML OpenJDK Jigsaw Developers
>
> *Subject:* Re: Unnamed module and dupl
Benedict [mailto:pbened...@apache.org]
Sent: Thursday, March 10, 2016 10:16 PM
To: Stephen Felts
Cc: Alex Buckley; ML OpenJDK Jigsaw Developers
Subject: Re: Unnamed module and duplicate package
Stephen, regarding your first paragraph, I would like some more detail. Are you
running your application
ion.jar with Jigsaw,
> I'm also running with an upgradeable module for
> javax.annotation-api-1.2.jar.
>
>
> -Original Message-
> From: Alex Buckley
> Sent: Thursday, March 10, 2016 9:15 PM
> To: jigsaw-dev@openjdk.java.net
> Subject: Re: Unnamed module a
ubject: Re: Unnamed module and duplicate package
The subtlety is that the Endorsed Standards Override Mechanism interpreted
"alternative implementations of the javax.* hierarchy" as "wholesale
replacements of entire javax.* packages placed in the location specified by
java.end
The subtlety is that the Endorsed Standards Override Mechanism
interpreted "alternative implementations of the javax.* hierarchy" as
"wholesale replacements of entire javax.* packages placed in the
location specified by java.endorsed.dirs". It was never permissible to
simply throw a handful of
Paul,
This sounds like you are suggesting a backwards-incompatible change to the
behaviour of the application classpath.
For example, many apps include on their classpath a library containing
javax.transaction.xa, since the version of this package provided by the JDK is
broken (omits several t
Yes -- and also the javax.** APIs in the modules directly required by
java.se.ee (see http://openjdk.java.net/jeps/200).
Alex
On 3/10/2016 1:41 PM, David M. Lloyd wrote:
One case to consider is javax.transaction.xa, which is part of the JDK
and also in the JTA API along with javax.transaction.
This would entail the module system enumerating every JAR on the
classpath after creating the module graph, in order to detect whether
the unnamed module splits any package exported by any named module.
There's no reason to special case JDK modules -- augmenting a user
module would lead to erro
-dev@openjdk.java.net
Subject: Re: Unnamed module and duplicate package
Alex,
For the sake of usability, however, it would be nice if the JDK verified that
jars do not contain any exported JDK packages. This would be an RFE. I
understand that in order to avoid split packages between modules and
One case to consider is javax.transaction.xa, which is part of the JDK
and also in the JTA API along with javax.transaction.
On 03/09/2016 05:13 PM, Alex Buckley wrote:
Paul, thank you for asking. The module system's treatment of the unnamed
module vis-a-vis named modules is probably the bigges
My apologies for omitting some key qualifiers in my explanation. Read
everything as a proposal to prohibit classpath jars from silently splitting
whatever packages the JDK exports. -- Thanks
On Thu, Mar 10, 2016 at 3:25 PM, Paul Benedict wrote:
> Alex,
>
> For the sake of usability, however, it
Alex,
For the sake of usability, however, it would be nice if the JDK verified
that jars do not contain any exported JDK packages. This would be an RFE. I
understand that in order to avoid split packages between modules and
classpath, the module version takes precedent. For developer vs. developer
Yes, we can keep tightening the split package scenario to ensure safety
without scanning the classpath. First, you have to promise that the JAR
on the classpath never has classes that overlap with a module in the
system image. Second, the named module of interest in the system image
can't be a
I see xml-apis.jar (2.0.2) contains:
- a javax.xml.parser package, which includes a FactoryFinder class
that's not in Java SE, and
- a javax.xml.transform package hierarchy, whose types at first glance
look identical to those in Java SE except for yet another FactoryFinder
class in javax.xml
Alex, there are JARs that contain javax packages. Anyone in the web
development community knows how many people have included xml-apis in their
WEB-INF :-) only to find out it wasn't loaded or it took precedent over the
JDK versions.
Has Jigsaw introduced any restrictions here on this front? Hones
On 10/03/2016 12:39, David M. Lloyd wrote:
I presume this wouldn't happen if the packages were sealed though,
whether in Java 8 or earlier or under the unnamed module in Java 9.
Right?
That's right although I don't think sealed packages have been popular.
With named modules then the packag
I presume this wouldn't happen if the packages were sealed though,
whether in Java 8 or earlier or under the unnamed module in Java 9. Right?
On 03/09/2016 03:17 PM, Paul Benedict wrote:
But isn't what your proposing a security issue? Let's say my package A is
in the unnamed module and your pa
This should, however, be completely safe in the case when one of those modules
is part of the JDK itself, isn’t it? It is not clear to me how you could ever
get a circular dependency in that case.
In fact, this should be true of any library as well - the only scenario that I
can think of where
Yes, a ClassCastException could only arise when (sticking with Paul's
scenario) the same class exists in both the named module and the unnamed
module.
It would be "safe" for the module system to allow a package that is
split perfectly between modules: no overlap of classes and no cyclic
refer
Doesn’t this kind of error only happen when a second module exports the same
_class_? What is the problem with another class being defined in the same
package, given that package B isn’t going to access that new class at all?
- Russ
> On Mar 9, 2016, at 4:37 PM, Alex Buckley wrote:
>
> Presum
Paul, thank you for asking. The module system's treatment of the unnamed
module vis-a-vis named modules is probably the biggest factor affecting
usability of the module system. This is true almost by definition
because at JDK 9 GA the only named modules in the world will be the
JDK's while ever
Thank you Alex. Since it's roughly the same as JDK 8, then it's also not
worse. I defer to your explanation on that point.
Cheers,
Paul
On Wed, Mar 9, 2016 at 3:37 PM, Alex Buckley
wrote:
> Presumably you would count the equivalent scenario on JDK 8 -- my package
> A is in Alex.jar on the class
Presumably you would count the equivalent scenario on JDK 8 -- my
package A is in Alex.jar on the classpath and your package A is in
Paul.jar on the classpath -- as a security issue too, because some of my
classes may substitute for yours (or some of yours for mine, depending
on how the classpa
But isn't what your proposing a security issue? Let's say my package A is
in the unnamed module and your package A is in a named module. You
basically took over my code; your classes will be substituted for mine.
Cheers,
Paul
On Wed, Mar 9, 2016 at 2:38 PM, Alex Buckley
wrote:
> On 3/9/2016 10:
On 3/9/2016 10:36 AM, Paul Benedict wrote:
From the doc:
"If a package is defined in both a named module and the unnamed module then
the package in the unnamed module is ignored. This preserves reliable
configuration even in the face of the chaos of the class path, ensuring
that every module sti
43 matches
Mail list logo
