Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Softpanorama Java Bulletin, 2003

[23 May 2003] Java trends Scripting languages Builder AU Program Java C C++

It’s all about rapid development
No question about it: Scripting languages, such as Jython, Python, Perl, and PHP, are becoming more and more popular. Jython is actually a complete implementation of the Python programming language. It’s written in 100 percent pure Java and allows easy access to Java libraries.

This scripting trend is being driven largely by rapid application development (RAD), a development style that is gaining disciples all the time. As marketing executives put the full-court press on IT shops to speed production, IT managers are forced to look at the most efficient ways to beat deadlines. RAD is a prime mover here.

“You can be very clever with some scripting languages and do things you can’t do with regular Java,” said Mukund Balasubramanian, CTO of Redwood City, CA-based Infravio, a Java and Web services integrator. “If you know how to use a good scripting language, you can save a lot of time and money in development.”

The advantages of scripting languages
Balasubramanian said that scripting languages offer the following advantages:

The disadvantages of scripting languages
However, Java scripting languages do have a few disadvantages:

“Thus, scripting languages can quicken the pace of software development to a very large extent, but must be carefully chosen for a specific application—such as dynamic Web pages or to complement a ‘real’ programming language like Jython to Java,” Balasubramanian said.

[July 15, 2003] Russell Beattie Notebook A Thought About Java and Python

So I'm diving in Python, and because I've spent the past 4 years heads down as a Java programmer, I can't help but compare and contrast and "wonder if".

First let me explain the primal urge. Python attracts me because it doesn't seem like a "formal" programming language. Java is now used everywhere from universities to NASA and there are a zillion rights and wrongs that have been handed down from those on high and programming in Java now just makes me feel like I'm always doing something wrong. Hacking is downright encouraged in Python which is a fucking relief. Honestly, at this point in my education, I still prefer Java's overall logic that Python lacks, but I'm really attracted to Python's cleanness, relative simplicity and *complete lack of guilt* while using it.

But the problem is that Python is definitely crufty. There are so many spots where you can see how the language has been expanded - by force if necessary - throughout the years. Things like the way running an app works: you write a function that tests to see if matches "__main__", instead of an actual main() function. The fact that *every* method in a class needs to refer to "self" first (i.e.: method(self, otherParam) ) is ugly. And self isn't actually a reserved word, just a "strong convention". Ugh. As I learn more, I find more. In my opinion, Python could definitely use a new version rev, drop backwards compatability and clean up the cruft.

So you can see that I'm digging Python because of it's hackiness, but also disliking it for the same exact reason. And of course, I'm constantly comparing it to Java. Different languages do different things better, but as I run into areas where Java is so much better (db access, portability, packaging in jars) I wish I was back in the Java fold.

Basically, I can't help thinking that Java could be made to work more like Python. I mean, there's Jython, but I don't want to talk about half-ass implementing Python on Java, I'm talking about making Java more programmer friendly like Python.

This is already happening - but mostly on the server side of things. What I'm talking about is the various versions of JSP. The biggest flaw that most server side programmers have is to consider JSP a separate technology, when in reality, JSP is simply an elaborate macro language for creating servlet classes. Jasper parses JSP and creates a class. And that's the key - it doesn't matter *what* you program in using Java as long as the end result is a valid class file. This is the way Jython works: when the Python code is parsed and compiled, the result isn't a .pyc, but a regular .class file. Other examples include Apache's Axis project and their .jws files that produce all the classes that are needed for SOAP and WDSL and JSP 2.0's upcoming .tag files as well that produce tag libraries. All examples of non-full Java producing real classes.

So for all us non-programmers who could give a flying fuck about the GoF and just want to get something cool done in the shortest time and minimum lines possible, there needs to be another option than the increasingly complex and bloated Java, but not just on the server - for use on a daily basis.

I guess if it's not Java, it's not Java. However, something could be "mostly" Java and work more like Python. Would it be optimized? No. Would it be for the hard core geeks? No. Would be useful? Yeah, I think so. But I don't want some random OSS project that no one takes seriously, I'd like a sanctioned Sun-backed spec like JSP.

