This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 17815 - Platformize the Core
Summary: Platformize the Core
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jaroslav Tulach
URL:
Keywords: UMBRELLA
Depends on: 20901 8617 9609 13693 18273 18781 19609 19620 19622 19623 20052 20663 20894 20895 20896 20898 20899 20900 20902 20955 20956 22062 22758 24853 24888 25868 26123 26642 27900 27903 28456 29124 29637 30161 34204
Blocks:
  Show dependency tree
 
Reported: 2001-11-19 09:45 UTC by Jaroslav Tulach
Modified: 2008-12-22 09:52 UTC (History)
5 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2001-11-19 09:45:58 UTC
Continue to load the core from the same startup classloader as now, but
in the module classloaders before handing down a request for core
classes or resources, check to see if the module has declared an
explicit dependency on the core (as a quasi-module) and refuse the
classloader delegation otherwise. Something similar could be done for
packages used by the core, such as JavaHelp, i.e. require users of these
classes to declare a package dependency on them. UI components of the
core could be implemented as a separate module depending on the main
core, to make it easier to substitute a different UI for the
application.
Comment 1 Jesse Glick 2001-11-19 10:49:05 UTC
It may in fact be desirable to increase separation further, e.g. by
treating help as a module, the execution or compilation engines, etc.
Comment 2 Jesse Glick 2002-01-14 14:23:30 UTC
Created branch javahelp_api_jan_2002 to work on splitting off JavaHelp
stuff at least. Plan on making a core/help module. Should at least
handle parsing and manipulation of JavaHelp help sets and links.

Tips of the day should also be housed elsewhere. Probably there ought
to be a general UI module core/ui that provides a variety of UI
niceties like most of the menus, welcome screen, etc. - anything not
related to use as an IDE. This can define an extension area for tips
of the day, which could then be physically moved to the usersguide. TBD.
Comment 3 Jesse Glick 2002-01-14 21:15:00 UTC
In progress.
Comment 4 Jesse Glick 2002-01-20 15:05:47 UTC
Tracking JavaHelp separation in its own issue now.
Comment 5 Jesse Glick 2002-01-20 15:08:27 UTC
Provides-requires semantics needed for some of these, probably.
Comment 6 Jesse Glick 2002-01-20 16:30:39 UTC
Reassigning to you to help work out exactly what is still not covered
by other things, maybe find people to work on them, and file tasks as
needed and make this depend on them - like to keep this a purely
tracking issue. Candidates we have talked about:

- split off a UI module from core, handling general application
display stuff, like the welcome screen, setup wizard, maybe import
wizard, most menus, most of the Options dialog, Editing workspace,
...; make a fixed module (classpath) but replaceable just using
-Dfixedmodules=... at build time

- split off an IDE-UI module from core: Build menu, mount wizard,
Processes node and maybe whole Runtime tab, Running workspace,
CompilerType/DebuggerType/Executor UI, ...; fixed classpath module

- split off compilation engine (OpenIDE-Module-Provides:
org.openide.compiler.CompilationEngine) incl. Next/Prev Error actions
and Stop Compile action; autoload module, automatic dependency from
old modules, newer should use -Requires: ...

- split off execution engine (OpenIDE-Module-Provides:
org.openide.execution.ExecutionEngine) incl. Execution Options;
autoload as for compilation engine

- split off terminal emulator and output window code; may be feasible
to make it an autoload if there were some abstract class
InputOutput.Provider handling what the methods in TopManager now do,
which could be in lookup and OpenIDE-Module-Provides

- not sure if window system can be moved anywhere, that is tough

Am I missing anything?

Forgot issue #18273, permitting us to move out all the beaninfo.
Comment 7 Jaroslav Tulach 2002-01-28 12:02:22 UTC
Hrebejku, can you create the subissues, you are the owner of the
platform ;-)
Comment 8 _ ttran 2002-02-13 16:45:22 UTC
increased prio to P1, must-have for 3.4
Comment 9 _ pkuzel 2002-02-14 18:38:45 UTC
I looked into i18n dependency reported as part of #19622 (a class
extends beaninfo/editors/StringEditor). Should be editors really in
core. 

Is not beaninfo package a candidate for a module?

This issue blocks #19622 (a positive feedback cycle).
Comment 10 Jesse Glick 2002-02-14 20:07:50 UTC
There should be no need to directly extend core beaninfos. dstrupl
should know more.

