Skip to main content

Including JDNC in the JRE

2 replies [Last post]
rameshgupta
Offline
Joined: 2004-06-04

I am splitting the topic "Including JDNC in the JRE" (http://www.javadesktop.org/forums/thread.jspa?forumID=53&threadID=3446&m...) from the topic "Is anyone else bothered by the JCA" (http://www.javadesktop.org/forums/thread.jspa?threadID=3446&tstart=0), because the discussion has turned from legal to technical. I hope this doesn't mess up the thread(s) :-)

Ramesh

Original messages follow:

==============================================

Adrian Sutton -- Including JDNC in the JRE
Posted: Jul 22, 2004 4:09 AM

I wanted to pick up on a comment made earlier by Joshua about including
JDNC in the JRE as it hits upon some concerns that I have.

> I don't think this likely since it's quite easy to version the APIs
> and say that version X will be in JRE y, but you can use a more recent
> version if you want to. Remember when the XML APIs moved into the
> JRE?

The problem with this is that when JDNC is moved into the JRE it winds
up on the boot classpath and becomes difficult or impossible to
override. This caused a lot of problems for the Xalan project when it
was included in the JRE because most people don't understand the
extension override mechanism and even when they do, it makes
application deployment more difficult. Worse still, for applets
there's no way to override the library.

I was very pleased to see that the version of Xerces shipped with JRE
5.0 was moved into a different namespace so that it's possible to
easily switch between the JRE version and a different version, however
that's not really an option with JDNC because it has public APIs that
would be broken.

I'm not really sure I know what the solution to this problem is but
wanted to flag the issue early so that people can start thinking about
it. Some possible options I see are:

1. Don't include JDNC in the JRE.
Pros: Really simple.
Cons: Every JDNC app has to ship a copy of JDNC
Reduces exposure of JDNC
Leaves Swing as-is instead of benefiting from the JDNC improvements.

2. Change the JDNC package when including it in the JRE.
Pros: Avoids problem while still allowing Swing to benefit from
improvements.
Cons: Existing apps will still have to ship the JDNC jar file or
change all their import statements. The upside of this is that
existing apps won't break as they'll be shipping the jar anyway.

3. Make it really simple to change JDNC's package so developers can put
the version they want in their own package and thus avoid the version
in the JRE.
Pros: Doesn't affect users who just want a version of JDNC or are
happy with the JRE
Allows Swing to benefit from the improvements.
Cons: Difficult to achieve, particularly when reflection is used.
Can make general development more difficult.

4. Do nothing and let people deal with it themselves.
Pros: Simplest for the JDNC team.
Cons: Annoying for users who have to deal with the problem.

I know the popular opinion is that WebStart is the solution to
everything and people shouldn't use applets at all but for a number of
things applets are the only solution so it would be good to at least
consider how to deal with the issues even if the JDNC team decides to
take option 4.

Personally, my favorite out of those is option 3, most likely
implemented by a fairly simple find/replace on the package name across
files. If that were supported by being able to perform the replace,
build and run the tests easily (and hopefully automatically every so
often) then it should be pretty simple to manage.

Any thoughts?

Regards,

Adrian Sutton.

==============================================

rameshgupta -- Re: Including JDNC in the JRE
Posted: Jul 22, 2004 10:53 AM

> I wanted to pick up on a comment made earlier by
> Joshua about including JDNC in the JRE as it hits upon
> some concerns that I have.
>
[snip]
>
> The problem .. is that when JDNC is moved into the JRE it winds
> up on the boot classpath and becomes difficult or
> impossible to override. This caused a lot of problems for the
> Xalan project when it was included in the JRE because most people don't
> understand the extension override mechanism and even when they do,
> it makes application deployment more difficult. Worse still,
> for applets there's no way to override the library.
>
[snip]
> I'm not really sure I know what the solution to this
> problem is but ... Some possible options I see are:
>
> 1. Don't include JDNC in the JRE...
>
> 2. Change the JDNC package when including it in the JRE...
>
> 3. Make it really simple to change JDNC's package so developers can
> put the version they want in their own package and thus
> avoid the version in the JRE...
>
> 4. Do nothing and let people deal with it themselves...
>
> Personally, my favorite out of those is option 3, most likely
> implemented by a fairly simple find/replace on the package name
> across files. If that were supported by being able to
> perform the replace, build and run the tests easily (and hopefully
> automatically every so often) then it should be pretty simple to manage.
>
> Any thoughts?
>
> Regards,
>
> Adrian Sutton.

These are well thought-out options, though I like 4 the least My preference (in order): 2, 3, 1, 4

Ramesh

==============================================
dhall -- Re: Including JDNC in the JRE
Posted: Jul 22, 2004 2:10 PM

Another question for Sun -- and this shows that I've been reading _way_ too much Groklaw. Is the JCA specific enough to qualify as a copyright assignment for specific files?

==============================================
zander -- Re: Including JDNC in the JRE
Posted: Jul 23, 2004 1:44 AM

>
> I'm not really sure I know what the solution to this
> problem is but
> wanted to flag the issue early so that people can
> start thinking about
> it. Some possible options I see are:
[snipped]

5.
provide a regularly-updates version of the project on a public Sun server. Fix java-webstart to allow it to use 1 global jar for all projects (possibly with versioning) and not require each project that uses it to ship it separately.

==============================================

James Todd -- Re: Including JDNC in the JRE
Posted: Jul 23, 2004 1:48 AM

What is the motivation for "1 global jar" given that WebStart/JNLP can
"chain" JNLP files across projects? We do this in JXTA all the time:

http://weblogs.java.net/pub/wlg/790

- james

jdnc-interest@javadesktop.org wrote:
>>I'm not really sure I know what the solution to this
>>problem is but
>>wanted to flag the issue early so that people can
>>start thinking about
>>it. Some possible options I see are:
>
> [snipped]
>
> 5.
> provide a regularly-updates version of the project on a public Sun server. Fix java-webstart to allow it to use 1 global jar for all projects (possibly with versioning) and not require each project that uses it to ship it separately.
> ---
> [Message sent by forum member 'zander' (Thomas Zander)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=18790?

==============================================

Patrick Wright -- Re: Including JDNC in the JRE
Posted: Jul 23, 2004 2:27 AM

Hi

I am glad people are addressing this question, just wanted to throw in a
couple of bits.

1) There needs to be a distinction between
a) 'useful and approved' libraries
b) 'official extensions'
c) 'core'

