- You can run into grief if you drop a JAR file into the jre/lib/ext directory and one of its classes needs to load a class that ist not a system or extension class.The extension class loader does not user the class path.Keep that in mind before you use the extension directory as a way to manage your class file hassles
扩展类加载器不会用放在jre/lib/ext中的你jar包中的类路径 - It might surprise you,however,that you can have two classes in the same virtual machine that have the same class and package name. A class is determined by its full name and the class loader.This technique is useful for loading code from multiple sources.For example,a browser uses separate instances of the applet class loader for each web page.This allows the virtual machine to separate classes from different web pages,no matter what they are named.Figure 9.2.Suppose a web page contains to applets,provided by different advertisers,and each applet has a class called Banner.Since each applet is loaded by a separate class loader,these classes are entirely distinct and do not conflict with each other.
用不同的包名或者类加载器可以实现同名类不冲突 -
To be exact,since intermediate stream operations are lazy,it is possible to mutate the collection up to the point when the terminal operation executes.For example,the following,while certainly not recommended,will work:It is very important that you don't modify the collection that is backing a stream while carrying out a stream operation(even if the modification is threadsafe).Remember that streams don't collect their data--that data is always in a separate collection.If you were to modify that collection,the outcome of the stream operations would be undefined.The JDK documentation refers to this requirement as noninterference.It applies both to sequential and parallel streams.
List<String wordList = …;
Stream words = wordList.stream();
wordList.add(“End”);
long n = words.distinct().count();
this code is wrong:
Stream words = wordList.stream();
words.forEach(s->if(s.length()<12) wordList.remove(s));
不要在遍历的时候操作流,因为数据保存在集合中而不是流中,如果操作了那么集合发生改变会出现异常
4、Why Java didn’t adopt the ODBC model,the reason ,as given the JavaOne conference in 1996
4.1、ODBC is hard to learn
4.2、ODBC has a few commands with lots of complex options.The preferred style in the Java programming language is to have simple and intuitive methods,but to have lots of them
4.3、ODBC relies on the use of void* pointers and other C features that are not natural in the Java programming language
4.4、An ODBC-based solution is inhherently less safe and harder to deploy than a pure Java solution
为什么Java不用ODBC,他们在1996说ODBC较难学习,ODBC有些方法需要很复杂的选项。他们的设计思路和Java的简洁和直观思想所违背。ODBC依赖于void*和指针和C的一些特性,而他们在Java语言中不自然。最后就是ODBC的解决方案天生是不安全的而且难以依赖纯净的Java
09-12
09-12
09-12
09-12