Hi Stuart, Thanks for your reply. Indeed, the class doesn't really fit into the modern world as it is now, for its original intended purpose. So, for its original intent of configuring and controlling the JIT compiler(s), I'm more than happy about the deprecation.
There are a couple of scenarios that I know of that make uses of the java.lang.Compiler class as a generic entry point into the VM, not related to the original intent at all. Let me think a bit about how to phrase those scenarios correctly and update in a follow-up reply. Thanks, Kris On Wed, Sep 7, 2016 at 4:42 PM, Stuart Marks <stuart.ma...@oracle.com> wrote: > Hi Kris, > > Well, there's not much background. We did contact IBM in regard to the > mentions of java.lang.Compiler from their product pages, and they were OK > with deprecating the API for removal. I can't speak to what impact this > might have on IBM's products. > > I don't know much about JEP 165 [1] but it does appear to be able to > update compiler directives at runtime. It doesn't seem to match the > semantics of java.lang.Compiler. On the other hand, j.l.Compiler was > introduced in the JDK 1.0 time frame, before production Java JIT compilers > were delivered, so it's unlikely that its semantics match the needs of a > modern JIT implementation. > > I really don't think anything is being lost by the deprecation and > eventual removal of java.lang.Compiler. If anything, it's an improvement, > as Rémi noted, since people will no longer confuse it with an API for > invoking javac. > > s'marks > > [1] http://openjdk.java.net/jeps/165 > > On 9/7/16 3:45 PM, Krystal Mok wrote: > > Hi Stuart, > > I see that on the JBS page, your most recent comment says it's been > decided that for JDK9 it's okay to deprecate and forRemoval=true, while > also mentioning the uses of this class in IBM's implementation. > > Does that mean IBM has agreed on the deprecation of this class? I thought > J9 had features that allowed Java applications to do fine-grained control > over the JIT compiler at runtime, e.g. force compilation of specified > methods *at some certain point* in the program. > What JEP 165 is proposing can only statically configure JIT behaviors for > HotSpot. The same approach doesn't seem to cover what J9 used to support. > > Could you please share more background on the discussions that led to the > decision? > > Thanks, > Kris > > On Wed, Sep 7, 2016 at 2:50 PM, Stuart Marks <stuart.ma...@oracle.com> > wrote: > >> Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler >> >> :-) >> >> >> On 9/7/16 2:44 PM, Remi Forax wrote: >> >>> Yes, i like this patch :) >>> >>> Aleksey, It's worst than what you think because for a lot of people >>> Compiler == java compiler and not JIT compiler so they try to compile a >>> .java file with the method compileClasses(String). >>> >>> I'm glad this class will disappear soon. >>> >>> Rémi >>> >>> ----- Mail original ----- >>> >>>> De: "Aleksey Shipilev" <aship...@redhat.com> >>>> À: "Stuart Marks" <stuart.ma...@oracle.com>, "core-libs-dev" < >>>> core-libs-dev@openjdk.java.net> >>>> Envoyé: Mercredi 7 Septembre 2016 23:34:02 >>>> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler >>>> >>> >>> On 09/07/2016 11:52 PM, Stuart Marks wrote: >>>> >>>>> Please review this small patch to deprecate java.lang.Compiler for >>>>> removal. >>>>> >>>> >>>> Yes, +1. >>>> This class is very confusing to have these days. >>>> >>>> -Aleksey >>>> >>> > >