Here's how I envision it. Imagine you had a new type of file called a .jv file. No compiling step needed. When you went to run it, the compiler would automatically be invoked, just like Python creating a normal Java class. There would be a set of libraries automatically imported that wrapped up the commonly used libraries in Java making things like i/o and Collections as simple to use as Python's Dictionaries, lists and open() function. Types would be dynamic, yet strongly typed and autoboxed (of course). It'd be easy to import existing libraries so you can take advantage of the massive amount of stuff produced for Java already, but not have to deal with the crap. Comments would have their own place, as well as neat functionality like overriding operators. No - I'm not asking for a VB for Java, just a version that's meant for higher productivity.

What do you think? I think if I never heard the term "anti-pattern" again, I'd be a happy man.

-Russ

Comment: There are quite a few languages that compile to java bytecodes besides Jython.

http://www.robert-tolksdorf.de/vmlanguages.html 

I have heard good things about Nice, and Jython of course.

Posted by Jason Horman
Homepage: http://www.jhorman.org/

Comment: In regards to your comment about Pythons "self.".

 Many OO scripting languages follow similar conventions, ruby uses @varname for member variables. The issue is that when you don't have to declare your variables, how can the interpreter know what scope you want. Python doesn't require, or allow, members to be pre-defined outside of instance methods. If it did, the interpreter could look at the pre-defined members and resolve the variable scope for local methods.

Also, one of Pythons goals is clarity and non-ambiguity. Magically resolving variable symbols in different scopes is not something Python wants users to get confused with, so "self." is used to make sure there is no confusion.

Posted by Jason Horman
Homepage: http://www.jhorman.org/

[Dec 19, 2003] JavaServer Pages, 3rd Edition

By Hans Bergsten
3rd Edition December 2003 
0-596-00563-6, Order Number: 5636
764 pages, $44.95 US, $69.95 CA, £31.95 UK

Chapter 11: Developing Custom Tag Libraries as Tag Files (PDF Format)

Xref-Java2Html - Software by Marian Vittek - Sunday, September 10th 2000 10:12 PDT Section:

Xref-Java2Html is a Java documentation tool that enhances standard JavaDoc documentation by linking to your source code and completing cross references of each symbol. The generated documentation can answer questions like where a field is defined or used, which virtual methods can be invoked at a place, where a method can be invoked, and similar questions about symbol definitions and usages.

Homepage:
http://www.xref-tech.com/java2html/index.html
Zip:
ftp://ftp.xref-tech.com/[..]/xref/new/xref-java2html-i86pc-linux.jar

Kassab, Lora, and Greenwald, Steven, "Towards Formalizing the Java Security Architecture in JDK 1.2," Proceedings European Symposium on Research in Computer Security (ESORICS) '98, Springer LNCS, Leuven-la-Neuve, Belgium, September, 1998. PostScript, PDF

The Java security architecture in the Java Development Kit 1.2 expands the current Java sandbox model, allowing finer-grained, configurable access control for Java code. This new security architecture permits more precise, yet flexible, protection for both remote code (loaded across a network connection) and local code (residing on the same machine running the Java Virtual Machine) developed using the Java programming language. Our formal model and analysis is intended to: (1) allow designers and implementers to understand and correctly use the protection provided by these security controls, and (2) provide guidance to a JVM implementer wishing to support these security controls. Access control decisions in Java are made based on the current execution context using stack introspection. To model this, we employ a state-based model that uses multiple access control matrices to model the security controls in JDK 1.2. We also present a safety analysis and discuss the effects of static and dynamic security policies for a given Java Virtual Machine.

Why Java Sucks For Sysadmins

I am not a fan of Java. (The programming language, not the drink (which I love) or the place.) There are a lot of pages out there on how and why Java sucks, but most of them are written by and for programmers, e.g. "Java sucks because you can only singly inherit dynamic classless initialization methods!" (Um...yeah! Righteous! Preach it, brother!) I'm sure they're all valid enough, but Java doesn't just suck for programmers, it sucks for sysadmins too! There's enough suckiness in it for everybody!
I should really specify more carefully exactly what I mean by Java (since this is something even its supporters have to do). I learned a little of Java the language proper back when it was new and the hot thing to learn: it seems like a language like any other, no better or worse than many others. Fussy with the syntax and rather verbose, but that could be said of other languages too. As a sysadmin, I don't have to deal much with it anyway. Java the VM and class library is a different issue. That I do have to deal with. Then there's the whole culture surrounding Java...and that's a whole other can of worms.

