??xml version="1.0" encoding="utf-8" standalone="yes"?>
Start installing ASP.NET (2.0.50727).
...
Finished installing ASP.NET (2.0.50727).
Microsoft(R) Windows Communication Foundation Installation Utility
[Microsoft (R) Windows (R) Communication Foundation, Version 3.0.4506.2152]
Copyright (c) Microsoft Corporation. All rights reserved.
Installing: Machine.config Section Groups and Handlers
Installing: System.Web Build Provider
Installing: System.Web Compilation Assemblies
Installing: HTTP Handlers
Installing: HTTP Modules
Installing: Web Host Script Mappings
Installing: WMI Classes
Installing: Windows CardSpace (idsvc)
Installing: Net.Tcp Port Sharing Service (NetTcpPortSharing)
Installing: HTTP Namespace Reservations
Microsoft(R) Windows Communication Foundation Installation Utility
[Microsoft (R) Windows (R) Communication Foundation, Version 3.0.4506.2152]
Copyright (c) Microsoft Corporation. All rights reserved.
Installing: Web Host Script Mappings
3.
C:\WINDOWS\Microsoft.NET\Framework\v3.5>WFServicesReg.exe /r
4. 发生Error: Failed to access IIS metabase
aspnet_regiis -ga ASPNET
Finished granting ASPNET access to the IIS metabase and other directories used by ASP.NET.
]]>
tabname=>'BTAM003TB',
partname=> NULL,
estimate_percent=>100,
cascade=>TRUE,
degree=>1);
]]>
? 安装VS.
以上两步没啥好说?
? ~译本地Qt? 不然你会出现找不到qmaind.lib文gq样的编译错?
通过Visual Studio 2008 Command Promptq入控制?
一定要通过q个. 不能在运行里直接输入cmdq入. q样的话是没有VC~译环境?
在控制台里cd到QT目录, 目录里有个configure.exe
输入: configure -platform win32-msvc
需要一定的旉但来配置完成.
然后输入: nmake
然后要等很长旉{待Qt被编译成VC的lib格式.
? 创徏目
在项目目录下:
控制台输? qmake -project
然后: qmake -t vcapp -spec %QT_HOME%\mkspecs\win32-msvc2008
spec后面的项目可以看mkspecs目录下的子目? win32-msvc2005, win32-msvn2003什么的都有.
然后有VC的项目文件了.
? Visual Studio中的配置
主要是qmake生成的项目配|中的qt路径有问?所以要重新配置.
主要是两?
1. include. 配置如下?
详细目:
2. linker 配置如下?
加蝲的lib详细目
q样应该可以了.
具体目名称要看你编译出来的名字? 我在我机器上~译出来的是QtGuid4.lib和QtCored4.lib
另外要想q行~译出来的exe, 记得吧相关的dll文g复制到system32目录?
]]>
和bat脚本for一起配?可以实现自动的把某个目录下的jar包都攑ֈclasspath?
rem Append to CLASSPATH
rem
rem $Id: cpappend.bat 301115 2002-08-04 18:19:43Z patrickl $
rem ---------------------------------------------------------------------------
rem Process the first argument
if ""%1"" == """" goto end
set CLASSPATH=%CLASSPATH%;%1
shift
rem Process the remaining arguments
:setArgs
if ""%1"" == """" goto doneSetArgs
set CLASSPATH=%CLASSPATH% %1
shift
goto setArgs
:doneSetArgs
:end
配合for一L
set CLASSPATH=.
for %%i in (%CURRENT_DIR%\lib\*.jar) do call cpappend.bat %%i
start java -Duser.dir=%CURRENT_DIR% -cp %CLASSPATH% a.b.c.MainApp
]]>
class A {}
class B extends A{}
public void testIt(){
A a = new A();
B b = new B();
assertTrue(a.getClass().isAssignableFrom(b.getClass()));
}
}
]]>
Users of JDKs older than 1.3.0 who wish to port to a Java HotSpot VM, should see Java HotSpot Equivalents of Exact VM flags.
Standard options recognized by the Java HotSpot VM are described on the Java Application Launcher reference pages for Windows, Solaris and Linux. This document deals exclusively with non-standard options recognized by the Java HotSpot VM:
-X
are non-standard (not guaranteed to be supported on all VM implementations), and are subject to change without notice in subsequent releases of the JDK.-XX
are not stable and are not recommended for casual use. These options are subject to change without notice.Default values are listed for Java SE 6 for Solaris Sparc with -server. Some options may vary per architecture/OS/JVM version. Platforms with a differing default value are listed in the description.
-XX:+<option>
and turned off with -XX:-<option>
.-XX:<option>=<number>
. Numbers can include 'm' or 'M' for megabytes, 'k' or 'K' for kilobytes, and 'g' or 'G' for gigabytes (for example, 32k is the same as 32768).-XX:<option>=<string>
, are usually used to specify a file, a path, or a list of commandsFlags marked as manageable are dynamically writeable through the JDK management interface (com.sun.management.HotSpotDiagnosticMXBean API) and also through JConsole. In Monitoring and Managing Java SE 6 Platform Applications, Figure 3 shows an example. The manageable flags can also be set through jinfo -flag.
The options below are loosely grouped into three categories.
Option and Default Value |
Description |
---|---|
-XX:-AllowUserSignalHandlers | Do not complain if the application installs signal handlers. (Relevant to Solaris and Linux only.) |
-XX:AltStackSize=16384 | Alternate signal stack size (in Kbytes). (Relevant to Solaris only, removed from 5.0.) |
-XX:-DisableExplicitGC | Disable calls to System.gc(), JVM still performs garbage collection when necessary. |
-XX:+FailOverToOldVerifier | Fail over to old verifier when the new type checker fails. (Introduced in 6.) |
-XX:+HandlePromotionFailure | The youngest generation collection does not require a guarantee of full promotion of all live objects. (Introduced in 1.4.2 update 11) [5.0 and earlier: false.] |
-XX:+MaxFDLimit | Bump the number of file descriptors to max. (Relevant to Solaris only.) |
-XX:PreBlockSpin=10 | Spin count variable for use with -XX:+UseSpinning. Controls the maximum spin iterations allowed before entering operating system thread synchronization code. (Introduced in 1.4.2.) |
-XX:-RelaxAccessControlCheck | Relax the access control checks in the verifier. (Introduced in 6.) |
-XX:+ScavengeBeforeFullGC | Do young generation GC prior to a full GC. (Introduced in 1.4.1.) |
-XX:+UseAltSigs | Use alternate signals instead of SIGUSR1 and SIGUSR2 for VM internal signals. (Introduced in 1.3.1 update 9, 1.4.1. Relevant to Solaris only.) |
-XX:+UseBoundThreads | Bind user level threads to kernel threads. (Relevant to Solaris only.) |
-XX:-UseConcMarkSweepGC | Use concurrent mark-sweep collection for the old generation. (Introduced in 1.4.1) |
-XX:+UseGCOverheadLimit | Use a policy that limits the proportion of the VM's time that is spent in GC before an OutOfMemory error is thrown. (Introduced in 6.) |
-XX:+UseLWPSynchronization | Use LWP-based instead of thread based synchronization. (Introduced in 1.4.0. Relevant to Solaris only.) |
-XX:-UseParallelGC | Use parallel garbage collection for scavenges. (Introduced in 1.4.1) |
-XX:-UseParallelOldGC | Use parallel garbage collection for the full collections. Enabling this option automatically sets -XX:+UseParallelGC. (Introduced in 5.0 update 6.) |
-XX:-UseSerialGC | Use serial garbage collection. (Introduced in 5.0.) |
-XX:-UseSpinning | Enable naive spinning on Java monitor before entering operating system thread synchronizaton code. (Relevant to 1.4.2 and 5.0 only.) [1.4.2, multi-processor Windows platforms: true] |
-XX:+UseTLAB | Use thread-local object allocation (Introduced in 1.4.0, known as UseTLE prior to that.) [1.4.2 and earlier, x86 or with -client: false] |
-XX:+UseSplitVerifier | Use the new type checker with StackMapTable attributes. (Introduced in 5.0.)[5.0: false] |
-XX:+UseThreadPriorities | Use native thread priorities. |
-XX:+UseVMInterruptibleIO | Thread interrupt before or with EINTR for I/O operations results in OS_INTRPT. (Introduced in 6. Relevant to Solaris only.) |
Option and Default Value |
Description |
---|---|
-XX:+AggressiveOpts | Turn on point performance compiler optimizations that are expected to be default in upcoming releases. (Introduced in 5.0 update 6.) |
-XX:CompileThreshold=10000 | Number of method invocations/branches before compiling [-client: 1,500] |
-XX:LargePageSizeInBytes=4m | Sets the large page size used for the Java heap. (Introduced in 1.4.0 update 1.) [amd64: 2m.] |
-XX:MaxHeapFreeRatio=70 | Maximum percentage of heap free after GC to avoid shrinking. |
-XX:MaxNewSize=size | Maximum size of new generation (in bytes). Since 1.4, MaxNewSize is computed as a function of NewRatio. [1.3.1 Sparc: 32m; 1.3.1 x86: 2.5m.] |
-XX:MaxPermSize=64m | Size of the Permanent Generation. [5.0 and newer: 64 bit VMs are scaled 30% larger; 1.4 amd64: 96m; 1.3.1 -client: 32m.] |
-XX:MinHeapFreeRatio=40 | Minimum percentage of heap free after GC to avoid expansion. |
-XX:NewRatio=2 | Ratio of new/old generation sizes. [Sparc -client: 8; x86 -server: 8; x86 -client: 12.]-client: 4 (1.3) 8 (1.3.1+), x86: 12] |
-XX:NewSize=2.125m | Default size of new generation (in bytes) [5.0 and newer: 64 bit VMs are scaled 30% larger; x86: 1m; x86, 5.0 and older: 640k] |
-XX:ReservedCodeCacheSize=32m | Reserved code cache size (in bytes) - maximum code cache size. [Solaris 64-bit, amd64, and -server x86: 48m; in 1.5.0_06 and earlier, Solaris 64-bit and and64: 1024m.] |
-XX:SurvivorRatio=8 | Ratio of eden/survivor space size [Solaris amd64: 6; Sparc in 1.3.1: 25; other Solaris platforms in 5.0 and earlier: 32] |
-XX:TargetSurvivorRatio=50 | Desired percentage of survivor space used after scavenge. |
-XX:ThreadStackSize=512 | Thread Stack Size (in Kbytes). (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.] |
-XX:+UseBiasedLocking | Enable biased locking. For more details, see this tuning example. (Introduced in 5.0 update 6.) [5.0: false] |
-XX:+UseFastAccessorMethods | Use optimized versions of Get<Primitive>Field. |
-XX:-UseISM | Use Intimate Shared Memory. [Not accepted for non-Solaris platforms.] For details, see Intimate Shared Memory. |
-XX:+UseLargePages | Use large page memory. (Introduced in 5.0 update 5.) For details, see Java Support for Large Memory Pages. |
-XX:+UseMPSS | Use Multiple Page Size Support w/4mb pages for the heap. Do not use with ISM as this replaces the need for ISM. (Introduced in 1.4.0 update 1, Relevant to Solaris 9 and newer.) [1.4.1 and earlier: false] |
Option and Default Value |
Description |
---|---|
-XX:-CITime | Prints time spent in JIT Compiler. (Introduced in 1.4.0.) |
-XX:ErrorFile=./hs_err_pid<pid>.log | If an error occurs, save the error data to this file. (Introduced in 6.) |
-XX:-ExtendedDTraceProbes | Enable performance-impacting dtrace probes. (Introduced in 6. Relevant to Solaris only.) |
-XX:HeapDumpPath=./java_pid<pid>.hprof | Path to directory or filename for heap dump. Manageable. (Introduced in 1.4.2 update 12, 5.0 update 7.) |
-XX:-HeapDumpOnOutOfMemoryError | Dump heap to file when java.lang.OutOfMemoryError is thrown. Manageable. (Introduced in 1.4.2 update 12, 5.0 update 7.) |
-XX:OnError="<cmd args>;<cmd args>" | Run user-defined commands on fatal error. (Introduced in 1.4.2 update 9.) |
-XX:OnOutOfMemoryError="<cmd args>; <cmd args>" |
Run user-defined commands when an OutOfMemoryError is first thrown. (Introduced in 1.4.2 update 12, 6) |
-XX:-PrintClassHistogram | Print a histogram of class instances on Ctrl-Break. Manageable. (Introduced in 1.4.2.) The jmap -histo command provides equivalent functionality. |
-XX:-PrintConcurrentLocks | Print java.util.concurrent locks in Ctrl-Break thread dump. Manageable. (Introduced in 6.) The jstack -l command provides equivalent functionality. |
-XX:-PrintCommandLineFlags | Print flags that appeared on the command line. (Introduced in 5.0.) |
-XX:-PrintCompilation | Print message when a method is compiled. |
-XX:-PrintGC | Print messages at garbage collection. Manageable. |
-XX:-PrintGCDetails | Print more details at garbage collection. Manageable. (Introduced in 1.4.0.) |
-XX:-PrintGCTimeStamps | Print timestamps at garbage collection. Manageable (Introduced in 1.4.0.) |
-XX:-PrintTenuringDistribution | Print tenuring age information. |
-XX:-TraceClassLoading | Trace loading of classes. |
-XX:-TraceClassLoadingPreorder | Trace all classes loaded in order referenced (not loaded). (Introduced in 1.4.2.) |
-XX:-TraceClassResolution | Trace constant pool resolutions. (Introduced in 1.4.2.) |
-XX:-TraceClassUnloading | Trace unloading of classes. |
-XX:-TraceLoaderConstraints | Trace recording of loader constraints. (Introduced in 6.) |
一, 文g名中文ؕ码问?
开始知道能用FTPClient的listNamesҎ得到当前目录下所有文件的列表. 但是发现中文文g名是q. 默认情况下FTPClient使用UTF-8字符集作为和服务器通讯的编码集. 而我们的ftp服务器是在中文windowsXP上装的ServU. 所有用GBK做ؓ通讯~码? l过查找api文档, 我看CsetControlEncodingҎ, 试了一?果然好. 于是q个问题p决了:
W?? ftp.setControlEncoding("GBK")
至于conf.setServerLanguageCode("zh")对这个有什么媄?我还没有验证. 但是只有q句是不行的.
? 传输binary文g, ׃FTPClient默认使用ASCII作ؓ传输模式, 所有不能传输二q制文g. 通过
ftp.setFileType(FTP.BINARY_FILE_TYPE)个可以解册个问? 但是要在login以后执行. 因ؓq个Ҏ要向服务器发?TYPE I"命o.
开始的时候用的是setFileTransferMode, 不过不好? 它会执行 MODE I命o, 服务器不接受.
? 用被动模式传? enterLocalPassiveMode()q个C用在login之后执行, 因ؓ它只改变FTPClient实例的内部属?
? 断点l传. 心想应该有支持吧, 于是查APIl果扑ֈ了setRestartOffset()Ҏ, 试了一?果真好. 用RandomAccessFile配合使用, 实现hq是蛮简单的.
? 只能传一个文?!
不知道大家有没有遇到q个问题, 传输W一个文件好? 后面的的retrieveFileStream(name)都是q回null. q个实在是o人头痛的问题, 难不成要传一个文仉新徏立一ơ连? 那样也太土了? 但是文档里也没有? 来点狠的,debug它的源码, 看看它究竟做了什么事? 首先看一下ftp服务器的日志, 发现日志没问? q来的命令和reply都是正确? 但是发现W一个文件以后没有执行RETR命o. 于是跟踪PASV命o的reply代码,发现不是227,而服务器上的日志明明q回的是227. N是FTPClient解析Reply出问题了. q一步跟t发C问题, 原来在一个文件传输过E中会生两个Reply:
150 Opening BINARY mode data connection for a.sql (19890 Bytes).
226 Transfer complete.
而FTPClient自动消费掉一?于是解析Reply发生了错位, 下一个命令的会解?66那条. 接下来的命o都不是解析自qReply而是前一ơ命令的. 所有在PASV命o的Reply码就不对? FTPClient也就不会执行接下来本应该执行RETR命o.
他不消费,我们来消费吧. 于是在文件传输完成以? d调用一ơgetReply()把接下来?26消费? q样做是可以解决q个暂时的问? 但不知道在其他的ftp操作上会不会也有cM的情? FTPClientq点可做的不大好.
对于上面q个问题, 我本来想修改一下FTPClientq个cLd解决问题. l果发现自己也想不出好办? 最后还是放弃了.
当Tomcat5启动以后Q它创徏一pdcd载器。这些类加蝲器以父子关系l织在一P父类加蝲器在子类加蝲器的上面Q?/p>
q些cd载器所扮演的角Ԍ以及它们可以见到的类和资源的规则如下Q?br />
如上图所C,Tomcat5 在初始化的时候创建如下类加蝲器:
Bootstrap - q个cd载器可以加蝲Java虚拟机的q行时基c,以及在系l扩展目?$JAVA_HOME/jre/lib/ext
)中的所有Jar包中的类?strong>注意Q一些JVM可能用多个类加蝲器来实现它,或者它是根本不能被看见的?br />
System - q个cd载器一般可以加?font face="Courier New">CLASSPATH环境变量的内宏V所有这个类对于Tomcat内部的类和web应用E序的都是可见的。尽如此,标准的Tomcat5启动脚本($CATALINA_HOME/bin/catalina.sh
?%CATALINA_HOME%\bin\catalina.bat
)都会忽略CLASSPATH环境变量Q取而代之的是从如下仓库加蝲Q?/font>
Common - q个cd载器可以使一些附加的cd?font face="Courier New">Tomcat内部的类和web应用E序可见。正常情况下Q应用程序不应该替换它。所?CATALINA_HOME/common/classes目录下的未打包类和资源,以及$CATALINA_HOME/commons/endorsed?CATALINA_HOME/commons/i18n?CATALINA_HOME/common/lib目录下的Jar包中的类和资源都是这个类加蝲器的加蝲对象。默认情况,包括如下内容Q?/font>
Catalina - q个cd载器主要加蝲Tomcat5自己所需要的cd资源。这些类和资源对于Web应用E序是完全不可见的。在$CATALINA_HOME/server/classes目录下的所有类和资源,$CATALINA_HOME/server/lib下的所有Jar包中cd资源是这个类加蝲器的加蝲对象。默认情况,包括个如下内容:
AJP
web 服务器的q接器,一般用于ApacheQiPlanet iAS?iWS.?
Shared - q个cd载器用于把一些类和资源共享给所?/strong>的web应用E序?除非Tomcat内部的类也需要访问这些类Q在q种情况下你应该把它们放?strong>Commoncd载能加蝲的地?. ?font face="Courier New">$CATALINA_BASE/shared/classes目录下的所有未打包cd资源Q以?CATALINA_BASE/shared/lib目录下的所有Jar包中的类和资源可以被其加载。如果通过$CATALINA_BASE环境变量来从同一个tomcatE序q行了多个在实例Q那么这个类加蝲器的仓库是相对于$CATALINA_BASE而不?CATALINA_HOME?/font>
WebappX - pȝ会ؓ部v在一个Tomcat实例中的每个应用E序创徏一个这Lcd载器Q它们ؓ所属的应用E序加蝲cR所有你的web应用E序包的/WEB-INF/classes目录下的cd资源Q以?/font> q样在一个web应用E序中,cd资源的加载顺序是q样Q?/p>
/WEB-INF/lib 目录下的所有Jar包中的类和资源是q个cȝ加蝲对象。这些类和资源仅对这个应用程序可见,q且q个应用E序也看不见其他应用E序的类和资源?br />
像上面所描述的,web应用E序的类加蝲的加载流E与默认的Java 2的类记蝲托管模型?strong>不一?/strong>的。当有一个请求需要应用程序的WebappX cd载器加蝲一个类的时候,q个cd载器?strong>首先到自q仓库中查找,而不是先交给上面的类加蝲器查找。这里有一些例外。JRE的基cL不能被覆盖的。对于其他一些类Q如J2SE 1.4+中的XML解析器组ӞQ可以用J2SE1.4的签名特性。最后Q何包括servlet APIcȝJar包会被忽略。Tomcat5中的其他的类加蝲器用正常托模式?/p>
]]>
http://jamesdu.blogchina.com/349567.html
JVM规范定义了两U类型的c装载器Q?strong>启动内装载器(bootstrap)和用戯定义装蝲?/strong>(user-defined class loader)?
一Q ?ClassLoader基本概念
1Q?/strong>ClassLoader分类
c装载器是用来把c?class)装蝲qJVM的?br />JVM规范定义了两U类型的c装载器Q?strong>启动内装载器(bootstrap)和用戯定义装蝲?/strong>(user-defined class loader)?
JVM在运行时会生三个ClassLoader:Bootstrap ClassLoader、Extension ClassLoader和AppClassLoader.Bootstrap是用C++~写的,我们在Java中看不到?是null,是JVM自带的类装蝲器,用来装蝲核心cdQ如java.lang.*{?br />AppClassLoader?/strong>Parent?/strong>ExtClassLoaderQ?/strong>ExtClassLoader?/strong>Parent?/strong>Bootstrap ClassLoader?/strong>
Java提供了抽象类ClassLoaderQ所有用戯定义c装载器都实例化?/strong>ClassLoader的子cR?/strong> System Class Loader是一个特D的用户自定义类装蝲器,?/strong>JVM的实现者提供,在编E者不特别指定装蝲器的情况下默认装载用L。系l类装蝲器可以通过ClassLoader.getSystemClassLoader() Ҏ得到?br />
?Q测试你所使用的JVM的ClassLoader
/*LoaderSample1.java*/
在我的机器上(Sun Java 1.4.2)的运行结?br />sun.misc.Launcher$AppClassLoader@1a0c10f
sun.misc.Launcher$ExtClassLoader@e2eec8
null
java.lang.Object's loader is null
LoaderSample1's loader is sun.misc.Launcher$AppClassLoader@1a0c10f
W一行表C,pȝc装载器实例化自csun.misc.Launcher$AppClassLoader
W二行表C,pȝc装载器的parent实例化自csun.misc.Launcher$ExtClassLoader
W三行表C,pȝc装载器parent的parent为bootstrap
W四行表C,核心cjava.lang.Object是由bootstrap装蝲?
W五行表C,用户cLoaderSample1是由pȝc装载器装蝲?
二.parent delegation模型
?.2版本开始,Java引入了双亲委托模型,从而更好的保证Javaq_的安全?strong>在此模型下,当一个装载器被请求装载某个类Ӟ它首先委托自qparent去装载,?/strong>parent能装载,则返回这个类所对应?/strong>Class对象Q若parent不能装蝲Q则?/strong>parent的请求者去装蝲?br />
?1 parent delegation模型
如图1所C,loader2的parent为loader1Qloader1的parent为system class loader。假设loader2被要求装载类MyClassQ在parent delegation模型下,loader2首先hloader1代ؓ装蝲Qloader1再请求系l类装蝲器去装蝲MyClass。若pȝ装蝲器能成功装蝲Q则MyClass所对应的Class对象的referenceq回lloader1Qloader1再将referenceq回lloader2Q从而成功将cMyClass装蝲q虚拟机。若pȝc装载器不能装蝲MyClassQloader1会尝试装载MyClassQ若loader1也不能成功装载,loader2会尝试装载。若所有的parent及loader2本n都不能装载,则装载失败?br />
若有一个能成功装蝲Q实际装载的c装载器被称为定义类装蝲器,所有能成功q回Class对象的装载器Q包括定义类装蝲器)被称为初始类装蝲器。如?所C,假设loader1实际装蝲了MyClassQ则loader1为MyClass的定义类装蝲器,loader2和loader1为MyClass的初始类装蝲器?br />
需要指出的是,Class Loader是对象,它的父子关系和类的父子关pL有Q何关pR?br />
那么parent delegation模型Z么更安全了?因ؓ在此模型下用戯定义的类装蝲器不可能装蝲应该q亲装载器装蝲的可靠类Q从而防止不可靠甚至恶意的代码代替由父亲装蝲器装载的可靠代码。实际上Q类装蝲器的~写者可以自由选择不用把请求委托给parentQ但正如上所_会带来安全的问题?/strong>
三.命名I间及其作用
每个c装载器有自q命名I间Q命名空间由所有以此装载器为创始类装蝲器的cȝ成。不同命名空间的两个cL不可见的Q但只要得到cL对应的Class对象的referenceQ还是可以访问另一命名I间的类?br />
?演示了一个命名空间的cd何用另一命名I间的类。在例子中,LoaderSample2ql类装蝲器装载,LoaderSample3p定义的装载器loader负责装蝲Q两个类不在同一命名I间Q但LoaderSample2得到了LoaderSample3所对应的Class对象的referenceQ所以它可以讉KLoaderSampl3中公q成员(如age)?br />?不同命名I间的类的访?br />/*LoaderSample2.java*/
/*sub/Loadersample3.java*/
~译Qjavac LoaderSample2.java; javac sub/LoaderSample3.java
q行Qjava LoaderSample2
LoaderSample3 loaded
age is 30
从运行结果中可以看出Q在cLoaderSample2中可以创建处于另一命名I间的类LoaderSample3中的对象q可以访问其公共成员age?br />q行时包(runtime package)
由同一c装载器定义装蝲的属于相同包的类l成了运行时包,军_两个cL不是属于同一个运行时包,不仅要看它们的包名是否相同,q要看的定义c装载器是否相同。只有属于同一q行时包的类才能互相讉K包可见的cd成员。这L限制避免了用戯q代码冒充核心cd的类讉K核心cd包可见成员的情况。假讄戯己定义了一个类java.lang.YesQƈ用用戯定义的类装蝲器装载,׃java.lang.Yes和核心类库java.lang.*׃同的装蝲器装载,它们属于不同的运行时包,所以java.lang.Yes不能讉K核心cdjava.lang中类的包可见的成员?
ȝ
命名I间q没有完全禁止属于不同空间的cȝ互相讉KQ双亲委托模型加ZJava的安全,q行时包增加了对包可见成员的保护?/strong>
二. 扩展ClassLoaderҎ
我们目的是从本地文gpȝ使用我们实现的类装蝲器装载一个类?strong>Z创徏自己的类装蝲器我们应该扩?/strong>ClassLoaderc,q是一个抽象类。我们创Z?/strong>FileClassLoader extends ClassLoader。我们需要覆?/strong>ClassLoader中的findClass(String name)ҎQ这个方法通过cȝ名字而得C?/strong>Class对象?/strong>
我们q应该提供一个方法loadClassData(String name)Q通过cȝ名称q回class文g的字
节数l。然后用ClassLoader提供的defineClass()Ҏ我们可以返回Class对象了?/strong>
唉~~Q看来我得加强字W编码方面的知识了!
今天看到的一?/SPAN>Blog上的内容Q我把大致内Ҏ录下来,作ؓ备忘?/SPAN>
http://javachaos.crazyredpanda.com/?p=99
首先看一?/SPAN>LinkedList?/SPAN>ArrayList的承关pR?/SPAN>
public class ArrayList<E> extends AbstractList<E> implements List<E>, RandomAccess, Cloneable, Serializable
public class LinkedList<E> extends AbstractSequentialList<E> implements List<E>, Queue<E>, Cloneable, Serializable
两者都实现List接口Q前者实?/SPAN>RandomAccess接口Q后者实?/SPAN>Queue接口?/SPAN>
ArrayList
ArrayList其实是包装了一个数l?/SPAN> Object[]Q当实例化一?/SPAN>ArrayListӞ一个数l也被实例化Q当?/SPAN>ArrayList中添加对象是Q数l的大小也相应的改变。这样就带来以下有缺点:
快速随卌?/SPAN> 你可以随卌问每个元素而不用考虑性能问题Q通过调用get(i)Ҏ来访问下标ؓi的数l元素?/SPAN>
向其中添加对象速度?/SPAN> 当你创徏数组是ƈ不能定其容量,所以当改变q个数组时就必须在内存中做很多事情?/SPAN>
操作其中对象的速度?/SPAN> 当你要想数组中Q意两个元素中间添加对象时Q数l需要移动所有后面的对象?/SPAN>
LinkedList
LinkedList是通过节点直接彼此q接来实现的。每一个节炚w包含前一个节点的引用Q后一个节点的引用和节点存储的倹{当一个新节点插入Ӟ只需要修改其中保持先后关pȝ节点的引用即可,当删除记录时也一栗这样就带来以下有缺点:
操作其中对象的速度?/SPAN> 只需要改变连接,新的节点可以在内存中的Q何地?/SPAN>
不能随即讉K 虽然存在get()ҎQ但是这个方法是通过遍历接点来定位的所以速度慢?/SPAN>
一些结论:
当一些被定义好的数据需要放C数组对应?/SPAN>List中,ArrayList是很好的选择Q因为它可以动态变化,但是不要在整个应用程序用频繁的用。当你要很方便的操作其中的数据而不用随卌问时LinkList是很好的选择。如果你要频J随卌问徏议用数l?/SPAN>
另外一个我没有提到的是关于Queue?/SPAN>LinkedList的实C其具有很好的可扩展性,可以方便的在开始和l尾d删除节点。所?/SPAN>LinkedList很适合用来实现Queue?/SPAN>StackQ尽在Java5U已l有了一?/SPAN>Stack的实现?/SPAN>
以上是原文中的观点,但是在回复中也有人反对:
LinkedList有以下缺P
对象分配-每添加一就分配一个对?/SPAN>
回收垃圾-对象分配的结?/SPAN>
随即讉K?/SPAN>-设计上的原因
d删除?/SPAN>-因ؓ首先要找C|?/SPAN>
应该使用LinkedList的情况非常少。大多数的徏议使用LinkedList是错误的?/SPAN>
JDK?/SPAN>Stack是用数l来实现的?/SPAN>
在多数时间里你ƈ不是?/SPAN>List中间d数据Q而是向在l尾dQ这L操作ArrayList表现的很好?/SPAN>
LinkedList在实?/SPAN>Queue时很有用?/SPAN>
然后是原文作者提供的一些数据:
addFirst() to array list took 1422
addFirst() to linked list using general methods took 16
addFirst() to linked list using linked list methods took 16
addLast() to array list took 16
addLast() to linked list using general methods took 15
addLast() to linked list using linked list methods took 0
addMiddleTest() to array list took 735
addMiddleTest() to linked list using general methods took 11688
addMiddleTest() to linked list using linked list methods took 8406
removeFirst() to array list took 1422
removeFirst() to linked list using general methods took 0
removeFirst() to linked list using linked list methods took 0
removeLast() to array list took 0
removeLast() to linked list using general methods took 0
removeLast() to linked list using linked list methods took 0
removeMiddle() to array list took 734
removeMiddle() to linked list using general methods took 7594
removeMiddle() to linked list using linked list methods took 7719
fetchFirst() to array list took 0
fetchFirst() to linked list using general methods took 0
fetchFirst() to linked list using linked list methods took 0
fetchLast() to array list took 16
fetchLast() to linked list using general methods took 0
fetchLast() to linked list using linked list methods took 0
fetchMiddle() to array list took 15
fetchMiddle() to linked list using general methods took 9156
fetchMiddle() to linked list using linked list methods took 9234