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 /
redistr
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 sma
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
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
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 kin
