Or if I have an old module containing lots of sources, I might find that many are incompatible with Java 'n'.
I could then compile the whole module with -source 'n-1'. Great. Now I need to leverage Java 'n' features elsewhere in the module. Ooops -- I can't until I clean up all the old sources or rework my build process! Instead I should be able to keep building the module with -source 'n-1' and either (1) denote all the problem sources as having source 'n-1' in the sources or (2) denote new sources as using source 'n' -- most likely (2) in this case. As people get used to declaring the intended source level of Java code, they could then stop using the pesky -source and just denote newer sources as source 'n' without hassle. This would be allow a seamless transition to new language features with the intended source level closely linked to and version controlled with the source -- that would be infinitely better than the -source switch. Incompatible API changes are another matter. Sun works hard on this for the most part, but in certain areas, e.g. JDBC interfaces, they really fall down. Possible solutions are quite clear, but they are also quite unrelated to a source keyword. Currently, compiling with Java 6 while using Java 5's core libraries is a royal pain. Sun should stop the sort of API evolution that necessitates this (e.g. growing existing interfaces). On the other hand, there are times where you really want to compile with Java 5 libraries just to ensure you don't use anything that's new to Java 6. For such cases, there really should be a simple way to declare that your module depends on the Java n-1 core rather than the Java n core, for instance, in your module... -- Jess Holle Reinier Zwitserloot wrote: > Alex, 'source' simply acknowledges that java (the language) syntax and > java (the runtime library) dependencies are utterly unrelated things. > Why MUST they track each other? In practice that already doesn't > happen: Code compiled on javac6 is routinely run on jvm5, and vice > versa. javac has -source and -target parameters for a reason. > > I should be able to write code with javac6 features (fine, there > really weren't any, but let's imagine there were), and define in my > module that I'm actually dependent on the java5 core runtime > libraries. The compiler should compile against those libraries and > warn if e.g. I use stuff that only showed in v1.6, but it should > compile my usage of new features without complaint. Unless, of course > a feature itself simply isn't expressable in the earlier version's > bytecode. > > On Sep 18, 1:40 am, Alex Buckley <[email protected]> wrote: > >> On Sep 17, 5:38 am, Jess Holle <[email protected]> wrote: >> >> >>> Joe Darcy recently cited discussion threads in which the source >>> statement was supposedly found to be problematic. >>> >>> I perused them -- and didn't see any substantive problems uncovered in >>> the course of those discussions. >>> >>> Personally I think a source statement would be a good thing. Otherwise >>> if you have a large set of sources in a module you have to go through >>> all sorts of shenanigans to compile some stuff with -source x and others >>> with -source y. This configuration is unnecessarily complex and is >>> fragile -- since the information is separate from the source files. >>> >> A 'source' keyword is a terrible idea because it does not sufficiently >> model the kinds of compatibility needed in practice. That is properly >> the job of versioning in a module system. >> >> The bigger issue regarding Java language changes is that Sun is >> expected to listen to thousands of ideas per year *and give detailed >> responses as to how those ideas could be made workable*. >> >> Alex >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
