Batch File Operations - Java SE (Archived)

One thing I've been hoping for is a standard utility library which would allow the definition of file sets (via regexes, recursive traversal of directories, inclusion/exclusion, etc.) and operations on those sets of files (delete, move, copy, all the usual suspects).  This isn't rocket science, and is the sort of thing that has to be reinvented every time someone needs to do any sort of scripting via Java.

> This isn't rocket science
No it isn't, its actually 5 lines of code.  I'm not sure how much easier it can be made...  Did you notice the FileFilter class and interface?

FileFilters are about half the battle for defining file sets as I've described.   There also needs to be support for union/intersection/difference of file sets, and defining file sets from directories(recursive or not).  More important to what I was talking about were the batch operations.  Again, not rocket science but tedious to do repeatedly, and error-prone in more complicated cases.

Wouldn't it be nice if the folks at Apache would take the notion of Path like structures in Ant, and abstract it out into a seperate library, independent of ANT itself?  It seems to me like their functionality is exactly what you want.

Correct.  I even began an attempt to do that myself, but I'm afraid those parts of Ant were not as well factored as they might be back when I did it.  I do think it's a reasonable bit of functionality to have in the core libraries, but a well-structured Apache library would suit me just fine.

Related

general purpose Java code generator library?

Is anyone aware of an open source Java code generator library? What I'm looking for is something that will let me write a program which builds up an abstract syntax tree in memory representing one or more classes, and then write it out as valid Java 1.6 source code files.
I have had to write code generators for several projects recently and just slapped them together as quick hacks, writing text out line by line. This works but it's messy and hard to maintain. So I figured there must be a better way.
The open source code generators I have found so far are either designed to be driven by a data model, or produce byte code instead of source code. But in my case there is really no data model (at least not for the generated code) and I want plain text source code that can be viewed and compiled along with everything else.
If nothing like that exists then I may try to build it myself. The Sun JDK includes a com.sun.source.tree package representing the source code AST object model so I could at least use that as a starting point. 
Nick_Radov wrote:
Is anyone aware of an open source Java code generator library? What I'm looking for is something that will let me write a program which builds up an abstract syntax tree in memory representing one or more classes, and then write it out as valid Java 1.6 source code files.There is no such thing - as you have phrased it.
I have had to write code generators for several projects recently and just slapped them together as quick hacks, writing text out line by line. This works but it's messy and hard to maintain. So I figured there must be a better way.You were writing part of an application to which a specific set of patterns (generic term not the GoF term) was represented. Then you wrote code that generated that set. Database layers would be an example that has a common set.
In terms of all programming in all domain spaces there is a miniscule set (of sets) that spans enough of the code to make it worthwhile for tools to exist in the wild for it. Again databases layers are an example of this.
There is another miniscule set (of sets) which for a specific project one can create a code generator. Either on going or even one shot. They do not and cannot serve any use outside the organization/problem domain space and often not even outside the project that they were created for. One example from personal experience of that would be where I created a generator that consumed a Word document representing a System Test Plan and the output was scripts in a commercial test product which used custom tools which tested a hardware device and the GUI front end that existed for it.
As a note I find code generation not only useful but enjoyable as well. If everything could be generated though then there wouldn't be any need for programmers. 
Nick_Radov wrote:
in my case there is really no data model.There must be something you plan to generate the code from, though. 
Nick_Radov wrote:
Is anyone aware of an open source Java code generator library? What I'm looking for is something that will let me write a program which builds up an abstract syntax tree in memory representing one or more classes, and then write it out as valid Java 1.6 source code files.I know this thread is quite old but I was looking for exactly the same thing, and I found it: CodeModel from Glassfish's Metro project.
[https://codemodel.dev.java.net/]
Unfortunately there is not much documentation, in fact the only documentation I found is the Javadoc, which is quite complete though. The main idea of this API is to use a top-down approach (package > class > method…) except for expressions. At first glance it seems to work quite well.

can you stop some one from decompiling your program

I have been told that its possible for some one to decompile your class file and view your source code. Is it possible to stop this from happening and how? 
there was an utilite which made the code much more unreadable.
i.e. renamed all the fields and added wierd blocks. Try to search for it. 
right - search on "obfuscator", but - anyone who is determined enough can get your source code from your class file. Of course, if it's worth anything without comments is another question.
Good luck
Lee 
I have been told that its possible for some one to
decompile your class file and view your source code.Yes.
Is it possible to stop this from happening and how? No. But you can make it harder.
This question is posted on a daily basis in these forums and it always makes me wonder, 'do other people really encounter this problem that often?'. On virtually every java project I've been apart of, decompilation was never a problem because no one ever had access to the class files. Nine times out of ten, we were making some app that a client just exposed to customers via the web. I realize that it could be a concern for people that are selling APIs, or have fat java clients, etc, etc, but it would seem to me that, any one who is designing a java app of that complexity, understands the issues involved with decompilation. I wonder if a lot of new developers simply here about decompilation and panic, forgetting that, in most java n-tier apps, no one is going to see your compiled code.
...(I suppose I am going out on a limb by assuming most developers are working on n-tier projects that are accessed via the web, rather then object brokering APIs, or network apps, etc, etc that do require complied code to be distributed, but I think that bet is fairly safe).
Speaking for myself, I am distributing sofware "independently" and don't have a large programming team or any staff, so the easiest way for me to rapidly get a program out there is to just make a windows executable out of it. I use an obfuscator and also include lot's of dummy files in the build, i.e. old versions that don't do anything anymore. It makes the distrubution larger, but anyone trying to deobfuscate it can be mislead by those files. I also use lot's of meaningless strings in random places, since constant strings can't be obfuscated. i.e. String bob = "REALLY IMPORTANT STUFF". Usually if you release a program where decompilation is a concern, you need to update the program frequently. I make minor changes in all my programs and then redistribute. It takes about 5 minutes to "completely" change the look of your obfuscated files and force a decompiler to start from scratch. I use a commercial product to create the Windows exe, the program is called exe4j. 
so the easiest way for me to rapidly get a program out there is to
just make a windows executable out of it. ... one would have to wonder why you bother to write java at all? 
I also use lot's of meaningless strings in random places,This is ridiculous advice.. within 1 second I can find out if your string is being used anywhere and completely ignore it. 
Ah you paranoids and your illusions of safety. Dummy files, dummy strings. Yes, that may help if a chimpanzee is trying to decompile your files. Obfuscating your code properly would take more time than coding it. 
This thread suggests another use for a decompiler.
Decompile every library that you buy (or hopefully do it on the demo.) If it is full of obscure stuff obviously intended to make decompiling it then it means the author/company is spending time on useless tasks rather than spending time fixing bugs and enhancing the product. Seems like a useable point to decide whether to buy it or not.

Good, Bad, indifferent?

I'm looking over some code for and application I wrote a little while ago, and I noticed that my main function had one method call, and the Class contructor, and that's it. All the program logic is in the Class. Is this considered good, bad or indifferent coding practice? In general, the app runs reasonably well, and speed is not critical, so I'm just a little curious, as this is typically how I tend to code. I might point out that it's a relatively large class with complex logic flow, and it's quite task specific, so I doubt I'll ever need to reuse it anywhere.
Another question. I'm looking into version control, and have looked at a few options. Any opinions on what is best. Any free options out there? 
If you're sure that the code won't ever be reused making everything static instead of instanciating the object and call it process or whatever method should give a little (not ot say mnimal) performance boost. You can also make the class final which will at least make method call non-virtual also giving a msla improvement.
My personnal taste is to never assume that code won't be reused though so I tend to use the second option if the class wo't ever need to be overloaded as I found it more elegant for an OOP language like Java.
If anyone is more enlighted on this topic I would gladly accept being corrected.
Regards 
As a general rule, if the logic is complex you want to break it up.
Version control - CVS is free and fairly popular. I use it, and it does some things well, although I've written quite a long list of things I'd like to put in a specification for a version control system. I don't think there's any system which does the things I'd like it to do. 
Caveat (that I understand you correctly)
That said ... this is NOT good practice.
Use final where you're SURE you want that.
Code your constructors carefully and with much forethought.
Don't put much code in main unless your doing a quick and dirty.
Save your X-time by creating minimum #objects, disposing properly, not overusing Strings, selecting correct IO Objects and methods, etc.
Remember the three main OOPS ideals ... inheritance, encapsulation and polymorphism. Difficult to do that with all your code in one place.HTH 
Caveat (that I understand you correctly)I'll try to be more specific
>
That said ... this is NOT good practice.
Use final where you're SURE you want that.Didn't touch final
Code your constructors carefully and with muchforethought.I should clarify that I'm instatiating an instance of my class in main
As for the constructor, all I do is add GUI components. The logic is handled via ActionListeners.
Don't put much code in main unless your doing a quickand dirty.Like I said, it's one method, and instatiating the class in main
Save your X-time by creating minimum #objects,disposing properly, not overusing Strings, selecting
correct IO Objects and methods, etc.OK
Remember the three main OOPS ideals ... inheritance,encapsulation and polymorphism. Difficult to do that
with all your code in one place.
HTHSo what I'm hearing here is by putting everything in the class, like I did, follows good OOP design practices? 
As a general rule, if the logic is complex you want to
break it up.
Version control - CVS is free and fairly popular. I
use it, and it does some things well, although I've
written quite a long list of things I'd like to put in
a specification for a version control system. I don't
think there's any system which does the things I'd
like it to do.RE Version control. I should add that I tend to develop on multiple machines which are all connected on a LAN, and currently I pull the file off one machine. I go remote occasionally, and my manual versioning system starts to fail because I'm lazy and forget to update the archive. I'd like something that handles this automatically (probably asking too much). Also, when (cough) I break my code, I'd like to be able to go back to the last version (I'll bet CVS does this).
CVS will let you rollback code and though it will not update your code automaticaly for you it will make it pretty damn easy to do yourself (one command and some coments and you are set) 
I'm (or more like was a couple months ago) a total Linux / CVS newbie. If I could recommend certain things, it would be :
1- If you wont have anything to do with Linux or cross platforms and just work with windows all the way, dont go for cvs. There are other alternatives I believe but they arent free though. For example, visual source safe is supposed to do a good job and is apparently very simple to use (although I havent tried it myself, but lots of friends have). I also tried some trial softwares on windows that were built using the CVS architecture, but were 10 times more simple to use, for example CS-RCS.
2- CVS has alot of advantages still, its free, has lots of tools you can use with (tools to view diffs, tools to do a changelog, in various platforms etc...) and its very stable (never had any problem of any sort other than human errors). The only drawback is I've find (like many other Linux tools) its NOT that much user-friendly. Expect to spend around a day to get used to the basic features and understand them. Then, you'll spend an hour or two every now and then for a little while to understand the more advanced stuff. All in all what I didnt liked the most is there isnt ONE tutorial that can help you understand all of it, so expect to be looking often for specific answers on the web. I've found the manual that comes with cvs has many 'holes' for the newcommers.
Anyways my 2 cents, bottom line is I still went for CVS (http://www.cvshome.org/ by the way) and it pays off once you went through all its little perks.
1- If you wont have anything to do with Linux or crossGood input, as I do deal with both Linux and Solaris. I've used CVS in the past for C++, guess I'll pull out the old text books and have a go.
Also as a side note, many IDE's include a cvs client now, so the integration is easy. For example, netbeans (or in my case the SunOne studio ide that is built on top of netbeans) has a good cvs client, so I can modify code and re-commit it all in one app which is nice.
If not, I recommand either WinCVS or SmartCVS. WinCVS is a little complicated but has every feature cvs has, and its obviously for a windows client. On the other hand, SmartCVS is built with java so it will run on any platform (will it I havent tried though :P but it should). You can find both on the cvs' website. 
Code your constructors carefully and with muchforethought.I should clarify that I'm instatiating an instance of
my class in main
As for the constructor, all I do is add GUI
components. The logic is handled via
ActionListeners.
So what I'm hearing here is by putting everything in
the class, like I did, follows good OOP design
practices?Just one point though ... Like another poster said, break up complicated code. I'll add that ine usually wants to break up code into logical units of work that can easilly be overriden or overloaded in sub-classes. If the one main method connects to a DB, opens an O/P file, writes out a new record, closes the file, closes the DB and shows a results screen all as a result of an ANON ActionListener Event, that's not usually a good idea. That's what I - and if I can take the liberty here - I think "we" are saying.
~Bill 
Just one point though ... Like another poster said,
break up complicated code. I'll add that ine usually
wants to break up code into logical units of work that
can easilly be overriden or overloaded in sub-classes.
If the one main method connects to a DB, opens an O/P
file, writes out a new record, closes the file, closes
the DB and shows a results screen all as a result of
an ANON ActionListener Event, that's not usually a
good idea. That's what I - and if I can take the
liberty here - I think "we" are saying.
~BillI feel I have a good handle on this. I don't put everything in the ActionListener, instead I call methods from the Listener. For example, I have a fileread() and a filewrite() method. I can easily call these methods from outside this program by importing the class from another program. They are a bit specific for this application which may be where I'm falling down (remembers some comment a while ago about a bloated API), nevermind, they are just fine ;) 
CVS will let you rollback codeReally? You can check out old versions, but they come with a sticky tag. I've never got -j to work, despite taking instruction from a colleague who does use it, so I generally do rollback using patch.
The big missing area of CVS, AFAIC, is an mv. The root of this is treating the filename as the key. I'd rather have a separate key. 
The big missing area of CVS, AFAIC, is an mv... what's an mv? 
It's the Unix "move" command (ren in MS-DOS). If you want to take a file called A and move it to B in CVS without losing the history, you have to copy the A,v file to B,v, cvs up B, make a trivial change to B, cvs rm A and finally cvs ci A B. Even then, things break badly if someone else made concurrent changes to A.