in the Java environment. Many Apache libraries would fit in category a),
that is, they are widely used, production quality, look good, but are not
officially part of the Java distribution. Java 3D would be in category b),
that is, a library that is a standard issued by Sun, but which doesn't
ship to people that don't need it. c) would include all libraries that Sun
considers part of a standard Java environment, and which defines the a
compatibile version of Java.

My suggestion is that JNDC is a category a) or b), but certainly not a c).
The question is then how to make category a) and b) easy to install,
distribute, etc.

There are complaints that too many things are winding up in category c),
and that the core is too large--both to understand and as a download. We
are probably a few years away from having networks so reliable that we can
always download on demand, so it makes sense to have more stuff in one
download when possible.

But what we appear to need, is the ability to have a central repository of
versioned packages, a way to install and uninstall them. The basics would
include
a) Standard means to identify packages available for distribution
b) Package signing
c) Package checksums
d) Standard-unique naming and versioning per package

A suggested approach
a) Distribution occurs through websites using JNLP to declare official
package name and version; should support signing and MD5 or other checks.

b) Libraries are loaded into a central Java package repository on the
user's machine. The repository is divided by package, and within package
by version, possibly with distributor at the top, so
/javadepo/apache.org/commons/1.5.1/jar/commons-1.5.1.jar

c) The repository can be loaded or unloaded by any approved process,
including WebStart, a CLI, or a Swing GUI. You might receive components on
a CD, through a downloaded Jar, etc. Checksums should ensure that the same
jar is never re-loaded into the repository.

d) When webstarting, dependent libraries can be downloaded into the
repository, in this case, JDNC would be an example. In case the standard
source for the file is unavailable, the target library could include a
mirror of the file, as long as checksum is respected.

Ideally there would be a way to see which libraries are not in use and
remove them, but that would be a whole nother level of control.

The Apache tool Maven does something like this. I am not pushing Maven (I
have nothing to do with them), but I have to say, I have a *lot* of
3rd-party (and Sun non-standard) libraries on my machine, and it is a rats
nest in there.

I think that .Net has some approach for this, and I haven't heard of a JSR
related to it.

As far as JDNC, I am not saying all of the above has to be in place
immediately, but perhaps that we start moving towards something like that.

I realize some of the proposal appears in related forms--there are JNLP
caches and applet caches, the JRE extension mechanism, etc.

Patrick

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rameshgupta
Offline
Joined: 2004-06-04

> zander -- Re: Including JDNC in the JRE
> Posted: Jul 23, 2004 1:44 AM
>
> 5.
> provide a regularly-updates version of the project on
> a public Sun server. Fix java-webstart to allow it to
> use 1 global jar for all projects (possibly with
> versioning) and not require each project that uses it
> to ship it separately.
>
> ==============================================
>
>> James Todd -- Re: Including JDNC in the JRE
>> Posted: Jul 23, 2004 1:48 AM
>>
>> What is the motivation for "1 global jar" given that
>> WebStart/JNLP can "chain" JNLP files across projects?
>> We do this in JXTA all the time:

Hi James,

We do have separate jar files that are referenced by a JNLP library that is chained to the application JNLP file, just like you suggest.

But we found that while this was fine for Web Start, referring to so many jar files was a pain for applet developers. It was to simplify their work, that we decided to consolidate the jar files.

Both, the consolidated and the individual jar files are available from the build process.

Ramesh

James Todd

With JXTA, we have JNLP files that refer to other JNLP files that in turn include
jar resources. It makes sense in JXTA given many apps are both standalone and also
components of higher-order apps, truly.

As such, each standalone app has it's own JNLP specifying it's constituents yet
other JNLP files can refer to the very same JNLP, being sheilded from the internal
resource details, namely jars.

hth,

- james

jdnc-interest@javadesktop.org wrote:
>>zander -- Re: Including JDNC in the JRE
>>Posted: Jul 23, 2004 1:44 AM
>>
>>5.
>>provide a regularly-updates version of the project on
>>a public Sun server. Fix java-webstart to allow it to
>>use 1 global jar for all projects (possibly with
>>versioning) and not require each project that uses it
>>to ship it separately.
>>
>>==============================================
>>
>>
>>>James Todd -- Re: Including JDNC in the JRE
>>>Posted: Jul 23, 2004 1:48 AM
>>>
>>>What is the motivation for "1 global jar" given that
>>>WebStart/JNLP can "chain" JNLP files across projects?
>>>We do this in JXTA all the time:
>
>
> Hi James,
>
> We do have separate jar files that are referenced by a JNLP library that is chained to the application JNLP file, just like you suggest.
>
> But we found that while this was fine for Web Start, referring to so many jar files was a pain for applet developers. It was to simplify their work, that we decided to consolidate the jar files.
>
> Both, the consolidated and the individual jar files are available from the build process.
>
> Ramesh
> ---
> [Message sent by forum member 'rameshgupta' (Ramesh Gupta)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=18818&#18818
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>

--
Java == platform independence
XML == application independence
JXTA == network independence

Secure End-to-End Computing

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net