<AWT Dev> Fwd: RFR: make life easier for general java plugin

[Jiri Vanek]

On 11/26/2014 07:21 PM, Phil Race wrote:
> What is the goal here ? Is it to allow icedtea-web to load an applet into
> a JRE other than icedtea ?
> If not and its all one bundle, you can patch the module system to
> allow whatever access you need.

The goal is to have icedtea-web working with any jdk.
Right now we are working with all openjdk6-9, similarly with all icedteas and also with all 
available oracle jdks. We have also limited support for IBM jdks (again, 6-7(8not tested)) 
(currently all unsigned, and few signed ones are running with ibm's - the only issue is shattered 
classpath)
>
> So what does icedtea-web need from such a standard interface ?

The patch allowing this functionality is this one:

http://icedtea.classpath.org/hg/icedtea-web/rev/c6591d36d68a (namely 
http://icedtea.classpath.org/hg/icedtea-web/rev/c6591d36d68a#l6.2 class)

This patch should be base for any public interface. You can see it is using reflection to get some 
necessary fields, so I'm afraid it may be unusable in jdk9 (and modules - or will there by any 
workaround to run jdk9+ as non modular one?) . I was trying to implement general applet provider 
(yuo can see that interface is moreover quite simple -

URL getDocumentURL()
void setApplet(Applet iapplet)
run()
superRunLoader() //ok this and run are quite troubling)
URL getBaseURL()


But I got stuck on :
+public abstract class AppletViewerPanelAccess extends AppletViewerPanel {

To avoid extending, I needed some generall acces like getInstabce or whatever... And I did not find 
how to do this...


If we say that modules are no blocker for itw, than  making fields/methods from abve list package 
private, is more then enough.

Thank you for your time spent on this,
  best regards,
    J.

>
> -phil.
>
> On 11/26/2014 9:41 AM, Jiri Vanek wrote:
>> ping?
>>
>> On 10/31/2014 03:30 PM, Mario Torre wrote:
>>> On Fri, 2014-10-31 at 14:54 +0100, Jiri Vanek wrote:
>>>> On 06/19/2014 04:46 PM, Petr Pchelko wrote:
>>>>> Hello, Jiri.
>>>>>
>>>>> Sorry for the delayed answer.
>>>>>   From the code point of view you current change looks OK to me. It's an internal package and
>>>>> we can change the access modifier easily.
>>>>>
>>>>> The more general question is what are you going to achieve by making this change?
>>>>> In JDK-9 we would have modules and you will not be able to use the sun.* packages at all, so
>>>>> this changeset is useless for JDK9.
>>>>> Do you want this to go to JDK8?
>>>>>
>>>>> In the original discussion there was a suggestion about providing a standard public interface
>>>>> for alternative plugins.
>>>>> This path looks more promising to me, because it will work in JDK9. Did any progress happen in
>>>>> that direction?
>>>>
>>>> hi guys!
>>>>
>>>> Do we need some JEP to make  this happen?
>>>
>>> Sorry, this one slipped off my radar.
>>>
>>> I think the general consensus here is that we need a JEP for JDK 9. I
>>> have no experience preparing one, but I was about to approach that for
>>> the look and feel idea, so I'll be happy to help.
>>>
>>> Perhaps something that will work with the new module system?
>>>
>>> We need some help from Oracle here, since there are other
>>> implementations of the plugins, getting to know your experience is quite
>>> important.
>>>
>>> Cheers,
>>> Mario
>>>
>>>
>>
>