Making beaninfo into a module may be hard because of the way
Introspector finds classes. I think it needs to be in the same
classloader as the beans.
Comment 11 Jaroslav Tulach 2002-02-15 10:02:16 UTC
Introspector uses (amoung others) also Thread.getContextClassLoader.
It seems possible to convince the system to load beaninfos using
SystemClassLoader (together with ThreadGroup.enumerate)...
Comment 12 Jesse Glick 2002-02-18 14:13:52 UTC
I've thought about contextClassLoader, but it's tricky.
systemClassLoader changes dynamically, so you would need to reset the
contextClassLoader periodically. ThreadGroup.enumerate will give you
all *current* threads but you cannot listen for newly created ones. If
it can be made to work reliably, setting contextClassLoader to
systemClassLoader would probably be useful for a number of libraries;
people sort of expect it to "just work", I think.
Comment 13 Jesse Glick 2002-02-18 16:37:57 UTC
BTW see the end of NbInstaller.java for hints on how to (1) auto-add
dependencies for older modules; (2) refuse classes on classpath to
modules without a suitable dependency. Both things should be helpful
for separating classes from core modules. #2 would not be necessary at
all for core modules which can be made into autoloads, e.g. execution,
where core-execution.jar has OpenIDE-Module-Provides:
org.openide.execution.ExecutionEngine and modules wishing to use
execution must declare OpenIDE-Module-Requires:
org.openide.execution.ExecutionEngine.
Comment 14 Jaroslav Tulach 2002-02-19 12:00:04 UTC
Re: contextClassLoader. Each new thread reuses the contextClassLoader
from its parent. So it seems necessary to set the system classloader
for the main thread, all others will inherit it. Plus reset for all
threads in the ThreadGroup when systemCL changes.
Comment 15 Jesse Glick 2002-02-19 13:29:13 UTC
Filing separate issue re. contextClassLoader.
Comment 16 Petr Hrebejk 2002-02-26 17:47:45 UTC
Dependencies added
Comment 17 Petr Hrebejk 2002-02-27 16:37:15 UTC
Adding new dependencies
Comment 18 Petr Hrebejk 2002-05-13 12:35:48 UTC
Removing the 3.4_MILESTONE_4 keyword. 

This issue is a overall core platformization effort issue. It should
contain (and it contains) all bugs related to the platformization
of core no matter in which release they will be solved. For the
3.4_MILESTONE_4 please see the issue 23399.

(Notice: Some of the bugs in the dependency tree are related to
more complex changes scheduled into next releases. None of these
subbugs has any implact on users of the NetBeans IDE)
Comment 19 Jan Becicka 2002-07-30 15:05:43 UTC
What about introduce a new keyword (PLATFORM?) 
instead of adding all related issues here?
Comment 20 Jesse Glick 2002-07-30 15:33:26 UTC
Well, the effort is specifically a task within the core group, and it
makes little sense for other modules. Also using IZ dependencies lets
us track progress in plans files pretty easily, I guess.
Comment 21 _ ttran 2002-08-06 12:20:49 UTC
reassigned to Jesse who will be the driver for these efforts
Comment 22 Jesse Glick 2002-08-18 21:52:53 UTC
Have been working on it.
Comment 23 Jesse Glick 2002-08-24 05:41:48 UTC
I think P1 is overkill for this. I am obviously not going to create
the platform out of thin air by tomorrow morning. :-) P2 is fine.
Comment 24 Jesse Glick 2002-11-07 21:27:57 UTC
Remaining tasks cannot all be solved in the 4.0 timeframe.
Comment 25 Jesse Glick 2005-06-16 17:54:51 UTC
Yarda's been doing the work on this recently. What are your plans? Is this "done"?
Comment 26 Jaroslav Tulach 2005-06-17 15:56:41 UTC
I have no special plans except fixing some of the still opened issue this one 
depends on. 
Comment 27 Jesse Glick 2005-10-03 17:04:18 UTC
This can probably be closed as FIXED for 5.0 I guess.
Comment 28 Jaroslav Tulach 2005-10-04 07:51:21 UTC
I thought about closing it, but the truth is that org-netbeans-core.jar is 
still pretty big and should be split into smaller pieces. Still there are some 
tasks this depends on and are not fixed. But if you think this can be closed, 
do it. 
Comment 29 Jesse Glick 2005-10-04 17:41:22 UTC
I think the subtasks capture remaining things well enough. Otherwise we could
just have this open forever; I'm sure there will always be more things to clean up.