3

I am using Eclipse and Netbeans, now preferring Netbeans. If developing a system class that is in the java library (such as FileReader) is there any way to add that class into an application and have the local one supercede the library copy?

The idea is to be able to work on augmenting a specific class at a time while still using the normal jdk.

Specifically I am working with java.lang.StringBuilder and java.io.FileWriter.

I wrote a modified StringBuilder class. If I create it in my directory: java/lang/FastStringBuilder

javac complains that I am trying to compile a restricted package java.lang.

If I rename the package, then it cannot inherit from AbstractStringBuilder which is not public.

They are making this way harder than it needs to be.

Dov
  • 8,000
  • 8
  • 46
  • 75
  • 4
    just use the same name in a different package ! – Ahmad Sanie Oct 29 '17 at 23:03
  • But do you mean `use your class that has the same name` or do you want to provide your own implementation of e.g. `java.io.Filereader`? It's classpath work in the second case. – Adam Kotwasinski Oct 29 '17 at 23:06
  • 1
    The closer I can think of is `/lib/ext` ( https://docs.oracle.com/javase/tutorial/ext/basics/install.html ). Not sure it would work though. – electrotype Oct 29 '17 at 23:07
  • For your own application that would be possible: place your java.io.File class first on the class path. With java 9 there will be problems so this might not be a good idea. As you are talking about implementation classes: a new FileReader is simply a pluggable Reader, your own package is not really a problem. Maybe AOP? – Joop Eggen Oct 29 '17 at 23:08
  • 2
    Whatever your reason for wanting this, I guarantee there is a better way to accomplish your goal. – VGR Oct 30 '17 at 01:13

2 Answers2

1

It is really-really bad idea in Java.

Do you need your own FileReader? - make it in your package and use it.

Do you need to use methods from standard FileReader? - extend or wrap it in your own FileReader and use it.

But never-ever try to replace any classes from any libraries regardless from where they are -in JDK or other third party frameworks.

For very rare and worse cases you can use AOP, but it is really painful and also another "better bad idea".

Vadim
  • 4,027
  • 2
  • 10
  • 26
  • 1
    If I am working on changes to a library class to propose back to java, I would rather not have to build a project with all source code, just edit the class I want while experimenting within a project. It seemed to me there should be some workaround. I think the suggestion of just changing the package name might be a good workaround unless there are files in the same package that would use default access to share data. – Dov Oct 30 '17 at 00:08
  • When you use another package name it cannot be called "override". It is just another class in another package and of course it is correct Java approach. You made your own class - you use it. Standard implementation is there but you do not use it. All right. But... if you think about to make your class to overload (let say "replace standard one") - NEVER DO THAT, whatever tricks are there to do such... – Vadim Oct 30 '17 at 00:14
  • 9
    typical useless stack over flow answer: "you don't actually want to do this" – Matt Swarthout Sep 02 '18 at 02:56
  • @MattSwarthout Why is that useless (or typical)? I've chosen a better approach based on such answers more than once. – Mark Dec 02 '19 at 15:35
  • Why would I like to do that? I identified a bug in a library. I want to patch one class to test my fix. I don't want to release a new snapshot of the library and import that every time I change a line. When it works I release a fix of the library. – Florian F Aug 24 '23 at 07:52
0

Instead of

import java.io.FileReader;

you just need

import package.of.your.FileReader;

to use your implementation instead of the standard one.

fvu
  • 32,488
  • 6
  • 61
  • 79
  • 1
    Ok, I am working with StringBuilder. If I create one in a different package, it will not have shared access to the non-public class AbstractStringBuilder. – Dov Oct 30 '17 at 02:43
  • @Dov - yes it will not. If you create `java.util.MyStringBuilder` it will to all non-public and non-private classes and their properties/methods in `java.util` package. But still, it will not override java.util.StringBuilder. Just there will be `StringBuilder` and `MyStringBuilder` classes. – Vadim Oct 30 '17 at 10:35