You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2006/06/08 17:42:01 UTC
Conflicts and JDT
Hi,
To avoid any possible conflicts, I see no choice but to package rename
the JDT subset that is used by Jasper.
Any other ideas ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Conflicts and JDT
Posted by Costin Manolache <co...@gmail.com>.
I got it, so we have to use jdt.
What about using a separate classloader to load JDT ( child or sibling of
server classloader for example ),
so any jdt in webapps won't be visible ?
Well - if you are comfortable maintaining JDT changes, I don't have a
problem, it just doesn't feel
right. For small things that we also change ( like modeler and maybe logger
), it is ok, but jdt seems like
a large thing.
Costin
On 6/8/06, Yoav Shapira <yo...@apache.org> wrote:
>
> Hi,
>
>
> > My understanding was that the main reason is that it's better / faster /
> > less leaky than
> > javac - is this correct ? Is it still true for JDK1.5 ? Could we just
> use
> > javac as default - and
> > in case of 'conflicts' ?
>
> There's also another reason: if we use JDT then we don't require users
> to have the complete JDK, only a JRE. This is a big deal (perhaps
> even more important than the technical / performance benefits) from a
> licensing perspective, especially for people who repackage /
> redistribute Tomcat as part of their products.
>
> Yoav
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Conflicts and JDT
Posted by Shankar Unni <sh...@netscape.net>.
Yoav Shapira wrote:
> There's also another reason: if we use JDT then we don't require users
> to have the complete JDK, only a JRE. This is a big deal (perhaps
> even more important than the technical / performance benefits) from a
> licensing perspective, especially for people who repackage /
> redistribute Tomcat as part of their products.
<nitpick>
The Sun JDK license terms explicitly state that "tools.jar" is
redistributable along with the JRE. So technically, that shouldn't be a
reason for including the JDT.
On the other hand, I can see (a) convenience (using unmodified JRE
distributions with Tomcat), (b) performance (JDT's compiler is
supposedly faster), etc., as good reasons for including it.
From java/jre/README.txt:
...
Redistribution of Java2 SDK Files.
The limited set of files from the SDK listed below may be included in
vendor redistributions of the Java 2 Runtime Environment. All paths
are relative to the top-level directory of the SDK.
...
- The javac bytecode compiler, consisting of the following files:
bin/javac [Solaris(TM) Operating Environment
and Linux]
bin/sparcv9/javac [Solaris Operating Environment
(SPARC(TM) Platform Edition)]
bin/javac.exe [Microsoft Windows]
lib/tools.jar [All platforms]
...
</nitpick>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Conflicts and JDT
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
> My understanding was that the main reason is that it's better / faster /
> less leaky than
> javac - is this correct ? Is it still true for JDK1.5 ? Could we just use
> javac as default - and
> in case of 'conflicts' ?
There's also another reason: if we use JDT then we don't require users
to have the complete JDK, only a JRE. This is a big deal (perhaps
even more important than the technical / performance benefits) from a
licensing perspective, especially for people who repackage /
redistribute Tomcat as part of their products.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Conflicts and JDT
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Could you summarise what conflicts and why do we have to use JDT ?
As usual: version conflicts with people who would use JDT in their webapps.
> My understanding was that the main reason is that it's better / faster /
> less leaky than
> javac - is this correct ? Is it still true for JDK1.5 ? Could we just use
> javac as default - and
> in case of 'conflicts' ?
More importantly, dependencies are read using a classloader, which is
much faster.
> Package rename kind of implies additional maintainance of a non-trivial
> piece of code, merging, etc.
>
> Of course - having it as a separate module ( and download ) might be the
> best solution IMO.
No, using it as a default is the best option by far (otherwise, people
need the JDK, etc), as was done with 5.5. javac remains usable at any time.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Conflicts and JDT
Posted by Costin Manolache <co...@gmail.com>.
Could you summarise what conflicts and why do we have to use JDT ?
My understanding was that the main reason is that it's better / faster /
less leaky than
javac - is this correct ? Is it still true for JDK1.5 ? Could we just use
javac as default - and
in case of 'conflicts' ?
Package rename kind of implies additional maintainance of a non-trivial
piece of code, merging, etc.
Of course - having it as a separate module ( and download ) might be the
best solution IMO.
Costin
On 6/8/06, Remy Maucherat <re...@apache.org> wrote:
>
> Hi,
>
> To avoid any possible conflicts, I see no choice but to package rename
> the JDT subset that is used by Jasper.
>
> Any other ideas ?
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>