That said, the major points against it from this sysadmin's point of view are:

  1. It is slow. Compared to compiled C programs, Java loses every time. Try time tar xf nonexistentfile and time jar xf nonexistentfile. On an otherwise idle 440MHz UltraSparcII running Solaris 8 with the Java 2 JRE 1.3.1, it takes jar over half a second just to report that it can't find the file! tar, on the other hand, takes just over 1/100th second. The fact that it's a semi-interpreted language is not an excuse. If I need to pull a plow, and you send me aardvarks instead of draft horses, saying "Well, they're aardvarks and you just have to expect that from aardvarks" does not get my field plowed any faster. So what's half a second, anyway? Well, times several million hits on your website per day, it's a whole lot. (OK, a lot of this is startup cost of the JVM, and hopefully you're not starting a whole new copy every time someone hits your site, like an old cgi, but the startup cost is still there, and if you think it doesn't make a difference, I refer you to the Sun memo above.) But, you say, it depends so much on your JRE! So, say I, show me any JRE as fast as native code. And if Sun, the inventor of Java, can't manage to make a decently fast JRE, it doesn't inspire great confidence, does it? Even if there are great JREs out there, the fact that one has to go hunt them down to get decent performance is a strike against Java. C programs pretty much work or they don't.
    I keep hearing "Well, the next generation of JREs will be just as fast as native code - maybe even faster!" I'll believe that when I see it. I've been hearing it since the first days of Java.
  2. It manages to be both verbose and unhelpful at the same time. Let's continue to use tar/jar as our examples. 
    devweb02:~$ tar xf qwertyuiop
tar: qwertyuiop: No such file or directory
devweb02:~$ jar xf asdfghjkl
java.io.FileNotFoundException: asdfghjkl (No such file or directory)
        at java.io.FileInputStream.open(Native Method)
        at java.io.FileInputStream.(FileInputStream.java:64)
        at sun.tools.jar.Main.run(Main.java:186)
        at sun.tools.jar.Main.main(Main.java:904)

    One of these error messages is helpful. One is not. (Not even "jar: FileNotFoundException". But "java.io.FileNotFoundException". Sure hope you didn't have more than one java process running at once.) And the situation only gets worse when you're dealing with larger projects. When a program runs into a problem, a concise description, like "Cannot open connection to host.example.net", is useful. A 100-line stack dump is not. (The beautiful thing about programs in C is that you can easily get a stack dump if you want it -
     

    devweb05:~$ pstack $$
5454:   -bash
 ff19bcf0 waitid   (7, 0, ffbefa30, 7)
 ff1560c0 _waitpid (7, ffbefb24, 4, ffbefb24, 21638, 39994) + 60
 00039994 ???????? (8ccfc, 8c7b4, 38708, 2, 1, 1)
 00038b00 wait_for (a8950, 16d6, 0, a7510, 0, 0) + 120
 0002cc88 execute_command_internal (8cc00, 0, ffffffff, 0, 0, 0) + 740
 0002c308 execute_command (a8890, a8890, 0, 0, 0, 0) + 44
 00021970 reader_loop (8c400, 8c400, 0, 1, 1, 1) + 1dc
 0001fc08 main     (8c400, 1, 8cc00, 8c400, 0, 0) + 890
 0001f360 _start   (0, 0, 0, 0, 0, 0) + b8

    - but you don't get it unless you want it. You can use a debugger on a core file or running process if your platform doesn't have pstack or the like.) The general problem is that Java gives you messages which are meaningful in a Java context and not in a system context. I suspect this is because Java was written in a sort of bubble-boy environment, where it had very little to do with the real world (cf. Perl) and it persists because most major Java apps are written by people who are in love with Java, and they are in love with Java because they are programmers; language-related messages are the only things that mean anything to them. Here's a real example: 

    **** Error      Fri Aug 31 16:04:18 EDT 2001    999288258613    /       a__.n______.N______Resources->cantResolveComponent : Unable to resolve component /a__/d_____/service/jdbc/JTDataSource  java.lang.UnsatisfiedLinkError: no ocijdbc8 in java.library.path
**** Error      Fri Aug 31 16:04:18 EDT 2001    999288258613    /               at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1312)
**** Error      Fri Aug 31 16:04:18 EDT 2001    999288258613    /               at java.lang.Runtime.loadLibrary0(Runtime.java:749)
**** Error      Fri Aug 31 16:04:18 EDT 2001    999288258613    /               at java.lang.System.loadLibrary(System.java:820)
**** Error      Fri Aug 31 16:04:18 EDT 2001    999288258613    /               at oracle.jdbc.oci8.OCIDBAccess.logon(OCIDBAccess.java)
**** Error      Fri Aug 31 16:04:18 EDT 2001    999288258613    /               at oracle.jdbc.driver.OracleConnection.(OracleConnection.java)
**** Error      Fri Aug 31 16:04:18 EDT 2001    999288258613    /               at oracle.jdbc.driver.OracleDriver.getConnectionInstance(OracleDriver.java)
**** Error      Fri Aug 31 16:04:18 EDT 2001    999288258613    /               at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java)
**** Error      Fri Aug 31 16:04:18 EDT 2001    999288258613    /               at java.sql.DriverManager.getConnection(DriverManager.java:517)
**** Error      Fri Aug 31 16:04:18 EDT 2001    999288258613    /               at java.sql.DriverManager.getConnection(DriverManager.java:146)
**** Error      Fri Aug 31 16:04:18 EDT 2001    999288258613    /       ....stack trace CROPPED after 10 lines.

    Only the first line is relevant to the system administrator, and that only tangentially. In fact, the system tacitly acknowledges the uselessness of the flood of error messages by stopping them after a point.

    Here's another real example: 

    ***ERROR***:    Wed Apr 10 15:52:27 EDT 2002    1018468347628   