Equivalent to C's #ifdef

I'm trying to solve a development problem. In C, this would be solved by using #ifdef.
Basically, I have huge chunks of code that are experimental replacements for existing code. I want to enable this experimental code while developing, but I want to ensure that the tested algorithms are used when building a release jar.
Much of the searching I've done online recommends using "final static" variables. This does not solve the problem, though, because our developers have to manually flip the values of these variables around when developing, then flip them back when checking in to our central code repository, which opens up way too many opportunities for mistakes.
Another suggestion that has been made is to use System.getProperty() to extract the desired behavior from environment variables at run time. This doesn't solve the problem either, since I can't then compile a jar and hand it to a non-technical person to test -- I have to provide them with instructions or some other nonsense to get their environment variables set up properly first, which is error-prone even with technical people, but even more so with non-technical testers.
No. I'd prefer to have an easy way to ensure that a particular jar is only capable of running one of the algorithms. What I need to really do this right is the equivalent of C's #ifdef. I want each developer to set an environment variable in his/her IDE once, and ensure that they're always compiling with the algorithms that are under development. And I want our dedicated environment for building production jars to have an environment variable set that guarantees that it always builds with the production algorithms. In a perfect world, the unused code wouldn't even be included in the final .class files, to keep the size of the resultant jar smaller, but that's not strictly necessary.
I could use either of the two presented options ... both will get the job done (although less cleanly, and with more possibility of error). If there really is no better way, the environment variable and System.getProperty() are probably the closest, but I'm hoping that I'm just searching poorly and that there IS a better solution.
Any thoughts? 
832706 wrote:
A suggestion that has been made is to use System.getProperty() to extract the desired behavior from environment variables at run time.You do not get env.var. content with getProperty().
C:\> set foo.bar="environment variable"
System.out.println(System.getenv("foo.bar"));
c:\> java -Dfoo.bar="property value"
System.out.println(System.getProperty("foo.bar"));Any thoughts?A configuration file. 
This sounds like a job for a version control system.
Java does not have an #ifdef per se, but you can use the C preprocessor on Java files. I recommend very strongly against this approach however. Just use proper source code control. 
Sometimes I suppose it would be handy to have a preprocessor in Java. Then again, having something go through your code and replace parts of it just seems error-prone. Even if it works, you still have to worry about what the real code is that's passed to the compiler - the preprocessor output. I'm guessing that's why the designers of Java decided not to have a preprocessor. The code you write is what gets compiled.
If you want to enable or disable parts of the code, why not just have a global constant that changes based on parameters passed into the main program? Just read the args[] string in the main method and if it contains say "--debug" then set the global debug flag otherwise disable it.
And I don't think System environment variables are that bad. Testers should have some idea what environment variables are set. You do have to jump through a bit more hoops in Windows 7 compared to previous versions of Windows (on *nix systems it's even easier - you just set the variable, perhaps in the startup script), but after doing it a few times it won't be that big of a deal. 
If it's a debug flag specific to the program then it probably makes more sense to pass it as a parameter. If you want to have the system itself in a debug/release mode, then the Environment variable probably makes more sense. 
radtad82 wrote:
Sometimes I suppose it would be handy to have a preprocessor in Java. Then again, having something go through your code and replace parts of it just seems error-prone.PLUSPLUS! 
832706 wrote:
Any thoughts?You could possibly use assertions.
The [url http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.10]JLS describes how a boolean primitive is silently assigned 'true' as a side effect of evaluating an assertion,
as well as describing possible pitfalls.
Personally I am not entirely convinced this is a good way to use assertions.
And still you would face the same issue of having your testers run with assertions enabled.
Delivering your application.jar along with
an application.bat file for normal running, and
an applicationBeta.bat for your testers to test algorithms under development
should solve this regardless of what mechanism you opt for. 
Thanks to everyone for all the suggestions. To be honest, I'm not really comfortable with any of them, perhaps I just have the C way of doing things too hardwired in my head, but in any event I have a number of things to try, and figure out which one seems to work best for us.
If anyone is curious, I've started another thread to address a related issue:
Convincing JAX-WS to ignore all certificate problems 
radtad82 wrote:
Sometimes I suppose it would be handy to have a preprocessor in Java. Then again, having something go through your code and replace parts of it just seems error-prone. Even if it works, you still have to worry about what the real code is that's passed to the compiler - the preprocessor output. I'm guessing that's why the designers of Java decided not to have a preprocessor. The code you write is what gets compiled.Have done it at times using ANT scripts to replace markers in a source with actual content from its configuration files.
Mainly on things like server-specific WSDL variations and autogeneration of configuration files for different environments to be included in ear files.
Not a perfect solution maybe, but IMO beats having to go in and manipulate files in an ear or worse, on a production server, by hand as part of each deployment process.

