Re: Use of JDK interanl ASM vs external

It would be nice to ship a byte code generation/manipulation package as part of the JVM since this would encourage many new types of libraries and applications. It would also be nice if the JVM didn't grow much! Therefore in the ideal world ASM would be publicly exposed and just the extra patching

Re: Use of JDK interanl ASM vs external

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,

Re: Use of JDK interanl ASM vs external

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 so

Re: Use of JDK interanl ASM vs external

Thx Attila, it was more a philosophical rant anyway. I have heard rumors of your dynamic plans and look forward to hearing about the details. Perhaps you would consider a workshop like talk at this years jvm summit regards mark ___ mlvm-dev mailing l

Re: Use of JDK interanl ASM vs external

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 compi

Re: Use of JDK interanl ASM vs external

On 02/18/2015 01:34 PM, Mark Roos wrote: 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

Re: Use of JDK interanl ASM vs external

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,

Re: Use of JDK interanl ASM vs external

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. One

Re: Use of JDK interanl ASM vs external

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 F

Re: Use of JDK interanl ASM vs external

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 no

Re: Use of JDK interanl ASM vs external

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 i

Re: Use of JDK interanl ASM vs external

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

Re: Use of JDK interanl ASM vs external

So that it does not mess up with the different version of the library that the user is trying to use. On Wed, Feb 18, 2015 at 2:10 PM, 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?

Re: Use of JDK interanl ASM vs external

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 wrote: > > On 02/17/2015 08:30 PM, Mark Roos wrote

Re: Use of JDK interanl ASM vs external

Thx Sent from my iPhone > On Feb 17, 2015, at 11:59 AM, Remi Forax wrote: > > >> On 02/17/2015 08:30 PM, Mark Roos wrote: >> I see that jdk8 now includes a copy of ASM (jdk.internal.org.objectweb.asm). >> >> Is it recommended to use that instance vs suppling a copy with my >> application?

Re: Use of JDK interanl ASM vs external

On 02/17/2015 08:30 PM, Mark Roos wrote: I see that jdk8 now includes a copy of ASM (jdk.internal.org.objectweb.asm). Is it recommended to use that instance vs suppling a copy with my application? thanks mark Hi Mark, These classes are not the one you are looking for :) As the 'internal

Re: Use of JDK interanl ASM vs external

Internal code is internal as the name says, so you should supply and use your own copy. -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile:+491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hambu