/a__/d_____/servlet/pagecompile/PageCompileServlet        
The detailed exception is: java.io.IOException: Not enough space

    That's the "detailed exception"?! "Not enough space"? Not enough what space? Heap? Disk? If that's the detailed one, I don't want to see the short version. (I'm picturing Java just saying "No." and dying.)

     

  3. It is fragile, and in some parts, actually broken. Far too many times have I heard "Oh, you need to use jre 1.1.8, not 1.1.7", or "This needs green_threads, not native_threads." I can't claim that non-java programs never have library problems, but they are far less common than Java's ticklish dependencies. It should be considered a sign of how finicky it is that even Sun's jar (just to pick on poor beleaguered jar one more time) requires an 87-line wrapper script to make sure it can run correctly. To name one particular broken part, the AWT (Abstract Windowing Toolkit) did not work well with the X Windowing System. Try to run a graphical java application with the output exported to another display, and while the window would come up, most of the widgets in it would be broken - not working correctly or not appearing at all. "The network is the computer", huh, Sun? (Apparently the AWT has been scrapped now, but its replacement, Swing, does not work much better.) The comments I made about the JRE apply here, too. I want programs to work without having to hunt down some unknown number of other components in order to get acceptable performance out of them.
  4. It's unfriendly to much of a sysadmin's standard bag of tricks for testing and troubleshooting. Ever truss a java process? 
    yoyodyne:~$ truss 2>&1 java HelloWorld >/dev/null | wc -l
    1107

    One thousand one hundred seven lines of truss output just to run Hello World? 

    yoyodyne:~$ truss 2>&1 java HelloWorld >/dev/null | egrep -c "sema|mutex"
40

    Forty lines of semaphore or mutex activity to run Hello World?
    a) No wonder it's slow,
    b) Good luck finding the meaningful needle in the haystack of syscalls. 

    yoyodyne:~$ ldd HelloWorld.class 
ldd: HelloWorld.class: unsupported or unknown file type

    Oops, can't look at the dependencies either. I've never tried using a library interposer with a Java program, but I don't think it would be much fun.

