OK - I'm going to bite.
Why are we doing this? If we're shipping a general purpose bytecode
manipulation library, then why is it private?
Surely this should become an official, supported public API?
On Tue, Feb 17, 2015 at 7:58 PM, Remi Forax fo...@univ-mlv.fr wrote:
On 02/17/2015 08:30 PM,
On 02/18/2015 11:26 AM, Debasish Ray Chawdhuri wrote:
So that it does not mess up with the different version of the library
that the user is trying to use.
It depends what you mean by mess up,
if you mean that your IDE is currently (jdk8) able to see different
versions of ASM, this is fixed
On 02/18/2015 09:40 AM, Ben Evans wrote:
OK - I'm going to bite.
Why are we doing this? If we're shipping a general purpose bytecode
manipulation library, then why is it private?
Surely this should become an official, supported public API?
Currently, the version of ASM shipped with the JDK
A statement from Remi defined the reason for my original question very
well.
the ASM packages are only
re-exported [1] for nashorn
Like the Nashorn folks I am building a language using the jvm for which it
would
be helpful if there was a standard api for bytecode writing.
With Nashorn, we're language implementers who happen to have their runtime
shipped as part of the JRE. For better or worse, we need to have our
dependencies shipped with it, hence a privately bundled ASM. We have a somewhat
unique deployment model, if you wish. It is still OW2 Consortium's ASM,
Of course this isolation does breaks down if multiple versions of the
same library, loaded into the runtime, read/write external files such as
config/property/cache/ files. Then there is the System Property
instance or is this something also addressed in Java 9?
On 18/02/2015 12:29, Remi
On 18/02/2015 11:21, Remi Forax wrote:
Currently, the version of ASM shipped with the JDK is a customized
version compiled directly from the trunk and lightly patched to bubble
up some internal methods that are not part of the public API.
In jdk8 world, it's an internal API and you should
On 02/18/2015 02:45 PM, Per Bothner wrote:
Kawa is optimized for static compilation and static optimization,
and does not use invokedynamic so far.
To clarify: Kawa does have a REPL and eval. It's just that the REPL
and eval first compile the expression to bytecode before running it.
The
On 02/18/2015 11:30 PM, Attila Szegedi wrote:
With Nashorn, we're language implementers who happen to have their
runtime shipped as part of the JRE. For better or worse, we need to
have our dependencies shipped with it, hence a privately bundled ASM.
We have a somewhat unique deployment model,
On 02/18/2015 01:15 PM, William Louth (JINSPIRED.COM) wrote:
Of course this isolation does breaks down if multiple versions of the
same library, loaded into the runtime, read/write external files such
as config/property/cache/ files. Then there is the System Property
instance or is this
10 matches
Mail list logo
