hg: jdk8/tl/corba: 11 new changesets
Changeset: 2a00aeeb466b Author:katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/2a00aeeb466b Added tag jdk8-b80 for changeset 5f3d4a6bdd02 ! .hgtags Changeset: 0ac9424678e7 Author:katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0ac9424678e7 Added tag jdk8-b81 for changeset 2a00aeeb466b ! .hgtags Changeset: 05386b4610e9 Author:lana Date: 2013-03-12 16:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/05386b4610e9 Merge Changeset: 3c73273667ae Author:coffeys Date: 2012-10-30 17:06 + URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/3c73273667ae 8000631: Restrict access to class constructor Reviewed-by: alanb, ahgross ! make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk ! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream_1_0.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream_1_0.java ! src/share/classes/com/sun/corba/se/impl/io/FVDCodeBaseImpl.java ! src/share/classes/com/sun/corba/se/impl/io/ValueHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/io/ValueUtility.java ! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ORBUtility.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdFactory.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java + src/share/classes/sun/corba/JavaCorbaAccess.java + src/share/classes/sun/corba/SharedSecrets.java Changeset: 80882eae6279 Author:ngmr Date: 2012-10-30 17:15 + URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/80882eae6279 8000540: Improve IIOP type reuse management Reviewed-by: alanb, ahgross, coffeys ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java Changeset: 0ca1fc7c5f44 Author:mbankal Date: 2012-12-17 07:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0ca1fc7c5f44 7141694: Improving CORBA internals Reviewed-by: coffeys, ahgross ! src/share/classes/com/sun/corba/se/spi/orb/ORB.java Changeset: f4f39d873b9a Author:coffeys Date: 2012-11-06 15:50 + URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/f4f39d873b9a 7201066: Change modifiers on unused fields Reviewed-by: alanb, skoivu ! src/share/classes/com/sun/corba/se/impl/activation/ServerMain.java ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ObjectStreamClass_1_3_1.java Changeset: 59bff16bc0bf Author:ewendeli Date: 2013-02-19 21:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/59bff16bc0bf Merge - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java Changeset: 996bd5fd0941 Author:ewendeli Date: 2013-02-25 07:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/996bd5fd0941 Merge - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java -
hg: jdk8/tl/jaxws: 2 new changesets
Changeset: c88bb21560cc Author:katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c88bb21560cc Added tag jdk8-b80 for changeset b0224010e2f0 ! .hgtags Changeset: d8d8032d02d7 Author:katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d8d8032d02d7 Added tag jdk8-b81 for changeset c88bb21560cc ! .hgtags
hg: jdk8/tl/langtools: 5 new changesets
Changeset: ed69d087fdfd Author:katleman Date: 2013-03-07 11:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ed69d087fdfd Added tag jdk8-b80 for changeset a8227c617684 ! .hgtags Changeset: 58289451d9ed Author:katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/58289451d9ed Added tag jdk8-b81 for changeset ed69d087fdfd ! .hgtags Changeset: 39f8eb897ec6 Author:lana Date: 2013-03-12 16:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/39f8eb897ec6 Merge - test/tools/apt/Basics/NullAPF.java - test/tools/apt/Basics/apt.sh - test/tools/apt/verifyVariables.sh - test/tools/javac/4846262/Test.java - test/tools/javac/4846262/Test.out - test/tools/javac/4846262/Test.sh - test/tools/javac/6302184/T6302184.sh - test/tools/javac/ClassPathTest/ClassPathTest.sh - test/tools/javac/ClassPathTest/ClassPathTest1.java - test/tools/javac/ClassPathTest/ClassPathTest2.java - test/tools/javac/ClassPathTest/ClassPathTest3.java - test/tools/javac/ClassPathTest/bar/pkg/ClassPathTestAux2.java - test/tools/javac/ClassPathTest/foo/pkg/ClassPathTestAux1.java - test/tools/javac/ClassPathTest/pkg/ClassPathTestAux3.java - test/tools/javac/ExtDirs/ExtDirTest_1.java - test/tools/javac/ExtDirs/ExtDirTest_2.java - test/tools/javac/ExtDirs/ExtDirTest_3.java - test/tools/javac/ExtDirs/ExtDirs.sh - test/tools/javac/MethodParameters.java - test/tools/javac/MissingInclude.java - test/tools/javac/MissingInclude.sh - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass_2.java - test/tools/javac/ProtectedInnerClass/p1/ProtectedInnerClass1.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass2.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass3.java - test/tools/javac/T5090006/T5090006.java - test/tools/javac/T5090006/compiler.sh - test/tools/javac/constDebug/ConstDebug.java - test/tools/javac/constDebug/ConstDebug.sh - test/tools/javac/fatalErrors/NoJavaLang.java - test/tools/javac/fatalErrors/NoJavaLang.out - test/tools/javac/fatalErrors/NoJavaLang.sh - test/tools/javac/generics/diamond/T6939780.java - test/tools/javac/generics/diamond/T6939780.out - test/tools/javac/innerClassFile/Driver.sh - test/tools/javac/innerClassFile/x/B.java - test/tools/javac/innerClassFile/x/C.java - test/tools/javac/innerClassFile/y/Main.java - test/tools/javac/innerClassFile/y/R1.java - test/tools/javac/innerClassFile/y/R2.java - test/tools/javac/innerClassFile/y/R3.java - test/tools/javac/javazip/A.java - test/tools/javac/javazip/Test.sh - test/tools/javac/javazip/bad/B.java - test/tools/javac/javazip/good/B.java - test/tools/javac/links/T.java - test/tools/javac/links/b/B.java - test/tools/javac/links/links.sh - test/tools/javac/newlines/Newlines.sh - test/tools/javac/stackmap/T4955930.java - test/tools/javac/stackmap/T4955930.sh - test/tools/javac/unicode/SupplementaryJavaID6.sh - test/tools/javah/6257087/foo.java - test/tools/javah/6257087/foo.sh - test/tools/javah/6257087/foo_bar.h - test/tools/javah/ConstMacroTest.sh - test/tools/javah/MissingParamClassException.java - test/tools/javah/MissingParamClassTest.sh - test/tools/javah/ParamClassTest.java - test/tools/javah/SubClassConsts.java - test/tools/javah/SubClassConsts.out - test/tools/javah/SubClassConsts.win - test/tools/javah/SuperClassConsts.java - test/tools/javap/NotPackagePrivateInterface.java - test/tools/javap/PublicInterfaceTest.sh - test/tools/javap/pathsep.sh - test/tools/javap/stackmap/T6271292.java - test/tools/javap/stackmap/T6271292.out - test/tools/javap/stackmap/T6271292.sh Changeset: 825da6847791 Author:lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/825da6847791 Merge Changeset: a3049f4a7987 Author:lana Date: 2013-03-15 23:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a3049f4a7987 Merge
hg: jdk8/tl: 10 new changesets
Changeset: 907a926d3c96 Author:erikj Date: 2013-03-04 16:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/907a926d3c96 8004352: build-infra: Limit JOBS on large machines Reviewed-by: mduigou ! common/autoconf/build-performance.m4 ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/spec.gmk.in ! common/makefiles/JavaCompilation.gmk ! common/makefiles/Main.gmk Changeset: cd7f2c7e2a0e Author:katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cd7f2c7e2a0e Added tag jdk8-b80 for changeset 907a926d3c96 ! .hgtags Changeset: 52741ab7c601 Author:erikj Date: 2013-03-06 10:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/52741ab7c601 8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions? Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/autoconf/toolchain_windows.m4 Changeset: 235854886494 Author:katleman Date: 2013-03-11 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/235854886494 Merge Changeset: 145dbc56f931 Author:tbell Date: 2013-03-12 22:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/145dbc56f931 8009819: build-infra: RE jdk8 build forest fails for windows since addition of --with-dxsdk Reviewed-by: katleman ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 Changeset: 0dc28db6525f Author:katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0dc28db6525f Added tag jdk8-b81 for changeset 145dbc56f931 ! .hgtags Changeset: 980ccff2d4f5 Author:lana Date: 2013-03-12 16:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/980ccff2d4f5 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: 22b9a31a92eb Author:lana Date: 2013-03-13 23:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/22b9a31a92eb Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: a69761ae281b Author:lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a69761ae281b Merge Changeset: 4984ac509993 Author:lana Date: 2013-03-15 23:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4984ac509993 Merge
hg: jdk8/tl/jaxp: 7 new changesets
Changeset: ef349a4c Author:katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ef349a4c Added tag jdk8-b80 for changeset 4873a0499bc3 ! .hgtags Changeset: 94000590f01f Author:katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/94000590f01f Added tag jdk8-b81 for changeset ef349a4c ! .hgtags Changeset: f4898ff0aff1 Author:joehw Date: 2012-12-12 15:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f4898ff0aff1 8001235: Improve JAXP HTTP handling Reviewed-by: lancea, skoivu ! src/com/sun/org/apache/xpath/internal/functions/FuncSystemProperty.java Changeset: 3206516132e8 Author:ewendeli Date: 2013-02-19 21:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/3206516132e8 Merge Changeset: 46ce56a4e40f Author:ewendeli Date: 2013-02-25 07:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/46ce56a4e40f Merge Changeset: 8a0cb78fefbc Author:lana Date: 2013-03-12 18:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/8a0cb78fefbc Merge Changeset: d5a58291f09a Author:lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d5a58291f09a Merge
hg: jdk8/tl/jdk: 8009222: java.lang.IllegalArgumentException: not invocable, no method type when attempting to get getter method handle for a static field
Changeset: c1165d566a23 Author:vlivanov Date: 2013-03-06 16:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1165d566a23 8009222: java.lang.IllegalArgumentException: not invocable, no method type when attempting to get getter method handle for a static field Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/DirectMethodHandle.java + test/java/lang/invoke/8009222/Test8009222.java
hg: jdk8/tl/jdk: 8010142: ProblemList.txt updates (3/2013)
Changeset: ec8229b26dbc Author:chegar Date: 2013-03-17 09:55 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ec8229b26dbc 8010142: ProblemList.txt updates (3/2013) Reviewed-by: alanb ! test/ProblemList.txt
Re: @Supported design issues
1. I suspect that the percentage of deprecated APIs is less than 0.1 % .. So removing 1 ouf every 1,000 methods is not exactly going to make a huge difference here. 2. Some methods were deprecated at a time when the policy was to encourage people to use newer API, even though there wasn't anything very wrong. with the old one. For example Component.show()/hide() were deprecated in favour of Component.setVisible(boolean) although as far as I know there's absolutely no problem with the former. So such a policy would not be something you could apply automatically you'd need to go examine each case to understand it. 3. Removing methods *from the doc* and *from the runtime* each have their consequences, from the doc would discourage new uses but make it harder to understand old code. I think a long ago ill-fated JSR for javadoc improvements pondered hiding deprecated methods if you didn't want to see them. Remiving from the runtime would break apps, and in some cases people don't have the option to change and fix. -phil. On 3/16/13 2:10 PM, Daniel Latrémolière wrote: I'm continually surprised by developers I meet at conferences who (sometimes angrily) demand that deprecated APIs be removed, so I think the reality is a mixed bag -- not that it matters a great deal either way. Just a personal opinion as a developer. Java APIs are very big and removing deprecated APIs can reduce this size. It will help solving this question: what can be the name of the currently needed class/method in all these APIs?, which is very important, particularly for new Java developers, frequently lost in these numerous APIs. Readability is the biggest design feature of Java, then I think there is some logic if developers ask for removal of deprecated API, because it will improve readability of APIs.
Re: @Supported design issues
1. I suspect that the percentage of deprecated APIs is less than 0.1 % ..
So removing 1 ouf every 1,000 methods is not exactly going to make
a huge difference here.
2. Some methods were deprecated at a time when the policy was to
encourage people to use newer API, even though there wasn't
anything very wrong. with the old one.
For example Component.show()/hide() were deprecated
in favour of Component.setVisible(boolean) although as far as I know
there's absolutely no problem with the former.
So such a policy would not be something you could apply automatically
you'd need to go examine each case to understand it.
Yes or no for 0,1%, depending if you include some big parts like AWT,
Swing, CORBA which are obsolete for many developers, because they are
not considered up-to-date for their domains (UI, RPC) and their
development is stopped. In this case, deprecated or obsolete API are
concerning important domains, like:
* UI (AWT - Swing - JavaFX),
* date management (Date - Calendar - JSR 310)
* RPC (RMI, CORBA, WebServices, REST like JAX-RS: not all are used
even if winner depends of project).
* LDAP dedicated API are provided by vendors like Apache Directory,
OpenDJ for replacing JNDI (not evolving since Java 1.4 and seen not
sufficiently specialized).
* Logging API is split between java.util.logging, Log4J, SLF4J
(depending of project).
Other domains has evolved (like IO, NIO, NIO2) but contains some complex
differences: e.g. Path vs. File. Considering File as deprecated in Java7
is frequent even if it is not official:
http://stackoverflow.com/questions/6903335/java-7-path-vs-file
Another related problem for a developer is that many parts of API show
their age given others enhancements: e.g. Math/StrictMath classes were
introduced before Integer/Long/Float/Double classes but would probably
not have existed if order was inverse (static methods are notoriously
difficult to find, because we don't know by default the class containing
them).
Globally, an API designed before Java 1.5 has usually be updated for
generics but not for enumerations and only partially for annotations.
Now, seeing an int for describing an enumeration in an API became
surprising (like Modifier in reflection). Marker interfaces (like
java.io.Serializable, java.util.RandomAccess) have same problem against
annotations. The reason is simply that Java 1.5 is old: it has 8.5
years. API designed before have accumulated a technical debt and are not
seen up-to-date.
I think, I have covered big parts of Java API, concerning all
developers, with various names (deprecated, obsolete, technical debt)
for only one problem: feeling of an old API and need of cleaning it.
NB: With static methods in interface, you will probably have the same
problem in some years:
1) First round: add factories methods in interface.
Developer speaking: When I want an instance of an interface it is always
difficult to search a subclass and only after that call its constructor.
I want to go to the expected interface and call a static factory for all
my frequent usecases, then: please add some static methods like
followings in List class (and all other interfaces with implementations
provided by default):
public static E ListE newRandomAccessList() {
return new ArrayListE();
}
public static E ListE newLinearAccessList() {
return new LinkedListE();
}
2) Second round (some years after): remove them from public API.
Developer speaking: I do not need to see AbstractList, ArrayList and
LinkedList because I don't call them directly, at least in 99% of my
usecases. This is a List-related implementation detail only useful when
I want to create my own custom List for a highly specific and
performance-sensitive usecase. Remove these classes from public API and
put them in another library not seen by me by default, excepted if I
really search it.
In Javadoc, I only see the signature of method, and not the code of
method (implementation detail), then I don't want to see these classes
only implementing interfaces (implementation detail): the factory method
in interface is sufficient with one paragraph in the Javadoc giving
tradeoffs of each implementation provided by default.
3. Removing methods *from the doc* and *from the runtime* each
have their consequences, from the doc would discourage new uses
but make it harder to understand old code. I think a long ago
ill-fated JSR
for javadoc improvements pondered hiding deprecated methods if
you didn't want to see them. Remiving from the runtime would
break apps, and in some cases people don't have the option to change
and fix.
Currently, profiles are clearly reducing some API complexity for developer.
NB: JavaFX doclet seems to remove methods with prefix impl_ from Javadoc.
I think it seems sad, that one of the biggest differences between Java
and shorter language like JavaScript is static typing: it
Re: @Supported design issues
That isn't at all what @deprecated means.
Encouraged for new development doesn't mean everything else is
@deprecated.
These are all part of the Java SE platform spec, and are documented as such
and are fully supported .. a focus on compatibility is very important to
a lot
of our customers, even if that's not you.
-phil.
On 3/17/13 12:10 PM, Daniel Latrémolière wrote:
1. I suspect that the percentage of deprecated APIs is less than 0.1
% ..
So removing 1 ouf every 1,000 methods is not exactly going to make
a huge difference here.
2. Some methods were deprecated at a time when the policy was to
encourage people to use newer API, even though there wasn't
anything very wrong. with the old one.
For example Component.show()/hide() were deprecated
in favour of Component.setVisible(boolean) although as far as I know
there's absolutely no problem with the former.
So such a policy would not be something you could apply
automatically
you'd need to go examine each case to understand it.
Yes or no for 0,1%, depending if you include some big parts like AWT,
Swing, CORBA which are obsolete for many developers, because they are
not considered up-to-date for their domains (UI, RPC) and their
development is stopped. In this case, deprecated or obsolete API are
concerning important domains, like:
* UI (AWT - Swing - JavaFX),
* date management (Date - Calendar - JSR 310)
* RPC (RMI, CORBA, WebServices, REST like JAX-RS: not all are used
even if winner depends of project).
* LDAP dedicated API are provided by vendors like Apache Directory,
OpenDJ for replacing JNDI (not evolving since Java 1.4 and seen
not sufficiently specialized).
* Logging API is split between java.util.logging, Log4J, SLF4J
(depending of project).
Other domains has evolved (like IO, NIO, NIO2) but contains some
complex differences: e.g. Path vs. File. Considering File as
deprecated in Java7 is frequent even if it is not official:
http://stackoverflow.com/questions/6903335/java-7-path-vs-file
Another related problem for a developer is that many parts of API show
their age given others enhancements: e.g. Math/StrictMath classes were
introduced before Integer/Long/Float/Double classes but would probably
not have existed if order was inverse (static methods are notoriously
difficult to find, because we don't know by default the class
containing them).
Globally, an API designed before Java 1.5 has usually be updated for
generics but not for enumerations and only partially for annotations.
Now, seeing an int for describing an enumeration in an API became
surprising (like Modifier in reflection). Marker interfaces (like
java.io.Serializable, java.util.RandomAccess) have same problem
against annotations. The reason is simply that Java 1.5 is old: it has
8.5 years. API designed before have accumulated a technical debt and
are not seen up-to-date.
I think, I have covered big parts of Java API, concerning all
developers, with various names (deprecated, obsolete, technical debt)
for only one problem: feeling of an old API and need of cleaning it.
NB: With static methods in interface, you will probably have the same
problem in some years:
1) First round: add factories methods in interface.
Developer speaking: When I want an instance of an interface it is
always difficult to search a subclass and only after that call its
constructor. I want to go to the expected interface and call a static
factory for all my frequent usecases, then: please add some static
methods like followings in List class (and all other interfaces with
implementations provided by default):
public static E ListE newRandomAccessList() {
return new ArrayListE();
}
public static E ListE newLinearAccessList() {
return new LinkedListE();
}
2) Second round (some years after): remove them from public API.
Developer speaking: I do not need to see AbstractList, ArrayList and
LinkedList because I don't call them directly, at least in 99% of my
usecases. This is a List-related implementation detail only useful
when I want to create my own custom List for a highly specific and
performance-sensitive usecase. Remove these classes from public API
and put them in another library not seen by me by default, excepted if
I really search it.
In Javadoc, I only see the signature of method, and not the code of
method (implementation detail), then I don't want to see these classes
only implementing interfaces (implementation detail): the factory
method in interface is sufficient with one paragraph in the Javadoc
giving tradeoffs of each implementation provided by default.
3. Removing methods *from the doc* and *from the runtime* each
have their consequences, from the doc would discourage new uses
but make it harder to understand old code. I think a long ago
ill-fated JSR
for javadoc improvements pondered hiding deprecated methods if
you didn't want to see them. Remiving