Other failings of Java are not intrinsic to the environment, but of the way it's been marketed, and why people say everyone should love Java.

  1. "It's object-oriented!" As a sysadmin, I don't care. Not one whit. I notice that the human race miraculously managed to survive many years of non-object-oriented programming, somehow.
  2. "It's cross-platform!" This is maybe an advantage for programmers. Not for sysadmins. Needing to run the same application - to say nothing of the same binary! - on multiple platforms is not that common. (Some companies apparently like it because they can develop on Windows desktops and deploy on Unix servers. I have seen exactly how well this usually works.) The particularly cynical part of me wants to say, "So it can be broken on multiple platforms at once!" but unfortunately there's a lot of truth to that. I'm sure "write once, run anywhere" really does look appealing to software companies. One app that will run on Solaris, Windows, HP-UX, Irix, and AIX? Great! Right? Unfortunately for the consumer, though, the software companies are not about to quintuple their testing and debugging efforts. (That would probably erase most of the gains of "write once, run anywhere", frankly.) So the consumer gets an app that hasn't been effectively tested or debugged on his platform. And do you really think that the software companies are going to start hiring five times as many support staff, or support staff skilled in five times as many operating systems?
    Furthermore, properly written C is pretty cross-platform too. Or maybe I just hallucinated the Apache project and NetBSD. Badly written Java isn't cross-platform either - I've actually seen vendor code that has nonportable stuff like     FileInputStream("C:\GronkSoft\Appulator\Store\Config\Flargulator.properties") embedded in it. This is obviously a development problem, not strictly a language problem, but the point is that cross-platform-ness is a state of mind, not just a platform.
  3. "It's easy to code in and reduces development time!" Things that make it easier to do your job are good, but not if they come at the cost of the quality of the result. As I said before, I'm not a programmer, but I strongly suspect that management and skills are a much greater factor in determining the speed and quality of a project than the particular language you use. That's certainly the way it is in system administration. It has been pointed out that good software takes time, anyway. Changing the language you use just to speed up one particular part of the project seems like rather a bold (read "poorly thought-out") move to make. And for your sanity and mine, I won't refer you to the web pages out there that basically say "I like Java because it lets me program without being a good programmer!" Bleurgh.

Miscellanea:

  1. "What about Perl, huh? Doesn't Perl have all the same problems, wise guy?" Well, yes and no. Perl is no speed demon, being an interpreted language, but OTOH it's never been sold as a replacement for C, either. And in my experience, it still manages to be faster in execution than Java, though that's not very scientific evidence. You do run into twisty mazes of dependencies from time to time, but I've always found them easier to deal with than Java's, and its error messages are far better than Java's: 
    sadalsuud:~$ perl perlopen.pl
Can't open file: No such file or directory at perlopen.pl line 1.

    and 

    sadalsuud:~$ perl perlinc.pl