suggestions for substituting a package name that constantly changes

I work with an organization that constantly changes their package names. I am tired of going to each program and changing them on a whim. I wanted to know if there is a procedure for making package names replaceable. This would be mostly a preventive method used to avoid using "find and replace" in huge, enterprise projects.
For example, one day it is as follows:
package com.megacorp.myclass;
The next day I want it to be changed as follows:
package com.mymegacorp.myclass;
Maybe the approach I was looking for was something like a .properties file or context containing the package name and I would substitute it using a variable like the following:
package ${constantly.changing.megacorp.name}.myclass;
This example my not be clear. Feel free to swing away as I cry tears of BLooD. Any info or suggestions would be greatly appreciated though. Thanks. 
What's wrong with using an IDE's refactoring capabilities? 
Initially, I didn't know what to call this type of programming or modification. Refactoring sounds like that's what it could have been called. I figure it can also be dangerous using an unfamiliar IDE (i.e. Eclipse). I would rather be able to do it through programming without any dependencies on any IDE (if possible). Then I would consider giving that a try when I understand what is happening. 
Refactoring is definitely what this kind of thing would be called. What you suggested isn't supported in Java, so you'd have to use some third party preprocessor-like tool (I've never looked into this sort of thing, I don't know what's out there) to replace your placeholders. It would have to become part of your build process, and could possibly introduce new bugs to your code if it didn't work properly every time. That sounds a lot more dangerous and dependent than using Eclipse's (or whatever IDE you fancy) refactor function, which is dead simple, and only has to be done once each time the package names change, so you can refactor, test, and forget about it. 
Will do. Thanks a bunch! 
My suggestion is to tell them to stop, and make sure you expose the costs of each change. 
While that may be helpful, most of these corps wanna do their own thing. 
So it isn't an organization problem at all. It is a dis-organization problem. I suggest you take it up with management, especially the cost issue. 
857913 wrote:
I work with an organization that constantly changes their package names. There are to many scenarios involved in that.
For example maybe just the company name changes.
Or you are selling a library via several distribution channels and each library needs a distinct entity.
Or marketing is pushing public product names down into the implementation.
Each requires different takes.

Categories

Resources