Can't locate NONEXISTENT.pm in @INC (@INC contains: /usr/lib/perl5/i386-linux /usr/lib/perl5 /usr/lib/perl5/site_perl/i386-linux /usr/lib/perl5/site_perl /usr/lib/perl5/site_perl .) at perlinc.pl line 1.
BEGIN failed--compilation aborted at perlinc.pl line 1.

    Perl is also open-source, so you can actually fix the broken stuff vendors send you, as opposed to waiting around for them to fix their bytecode. (I have run into intentionally obfuscated Perl that is effectively impossible to read; I can't excuse this and won't use it if I have a choice.)

  2. Sun won't eat its own dog food. NEW!
    If Java's so great, how come none of Sun's major software (to the best of my knowledge) is written in it? If it's not right for any of their projects, why is it right for any of ours?
    Well, this is not quite true any more. A reader informs me that the Sun Management Center, the ODS GUI, parts of Star Office, and other system configuration tools are now written in Java. Given that Star Office is supposed to run just about everywhere, I'm not too surprised at that one. Given that ODS is strictly a Solaris tool, I am a bit surprised at that one, but the old ODS GUI was so bad it seriously needed to be taken behind the barn and shot, and probably when the time came to do a new one, there was a management fiat to do it in Java. The reader informs me that the process of rewriting is going slowly and not producing terribly satisfactory results. Quelle surprise, eh?
  3. Java breaks OS standards. The way you have to invoke Java class files grossly violates long-accepted standards on Unix (I don't know about Windows). For example: 
    devweb02:~$ java HelloWorld.class 
Exception in thread "main" java.lang.NoClassDefFoundError: HelloWorld/class
devweb02:~$ java HelloWorld       
Hello World
    • It's confusing. The file is named HelloWorld.class, but you can't call it that.
    • As is usual for Java, the error message gives you no clue what might be wrong, unless you're already familiar with what you have to do.
    • It's extremely un-Unixy. Unix programs traditionally don't give a flying leap what they're called (with a very few notable exceptions). perl script.pl works, but so does perl Ekki-Ekki-Ekki-Ekki-PTANG if you happen to name your script that. If I rename bash to mash, it still works just fine. ("rbash" is one of the notable exceptions. It still works, it just works differently.) The fact that people familiar with Unix, working for a major Unix vendor, would create a language like this is mindboggling.

      Here's another stunning example of the poor integration of Java (with Solaris, anyway). 

      yoyodyne:~$ pwd
/export/home/jdweiner
yoyodyne:~$ java HelloWorld
Hello World
yoyodyne:~$ cd ..
yoyodyne:/export/home$ java jdweiner/HelloWorld 
Exception in thread "main" java.lang.NoClassDefFoundError: jdweiner/HelloWorld (wrong name: HelloWorld)

      This is jaw-droppingly braindamaged from a Unix POV. You actually aren't allowed to address the class file by its location in the filesystem! This shouldn't be surprising, given the fact that you aren't allowed to address it by its actual filename. I'd be curious to know how Java developers deal with this. It's normal to be able to rename myprogram to myprogram.old if you want to compile a new version of myprogram, and then still be able to invoke myprogram.old. But, of course, you can't do that with java. You can do this:

      panix2:~$ env CLASSPATH=~/myjavaprogs java HelloWorld

      but that doesn't help if you've renamed the file. It's painfully clear that Java did not begin its life in the Unix world, and simply got bolted on like a sidecar when Sun decided that it would be a nifty tool. To which they basically admit in http://java.sun.com/features/1998/05/birthday.html:

      Java technology was created as a programming tool in a small, closed-door project...[for] the convergence of digitally controlled consumer devices and computers.

      In the summer of 1992, they emerged with a working demo, an interactive, handheld home-entertainment device controller with an animated touchscreen user interface.

      ...says James Gosling. "We were pitching the cable companies on the idea that this is what your network should look like. It was interactive, and users could read and write information into the system. But the companies didn't want to lose that much control." It was too far ahead of its time, and the team, now numbering 70 people, was still searching for a target market.

      "After we realized that there wasn't a business in digital cable television, we had a group meeting at The Inn at Squaw Creek near Lake Tahoe. We had to figure out what to do with this technology, or what to do with our lives." There, over the course of three days, John Gage, James Gosling, Bill Joy, Patrick Naughton, Wayne Rosing, and Eric Schmidt had a group epiphany: why not the Internet?"

      The article goes on to explain that Java was, in fact, originally intended only for things like interactive web pages. At what point they decided an environment so closely tied to interactive TV and web page animations would be appropriate for general-purpose computing is never explained.

      Another telling quote, this time from http://www.wired.com/wired/archive/3.12/java.saga.html :

      In April 1991, the team moved from Sun's main campus to office space above a branch of the Bank of America on Menlo Park's Sand Hill Road, cutting itself off from Sun's internal computer network. The programmers disconnected culturally as well. ''We thought if we stayed over there, we would end up with just another workstation,'' Sheridan says. "I was obnoxious about keeping it secret.''

      I.e., "we threw out all the existing standards and then expected everybody to change to do things our way."

jEdit - Open Source programmer's text editor  -- A project of Slava Pestov. Functionality of this free editor is just amazing. Supports folding (both indent and 'marker' based). Of course it suffers from typical Java problems but I think that Java programmers should eat thier own dog food ;-). Anyway true multiplatform GIU editor with folding.  And its free.

At http://community.jedit.org, you can find articles on jEdit, macros written by users, beta versions of plugins, and more.

http--www.doctorj.org DoctorJ analyzes Java code, in the following functional areas:

Documentation Verification. Beyond the level of what Javadoc does, DoctorJ compares documentation against code. Among what it detects:

Statistics Generation. Outputs the following statistics:

Syntax Analysis. (In development.) Inspired by lint, currently finds:

DoctorJ was written to be extremely fast. Running under Linux on a 1.4 Xeon with 1GB of RAM, it processes a project consisting of 63,577 lines of code in under 4 seconds.

This application is written in POSIX-compliant C++, Lex, and Yacc, and consists of approximately 82,000 lines of code.

Through the addition of error and warning levels, filtering is now supported. Thus, this application can be tailored for specific checks and preferences.

jregex.sourceforge The JRegex is compact and efficient regular expression library for Java.

It provides support for full perl5.6 regex syntax and is compliant with unicode.org's regex guidelines.
Besides that, jregex supports named groups (existing in Python regexes but neither in perl nor in other java libs), and incomplete matching, which is hardly found elsewhere.
Fast string search algorithms also are on the schedule. Perl5.6 regex syntax, including lookahead/lookbehind assertions.

How JRegex compares to other regex libs JRegex vs. java.util.regex

The schedule outline

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

 You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019